10:35 a.m.
Adrian Brock wrote, On 11/04/2008 05:32 PM (EEST):
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. :-)
So you're saying the approach I suggest is *fundamentally* flawed? See
below why I don't agree. I just opt for a better temporary solution so
we don't have to deal with the current for a long time. If too hard then
I'm ok with that.
Let me summarize what I don't like in current server/lib approach and I
hope that to be my last mail.
1. repurposing servers directory (I think better would be
JBOSS_HOME/shared or something)
2. will possibly be hardly reusable for additional server configurations
(imagine if we want one less lib in the configuration) + leads again to
duplication of libs in the distribution (although much less).
3. one can't easily change a bundled library only in one configuration
for some test purposes (imagine security update testing)
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
Actually I just said (or wanted to say) that server/*/lib can be
deleted, not that it should. See my latter emails. I agree these should
stay to keep user libs if users want to use them. All arguments against
my suggestion I saw were against that small detail of removing server/*/lib.
Does that address your concern?
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.
So you're sold on the idea? :)
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