tbee at tbee.org
Tue Dec 13 04:42:38 PST 2011
> I've used java.net and also not used it. The maven support in java.net is actually just a direct throw over to sonatype and any questions you have get directed to the sonatype guys anyway. I say cut out the middle man. I have the email address for the support guy at sonatype who's been helpful for me in the past. It was the same guy when I did it through java.net as when I did it through google code. I'll fire an opening email to get some info on what they will let us do and the best way to do it if you want (I'll cc you in)?
> I think we could just set up a pom that does the release of the jars and natives off a local install directory. Unless I'm missing something it should be relatively straight forward to get it into the snapshots area at least. I can't remember if you have to promote it through the sonatypr GUI or whether you can command line this. Either way I dont remember it being overly painful?
Initial release must be promoted through the UI, MigLayout now has its second release "new style" and it seems to have gone into oblivia. Mikael (who attempted this release) currently is trying to figure out where it went.
> As above, I reckon we sort it out with sonatype directly. Then we just need a login with permission. I think we can either share the login or have sonatype add remove user accounts to our artifacts. We'll ask them what's best/normal.
Separate Nexus users work fine.
> Ok, great. Your prelauncher should be perfect as a separate dependency then. I'd personally say keep it in jfxtras as it's own artifact. Co-bundling jfx+java will change the game completely (I'm not sure we will even be able to choose jfx versions when this happens!). Keeping it separate keeps us more open for future changes. I think it is a moving target at this stage.
Which reminds me... TODO: releasing JFXtras to a Maven repo.
> Cool. Thinking about it, it should just be a case of setting up a pom to deploy the jars/natives built by the ant scripts. Then one of us just run the ant build and a mvn deploy once a week. We have to sort the pgp key issue but I'm sure we can work something out.
Should not be a biggie indeed. If we make it really really simple to release to a Maven repo, maybe the Oracle guys are willing to add it to their release cycle. (Did I just use "easy" and "Maven" in one sentense? That's new.)
> I like openjdk as a group. It should probably be 'net.java.openjdk' though. I wonder if we need to ask the bigger openjdk community about this? It is very weird that jfx is part of the jdk AND also a maven artifact. Only one of those things make sense. When cobundling happens it's all going to get strange.
> I wonder if the other group shouldn't then be com.oracle.javafx?
> Actually just thinking about this, once jfx is fully open sourced, we should only really maintain the openjdk one. If oracle don't want to maintain their jar in the repo there's no reason for us to do it for them really. People will just use the openjfx one then which is what we'd probably want anyway.
I'd only go for releasing the openjdk version.
There is this tendency to strip the prefixes from the groups. Personally I prefer with prefix (reversed internet domain name) because of more change of it being unique.
More information about the openjfx-dev