On Wed, Aug 10, 2011 at 4:40 PM, Mitesh Meswani
<mitesh.meswani_at_oracle.com>wrote:
> While I understand that the version of Hibernate is out-of-date in update
> center and needs to be updated, I am not able to totally grasp what is being
> proposed as the solution here. Are you proposing that GlassFish update
> center will have multiple versions of Hibernate and user can chose the
> version that he wants to use with his application using the mechanism
> described above?
>
No, although that doesn't sound so bad. :-)
I'm proposing a hibernate add-on package that is easy to maintain so that we
don't go years in between upgrades. I'm also proposing that the current
Hibernate support be constructed and packaged in such a way that it can be
used when applications want it, and not part of the running classpath when
applications don't want it. I was informed that --libraries was the best
way to accomplish this.
I was also told that Update Center is a great way for delivering packages to
end users without any hunting, and for upgrading those packages when called
for.
Lastly, I was told that IPS packages should not attempt to install inside
domains/domain1 (or any other "user space" areas), which makes all kinds of
sense.
The net result was that I was proposing:
- A Hibernate package consisting of an empty jar with a MANIFEST.MF file
with a Class-Path: in it pointing at jar files in a well-known sibling
directory
- Locating this package in some off-to-the-side directory under, say,
domains. Something like domains/applibs.
- asadmin deploy be updated to resolve relative file names both from
within a domain's applibs directory (as it does today) and from some
domain-independent directory somewhere (like, say, domains/applibs, or
simply $GLASSFISH_HOME/applibs--doesn't matter to me).
The goal behind including Hibernate in update center is to provide
> "out-of-the-box-ease-of-use".
>
Understood. If I'm reading the "please allow Hibernate to be used in
Glassfish" history properly from all over the web, the current Update Center
Hibernate package doesn't even work entirely properly (though I confess it
works OK for our company). Dumping Hibernate in the main lib directory
doesn't either. Nor, apparently, does simply packaging Hibernate in your
application. I'm looking for an easy-to-use out of the box solution to this
problem.
> I would vote for documenting the mechanism above in general for any
> external library that can be used with GlassFish and not implementing it as
> part of update center for a specific external library.
>
As arcane as I find the update center and IPS, I would vote for keeping it
as the distribution mechanism for interesting third-party libraries that
thousands of developers need on a daily basis, or popular alternative
implementations of standards. For other company-specific stuff, or odd bits
that are better packaged with your own application, I obviously wouldn't
condone such things.
Best,
Laird