New release on maven central?

[Tomas-Kraus]

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?

[Tomas-Kraus]

• Issue Imported From: https://github.com/javaee/metro-fi/issues/39
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @glassfishrobot
• Original Issue Closed By:@glassfishrobot

[Tomas-Kraus]

@glassfishrobot Commented Reported by bimargulies

[Tomas-Kraus]

@glassfishrobot Commented oleksiys said: Hi,

the latest release is 1.2.9. We've recently changed the maven repository [1], the artifacts are available there.

WBR.

[1] http://fi.java.net/how-to-use.html

[Tomas-Kraus]

@glassfishrobot Commented bimargulies said: Gee, hmm, do you plan to arrange for these to push to central? A lot of people won't touch the java.net repo, and it's considered bad form to put a custom in a POM.

[Tomas-Kraus]

@glassfishrobot Commented bimargulies said: The version used in japex is not 1.2.9. It needs public access to a bunch of fields in DecoderStateTables that are not public in 1.2.9. They are public in the current FI trunk.

[Tomas-Kraus]

@glassfishrobot Commented oleksiys said: hmm, which version is used in japex? By saying japex tree, you mean project japex.java.net?

[Tomas-Kraus]

@glassfishrobot Commented bimargulies said: yes.

[Tomas-Kraus]

@glassfishrobot Commented bimargulies said: I don't suppose you sit near Sergio

[Tomas-Kraus]

@glassfishrobot Commented oleksiys said: you mean Santiago, guy who's doing japex? no

I'm really not sure, which FI trunk you mean, cause after recent migration and changes [1], the 1.2.x branch was moved to trunk. If you refer former CVS repository trunk, then you probably mean FI 1.1.x branch?

WBR.

[1] http://blogs.sun.com/oleksiys/entry/fastinfoset_1_2_9_has

[Tomas-Kraus]

@glassfishrobot Commented bimargulies said: 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.

[Tomas-Kraus]

@glassfishrobot Commented bimargulies said: 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.

[Tomas-Kraus]

@glassfishrobot Commented tsaloranta said: 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.

[Tomas-Kraus]

@glassfishrobot Commented bimargulies said: 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.

[Tomas-Kraus]

@glassfishrobot Commented oleksiys said: thanks a lot!

[Tomas-Kraus]

@glassfishrobot Commented This issue was imported from java.net JIRA FI-39

[Tomas-Kraus]

@glassfishrobot Commented Marked as fixed on Sunday, February 13th 2011, 8:19:42 pm