[jboss-dev] new shared JBOSS_HOME/server/lib directory

[Adrian Brock]

On Tue, 2008-11-04 at 11:40 -0500, Stan Silvert wrote:
> Why not use the Maven repo?  Then the initial download becomes really 
> small and dependencies are just loaded from the local repository.
> 

That is the future solution. Which is why I quoted "OBR"
in an earlier post. It really just means loading the jars
"on demand" from some a versioned source.

The actual source of the jars doesn't matter, all we should require
is a versioned repository (or list/hierarchy of them).

It then becomes possible to have a jboss distribution that
includes a local repository of jars or a smaller one
with minimal code that allows you to get them from
where ever you want.

The problem at the moment is not that we don't know how to
do this, the problem is that none of our services specify
what jars they actually need (not even the name, let alone the
version :-).

> Dimitris Andreadis wrote:
> > JBOSS_HOME/lib is our bootstrap directory so we wouldn't add shared 
> > libs there. And any new directory we introduce will break scripts anyway.
> >
> > The only point of discussion is whether to put all libs in server/lib 
> > and reference them explicitly, or put only the shared ones and 
> > reference them implicitly.
> >
> > The down side for referencing explicitly the chosen libs is that it is 
> > harder to maintain, since whenever a lib is added you'd have to update 
> > all affected configurations.
> >
> > The up side is that you have a single lib dir for server libs.
> >
> > Aleksandar Kostadinov wrote:
> >> I'm not the best one to give opinion on that but here it is.
> >>
> >> The change will complicate things and confuse users. As well doesn't 
> >> seem scalable to me. When we have more server configurations, we'll 
> >> need more lib directories (platforms more affected)... The change 
> >> could break user utilities that expect the old layout, etc.
> >>
> >> IMHO a straightforward approach will be to remove the 
> >> JBOSS_HOME/server/*/lib directories altogether and have all libraries 
> >> in JBOSS_HOME/lib or another directory. Then appropriate libraries 
> >> for every server configuration be selected in a configuration file 
> >> (conf/jboss-service.xml?).
> >>
> >> Best Regards,
> >> Aleksandar
> >>
> >> Dimitris Andreadis wrote, On 11/04/2008 12:38 PM (EEST):
> >>> The new JBOSS_HOME/server/lib directory pointed to at by the 
> >>> jboss.shared.lib.url property currently contains the libraries 
> >>> shared by the default and all configurations.
> >>>
> >>> So server/default/lib is now empty and server/all/lib contains only:
> >>>
> >>> avalon-framework.jar
> >>> hibernate-jbosscache2.jar
> >>> jacorb.jar
> >>> jbosscache-core.jar
> >>> jbosscache-pojo.jar
> >>> jgroups.jar
> >>>
> >>> The new directory is added to the classpath in conf/jboss-service.xml:
> >>>
> >>>    <classpath codebase="${jboss.server.lib.url}" archives="*"/>
> >>>    <classpath codebase="${jboss.shared.lib.url}" archives="*"/>
> >>>
> >>> The minimal config remains unchanged.
> >>>
> >>> https://jira.jboss.org/jira/browse/JBAS-6158
> >>>
> >>> You probably need to cleanup your build/output/** directory to pick 
> >>> up the change at your next svn update.
> >>> _______________________________________________
> >>> jboss-development mailing list
> >>> jboss-development at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/jboss-development
> >> _______________________________________________
> >> jboss-development mailing list
> >> jboss-development at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/jboss-development
> > _______________________________________________
> > jboss-development mailing list
> > jboss-development at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jboss-development
> 
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx