2.0.2

[Daniel Zwolenski]

On 13/12/2011, at 9:48 PM, Tom Eugelink <tbee at tbee.org> wrote:

> 
> 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.

Being on the run from the law could be fun for a while ;)

> 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.

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)?

> 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.)

Cool I reckon the guy I have the address for will be able to answer this. I think you're right that they will be ok with it.

> 
> 
>> 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.

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?

> 
> 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.
> 
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. 


> 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.

I guess we need a 'sealed envelope' somewhere for the pgp key. Bit of a tricky one since normally this would be in the protective custody of the owning company (ie oracle).

Based on email conversations I've had with the oracle guys, I think the official line is that oracle are leaving all maven stuff (including deployment) up to the community. I think this is largely due to a lack of maven users within their development team rather than any business or legal factor. 

Someone from oracle to confirm the official stance on maven deployment ownership please?


> 
> 
>> 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.)

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. 

> 
> 
>> 
>> 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).
> 

Nice 

> 
>> 
>> 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?

The ant-javafx.jar is not my code. It's the official code from oracle that contains the build/deploy tools (ie their packager and their ant tasks). I reckon this should be under the jfx group. 

My code is a maven plugin that provides a wrapper over this jar. You make a good point on that one, I will deploy it under a separate group as it is not official code (similar to your prelauncher in that sense). 


> 
>> 
>> 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.

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. 

> 
> 
>> 
>> 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?

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. 


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