geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <>
Subject Re: Shared Libs
Date Wed, 05 Apr 2006 20:41:28 GMT
Consider this:

I get my Geronimo environment set up perfectly -- security, database,
JMS, dependencies in the repo, etc.  I deploy the empty shell of the
application I want to develop (myapp-1.0.ear).

Now I tell the rest of my team: Install Geronimo, go into the console
Import/Export screen, enter the URL for my machine, click the link to
install myapp-1.0.ear.

Everyone who does that gets the empty application, database pool,
security realm, JMS resources, dependencies in the repo, etc. and can
immediately start development on the application.  Too bad it doesn't
check out the code for you too!  :)


On 4/5/06, Matt Hogstrom <> wrote:
> Aaron,
> For the use case of exporting the configuration how do you think folks would use that?
 At least
> based on my experience with WebSphere and the other AppServers I've often gotten questions
> people who after using teh big AppServers are torn between the incremental benefit of
going to the
> full product and leaving the simplicity of something like Tomcat.  I think the shared
lib will help
> to bridge that gap for many people.  And for those who use it, they probably won't be
> about exporting a configuration.
> Aaron Mulder wrote:
> > I'm not so keen on the shared libs, because then we don't know what
> > the dependencies are and it won't be easy to export a configuration
> > with all the necessary metadata.  It might be possible to include a
> > flag in the deployment plan saying "enable shared libs" and then if
> > that's set we can refuse to export the configuration or set a special
> > flag saying that the configuration has unknown dependencies.  But
> > needing to enable the shared libs would make them a little harder to
> > use.  I'm not sure what to think.
> >
> > Thanks,
> >     Aaron
> >
> > On 4/5/06, Dain Sundstrom <> wrote:
> >
> >>One new feature I'm working on for 1.1 is support for tomcat style
> >>shared libs.  This creates a shared class loader visible to all j2ee
> >>applications which contains shared/lib/*.jar and shared/classes/ to
> >>the class loader.
> >>
> >>Will this address your issues?
> >>
> >>-dain
> >>
> >>On Apr 4, 2006, at 7:35 PM, Joe Bohn wrote:
> >>
> >>
> >>>I have a situation where I need to make several web modules
> >>>dependent upon a large number of jars.  I'd like to add the jars to
> >>>the Geronimo repo and add the dependencies into the plans for the
> >>>web modules. However, most of the jars don't follow the maven
> >>>naming convention because the names don't include a version (and
> >>>I'd rather not rename all the jars).
> >>>
> >>>I know that there are changes being included in 1.1 to make the
> >>>version in a reference optional.  However, I doubt that it is
> >>>possible to reference a jar in the repo that doesn't contain any
> >>>version.  Just thought I should ask in case it really is possible.
> >>>I could see where this might be something users would like when
> >>>they have picked up jars from various places which may or may not
> >>>contain a version in the jar name.
> >>>
> >>>If it *is* possible to have a non-versioned jar in the repo ... how
> >>>do we differentiate in geronimo 1.1 between a dependency on a non-
> >>>versioned jar versus a dependency on the latest version of a jar
> >>>(in case both are present).
> >>>
> >>>Thanks for the help,
> >>>Joe
> >>>
> >>>--
> >>>Joe Bohn
> >>>joe.bohn at
> >>>
> >>>"He is no fool who gives what he cannot keep, to gain what he
> >>>cannot lose."   -- Jim Elliot
> >>
> >>
> >
> >
> >

View raw message