On Wed, Aug 10, 2011 at 5:42 PM, Mitesh Meswani
<mitesh.meswani_at_oracle.com>wrote:
> ...before we decide to give away the simplicity.
>
This just occurred to me: what if we do this?
1. Adopt a naming scheme for update-center-installed packages that are
non-Oracle, non-Glassfish-supplied. (Or better yet, add another directory
to the common
classloader<
http://download.oracle.com/docs/cd/E18930_01/html/821-2418/beadf.html#scrolltoc>,
but failing that a naming scheme would work.) The rationale here is: I
don't want to step on you; I don't want you stepping on me.
2. By convention, IPS packages like this Hibernate support install an
empty jar following this naming convention in $GLASSFISH_HOME/lib.
3. The empty jar has a MANIFEST.MF file in it with a Class-Path: in it
that has ../ as the prefix used by all elements in the Class-Path:.
4. Each element of the Class-Path: then points to another directory that
is a sibling of lib and which is under IPS control (i.e. I can kill it,
stomp on it, fill it up, whatever) and which is named exactly the same as
the equivalent .jar file.
So, for example:
$GLASSFISH_HOME/lib/IPS-com.whatever.foobar-hibernate-3.6.6.Final.jar (some
naming scheme; this is a pretty lousy example but I hope you get the idea.
:-) Make it hard for Oracle updates to crash into contributor updates.)
...is empty and has a MANIFEST.MF that contains (folding eliminated for
simplicity):
Class-Path: ../IPS-com.whatever.foobar-hibernate-3.6.6.Final/jar1.jar
../IPS-com.whatever.foobar-hibernate-3.6.6.Final/jar2.jar
...and then:
$GLASSFISH_HOME/IPS-com.whatever.foobar-hibernate-3.6.6.Final/jar1.jar
$GLASSFISH_HOME/IPS-com.whatever.foobar.hibernate-3.6.6.Final/jar2.jar
...etc....
...? So, briefly, follow Sahoo's idea of referring to a cluster of
dependencies via the MANIFEST.MF Class-Path, but eliminate the
--librariesoption. This would be equivalent to dumping everything in
$GLASSFISH_HOME/lib, but without the clutter or the "hmm, now which one of
these jars depends on which other of these jars" headaches that happen in
real-world situations.
It separates the real Glassfish stuff (whatever you/Oracle decide to put in
$GLASSFISH_HOME/lib, whenever you want) from the I'm-customizing-my-system
stuff (adding a Hibernate provider for all domains, or some other IPS update
from the contrib repository), but keeps the one-click simplicity you're
after.
It allows upgrades because ultimately you remove or add one .jar file in the
lib directory--it is in charge of pointing to its dependencies off to the
side, possibly with different permissions.
Am I missing anything important here?
Best,
Laird