Changes in Java packaging guidelines - RFC

[Nicolas Mailhot]

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.

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.

-- 
Nicolas Mailhot