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 2009/12/10 06:48:07 UTC

Re: Move dependencyManagment segment in framework/pom.xml to the root pom.xml

On Dec 9, 2009, at 6:51 PM, Ivan wrote:

> Hi,
>     I found some third-party bundle defintions are in the framework/ 
> pom.xml, Is there any reason to keep them there ? If not, I would  
> suggest to move them to the root pom.xml file, so that all the  
> plugins could refer to them.

To me this is a difficult question.  There are two plausible  
alternatives:

1. move all dependency management for the entire project to the root  
pom.

2. move all dependency management to either framework root pom or the  
plugins root pom that introduces them, and use the <scope>import</ 
scope> in dependency management for other plugins that need the  
dependency to import the pom that sets up the dependencyManagement..

2 depends on the very recent import scope feature, we could not have  
done it for any 2.1 or earlier releases.

Arguments can definitely be made on both sides of this discussion.  At  
the moment my thinking is that (1) promotes a monolithic project that  
is difficult to split into independent modules that are assembled, and  
that (2) promotes more modularity at the possible cost of making  
dependency tracking slightly harder.  So, over the last few months  
I've been moving towards (2), putting dependency management for e.g.  
the imported jetty jars in the jetty8 root pom.

So, I'm in favor of gradually moving all the dependency management out  
of the root pom.

thanks
david jencks

>     Thanks !
> -- 
> Ivan


Re: Move dependencyManagment segment in framework/pom.xml to the root pom.xml

Posted by David Jencks <da...@yahoo.com>.
On Dec 9, 2009, at 10:53 PM, Jarek Gawor wrote:

> I'm +1 for moving some shared dependencies into root pom. If some
> dependency is not shared then it can live in some plugin's root pom.

To me it depends on "how shared".  Something like xmlbeans is used  
independently in a lot of builders.  On the other hand there are a lot  
of console-related dependencies that are used only in console plugins,  
and for these I am inclined to think they should be specified in the  
base console plugins pom and that imported for the other console  
plugins.

>
> I do have problems with <scope>import</scope> imports or at least with
> how maven handles them. During a build, Maven might initially
> download/use a snapshot of that imported pom with one set of
> dependencies but later build the same pom with another set of
> dependencies. So I never know which dependencies are really used at
> build time with scope imports.

I haven't seen this myself.  IIUC it seems like a really serious maven  
bug.  Is it reported?
>
> Because of that I've been trying to avoid <scope>import</scope>
> imports and wanted to make sure we don't over abuse them.

I forgot to mention that my overriding goal is to make it easier to  
build and release the plugins independently, and then assemble servers  
even more independently.  In this model the idea of a root pom sort of  
disappears.

thanks
david jencks

>
> Jarek
>
> On Thu, Dec 10, 2009 at 1:03 AM, Ivan <xh...@gmail.com> wrote:
>> Thanks for the clarification for the two solutions, David.
>> But I do not think that it is better to move all the dependencies  
>> out from
>> the root pom.xml file. It makes sense that define them in the  
>> plugin's pom
>> file for Tomcat or Jetty. But for those tool packages, like xmlbeans,
>> xmlresovle, etc, I still think it is better to put them in the root  
>> pom
>> file. For example, it will make it strange to import pluginA just  
>> for using
>> a xmlbean package, although it would not a problem from technical  
>> side.
>> Any comments ?
>>
>> 2009/12/10 David Jencks <da...@yahoo.com>
>>>
>>> On Dec 9, 2009, at 6:51 PM, Ivan wrote:
>>>
>>>> Hi,
>>>>    I found some third-party bundle defintions are in the
>>>> framework/pom.xml, Is there any reason to keep them there ? If  
>>>> not, I would
>>>> suggest to move them to the root pom.xml file, so that all the  
>>>> plugins could
>>>> refer to them.
>>>
>>> To me this is a difficult question.  There are two plausible  
>>> alternatives:
>>>
>>> 1. move all dependency management for the entire project to the  
>>> root pom.
>>>
>>> 2. move all dependency management to either framework root pom or  
>>> the
>>> plugins root pom that introduces them, and use the <scope>import</ 
>>> scope> in
>>> dependency management for other plugins that need the dependency  
>>> to import
>>> the pom that sets up the dependencyManagement..
>>>
>>> 2 depends on the very recent import scope feature, we could not  
>>> have done
>>> it for any 2.1 or earlier releases.
>>>
>>> Arguments can definitely be made on both sides of this  
>>> discussion.  At the
>>> moment my thinking is that (1) promotes a monolithic project that is
>>> difficult to split into independent modules that are assembled,  
>>> and that (2)
>>> promotes more modularity at the possible cost of making dependency  
>>> tracking
>>> slightly harder.  So, over the last few months I've been moving  
>>> towards (2),
>>> putting dependency management for e.g. the imported jetty jars in  
>>> the jetty8
>>> root pom.
>>>
>>> So, I'm in favor of gradually moving all the dependency management  
>>> out of
>>> the root pom.
>>>
>>> thanks
>>> david jencks
>>>
>>>>    Thanks !
>>>> --
>>>> Ivan
>>>
>>
>>
>>
>> --
>> Ivan
>>


Re: Move dependencyManagment segment in framework/pom.xml to the root pom.xml

Posted by Jarek Gawor <jg...@gmail.com>.
I'm +1 for moving some shared dependencies into root pom. If some
dependency is not shared then it can live in some plugin's root pom.

I do have problems with <scope>import</scope> imports or at least with
how maven handles them. During a build, Maven might initially
download/use a snapshot of that imported pom with one set of
dependencies but later build the same pom with another set of
dependencies. So I never know which dependencies are really used at
build time with scope imports.

Because of that I've been trying to avoid <scope>import</scope>
imports and wanted to make sure we don't over abuse them.

Jarek

On Thu, Dec 10, 2009 at 1:03 AM, Ivan <xh...@gmail.com> wrote:
> Thanks for the clarification for the two solutions, David.
> But I do not think that it is better to move all the dependencies out from
> the root pom.xml file. It makes sense that define them in the plugin's pom
> file for Tomcat or Jetty. But for those tool packages, like xmlbeans,
> xmlresovle, etc, I still think it is better to put them in the root pom
> file. For example, it will make it strange to import pluginA just for using
> a xmlbean package, although it would not a problem from technical side.
> Any comments ?
>
> 2009/12/10 David Jencks <da...@yahoo.com>
>>
>> On Dec 9, 2009, at 6:51 PM, Ivan wrote:
>>
>>> Hi,
>>>    I found some third-party bundle defintions are in the
>>> framework/pom.xml, Is there any reason to keep them there ? If not, I would
>>> suggest to move them to the root pom.xml file, so that all the plugins could
>>> refer to them.
>>
>> To me this is a difficult question.  There are two plausible alternatives:
>>
>> 1. move all dependency management for the entire project to the root pom.
>>
>> 2. move all dependency management to either framework root pom or the
>> plugins root pom that introduces them, and use the <scope>import</scope> in
>> dependency management for other plugins that need the dependency to import
>> the pom that sets up the dependencyManagement..
>>
>> 2 depends on the very recent import scope feature, we could not have done
>> it for any 2.1 or earlier releases.
>>
>> Arguments can definitely be made on both sides of this discussion.  At the
>> moment my thinking is that (1) promotes a monolithic project that is
>> difficult to split into independent modules that are assembled, and that (2)
>> promotes more modularity at the possible cost of making dependency tracking
>> slightly harder.  So, over the last few months I've been moving towards (2),
>> putting dependency management for e.g. the imported jetty jars in the jetty8
>> root pom.
>>
>> So, I'm in favor of gradually moving all the dependency management out of
>> the root pom.
>>
>> thanks
>> david jencks
>>
>>>    Thanks !
>>> --
>>> Ivan
>>
>
>
>
> --
> Ivan
>

Re: Move dependencyManagment segment in framework/pom.xml to the root pom.xml

Posted by Ivan <xh...@gmail.com>.
Thanks for the clarification for the two solutions, David.
But I do not think that it is better to move all the dependencies out from
the root pom.xml file. It makes sense that define them in the plugin's pom
file for Tomcat or Jetty. But for those tool packages, like xmlbeans,
xmlresovle, etc, I still think it is better to put them in the root pom
file. For example, it will make it strange to import pluginA just for using
a xmlbean package, although it would not a problem from technical side.
Any comments ?

2009/12/10 David Jencks <da...@yahoo.com>

>
> On Dec 9, 2009, at 6:51 PM, Ivan wrote:
>
>  Hi,
>>    I found some third-party bundle defintions are in the
>> framework/pom.xml, Is there any reason to keep them there ? If not, I would
>> suggest to move them to the root pom.xml file, so that all the plugins could
>> refer to them.
>>
>
> To me this is a difficult question.  There are two plausible alternatives:
>
> 1. move all dependency management for the entire project to the root pom.
>
> 2. move all dependency management to either framework root pom or the
> plugins root pom that introduces them, and use the <scope>import</scope> in
> dependency management for other plugins that need the dependency to import
> the pom that sets up the dependencyManagement..
>
> 2 depends on the very recent import scope feature, we could not have done
> it for any 2.1 or earlier releases.
>
> Arguments can definitely be made on both sides of this discussion.  At the
> moment my thinking is that (1) promotes a monolithic project that is
> difficult to split into independent modules that are assembled, and that (2)
> promotes more modularity at the possible cost of making dependency tracking
> slightly harder.  So, over the last few months I've been moving towards (2),
> putting dependency management for e.g. the imported jetty jars in the jetty8
> root pom.
>
> So, I'm in favor of gradually moving all the dependency management out of
> the root pom.
>
> thanks
> david jencks
>
>     Thanks !
>> --
>> Ivan
>>
>
>


-- 
Ivan