Changes in Java packaging guidelines - RFC

[Alexander Kurtakov]

> Le mercredi 03 novembre 2010 à 22:28 +0200, Ville Skyttä a écrit :
> > On Wednesday 03 November 2010, Nicolas Mailhot wrote:
> > > Le mercredi 03 novembre 2010 à 21:32 +0200, Ville Skyttä a écrit :
> > > > On Wednesday 03 November 2010, Nicolas Mailhot wrote:
> > > > > Le mercredi 03 novembre 2010 à 19:27 +0200, Ville Skyttä a écrit :
> > > > > > 3) In my opinion, the whole alternatives setup in the JRE and SDK
> > > > > > packages should be purged.  It's a relic from times that are long
> > > > > > gone,
> > > > > 
> > > > > Having a semi-sane way to install multi-vendor multi-version JVMs
> > > > > is still needed EPEL side. Expensive apps like SAP still make you
> > > > > install the specific JVM they've been qualified against.
> > > > 
> > > > But such JVMs do not need to be made the system default at all,
> > > > people can just run $expensive_app with it by whatever means they
> > > > like (e.g. direct modification of $PATH, $JAVA_HOME, etc _for that
> > > > specific app_).
> > > 
> > > When you pass a certain level of expensiveness, ISVs just assume the
> > > *only* jvm on the system will be the one they require (quite simply the
> > > software price is many times the price of hardware, so there is no
> > > reason to share the hardware with anything else).
> > 
> > Ok.  So again, for what do you need the alternatives stuff for in this
> > scenario?
> 
> You need it to keep the jvm packaging modular and not have to package
> the same jvm in multiple ways (jvm-as-system-default,
> jvm-as-secondary-jvm, jvm-a-for-mixing-with-jvm-b, etc). For practical
> purposes the "Enterprise" market is still stuck where JPackage was when
> we added alternatives (which, btw, I hate dearly).
> 
> And it's unreasonable to expect those ISVs to change when Fedora has not
> managed to package a working JBoss. If the Red Hat Java packaging can
> not even be used with the top Red Hat Java product, what is there to
> say? (and on this subject, I don't think Fedora Java can be dissociated
> from Red Hat java)
> 
> The main reason other project members went for the packaging changes I
> proposed in JPackage at the time (what people call the JPackage
> guidelines now) is that I got the then top floss java application,
> tomcat, to work with them (which was a beast to do alone before others
> joined the ship). I find it worrying that Java packaging changes are
> proposed now, but nobody seems to have taken the time to repackage a big
> demanding java app with the new guidelines as a reality check.

Most of these changes are nothing new but bringing guidelines closer to 
reality and removing some stuff that is causing nothing but confusion. And they 
have been verified during the recent Maven 2.2.1 update and the ongoing Maven 3 
work. Maven may not be as big as Tomcat if we speak in LOC but Maven is really 
changing the way Java packaging is done. 

Regards,
Alex

> 
> But those who do the work decide, that was true then and is true now,
> and I'm definitely not doing java packaging anymore. So feel free to
> ignore me.