Tom Eugelink tbee at tbee.org
Tue Dec 13 02:48:11 PST 2011

Owwwww, loads of questions.

Point #1: get confirmation. I'm not going to burn my fingers on any legal stuff and need someone from Oracle to tell me it's ok first.

On 13-12-2011 10:26, Daniel Zwolenski wrote:
> Are you going to manage the deployments then (definitely fine by me) and do you go via Sonatype or something else (actually I don't think you can use Sonatype unless it is fully open source - what's your plan)?

Well, java.net uses the same procedure as Sonatype, so I figured I'll run this one through them. See what happens.

> How does it work with the fact that you don't own the domain/group (I've only ever deployed stuff I've built) - will you need to get someone from Oracle to ok it, or do the Maven guys just not care?

No idea. Try and see what happens? I was allowed to release MigLayout even if I didn't own the project. (I've just went through the hoops for MigLayout 4.2, helping Mikael.)

> There's that whole PGP key generation stuff too, that has to be published. It would be good that if you end up not able/willing to do the deploy in the future that everything is setup for someone else (i.e. anyone on this list) to pick it up and do it too. Maybe we need a small open source project somewhere that is the pre-loader and PGP signatures (or whatever we need) , along with a simple wiki on how to do it? Or could something like that be part of this openjfx code base?

Well, ideally the build scripts should be modified. For since the change that that will happen during my life time seems slim, I'm now aiming for releasing what is part of the JavaFX SDK. That would be good enough I guess. The release process is not trivial. I probably will setup a VMWare that does it.

Naturally only people who have permission can release, so yes, we need more people that can do it. They would need to get permission to do so on java.net's Nexus.

Signing the jars is required by the process. The idea of signing is to get some kind of authentication and trust. Signing would be quite useless if anyone can get their hands on the (open sourced) private key, escpecially with the DLL's. So either everyone signs with a personal key, or we have to have some kind of secure handling of a shared private key. I'm not sure on this. Ideas? Also depends on the role Oracle would like to play in this.

> How do you add your pre-loader to it, do you rejar up jfxrt.jar with the extra code and dll's into a new jar or do something else? It would be great if there was a way to keep a 'pure' artifact that is the runtime jar exactly as it comes from JFX, and then just have the preloader as a separate artifact. Is this possible or does the preloader need to be in the same jar/artifact to work?

I only jar up the DLL's in a new jar. The original javafx jar is unaltered (and hopefully signed by Oracle... Checked. OMG, it is't signed???)

JFXtras currently has my prelaunch code that finds a certain DLL as a resource, and then extracts the whole JAR to a temp/version directory (if not already there). It then modifies java-library-path to include that path and JavaFX continues loading normally. This is the best I can do until the actual loading code is open sourced. Probably it would be wise to move the prelaunch over to openjfx. (Hopefully I'll have some time this afternoon. Swamped with work lately.)

> What's your thinking on per-platform native files: one artifact for all platforms with a jar that contains all natives and just extracts as appropriate, or a separate jar per platform?

I'd go for a separate jar per platform using the classifier. It makes for smaller downloads, no logic is needed in the prelaunch (just extract the jar).

> Can I also put in a request that we get the 'ant-javafx.jar' (from the 'tools' directory of the install) added to maven as a separate artifact as well.

Not sure if we should be releasing things that are not part of openjfx under the same group. So if your code is separate maybe release it separately? Until it is officially part of openfx?

> One other thought - can we also now be deploying these pre-alpha releases of the 2.1 code, maybe just to the snapshot directory (i.e. use at own risk)? If we can deploy regular (weekly?) snapshots of the openjfx 2.1 stuff it will make it real easy for developers to start testing it, and people on this forum (who like maven) will be able to easily create test apps and try out new features, ideas, etc.

I was planning to do so, yes. Need help of course.

> Oh, and will the openjfx be under a different a group/artifact to the Oracle one? I guess it would have to be.

Well, actually I think Oracle has some say in that. If they don't want to, how about group "openjfx" and artifact "javafx-rt"? Or anticipating the future: openjdk and javafx-rt?

> Can you tell I'm a little bit excited about having a clean build again :) It's like nerd christmas!

Yeah ;-)


More information about the openjfx-dev mailing list