Goal: Increased Modularity?

[Les Mikesell]

Nicolas Mailhot wrote:

>> OK, but how about the answer for the known universe of JVM's included in 
>>   the fedora/RHEL repositories plus the jpackage repository, including 
>> the ones that don't actually contain the JVM, but do determine the 
>> location where it will be installed?
> 
> For the FLOSS ones you can use yum tricks
> For the non-FLOSS ones you have to assemble them yourself starting from
> the non-free material @jpp, and you can check the paths at the same
> time.
> 
> A jpp-style repository does *not* maintain a central JVM list. That's
> how it was done before I wrote the "new" guidelines in 2003 and it was
> hell to maintain. In a jpp-style repository any jvm that drops
> directories in the right place may be used through alternatives, but the
> rest of the system need not care about the jvms that may or may not be
> packaged this way.

I could have sworn I ran into dependencies on specific JVM versions when 
trying to install some packages from the jpackage repo.  How can that be 
if you don't keep track of the JVMs themselves?  Or if the packages are 
supposed to be usable with unpackaged JVMs?

> If you want to bring back central lists from the dead you're welcome to
> try, but anyone who touched pre-1.5 jpp won't follow you. For more
> information, read jpackage-discuss archives around march 2003.

I don't particularly care how the files are managed or where they live. 
  I'm just trying to learn how to find what alternatives are available 
and how to access them when certain apps require different JVMs and you 
want to run them at the same time - and I haven't found much 
documentation on the topic.

-- 
   Les Mikesell
    lesmikesell at gmail.com