The primary motivation for the change at this point was to save space (17.7Mb) from the
distro because we need to add a new "standard" tck config. (Or change the
default to conform
to that).
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4182964
The only "confusing" thing for me is that directories under server have always
represented
configurations, but then again the name 'lib' should make it obvious.
Beyond that it doesn't look too bad and things should work as before and even the
testsuite
looks happy).
User scripts that copy files around to create custom configs would need to be updated,
sure.
As Adrian says, things will change again in a future release.
Adrian Brock wrote:
On Tue, 2008-11-04 at 14:47 +0200, 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,
Its more scalable than having N copies of the jars in the
distribution where N is the number of configurations. :-)
> we'll need
> more lib directories (platforms more affected)...
This is just a temporary solution until our deployments actually
specify what they use (classloading dependencies).
Once that is done we would only need one
repository/lib folder which would be loaded from as required
and the current server/[conf]/lib folder for people that
are too lazy to specify their dependencies. :-)
> The change could break
> user utilities that expect the old layout, etc.
Its JBoss5 so although change for change sake is not good,
something that has benefit (smaller distribution size)
is something that can change in a major release.
> 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?).
>
That makes a user's life harder. They have to modify the
configuration file to add shared jars (e.g. a jdbc driver)
whereas before they could just drop it in server/[conf]/lib
without further configuration steps.
I wouldn't have a problem with having all our jars
in the shared lib folder and explicitly list them
in jboss-service.xml according to what the configuration
uses.
i.e. server/all/lib would be empty but
server/all/conf/jboss-service.xml would list more jars
than server/default/lib
This would also mean that the minimal config is smaller,
nothin in server/minimal/lib
> 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(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/jboss-development
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/jboss-development