Voting is irrelevant.
Reasoned arguments are what counts in software design.
e.g. It only takes one person to give one example that
shows that something is fundamentally flawed
despite everybody else voting for it. :-)
For example, the problem with your "everything in server/lib"
would be that it is very difficult for somebody to have
different jboss configurations in the same installation
for developing different versions of their applications.
i.e. where the shared jars need to change version
I agree with it for our jars since there's no reason
for two different versions of the shared jboss jars
in the same jboss installation.
Versioning is something that the "OBR" solution would cover
when it is completed and would remove my criticism.
On Tue, 2008-11-04 at 17:43 +0200, Aleksandar Kostadinov wrote:
If that matters here is my vote:
"libs in server/lib and reference them explicitly"
This way all servers will be consistent. And there will be low overhead
for adding configurations.
If possible use some dir outside servers.
Regards
Dimitris Andreadis wrote, On 11/04/2008 04:26 PM (EEST):
> 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(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
> _______________________________________________
> 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 --
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx