fi
  1. fi
  2. FI-39

New release on maven central?

    Details

    • Type: Task Task
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.2.9
    • Component/s: None
    • Labels:
      None

      Description

      The most recent published release of fastinfoset, 1.2.8, is not up to date with the version of the fastinfoset jar that is checked into the JAPEX tree.

      This is inconvenient for update japex to build with maven. Could we please have a release?

        Activity

        Hide
        bimargulies added a comment -

        Yes, I meant Santiago. My fingers got loose from my brains.

        I had an svn checkout of https://svn.java.net/svn/fi~svn/trunk that was up to date a couple of weeks ago. I compared the jar checked into japex with the source i had, and they matched. I thought.

        An example is DecoderStateTables.UTF8.

        However, I just did an 'up' and that field is private. So, Japex has captured, as far as I can tell, some intermediate state version of FIS from between 1.2.8 and 1.2.9, or a private version.

        The ONE, TWO, THREE, FOUR constants, which are also in there, are now package access.

        I can update Japex to use the public API for UTF8, and just have it's own constants for 1, 2, 3, and 4, and then it would work with 1.2.9.

        Show
        bimargulies added a comment - Yes, I meant Santiago. My fingers got loose from my brains. I had an svn checkout of https://svn.java.net/svn/fi~svn/trunk that was up to date a couple of weeks ago. I compared the jar checked into japex with the source i had, and they matched. I thought. An example is DecoderStateTables.UTF8. However, I just did an 'up' and that field is private. So, Japex has captured, as far as I can tell, some intermediate state version of FIS from between 1.2.8 and 1.2.9, or a private version. The ONE, TWO, THREE, FOUR constants, which are also in there, are now package access. I can update Japex to use the public API for UTF8, and just have it's own constants for 1, 2, 3, and 4, and then it would work with 1.2.9.
        Hide
        bimargulies added a comment -

        Sorry for all the noise, but one more note.

        The policy for maven central, as I understand it, forbids anything that goes there from having dependencies on things that are somewhere else.

        So, nothing that gets published to maven central can point to 1.2.9 until 1.2.9 goes to central.

        I would be more than happy to volunteer to do the work to push fi to central via the ossrh process (https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide). It would be helpful to be a 'developer' on FI so that I could claim with some validity that I'm authorized to push an official release of FI to central.

        Show
        bimargulies added a comment - Sorry for all the noise, but one more note. The policy for maven central, as I understand it, forbids anything that goes there from having dependencies on things that are somewhere else. So, nothing that gets published to maven central can point to 1.2.9 until 1.2.9 goes to central. I would be more than happy to volunteer to do the work to push fi to central via the ossrh process ( https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide ). It would be helpful to be a 'developer' on FI so that I could claim with some validity that I'm authorized to push an official release of FI to central.
        Hide
        tsaloranta added a comment -

        For what it's worth, I think central Maven repo stopped syncing with java.net Maven repo quite a while ago, due to there being cases where incorrect or invalid project definitions were published. That is, it was a perceived quality issue.
        I don't know if it might be possible to contact developers at maven.org to see if there was a way to enable some subset of projects to be auto-synced (or have some mechanism to at least publish specific versions of artifacts).

        Sonatype is a good route and I use it, so that would definitely work as well.

        Show
        tsaloranta added a comment - For what it's worth, I think central Maven repo stopped syncing with java.net Maven repo quite a while ago, due to there being cases where incorrect or invalid project definitions were published. That is, it was a perceived quality issue. I don't know if it might be possible to contact developers at maven.org to see if there was a way to enable some subset of projects to be auto-synced (or have some mechanism to at least publish specific versions of artifacts). Sonatype is a good route and I use it, so that would definitely work as well.
        Hide
        bimargulies added a comment -

        I've pushed 1.2.9 to central using the OSSRH third-party mechanism. I would be most grateful if you would add the description elements as described in another JIRA to make this easier next time, or even set up code signing so that I don't have to that.

        Show
        bimargulies added a comment - I've pushed 1.2.9 to central using the OSSRH third-party mechanism. I would be most grateful if you would add the description elements as described in another JIRA to make this easier next time, or even set up code signing so that I don't have to that .
        Hide
        oleksiys added a comment -

        thanks a lot!

        Show
        oleksiys added a comment - thanks a lot!

          People

          • Assignee:
            Unassigned
            Reporter:
            bimargulies
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: