Goal: Increased Modularity?

[Les Mikesell]

Nicolas Mailhot wrote:

>>>>> I want to know the correct JAVA_HOME and PATH settings for all the 
>>>>> possible JVMs when they are installed as alternatives-conforming RPM 
>>>>> packages but are not the system default.  Is this documented somewhere?
>> So, where do I find the answer to the question above regarding the 
>> correct JAVA_HOME and PATH to use a JVM that is not the system default?
> 
> If the question is "what is the list of the roots of all the possible
> JVMs that may be released for Linux and packaged using jpp conventions"
> – no one has the answer because no one knows the JVM list in the first
> place.

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?

> Given the vendor name, java standard version, build number etc
> one can make an educated guess because people tend to use the same
> template but there is no absolute naming requirement. The packager must
> choose a unique directory name and it must be under %{libdir}/jvm that's
> about it.


> If the question is "how does a particular jpp-packaged app choose its
> JVM" the answer is it follows the JAVA_HOME env var, and which can be
> set:
> 1. in the user environment
> 2. in app-specific conf file
> 3. in user-level conf file
> 4. in system-level conf file
> 4. or falling all that trying pre-defined fallbacks (meaning java apps
> require java or java-devel, if a java package is installed
> %{libdir}/jvm/jre must exist and if a java-devel package is installed
> ditto for %{libdir}/jvm/java
> 
> It's the responsability of the admin or user that overrides JAVA_HOME
> instead of letting the scripts fallback to the defaults to make sure
> JAVA_HOME is set properly (ie if you set it as something stupid things
> will go boom)

No, I wouldn't limit a question like that to just packaged apps.  The 
main issue is whether everything expected to be under JAVA_HOME is still 
in the correct relative position with all the matching binaries in 
$JAVA_HOME/bin.

>> How is the split exports/private directory supposed to relate to that?
> 
> Read the documentation bundled with jpackage-utils

$ rpm -q jpackage-utils
jpackage-utils-1.7.3-1jpp.3.fc6
$ man jpackage-utils
No manual entry for jpackage-utils

Does jpackage have its own convention about what to do with 
documentation as well?

>>> Fedora Java packaging as it's known today is a JPackage fork
>>> (periodically rebased). The Red Hat Java group originally started from
>>> its own package repository IIRC, but struggled to package the Java world
>>> and decided later to use a JPackage base as its repo was more complete.
>> And what's the current situation with this now that Fedora and RHEL5 
>> include some stuff that looks jpackage'd but isn't?   How do you 
>> control, for example, which tomcat version you install?
> 
> How do you control the installed apache version ?

I didn't know anyone offered more than one.

> You get the one the
> Fedora maintainer selected. Same for Tomcat. You get the one Fedora
> selected if you source Fedora, and you get the one JPP selected if you
> source JPP. And the version will change from Fedora release to Fedora
> release, and JPP release to JPP release.

What if you source both fedora and jpackage repositories?  Is that not a 
reasonable thing to do?  Or you need both tomcat4 and 5 installed on the 
same machine?

> If you're not happy with the choices you can contribute another
> parallel-installable tomcat to Fedora or JPP, they're both projects open
> to external contributions. 

I did not have any problem installing both tomcat4 and tomcat55 from the 
jpackage repo before fedora/RHEL incorporated parts that don't seem to 
play well with others.

> But speaking as a former Tomcat packager –
> it's a beast with tentacular dependencies, so you better allocate a lot
> of packaging time.

That's precisely the sort of thing that you want someone else to get 
right in the repositories.  I can do the easy stuff myself...

> If you have more java packaging questions I suggest posting on
> jpackage-discuss, and not be offended if the answer is long in coming —
> the project is ressource-starved.

No, I'm more interested in the relationship between the embedded 
jpackage-looking stuff in fedora/RHEL5 and whether it is intended to 
break access to jpackage.  Or if they are supposed to work together, how 
do you do it?

-- 
   Les Mikesell
    lesmikesell at gmail.com