geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <djen...@gluecode.com>
Subject Lets make recursive dependencies obvious rather than hidden. [was Re: Proposal to remove processing of geronimo-service.xml files in dependencies]
Date Mon, 27 Dec 2004 20:08:50 GMT
I think I am completely failing to communicate my concern.  Perhaps the 
problem is that the subject header is now completely misleading.

I agree 100% that the external dependency list, now called 
geronimo-service.xml, is a good idea and should be kept under some name 
and syntax, and that we should spiff up the maven stuff so it gets its 
dependency versions set during the build.  I don't care what we name 
it.

What I would like is that by looking at the top level plan containing 
gbean instance definitions, you can easily see whether a dependency is 
a plain jar or if it contains more information such as a 
geronimo-service.xml.  I suggested some syntax for this:

<dependency>
   <uri>foo/jars/foo-1.0.jar</uri>
   <pom>foo/poms/geronimo-service.xml</pom>
</dependency>

for external dependency lists or

<dependency>
   <uri>foo/jars/foo-1.0.jar</uri>
   <embedded-pom/>
</dependency>

Then, including just

<dependency>
   <uri>foo/jars/foo-1.0.jar</uri>
</dependency>
would result in an embedded dependency list being ignored.

Obviously, pom is the wrong name, but I haven't figured out a better 
one.

thanks
david jencks

On Dec 27, 2004, at 11:48 AM, Dain Sundstrom wrote:

> On Dec 27, 2004, at 11:31 AM, Jeremy Boynes wrote:
>
>> David Jencks wrote:
>>> After thinking about this some more I think the major issue is that 
>>> one cannot tell from the top level plan whether a dependency is a 
>>> plain jar or if it includes a 570-node tree of recursive 
>>> sub-dependencies.  Renaming and autogenerating the xml config file, 
>>> while good ideas, won't help with this problem.
>>
>> The 570 nodes are still there - it comes down to do you want the user 
>> to have to figure all that out by hand and explicitly put them in the 
>> plan, or do you want the deployer to figure it out as it is building 
>> the configuration.
>
> +1 As a user I frankly don't care what a module depends on, I just 
> want want it installed.  This is why wars contain a lib directory 
> (which has it's own sucky problems).
>
>
>> I don't want to do it by hand so would opt to have the deployer do 
>> it. Having a tool that told me what I needed put in the repo would be 
>> useful though.
>
> Maybe our deployment tool could have an info operation that dumps 
> "interesting" stuff about a module.  Of course determining what is 
> interesting maybe very difficult, and most likely requires asking the 
> deployer gbeans on the server :)
>
> -dain
>


Mime
View raw message