You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <da...@yahoo.com> on 2005/10/20 05:56:02 UTC

transitive dependencies

I've been working on building geronimo using the packaging and assembly 
plugins.  This works fine except for the unmanageable dependencies.   
The project for the assemby plugin to work on currently needs to 
include in the project.xml every jar to go into the assembly's 
repository.  Tracking these is impossible.

We need some way for a configuration or even a plain dependency to 
instruct the assembly plugin to copy the artifacts dependencies into 
the repository.

One possibility is to use maven poms.  IIUC Dain is working on 
integrating or imitating the latest maven repository management code.  
Will this give us transitive dependencies?  Will the maven model work 
for us?  How close is this?  If we had it, it would be pretty easy to 
construct separate jetty and tomcat assemblies, a both assembly, an 
assembly w/o ejbs, etc etc.  Without transitive dependencies, it will 
be a nightmare to try to keep the repository contents adequate and 
restricted to what is actually needed to run the server.

thanks
david jencks 


Re: transitive dependencies

Posted by David Jencks <da...@yahoo.com>.
On Oct 19, 2005, at 11:20 PM, Gianny Damour wrote:

> On 20/10/2005 3:08 PM, David Blevins wrote:
>
>> On Oct 19, 2005, at 9:23 PM, Gianny Damour wrote:
>>
>>> On 20/10/2005 1:56 PM, David Jencks wrote:
>>>
>>>
>>>> I've been working on building geronimo using the packaging and  
>>>> assembly plugins.  This works fine except for the unmanageable  
>>>> dependencies.   The project for the assemby plugin to work on  
>>>> currently needs to include in the project.xml every jar to go into  
>>>> the assembly's repository.  Tracking these is impossible.
>>>>
>>>> We need some way for a configuration or even a plain dependency to  
>>>> instruct the assembly plugin to copy the artifacts dependencies  
>>>> into the repository.
>>>>
>>>> One possibility is to use maven poms.  IIUC Dain is working on  
>>>> integrating or imitating the latest maven repository management  
>>>> code.  Will this give us transitive dependencies?  Will the maven  
>>>> model work for us?  How close is this?  If we had it, it would be  
>>>> pretty easy to construct separate jetty and tomcat assemblies, a  
>>>> both assembly, an assembly w/o ejbs, etc etc.  Without transitive  
>>>> dependencies, it will be a nightmare to try to keep the repository  
>>>> contents adequate and restricted to what is actually needed to run  
>>>> the server.
>>>
>>>
>>> Another approach would be: for each plain dependency, we could  
>>> generate a META-INF/geronimo-service.xml file based on the POM  
>>> dependencies as part of a standard build. Transitive dependencies  
>>> would be achieved by walking down the dependencies defined by the  
>>> geronimo-service.xml file.
>>>
>>
>> That really wouldn't solve the transitive side of the problem.  I  
>> mean it would work as we maintain our poms to include our  
>> dependency's dependencies (and dependencies of those dependencies  
>> (and ...(N))), but expecting a completely flattened list of  
>> dependencies in a single file per configuration isn't really the  
>> definition of transitive.
>
> LOL. Hopefully, this is not the approach that I was trying to 
> explained. Our POMs stay "as is" (w/o the dependencies of dependencies 
> and this transitively). Upon build, we generate a geronimo-service 
> plan defining all the "direct" runtime dependencies identified by the 
> POM.
>
> Based on the resulting geronimo-service file, there would be two 
> approaches:
> 1. upon car packaging, runtime dependencies defined by the POM 
> dependencies are copied from the local maven repo to the car. Upon 
> assembly, the runtime dependencies defined by the car module are 
> copied to the repository; or

That's what "include" does, except the dependencies stay in the car.  I 
don't think this is a good idea generally, it sort of defeats the 
purpose of the maven repo.
> 2. upon assembly, the runtime dependencies are read from the car and 
> copied from the local maven repo to the repository.
This is what I would like.

>
> Thanks,
> Gianny
>
>>
>> Just being a stickler :)
>>
>> We already generate part of the geronimo-service.xml files at build- 
>> time, we might as well go all the way.

??? where is a geronimo-service.xml file generated today? do you mean 
the version substitution?

thanks
david jencks

>>
>> -David
>>
>>
>
>


Re: transitive dependencies

Posted by Gianny Damour <gi...@optusnet.com.au>.
On 20/10/2005 3:08 PM, David Blevins wrote:

> On Oct 19, 2005, at 9:23 PM, Gianny Damour wrote:
>
>> On 20/10/2005 1:56 PM, David Jencks wrote:
>>
>>
>>> I've been working on building geronimo using the packaging and  
>>> assembly plugins.  This works fine except for the unmanageable  
>>> dependencies.   The project for the assemby plugin to work on  
>>> currently needs to include in the project.xml every jar to go into  
>>> the assembly's repository.  Tracking these is impossible.
>>>
>>> We need some way for a configuration or even a plain dependency to  
>>> instruct the assembly plugin to copy the artifacts dependencies  
>>> into the repository.
>>>
>>> One possibility is to use maven poms.  IIUC Dain is working on  
>>> integrating or imitating the latest maven repository management  
>>> code.  Will this give us transitive dependencies?  Will the maven  
>>> model work for us?  How close is this?  If we had it, it would be  
>>> pretty easy to construct separate jetty and tomcat assemblies, a  
>>> both assembly, an assembly w/o ejbs, etc etc.  Without transitive  
>>> dependencies, it will be a nightmare to try to keep the repository  
>>> contents adequate and restricted to what is actually needed to run  
>>> the server.
>>
>>
>> Another approach would be: for each plain dependency, we could  
>> generate a META-INF/geronimo-service.xml file based on the POM  
>> dependencies as part of a standard build. Transitive dependencies  
>> would be achieved by walking down the dependencies defined by the  
>> geronimo-service.xml file.
>>
>
> That really wouldn't solve the transitive side of the problem.  I  
> mean it would work as we maintain our poms to include our  
> dependency's dependencies (and dependencies of those dependencies  
> (and ...(N))), but expecting a completely flattened list of  
> dependencies in a single file per configuration isn't really the  
> definition of transitive.

LOL. Hopefully, this is not the approach that I was trying to explained. 
Our POMs stay "as is" (w/o the dependencies of dependencies and this 
transitively). Upon build, we generate a geronimo-service plan defining 
all the "direct" runtime dependencies identified by the POM.

Based on the resulting geronimo-service file, there would be two approaches:
1. upon car packaging, runtime dependencies defined by the POM 
dependencies are copied from the local maven repo to the car. Upon 
assembly, the runtime dependencies defined by the car module are copied 
to the repository; or
2. upon assembly, the runtime dependencies are read from the car and 
copied from the local maven repo to the repository.

Thanks,
Gianny

>
> Just being a stickler :)
>
> We already generate part of the geronimo-service.xml files at build- 
> time, we might as well go all the way.
>
> -David
>
>



Re: transitive dependencies

Posted by David Blevins <da...@visi.com>.
On Oct 19, 2005, at 9:23 PM, Gianny Damour wrote:

> On 20/10/2005 1:56 PM, David Jencks wrote:
>
>
>> I've been working on building geronimo using the packaging and  
>> assembly plugins.  This works fine except for the unmanageable  
>> dependencies.   The project for the assemby plugin to work on  
>> currently needs to include in the project.xml every jar to go into  
>> the assembly's repository.  Tracking these is impossible.
>>
>> We need some way for a configuration or even a plain dependency to  
>> instruct the assembly plugin to copy the artifacts dependencies  
>> into the repository.
>>
>> One possibility is to use maven poms.  IIUC Dain is working on  
>> integrating or imitating the latest maven repository management  
>> code.  Will this give us transitive dependencies?  Will the maven  
>> model work for us?  How close is this?  If we had it, it would be  
>> pretty easy to construct separate jetty and tomcat assemblies, a  
>> both assembly, an assembly w/o ejbs, etc etc.  Without transitive  
>> dependencies, it will be a nightmare to try to keep the repository  
>> contents adequate and restricted to what is actually needed to run  
>> the server.
>
> Another approach would be: for each plain dependency, we could  
> generate a META-INF/geronimo-service.xml file based on the POM  
> dependencies as part of a standard build. Transitive dependencies  
> would be achieved by walking down the dependencies defined by the  
> geronimo-service.xml file.
>

That really wouldn't solve the transitive side of the problem.  I  
mean it would work as we maintain our poms to include our  
dependency's dependencies (and dependencies of those dependencies  
(and ...(N))), but expecting a completely flattened list of  
dependencies in a single file per configuration isn't really the  
definition of transitive.

Just being a stickler :)

We already generate part of the geronimo-service.xml files at build- 
time, we might as well go all the way.

-David

Re: transitive dependencies

Posted by Gianny Damour <gi...@optusnet.com.au>.
On 20/10/2005 4:13 PM, David Jencks wrote:

>
> On Oct 19, 2005, at 11:03 PM, Gianny Damour wrote:
>
>> On 20/10/2005 2:58 PM, David Jencks wrote:
>>
>>>
>>> On Oct 19, 2005, at 9:57 PM, Gianny Damour wrote:
>>>
>>>> You may be right. Having said that, this XML parsing is done each  
>>>> time that a dependency is declared by a configuration. I see this  
>>>> approach as more self-contained than a solution based on the build  
>>>> system. Indeed, this approach allows to declare the runtime  
>>>> dependencies of a dependency, which is rather handy.
>>>
>>>
>>>
>>> Could you explain what you mean by this?
>>
>>
>> I think that this is better explained with an example:
>> Based on the META-INF/geronimo-service.xml file of the 
>> geronimo-tomcat  dependency, I know that 4 runtime dependencies are 
>> required. As a  user, it is clear that I need these 4 dependencies in 
>> my repository to  be able to use geronimo-tomcat. Without this file, 
>> I do not know that.  Based on the geronimo-tomcat POM, a user is able 
>> to derive the compile  time dependencies; yet it is not clear that 
>> tomcat-coyote needs to be  there at runtime.
>
>
> Ah, I see.  thanks.
>
>>
>> I think that this is more handy as it is then trivial to write a  
>> tomcat plan: I add the tomcat-plan dependency; define my GBeans; and  
>> add to my repo the geronimo-service.xml runtime dependencies. With 
>> the  current approach, I would need to add to my custom plan all the  
>> dependencies defined by j2ee-tomcat-plan (do I need all of them?).
>
>
> Now I'm confused again.  Right now, the dependencies in  
> modules/tomcat/src/etc/META-INF/geronimo-service.xml become  
> dependencies of any configuration that uses  
> geronimo-tomcat-${geronimo_version}.jar as a dependency.   
> Unfortunately, they are a shortened version of the dependencies for  
> jetty and don't include the 1001 tomcat jars that are needed to run  
> tomcat :-)  So, if we edited all the geronimo-service.xml files and  
> added them where missing would that do what you describe?

Yes. Also, if they could be used upon assembly that would be exactly 
what I was describing.

Thanks,
Gianny

>
> thanks
> david jencks
>
>>
>>>>
>>>> Also, I think that it is also a pain to declare the transitive  
>>>> dependencies in a configuration. I would prefer to simply define 
>>>> the  top level dependencies, e.g. the ones defining the declared 
>>>> GBeans,  and let them define the other dependencies.
>>>
>>>
>>>
>>> That is certainly a goal I like :-).
>>>
>>> I like the idea of constructing the geronimo-service.xml's from the  
>>> project.xml.  That would eliminate one source of duplication.  And,  
>>> we could open up the configurations and possibly jars included  
>>> explicitly in an assembly and extract the dependencies and install  
>>> them into the geronimo repo providing they are available.  However,  
>>> unless maven is also keeping track of the transitive dependencies  
>>> somehow, such as through poms, I don't see how maven will be able 
>>> to  guarantee that all the dependencies needed for an assembly are  
>>> actually present in the local maven repo, so we can copy them.  Any  
>>> ideas?
>>
>>
>> I see the problem now: all the dependencies need to be in the local  
>> maven repo and it seems that only Maven will be able to do that.
>>
>> Thanks,
>> Gianny
>>
>>>
>>> thanks,
>>> david jencks
>>>
>>>>
>>>> Thanks,
>>>> Gianny
>>>>
>>>> On 20/10/2005 2:40 PM, Bruce Snyder wrote:
>>>>
>>>>> On 10/19/05, Gianny Damour <gi...@optusnet.com.au> wrote:
>>>>>
>>>>>> Another approach would be: for each plain dependency, we could  
>>>>>> generate
>>>>>> a META-INF/geronimo-service.xml file based on the POM 
>>>>>> dependencies  as
>>>>>> part of a standard build. Transitive dependencies would be  
>>>>>> achieved by
>>>>>> walking down the dependencies defined by the 
>>>>>> geronimo-service.xml  file.
>>>>>>
>>>>>
>>>>> I'm not shooting down anything, but that sounds like a lot of extra
>>>>> XML parsing. I'm curious to hear Dain chime in here to describe
>>>>> exactly what he's doing with the Maven repo management code.
>>>>>
>>>>> Bruce
>>>>> --  perl -e 'print  
>>>>> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC; VT*"
>>>>> );'
>>>>>
>>>>> The Castor Project
>>>>> http://www.castor.org/
>>>>>
>>>>> Apache Geronimo
>>>>> http://geronimo.apache.org/
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>



Re: transitive dependencies

Posted by David Jencks <da...@yahoo.com>.
On Oct 19, 2005, at 11:03 PM, Gianny Damour wrote:

> On 20/10/2005 2:58 PM, David Jencks wrote:
>
>>
>> On Oct 19, 2005, at 9:57 PM, Gianny Damour wrote:
>>
>>> You may be right. Having said that, this XML parsing is done each  
>>> time that a dependency is declared by a configuration. I see this  
>>> approach as more self-contained than a solution based on the build  
>>> system. Indeed, this approach allows to declare the runtime  
>>> dependencies of a dependency, which is rather handy.
>>
>>
>> Could you explain what you mean by this?
>
> I think that this is better explained with an example:
> Based on the META-INF/geronimo-service.xml file of the geronimo-tomcat  
> dependency, I know that 4 runtime dependencies are required. As a  
> user, it is clear that I need these 4 dependencies in my repository to  
> be able to use geronimo-tomcat. Without this file, I do not know that.  
> Based on the geronimo-tomcat POM, a user is able to derive the compile  
> time dependencies; yet it is not clear that tomcat-coyote needs to be  
> there at runtime.

Ah, I see.  thanks.
>
> I think that this is more handy as it is then trivial to write a  
> tomcat plan: I add the tomcat-plan dependency; define my GBeans; and  
> add to my repo the geronimo-service.xml runtime dependencies. With the  
> current approach, I would need to add to my custom plan all the  
> dependencies defined by j2ee-tomcat-plan (do I need all of them?).

Now I'm confused again.  Right now, the dependencies in  
modules/tomcat/src/etc/META-INF/geronimo-service.xml become  
dependencies of any configuration that uses  
geronimo-tomcat-${geronimo_version}.jar as a dependency.   
Unfortunately, they are a shortened version of the dependencies for  
jetty and don't include the 1001 tomcat jars that are needed to run  
tomcat :-)  So, if we edited all the geronimo-service.xml files and  
added them where missing would that do what you describe?

thanks
david jencks

>
>>>
>>> Also, I think that it is also a pain to declare the transitive  
>>> dependencies in a configuration. I would prefer to simply define the  
>>> top level dependencies, e.g. the ones defining the declared GBeans,  
>>> and let them define the other dependencies.
>>
>>
>> That is certainly a goal I like :-).
>>
>> I like the idea of constructing the geronimo-service.xml's from the  
>> project.xml.  That would eliminate one source of duplication.  And,  
>> we could open up the configurations and possibly jars included  
>> explicitly in an assembly and extract the dependencies and install  
>> them into the geronimo repo providing they are available.  However,  
>> unless maven is also keeping track of the transitive dependencies  
>> somehow, such as through poms, I don't see how maven will be able to  
>> guarantee that all the dependencies needed for an assembly are  
>> actually present in the local maven repo, so we can copy them.  Any  
>> ideas?
>
> I see the problem now: all the dependencies need to be in the local  
> maven repo and it seems that only Maven will be able to do that.
>
> Thanks,
> Gianny
>
>>
>> thanks,
>> david jencks
>>
>>>
>>> Thanks,
>>> Gianny
>>>
>>> On 20/10/2005 2:40 PM, Bruce Snyder wrote:
>>>
>>>> On 10/19/05, Gianny Damour <gi...@optusnet.com.au> wrote:
>>>>
>>>>> Another approach would be: for each plain dependency, we could  
>>>>> generate
>>>>> a META-INF/geronimo-service.xml file based on the POM dependencies  
>>>>> as
>>>>> part of a standard build. Transitive dependencies would be  
>>>>> achieved by
>>>>> walking down the dependencies defined by the geronimo-service.xml  
>>>>> file.
>>>>>
>>>>
>>>> I'm not shooting down anything, but that sounds like a lot of extra
>>>> XML parsing. I'm curious to hear Dain chime in here to describe
>>>> exactly what he's doing with the Maven repo management code.
>>>>
>>>> Bruce
>>>> --  
>>>> perl -e 'print  
>>>> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC; 
>>>> VT*"
>>>> );'
>>>>
>>>> The Castor Project
>>>> http://www.castor.org/
>>>>
>>>> Apache Geronimo
>>>> http://geronimo.apache.org/
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>


Re: transitive dependencies

Posted by Gianny Damour <gi...@optusnet.com.au>.
On 20/10/2005 2:58 PM, David Jencks wrote:

>
> On Oct 19, 2005, at 9:57 PM, Gianny Damour wrote:
>
>> You may be right. Having said that, this XML parsing is done each 
>> time that a dependency is declared by a configuration. I see this 
>> approach as more self-contained than a solution based on the build 
>> system. Indeed, this approach allows to declare the runtime 
>> dependencies of a dependency, which is rather handy.
>
>
> Could you explain what you mean by this?

I think that this is better explained with an example:
Based on the META-INF/geronimo-service.xml file of the geronimo-tomcat 
dependency, I know that 4 runtime dependencies are required. As a user, 
it is clear that I need these 4 dependencies in my repository to be able 
to use geronimo-tomcat. Without this file, I do not know that. Based on 
the geronimo-tomcat POM, a user is able to derive the compile time 
dependencies; yet it is not clear that tomcat-coyote needs to be there 
at runtime.

I think that this is more handy as it is then trivial to write a tomcat 
plan: I add the tomcat-plan dependency; define my GBeans; and add to my 
repo the geronimo-service.xml runtime dependencies. With the current 
approach, I would need to add to my custom plan all the dependencies 
defined by j2ee-tomcat-plan (do I need all of them?).

>>
>> Also, I think that it is also a pain to declare the transitive 
>> dependencies in a configuration. I would prefer to simply define the 
>> top level dependencies, e.g. the ones defining the declared GBeans, 
>> and let them define the other dependencies.
>
>
> That is certainly a goal I like :-).
>
> I like the idea of constructing the geronimo-service.xml's from the 
> project.xml.  That would eliminate one source of duplication.  And, we 
> could open up the configurations and possibly jars included explicitly 
> in an assembly and extract the dependencies and install them into the 
> geronimo repo providing they are available.  However, unless maven is 
> also keeping track of the transitive dependencies somehow, such as 
> through poms, I don't see how maven will be able to guarantee that all 
> the dependencies needed for an assembly are actually present in the 
> local maven repo, so we can copy them.  Any ideas?

I see the problem now: all the dependencies need to be in the local 
maven repo and it seems that only Maven will be able to do that.

Thanks,
Gianny

>
> thanks,
> david jencks
>
>>
>> Thanks,
>> Gianny
>>
>> On 20/10/2005 2:40 PM, Bruce Snyder wrote:
>>
>>> On 10/19/05, Gianny Damour <gi...@optusnet.com.au> wrote:
>>>
>>>> Another approach would be: for each plain dependency, we could 
>>>> generate
>>>> a META-INF/geronimo-service.xml file based on the POM dependencies as
>>>> part of a standard build. Transitive dependencies would be achieved by
>>>> walking down the dependencies defined by the geronimo-service.xml 
>>>> file.
>>>>
>>>
>>> I'm not shooting down anything, but that sounds like a lot of extra
>>> XML parsing. I'm curious to hear Dain chime in here to describe
>>> exactly what he's doing with the Maven repo management code.
>>>
>>> Bruce
>>> -- 
>>> perl -e 'print 
>>> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
>>> );'
>>>
>>> The Castor Project
>>> http://www.castor.org/
>>>
>>> Apache Geronimo
>>> http://geronimo.apache.org/
>>>
>>>
>>>
>>>
>>
>>
>
>
>



Re: transitive dependencies

Posted by David Jencks <da...@yahoo.com>.
On Oct 19, 2005, at 9:57 PM, Gianny Damour wrote:

> You may be right. Having said that, this XML parsing is done each time 
> that a dependency is declared by a configuration. I see this approach 
> as more self-contained than a solution based on the build system. 
> Indeed, this approach allows to declare the runtime dependencies of a 
> dependency, which is rather handy.

Could you explain what you mean by this?
>
> Also, I think that it is also a pain to declare the transitive 
> dependencies in a configuration. I would prefer to simply define the 
> top level dependencies, e.g. the ones defining the declared GBeans, 
> and let them define the other dependencies.

That is certainly a goal I like :-).

I like the idea of constructing the geronimo-service.xml's from the 
project.xml.  That would eliminate one source of duplication.  And, we 
could open up the configurations and possibly jars included explicitly 
in an assembly and extract the dependencies and install them into the 
geronimo repo providing they are available.  However, unless maven is 
also keeping track of the transitive dependencies somehow, such as 
through poms, I don't see how maven will be able to guarantee that all 
the dependencies needed for an assembly are actually present in the 
local maven repo, so we can copy them.  Any ideas?

thanks,
david jencks
>
> Thanks,
> Gianny
>
> On 20/10/2005 2:40 PM, Bruce Snyder wrote:
>
>> On 10/19/05, Gianny Damour <gi...@optusnet.com.au> wrote:
>>
>>> Another approach would be: for each plain dependency, we could 
>>> generate
>>> a META-INF/geronimo-service.xml file based on the POM dependencies as
>>> part of a standard build. Transitive dependencies would be achieved 
>>> by
>>> walking down the dependencies defined by the geronimo-service.xml 
>>> file.
>>>
>>
>> I'm not shooting down anything, but that sounds like a lot of extra
>> XML parsing. I'm curious to hear Dain chime in here to describe
>> exactly what he's doing with the Maven repo management code.
>>
>> Bruce
>> --
>> perl -e 'print 
>> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
>> );'
>>
>> The Castor Project
>> http://www.castor.org/
>>
>> Apache Geronimo
>> http://geronimo.apache.org/
>>
>>
>>
>>
>
>


Re: transitive dependencies

Posted by Gianny Damour <gi...@optusnet.com.au>.
You may be right. Having said that, this XML parsing is done each time 
that a dependency is declared by a configuration. I see this approach as 
more self-contained than a solution based on the build system. Indeed, 
this approach allows to declare the runtime dependencies of a 
dependency, which is rather handy.

Also, I think that it is also a pain to declare the transitive 
dependencies in a configuration. I would prefer to simply define the top 
level dependencies, e.g. the ones defining the declared GBeans, and let 
them define the other dependencies.

Thanks,
Gianny

On 20/10/2005 2:40 PM, Bruce Snyder wrote:

>On 10/19/05, Gianny Damour <gi...@optusnet.com.au> wrote:
>  
>
>>Another approach would be: for each plain dependency, we could generate
>>a META-INF/geronimo-service.xml file based on the POM dependencies as
>>part of a standard build. Transitive dependencies would be achieved by
>>walking down the dependencies defined by the geronimo-service.xml file.
>>    
>>
>
>I'm not shooting down anything, but that sounds like a lot of extra
>XML parsing. I'm curious to hear Dain chime in here to describe
>exactly what he's doing with the Maven repo management code.
>
>Bruce
>--
>perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
>);'
>
>The Castor Project
>http://www.castor.org/
>
>Apache Geronimo
>http://geronimo.apache.org/
>
>
>
>  
>



Re: transitive dependencies

Posted by Bruce Snyder <br...@gmail.com>.
On 10/19/05, Gianny Damour <gi...@optusnet.com.au> wrote:
> Another approach would be: for each plain dependency, we could generate
> a META-INF/geronimo-service.xml file based on the POM dependencies as
> part of a standard build. Transitive dependencies would be achieved by
> walking down the dependencies defined by the geronimo-service.xml file.

I'm not shooting down anything, but that sounds like a lot of extra
XML parsing. I'm curious to hear Dain chime in here to describe
exactly what he's doing with the Maven repo management code.

Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'

The Castor Project
http://www.castor.org/

Apache Geronimo
http://geronimo.apache.org/

Re: transitive dependencies

Posted by Gianny Damour <gi...@optusnet.com.au>.
Another approach would be: for each plain dependency, we could generate 
a META-INF/geronimo-service.xml file based on the POM dependencies as 
part of a standard build. Transitive dependencies would be achieved by 
walking down the dependencies defined by the geronimo-service.xml file.

Thanks,
Gianny

On 20/10/2005 1:56 PM, David Jencks wrote:

> I've been working on building geronimo using the packaging and 
> assembly plugins.  This works fine except for the unmanageable 
> dependencies.   The project for the assemby plugin to work on 
> currently needs to include in the project.xml every jar to go into the 
> assembly's repository.  Tracking these is impossible.
>
> We need some way for a configuration or even a plain dependency to 
> instruct the assembly plugin to copy the artifacts dependencies into 
> the repository.
>
> One possibility is to use maven poms.  IIUC Dain is working on 
> integrating or imitating the latest maven repository management code.  
> Will this give us transitive dependencies?  Will the maven model work 
> for us?  How close is this?  If we had it, it would be pretty easy to 
> construct separate jetty and tomcat assemblies, a both assembly, an 
> assembly w/o ejbs, etc etc.  Without transitive dependencies, it will 
> be a nightmare to try to keep the repository contents adequate and 
> restricted to what is actually needed to run the server.
>
> thanks
> david jencks
>
>



Re: transitive dependencies

Posted by Dain Sundstrom <da...@iq80.com>.
On Oct 20, 2005, at 5:56 AM, David Jencks wrote:

> I've been working on building geronimo using the packaging and  
> assembly plugins.  This works fine except for the unmanageable  
> dependencies.   The project for the assemby plugin to work on  
> currently needs to include in the project.xml every jar to go into  
> the assembly's repository.  Tracking these is impossible.
>
> We need some way for a configuration or even a plain dependency to  
> instruct the assembly plugin to copy the artifacts dependencies  
> into the repository.
>
> One possibility is to use maven poms.  IIUC Dain is working on  
> integrating or imitating the latest maven repository management  
> code.  Will this give us transitive dependencies?

Yes :)

I'm going to start working on this as soon as I get back to the states.

-dain