Re: [m2] POM Inheritance
This is exactly what I was looking for. I didn't realize that you could include a pom as a dependency. This makes things much cleaner. Thanks again, jp4 Eric Redmond wrote: > > Abstract it? I don't understand. The JDBC pom is just a seperate project. > Like this: > > JDBC POM: > > ... > my-jdbc-project > pom > > ... add jdbc dependencies here, like mysql jdbc, or sqlserver jdbc ... > > > > Then, in your project that needs to use the jdbc drivers: > > > ... > my-jdbc-project > ... > pom > > > > > > On 2/28/07, jp4 <[EMAIL PROTECTED]> wrote: >> >> >> So how to you use this abstract jdbc pom file? Do you include it as a >> dependency in your data access modules?Do you use it as the parent of >> your data access modules? >> >> jp4 >> >> >> Eric Redmond wrote: >> > >> > Yeah, I do this quite a lot - for example, to abstract jdbc >> > implementations >> > across and organization - all jars required go into a pom project >> called >> > "jdbc". If you need to make an orthogonal change, just change jdbc's >> > dependency list. >> > >> > Eric >> > >> > On 2/28/07, Thierry Lach <[EMAIL PROTECTED]> wrote: >> >> >> >> Is it possible to declare a pom as a dependency, so that its >> dependencies >> >> would be inherited? If that doesn't work, them maybe it should be >> added >> >> as >> >> an enhancement. >> >> >> >> On 2/27/07, jp4 <[EMAIL PROTECTED]> wrote: >> >> > >> >> > >> >> > I wonder if it would make sense to create a project of type jar that >> >> does >> >> > nothing more than declare common dependencies like spring and >> >> hibernate. >> >> > This way, by including a common data access jar file, all other data >> >> > access >> >> > modules would transitively include the spring and hibernate jars. >> >> > >> >> > Any thoughts our ideas would be greatly appreciated. >> >> > >> >> > jp4 >> >> > >> >> > jp4 wrote: >> >> > > >> >> > > I have been doing some reading and it looks like the >> >> >> >> > > section will allow me to achieve part of what I want to do with >> >> reusing >> >> > > plugin configurations. >> >> > > >> >> > > jp4 >> >> > > >> >> > > jp4 wrote: >> >> > >> >> >> > >> I have posted about this question several times before but >> haven't >> >> > >> received many responses. I am hoping that someone has done or >> knows >> >> > how >> >> > >> to accomplish the following. >> >> > >> >> >> > >> Basically, I have several multi module projects. Each project >> >> defines >> >> > a >> >> > >> parent pom.xml file which contains a list of modules as well as >> the >> >> > >> project's version id (all children use the parent.version). In >> >> > addition, >> >> > >> if necessary, it defines any common dependencies for it's >> modules. >> >> > >> >> >> > >> I have several projects that follow this pattern, most of which >> >> produce >> >> > a >> >> > >> deployable webapp and consist of webapp, model, data access, and >> >> > service >> >> > >> modules. For the most part, the data access modules usually >> share >> >> > common >> >> > >> configuration such as spring and hibernate dependencies and >> perhaps >> >> > some >> >> > >> common plugins. So, in the case of a data access module, I would >> >> like >> >> > >> it's parent to be the projects' parent pom.xml file, but I would >> >> also >> >> > >> like it to be able to inherit data access configurations from a >> >> > different >> >> > >> pom.xml file. >> >> > >> >> >> > >> I know that you can create an inheritance chain, but in this >> case, >> I >> >> > >> really don't want the project's parent pom.xml file to inherit >> from >> >> a >> >> > >> data access pom.xml for obvious reasons. >> >> > >> >> >> > >> The solution may be that I have to redefine the spring and >> hibernate >> >> > >> dependencies as well as plugins in each data access project. I >> can >> >> do >> >> > >> that, but I wanted to explore a more elegant solution before >> >> resorting >> >> > to >> >> > >> that. >> >> > >> >> >> > >> Any help would be greatly appreciated. >> >> > >> >> >> > >> Thanks, >> >> > >> >> >> > >> jp4 >> >> > >> >> >> > > >> >> > > >> >> > >> >> > -- >> >> > View this message in context: >> >> > http://www.nabble.com/POM-Inheritance-tf3304518s177.html#a9196345 >> >> > Sent from the Maven - Users mailing list archive at Nabble.com. >> >> > >> >> > >> >> > >> - >> >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> > For additional commands, e-mail: [EMAIL PROTECTED] >> >> > >> >> > >> >> >> > >> > >> > >> > -- >> > Eric Redmond >> > http://codehaus.org/~eredmond >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/POM-Inheritance-tf3304518s177.html#a9226529 >> Sent from the Maven - Users mailing list archive at Nabble.com. >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail:
Re: [m2] POM Inheritance
Abstract it? I don't understand. The JDBC pom is just a seperate project. Like this: JDBC POM: ... my-jdbc-project pom ... add jdbc dependencies here, like mysql jdbc, or sqlserver jdbc ... Then, in your project that needs to use the jdbc drivers: ... my-jdbc-project ... pom On 2/28/07, jp4 <[EMAIL PROTECTED]> wrote: So how to you use this abstract jdbc pom file? Do you include it as a dependency in your data access modules?Do you use it as the parent of your data access modules? jp4 Eric Redmond wrote: > > Yeah, I do this quite a lot - for example, to abstract jdbc > implementations > across and organization - all jars required go into a pom project called > "jdbc". If you need to make an orthogonal change, just change jdbc's > dependency list. > > Eric > > On 2/28/07, Thierry Lach <[EMAIL PROTECTED]> wrote: >> >> Is it possible to declare a pom as a dependency, so that its dependencies >> would be inherited? If that doesn't work, them maybe it should be added >> as >> an enhancement. >> >> On 2/27/07, jp4 <[EMAIL PROTECTED]> wrote: >> > >> > >> > I wonder if it would make sense to create a project of type jar that >> does >> > nothing more than declare common dependencies like spring and >> hibernate. >> > This way, by including a common data access jar file, all other data >> > access >> > modules would transitively include the spring and hibernate jars. >> > >> > Any thoughts our ideas would be greatly appreciated. >> > >> > jp4 >> > >> > jp4 wrote: >> > > >> > > I have been doing some reading and it looks like the >> >> > > section will allow me to achieve part of what I want to do with >> reusing >> > > plugin configurations. >> > > >> > > jp4 >> > > >> > > jp4 wrote: >> > >> >> > >> I have posted about this question several times before but haven't >> > >> received many responses. I am hoping that someone has done or knows >> > how >> > >> to accomplish the following. >> > >> >> > >> Basically, I have several multi module projects. Each project >> defines >> > a >> > >> parent pom.xml file which contains a list of modules as well as the >> > >> project's version id (all children use the parent.version). In >> > addition, >> > >> if necessary, it defines any common dependencies for it's modules. >> > >> >> > >> I have several projects that follow this pattern, most of which >> produce >> > a >> > >> deployable webapp and consist of webapp, model, data access, and >> > service >> > >> modules. For the most part, the data access modules usually share >> > common >> > >> configuration such as spring and hibernate dependencies and perhaps >> > some >> > >> common plugins. So, in the case of a data access module, I would >> like >> > >> it's parent to be the projects' parent pom.xml file, but I would >> also >> > >> like it to be able to inherit data access configurations from a >> > different >> > >> pom.xml file. >> > >> >> > >> I know that you can create an inheritance chain, but in this case, I >> > >> really don't want the project's parent pom.xml file to inherit from >> a >> > >> data access pom.xml for obvious reasons. >> > >> >> > >> The solution may be that I have to redefine the spring and hibernate >> > >> dependencies as well as plugins in each data access project. I can >> do >> > >> that, but I wanted to explore a more elegant solution before >> resorting >> > to >> > >> that. >> > >> >> > >> Any help would be greatly appreciated. >> > >> >> > >> Thanks, >> > >> >> > >> jp4 >> > >> >> > > >> > > >> > >> > -- >> > View this message in context: >> > http://www.nabble.com/POM-Inheritance-tf3304518s177.html#a9196345 >> > Sent from the Maven - Users mailing list archive at Nabble.com. >> > >> > >> > - >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> > > > > -- > Eric Redmond > http://codehaus.org/~eredmond > > -- View this message in context: http://www.nabble.com/POM-Inheritance-tf3304518s177.html#a9226529 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Eric Redmond http://codehaus.org/~eredmond
Re: [m2] POM Inheritance
Will this work? I do not know. Introduce a third pom (the data access pom) as a new module of the original parent. The original parent pom remains unchanged except for the addition of the new data access pom module. The new data access pom declares data access dependencies. The data access modules parent is changed from the original parent to the new data access pom. Regards, John jp4 wrote: > > I have posted about this question several times before but haven't > received many responses. I am hoping that someone has done or knows how > to accomplish the following. > > Basically, I have several multi module projects. Each project defines a > parent pom.xml file which contains a list of modules as well as the > project's version id (all children use the parent.version). In addition, > if necessary, it defines any common dependencies for it's modules. > > I have several projects that follow this pattern, most of which produce a > deployable webapp and consist of webapp, model, data access, and service > modules. For the most part, the data access modules usually share common > configuration such as spring and hibernate dependencies and perhaps some > common plugins. So, in the case of a data access module, I would like > it's parent to be the projects' parent pom.xml file, but I would also like > it to be able to inherit data access configurations from a different > pom.xml file. > > I know that you can create an inheritance chain, but in this case, I > really don't want the project's parent pom.xml file to inherit from a data > access pom.xml for obvious reasons. > > The solution may be that I have to redefine the spring and hibernate > dependencies as well as plugins in each data access project. I can do > that, but I wanted to explore a more elegant solution before resorting to > that. > > Any help would be greatly appreciated. > > Thanks, > > jp4 > -- View this message in context: http://www.nabble.com/POM-Inheritance-tf3304518s177.html#a9226530 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] POM Inheritance
So how to you use this abstract jdbc pom file? Do you include it as a dependency in your data access modules?Do you use it as the parent of your data access modules? jp4 Eric Redmond wrote: > > Yeah, I do this quite a lot - for example, to abstract jdbc > implementations > across and organization - all jars required go into a pom project called > "jdbc". If you need to make an orthogonal change, just change jdbc's > dependency list. > > Eric > > On 2/28/07, Thierry Lach <[EMAIL PROTECTED]> wrote: >> >> Is it possible to declare a pom as a dependency, so that its dependencies >> would be inherited? If that doesn't work, them maybe it should be added >> as >> an enhancement. >> >> On 2/27/07, jp4 <[EMAIL PROTECTED]> wrote: >> > >> > >> > I wonder if it would make sense to create a project of type jar that >> does >> > nothing more than declare common dependencies like spring and >> hibernate. >> > This way, by including a common data access jar file, all other data >> > access >> > modules would transitively include the spring and hibernate jars. >> > >> > Any thoughts our ideas would be greatly appreciated. >> > >> > jp4 >> > >> > jp4 wrote: >> > > >> > > I have been doing some reading and it looks like the >> >> > > section will allow me to achieve part of what I want to do with >> reusing >> > > plugin configurations. >> > > >> > > jp4 >> > > >> > > jp4 wrote: >> > >> >> > >> I have posted about this question several times before but haven't >> > >> received many responses. I am hoping that someone has done or knows >> > how >> > >> to accomplish the following. >> > >> >> > >> Basically, I have several multi module projects. Each project >> defines >> > a >> > >> parent pom.xml file which contains a list of modules as well as the >> > >> project's version id (all children use the parent.version). In >> > addition, >> > >> if necessary, it defines any common dependencies for it's modules. >> > >> >> > >> I have several projects that follow this pattern, most of which >> produce >> > a >> > >> deployable webapp and consist of webapp, model, data access, and >> > service >> > >> modules. For the most part, the data access modules usually share >> > common >> > >> configuration such as spring and hibernate dependencies and perhaps >> > some >> > >> common plugins. So, in the case of a data access module, I would >> like >> > >> it's parent to be the projects' parent pom.xml file, but I would >> also >> > >> like it to be able to inherit data access configurations from a >> > different >> > >> pom.xml file. >> > >> >> > >> I know that you can create an inheritance chain, but in this case, I >> > >> really don't want the project's parent pom.xml file to inherit from >> a >> > >> data access pom.xml for obvious reasons. >> > >> >> > >> The solution may be that I have to redefine the spring and hibernate >> > >> dependencies as well as plugins in each data access project. I can >> do >> > >> that, but I wanted to explore a more elegant solution before >> resorting >> > to >> > >> that. >> > >> >> > >> Any help would be greatly appreciated. >> > >> >> > >> Thanks, >> > >> >> > >> jp4 >> > >> >> > > >> > > >> > >> > -- >> > View this message in context: >> > http://www.nabble.com/POM-Inheritance-tf3304518s177.html#a9196345 >> > Sent from the Maven - Users mailing list archive at Nabble.com. >> > >> > >> > - >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> > > > > -- > Eric Redmond > http://codehaus.org/~eredmond > > -- View this message in context: http://www.nabble.com/POM-Inheritance-tf3304518s177.html#a9226529 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] POM Inheritance
Will this work? I do not know. Introduce a third pom (the data access pom) as a new module of the original parent. The original parent pom remains unchanged except for the addition of the new data access pom module. The new data access pom declares data access dependencies. The data access modules parent is changed from the original parent to the new data access pom. Regards, John jp4 wrote: > > I have posted about this question several times before but haven't > received many responses. I am hoping that someone has done or knows how > to accomplish the following. > > Basically, I have several multi module projects. Each project defines a > parent pom.xml file which contains a list of modules as well as the > project's version id (all children use the parent.version). In addition, > if necessary, it defines any common dependencies for it's modules. > > I have several projects that follow this pattern, most of which produce a > deployable webapp and consist of webapp, model, data access, and service > modules. For the most part, the data access modules usually share common > configuration such as spring and hibernate dependencies and perhaps some > common plugins. So, in the case of a data access module, I would like > it's parent to be the projects' parent pom.xml file, but I would also like > it to be able to inherit data access configurations from a different > pom.xml file. > > I know that you can create an inheritance chain, but in this case, I > really don't want the project's parent pom.xml file to inherit from a data > access pom.xml for obvious reasons. > > The solution may be that I have to redefine the spring and hibernate > dependencies as well as plugins in each data access project. I can do > that, but I wanted to explore a more elegant solution before resorting to > that. > > Any help would be greatly appreciated. > > Thanks, > > jp4 > -- View this message in context: http://www.nabble.com/POM-Inheritance-tf3304518s177.html#a9226499 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: [m2] POM Inheritance
woops, forgot to cc the group -- Forwarded message -- From: Eric Redmond <[EMAIL PROTECTED]> Date: Feb 28, 2007 11:53 AM Subject: Re: [m2] POM Inheritance To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> There's not much more to say about it. Create a pom.xml of packaging "pom" Give it a bunch of dependencies Install/Deploy that pom to your repository Now any project that depends on that pom project will get all of the pom project's dependencies, transatively. Eric On 2/28/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Could you pl elaborate on this use case? Thanks, /U -- Original message -- From: "Eric Redmond" <[EMAIL PROTECTED]> > Yeah, I do this quite a lot - for example, to abstract jdbc implementations > across and organization - all jars required go into a pom project called > "jdbc". If you need to make an orthogonal change, just change jdbc's > dependency list. > > Eric > > On 2/28/07, Thierry Lach < [EMAIL PROTECTED]> wrote: > > > > Is it possible to declare a pom as a dependency, so that its dependencies > > would be inherited? If that doesn't work, them maybe it should be added > > as > > an enhancement. > > > > On 2/27/07, jp4 <[EMAIL PROTECTED]> wrote: > > > > > > > > > I wonder if it would make sense to create a project of type jar that > > does > > > nothing more than declare common dependencies like spring and hibernate. > > > This way, by including a common data access jar file, all other data > > > access > > > modules would transitively include the spring and hibernate jars. > > > > > > Any thoughts our ideas would be greatly appreciated. > > > > > > jp4 > > > > > > jp4 wrote: > > > > > > > > I have been doing some reading and it looks like the > > > > > > section will allow me to achieve part of what I want to do with > > reusing > > > > plugin configurations. > > > > > > > > jp4 > > > > > > > > jp4 wrote: > > > >> > > > >> I have posted about this question several times before but haven't > > > >> received many responses. I am hoping that someone has done or knows > > > how > > > >> to accomplish the following. > > > >> > > > >> Basically, I have several multi module projects. Each project > > defines > > > a > > > >> parent pom.xml file which contains a list of modules as well as the > > > >> project's version id (all children use the parent.version ). In > > > addition, > > > >> if necessary, it defines any common dependencies for it's modules. > > > >> > > > >> I have several projects that follow this pattern, most of which > > produce > > > a > > > >> deployable webapp and consist of webapp, model, data access, and > > > service > > > >> modules. For the most part, the data access modules usually share > > > common > > > >> configuration such as spring and hibernate dependencies and perhaps > > > some > > > >> common plugins. So, in the case of a data access module, I would > > like > > > >> it's parent to be the projects' parent pom.xml file, but I would also > > > >> like it to be able to inherit data access configurations from a > > > different > > > >> pom.xml file. > > > >> > > > >> I know that you can create an inheritance chain, but in this case, I > > > >> really don't want the project's parent pom.xml file to inherit from a > > > >> data access pom.xml for obvious reasons. > > > >> > > > >> The solution may be that I have to redefine the spring and hibernate > > > >> dependencies as well as plugins in each data access project. I can > > do > > > >> that, but I wanted to explore a more elegant solution before > > resorting > > > to > > > >> that. > > > >> > > > >> Any help would be greatly appreciated. > > > >> > > > >> Thanks, > > > >> > > > >> jp4 > > > >> > > > > > > > > > > > > > > -- > > > View this message in context: > > > http://www.nabble.com/POM-Inheritance-tf3304518s177.html#a9196345 > > > Sent from the Maven - Users mailing list archive at Nabble.com. > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > Eric Redmond > http://codehaus.org/~eredmond <http://codehaus.org/%7Eeredmond> -- Eric Redmond http://codehaus.org/~eredmond <http://codehaus.org/%7Eeredmond> -- Eric Redmond http://codehaus.org/~eredmond
Re: [m2] POM Inheritance
Yeah, I do this quite a lot - for example, to abstract jdbc implementations across and organization - all jars required go into a pom project called "jdbc". If you need to make an orthogonal change, just change jdbc's dependency list. Eric On 2/28/07, Thierry Lach <[EMAIL PROTECTED]> wrote: Is it possible to declare a pom as a dependency, so that its dependencies would be inherited? If that doesn't work, them maybe it should be added as an enhancement. On 2/27/07, jp4 <[EMAIL PROTECTED]> wrote: > > > I wonder if it would make sense to create a project of type jar that does > nothing more than declare common dependencies like spring and hibernate. > This way, by including a common data access jar file, all other data > access > modules would transitively include the spring and hibernate jars. > > Any thoughts our ideas would be greatly appreciated. > > jp4 > > jp4 wrote: > > > > I have been doing some reading and it looks like the > > section will allow me to achieve part of what I want to do with reusing > > plugin configurations. > > > > jp4 > > > > jp4 wrote: > >> > >> I have posted about this question several times before but haven't > >> received many responses. I am hoping that someone has done or knows > how > >> to accomplish the following. > >> > >> Basically, I have several multi module projects. Each project defines > a > >> parent pom.xml file which contains a list of modules as well as the > >> project's version id (all children use the parent.version). In > addition, > >> if necessary, it defines any common dependencies for it's modules. > >> > >> I have several projects that follow this pattern, most of which produce > a > >> deployable webapp and consist of webapp, model, data access, and > service > >> modules. For the most part, the data access modules usually share > common > >> configuration such as spring and hibernate dependencies and perhaps > some > >> common plugins. So, in the case of a data access module, I would like > >> it's parent to be the projects' parent pom.xml file, but I would also > >> like it to be able to inherit data access configurations from a > different > >> pom.xml file. > >> > >> I know that you can create an inheritance chain, but in this case, I > >> really don't want the project's parent pom.xml file to inherit from a > >> data access pom.xml for obvious reasons. > >> > >> The solution may be that I have to redefine the spring and hibernate > >> dependencies as well as plugins in each data access project. I can do > >> that, but I wanted to explore a more elegant solution before resorting > to > >> that. > >> > >> Any help would be greatly appreciated. > >> > >> Thanks, > >> > >> jp4 > >> > > > > > > -- > View this message in context: > http://www.nabble.com/POM-Inheritance-tf3304518s177.html#a9196345 > Sent from the Maven - Users mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Eric Redmond http://codehaus.org/~eredmond
Re: [m2] POM Inheritance
Is it possible to declare a pom as a dependency, so that its dependencies would be inherited? If that doesn't work, them maybe it should be added as an enhancement. On 2/27/07, jp4 <[EMAIL PROTECTED]> wrote: I wonder if it would make sense to create a project of type jar that does nothing more than declare common dependencies like spring and hibernate. This way, by including a common data access jar file, all other data access modules would transitively include the spring and hibernate jars. Any thoughts our ideas would be greatly appreciated. jp4 jp4 wrote: > > I have been doing some reading and it looks like the > section will allow me to achieve part of what I want to do with reusing > plugin configurations. > > jp4 > > jp4 wrote: >> >> I have posted about this question several times before but haven't >> received many responses. I am hoping that someone has done or knows how >> to accomplish the following. >> >> Basically, I have several multi module projects. Each project defines a >> parent pom.xml file which contains a list of modules as well as the >> project's version id (all children use the parent.version). In addition, >> if necessary, it defines any common dependencies for it's modules. >> >> I have several projects that follow this pattern, most of which produce a >> deployable webapp and consist of webapp, model, data access, and service >> modules. For the most part, the data access modules usually share common >> configuration such as spring and hibernate dependencies and perhaps some >> common plugins. So, in the case of a data access module, I would like >> it's parent to be the projects' parent pom.xml file, but I would also >> like it to be able to inherit data access configurations from a different >> pom.xml file. >> >> I know that you can create an inheritance chain, but in this case, I >> really don't want the project's parent pom.xml file to inherit from a >> data access pom.xml for obvious reasons. >> >> The solution may be that I have to redefine the spring and hibernate >> dependencies as well as plugins in each data access project. I can do >> that, but I wanted to explore a more elegant solution before resorting to >> that. >> >> Any help would be greatly appreciated. >> >> Thanks, >> >> jp4 >> > > -- View this message in context: http://www.nabble.com/POM-Inheritance-tf3304518s177.html#a9196345 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] POM Inheritance
I wonder if it would make sense to create a project of type jar that does nothing more than declare common dependencies like spring and hibernate. This way, by including a common data access jar file, all other data access modules would transitively include the spring and hibernate jars. Any thoughts our ideas would be greatly appreciated. jp4 jp4 wrote: > > I have been doing some reading and it looks like the > section will allow me to achieve part of what I want to do with reusing > plugin configurations. > > jp4 > > jp4 wrote: >> >> I have posted about this question several times before but haven't >> received many responses. I am hoping that someone has done or knows how >> to accomplish the following. >> >> Basically, I have several multi module projects. Each project defines a >> parent pom.xml file which contains a list of modules as well as the >> project's version id (all children use the parent.version). In addition, >> if necessary, it defines any common dependencies for it's modules. >> >> I have several projects that follow this pattern, most of which produce a >> deployable webapp and consist of webapp, model, data access, and service >> modules. For the most part, the data access modules usually share common >> configuration such as spring and hibernate dependencies and perhaps some >> common plugins. So, in the case of a data access module, I would like >> it's parent to be the projects' parent pom.xml file, but I would also >> like it to be able to inherit data access configurations from a different >> pom.xml file. >> >> I know that you can create an inheritance chain, but in this case, I >> really don't want the project's parent pom.xml file to inherit from a >> data access pom.xml for obvious reasons. >> >> The solution may be that I have to redefine the spring and hibernate >> dependencies as well as plugins in each data access project. I can do >> that, but I wanted to explore a more elegant solution before resorting to >> that. >> >> Any help would be greatly appreciated. >> >> Thanks, >> >> jp4 >> > > -- View this message in context: http://www.nabble.com/POM-Inheritance-tf3304518s177.html#a9196345 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] POM Inheritance
I have been doing some reading and it looks like the section will allow me to achieve part of what I want to do with reusing plugin configurations. jp4 jp4 wrote: > > I have posted about this question several times before but haven't > received many responses. I am hoping that someone has done or knows how > to accomplish the following. > > Basically, I have several multi module projects. Each project defines a > parent pom.xml file which contains a list of modules as well as the > project's version id (all children use the parent.version). In addition, > if necessary, it defines any common dependencies for it's modules. > > I have several projects that follow this pattern, most of which produce a > deployable webapp and consist of webapp, model, data access, and service > modules. For the most part, the data access modules usually share common > configuration such as spring and hibernate dependencies and perhaps some > common plugins. So, in the case of a data access module, I would like > it's parent to be the projects' parent pom.xml file, but I would also like > it to be able to inherit data access configurations from a different > pom.xml file. > > I know that you can create an inheritance chain, but in this case, I > really don't want the project's parent pom.xml file to inherit from a data > access pom.xml for obvious reasons. > > The solution may be that I have to redefine the spring and hibernate > dependencies as well as plugins in each data access project. I can do > that, but I wanted to explore a more elegant solution before resorting to > that. > > Any help would be greatly appreciated. > > Thanks, > > jp4 > -- View this message in context: http://www.nabble.com/POM-Inheritance-tf3304518s177.html#a9196293 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] POM Inheritance
I still haven't found a good solution for this and I was hoping to spark some
discussion with a follow up post.
jp4 wrote:
>
> I was wondering if there is any way to achieve multiple pom inheritance
> with maven. I have created several pom abstractions (i.e. data access
> which includes dependencies for hibernate, spring, etc... webapp which
> includes dependencies for struts, etc) for convenience as most of my data
> access projects follow the same pattern using hibernate and spring. I
> don't want to have to redefine these dependencies in each of my data
> access projects.
>
> Now here is where the problem comes in, I have a multi-module projectA
> that has a model, data access, webapp projects. In addition, I have a
> multi-module projectB that has a model, data access, webapp project. I
> would like to have all modules in projectA have the same version so that I
> can refer to version for projectA as ${project.version} in my model, data
> access, and webapp. The problem that I have is that I want projectA's
> data access project to inherit from both the data access pom as well as
> the projectA pom. Is there any way to do this? Or is there a different
> approach to achieve the desired results?
>
> Thanks,
> jp4
>
--
View this message in context:
http://www.nabble.com/POM-Inheritance-tf3164691s177.html#a9107889
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[m2] POM inheritance in a flat multiproject
Hi all, I have this directory layout: projects parent-proj pom.xml sub-proj pom.xml In parent-proj/pom.xml I have defined ../sub-proj In sub-proj/pom.xml I have defined ... ../parent-proj This works only if the sub-proj has defined a identical to that of the parent-proj. Otherwise, M2 complains that it cannot find the artifact (the parent-proj POM). In a normal multi-project layout this does not happen. I.e. I can define other or not define one at all and M2 will find the parent. Any comments? Adrian. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] POM inheritance
Hi, Now that alpha-2 is out, I'm trying to catch up. I'd like to apply the documentation you sent - just wanted to check whether you'd made any changes after getting those clarifications? Could you attach it to a JIRA ticket? It's preferred over email for tracking and history. Thanks, Brett > On 5/5/05, J. Matthew Pryor <[EMAIL PROTECTED]> wrote: > > OK so my (hopefully) last question then is "How do I tell what the canonical > > list of 'Implied plugins like maven-compiler-plugin' is"? > > > > Thanks for the clarification (of the clarification ;-) > > > > Matthew > > > > > -Original Message- > > > From: John Casey [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, May 05, 2005 3:01 AM > > > To: Maven Users List > > > Subject: Re: [m2] POM inheritance > > > > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA1 > > > > > > Alright, this is the part where I print a complete retraction > > > of everything I just emailed to the list... :) > > > > > > Next time, I promise, I'll actually re-read the code and/or > > > do some Right-Click -> References -> Project in Eclipse for a > > > given piece of code before I shoot my mouth off. In reality, > > > Brett is 100% correct (he should be, he's looking at the code > > > right now :). Implied plugins like maven-compiler-plugin will > > > also trigger the configurations in on a > > > plugin-by-plugin basis. So, in reality, both of the examples > > > that I gave below will work to configure the compiler plugin. > > > > > > Sorry for the confusion, and I'll try not to yell my comments > > > in from the other room next time. :) > > > > > > john > > > > > > John Casey wrote: > > > > I have a refinement or two to this... > > > > > > > > Brett Porter wrote: > > > > > > > >>>John has just made a final fix. So, to summarise the > > > behaviour here: > > > >>> > > > >>>- is inherited > > > >>>- elements are merged together during inheritence > > > >>>- is NOT inherited > > > >>>- the final plugin management values are merged into the > > > > > > >>>element of the POM being built. > > > > > > > > > > > > This is critical: the configurations are ONLY > > > > activated if you declare a corresponding entry in > > > the build > > > > section's stanza. pluginManagement is an opt-in > > > system; it > > > > will only affect your build if you specifically invite it in. Also, > > > > you cannot opt-in for all of the managed configuration at one go. > > > > > > > > To be clear: The only way to use the configuration declared within > > > > section is to declare a corresponding > > > > entry within . The minimal information > > > > necessary to link a build's actual plugin to the > > > corresponding managed > > > > plugin information is and . > > > > > > > > This WILL NOT configure the source/target properties of the > > > > maven-compiler-plugin: > > > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > > > org.apache.maven.plugins > > > > maven-compiler-plugin > > > > 1.0-alpha-1 > > > > > > > > 1.5 > > > > 1.5 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The managed information will ONLY be used when you opt-in for that > > > > configuration by declaring the plugin for use in the build > > > section, like so: > > > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > > > org.apache.maven.plugins > > > > maven-compiler-plugin > > > > 1.0-alpha-1 > > > > > > > > 1.5 > > > > 1.5 > > > > > > > > > > > > > > > > > > > > > > > > >
Re: [m2] POM inheritance
Anything executed is implied. The difference is that the plugins section can actually cause a plugin to be executed, but the equivalent management section will not. Cheers, Brett On 5/5/05, J. Matthew Pryor <[EMAIL PROTECTED]> wrote: > OK so my (hopefully) last question then is "How do I tell what the canonical > list of 'Implied plugins like maven-compiler-plugin' is"? > > Thanks for the clarification (of the clarification ;-) > > Matthew > > > -Original Message- > > From: John Casey [mailto:[EMAIL PROTECTED] > > Sent: Thursday, May 05, 2005 3:01 AM > > To: Maven Users List > > Subject: Re: [m2] POM inheritance > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Alright, this is the part where I print a complete retraction > > of everything I just emailed to the list... :) > > > > Next time, I promise, I'll actually re-read the code and/or > > do some Right-Click -> References -> Project in Eclipse for a > > given piece of code before I shoot my mouth off. In reality, > > Brett is 100% correct (he should be, he's looking at the code > > right now :). Implied plugins like maven-compiler-plugin will > > also trigger the configurations in on a > > plugin-by-plugin basis. So, in reality, both of the examples > > that I gave below will work to configure the compiler plugin. > > > > Sorry for the confusion, and I'll try not to yell my comments > > in from the other room next time. :) > > > > john > > > > John Casey wrote: > > > I have a refinement or two to this... > > > > > > Brett Porter wrote: > > > > > >>>John has just made a final fix. So, to summarise the > > behaviour here: > > >>> > > >>>- is inherited > > >>>- elements are merged together during inheritence > > >>>- is NOT inherited > > >>>- the final plugin management values are merged into the > > > > >>>element of the POM being built. > > > > > > > > > This is critical: the configurations are ONLY > > > activated if you declare a corresponding entry in > > the build > > > section's stanza. pluginManagement is an opt-in > > system; it > > > will only affect your build if you specifically invite it in. Also, > > > you cannot opt-in for all of the managed configuration at one go. > > > > > > To be clear: The only way to use the configuration declared within > > > section is to declare a corresponding > > > entry within . The minimal information > > > necessary to link a build's actual plugin to the > > corresponding managed > > > plugin information is and . > > > > > > This WILL NOT configure the source/target properties of the > > > maven-compiler-plugin: > > > > > > > > > ... > > > > > > > > > > > > > > > org.apache.maven.plugins > > > maven-compiler-plugin > > > 1.0-alpha-1 > > > > > > 1.5 > > > 1.5 > > > > > > > > > > > > > > > > > > > > > > > > The managed information will ONLY be used when you opt-in for that > > > configuration by declaring the plugin for use in the build > > section, like so: > > > > > > > > > ... > > > > > > > > > > > > > > > org.apache.maven.plugins > > > maven-compiler-plugin > > > 1.0-alpha-1 > > > > > > 1.5 > > > 1.5 > > > > > > > > > > > > > > > > > > > > > > > > > > > org.apache.maven.plugins > > > maven-compiler-plugin > > > > > > > > > > > > > > > > > > Looking at this, I'm not 100% convinced that the implicit > > > configuration of maven-compiler-plugin is not > > appropriate...the only > > > question in that case is how to undo this configuration, > > which has the > > > same answer as undoing any configuration element: don't put > > it in the > > > shared configuration in the first place. All I'm attempting > > to
RE: [m2] POM inheritance
OK so my (hopefully) last question then is "How do I tell what the canonical list of 'Implied plugins like maven-compiler-plugin' is"? Thanks for the clarification (of the clarification ;-) Matthew > -Original Message- > From: John Casey [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 05, 2005 3:01 AM > To: Maven Users List > Subject: Re: [m2] POM inheritance > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Alright, this is the part where I print a complete retraction > of everything I just emailed to the list... :) > > Next time, I promise, I'll actually re-read the code and/or > do some Right-Click -> References -> Project in Eclipse for a > given piece of code before I shoot my mouth off. In reality, > Brett is 100% correct (he should be, he's looking at the code > right now :). Implied plugins like maven-compiler-plugin will > also trigger the configurations in on a > plugin-by-plugin basis. So, in reality, both of the examples > that I gave below will work to configure the compiler plugin. > > Sorry for the confusion, and I'll try not to yell my comments > in from the other room next time. :) > > john > > John Casey wrote: > > I have a refinement or two to this... > > > > Brett Porter wrote: > > > >>>John has just made a final fix. So, to summarise the > behaviour here: > >>> > >>>- is inherited > >>>- elements are merged together during inheritence > >>>- is NOT inherited > >>>- the final plugin management values are merged into the > > >>>element of the POM being built. > > > > > > This is critical: the configurations are ONLY > > activated if you declare a corresponding entry in > the build > > section's stanza. pluginManagement is an opt-in > system; it > > will only affect your build if you specifically invite it in. Also, > > you cannot opt-in for all of the managed configuration at one go. > > > > To be clear: The only way to use the configuration declared within > > section is to declare a corresponding > > entry within . The minimal information > > necessary to link a build's actual plugin to the > corresponding managed > > plugin information is and . > > > > This WILL NOT configure the source/target properties of the > > maven-compiler-plugin: > > > > > > ... > > > > > > > > > > org.apache.maven.plugins > > maven-compiler-plugin > > 1.0-alpha-1 > > > > 1.5 > > 1.5 > > > > > > > > > > > > > > > > The managed information will ONLY be used when you opt-in for that > > configuration by declaring the plugin for use in the build > section, like so: > > > > > > ... > > > > > > > > > > org.apache.maven.plugins > > maven-compiler-plugin > > 1.0-alpha-1 > > > > 1.5 > > 1.5 > > > > > > > > > > > > > > > > > > org.apache.maven.plugins > > maven-compiler-plugin > > > > > > > > > > > > Looking at this, I'm not 100% convinced that the implicit > > configuration of maven-compiler-plugin is not > appropriate...the only > > question in that case is how to undo this configuration, > which has the > > same answer as undoing any configuration element: don't put > it in the > > shared configuration in the first place. All I'm attempting > to do here > > is describe the way the current process functions...this > may change in > > the future. > > > > > >>>The downside here is that there is no way to exclude > something that > >>>has already been declared in a parent. This is intended - > if you come > >>>across the situation you can redefine it with a different > value, or > >>>you should not inherit the value. > >>> > >>>Why was this chosen, given the downside? > >>> > >>>The downside of going the other direction (where > configuration would > >>>completely replace anything given by the inherited > version) was much > >>>more confusing: options set for inheritence would have d
Re: [m2] POM inheritance
>>> >>>>John Casey wrote: >>>> >>> >>>I'm looking at: >>> >>>- org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler >>>- org.apache.maven.project.injection.DefaultModelDefaultsInjector >>> >>>and here's what I see: >>> >>>- Combination of inherited sections (both parent and >>>child have stuff defined): >>>-- >>> >>>Everything is merged, with locally specified elements overriding >>>ancestor-specified elements in the event of a tie. >>> >>>NOTE: There was a problem with the of a plugin not >>>being merged. I'm fixing this as we speak, although it's not going to be >>>in alpha-1 obviously... :) >>> >>> >>> >>>- Combination of local POM's with [inherited] >>> section: >>>-- >>> >>>HOW IT WORKS: elements (both on and on >>>) are combined, with ties going to the local configuration (if >>>the elements collide, the local specification wins). The list of goals >>>is accumulated, with the previous note applying to collisions of goals. >>>That is, if the section specifies some goals and >>>their configuration for a given plugin, and the section >>>specifies some goals, the goal definitions from the >>>section are merged into the one from the plugin specification itself. >>> >>>NOTE-TO-SELF: Now that I look at this, it might not be a Good Thing(tm). >>>For instance, how would I suppress a goal that was declared in >>> but allow other goals from that plugin to run? How >>>would I suppress plugin configuration declared similarly? >>> >>>HOW I'M FIXING IT TO WORK: Any or element >>>specified within a plugin in a local POM will negate the usage of the >>>corresponding element in the section for that >>>plugin. This allows users to specify local overrides without having to >>>deal with the accumulation of common settings which are wrong for the >>>local case but which are not overridden in the local POM. It also makes >>>the override mechanism more consistent with . >>> >>>These changes will not be available to -alpha-1, obviously, but should >>>work on the svn-trunk in a few minutes. >>> >>> >>>Hope this clears things up somewhat. :) >>> >>>Cheers, >>> >>>-john >>> >>> >>>J. Matthew Pryor wrote: >>> >>> >>> >>>>>From the docs here >>>>http://maven.apache.org/maven2/project-descriptor.html#Build about the >>>> element >>> >>>>Any local configuration for a given plugin will override the plugin's entire >>>>definition here. >>> >>>>So what constitutes 'local configuration'. If I am to reference the plugin, >>>>enough to invoke the configuration supplied in a parent , >>>>how do I do that without overriding the plugin's entire definition? >>> >>>>Also am I understanding correctly that setting are never >>>>inherited? >>> >>>>BTW I am making good progress writing all this up for the user docs. >>>>Definitely need this clarification >>> >>>>jmp >>> >>> >>> >>> >>>>>-Original Message- >>>>>From: Peter van de Hoef [mailto:[EMAIL PROTECTED] >>>>>Sent: Wednesday, April 27, 2005 6:32 PM >>>>>To: Maven Users List >>>>>Subject: Re: [m2] POM inheritance >>>>> >>>>>Hi John, >>>>> >>>>>Thanks for your help. So is used for >>>>>specifying plugin versions and configuration parameters, >>>>>whether they are used or not. This will be inherited by child >>>>>projects. The section is just a list of plugins >>>>>that will actually be used. This list has to be repeated in a >>>>>child project though, whenever a setting of build-section has >>>>>to be changed. >>>>> >>>>>Now, I have specified a section in the >>>>>parent POM, in the hope that it gets inherited by derived >>>>>projects, but it does not; in the child project, the java >>>>>compiler starts complaining about assertions again. >>>>>
Re: [m2] POM inheritance
OTE-TO-SELF: Now that I look at this, it might not be a Good Thing(tm). > For instance, how would I suppress a goal that was declared in > but allow other goals from that plugin to run? How > would I suppress plugin configuration declared similarly? > > HOW I'M FIXING IT TO WORK: Any or element > specified within a plugin in a local POM will negate the usage of the > corresponding element in the section for that > plugin. This allows users to specify local overrides without having to > deal with the accumulation of common settings which are wrong for the > local case but which are not overridden in the local POM. It also makes > the override mechanism more consistent with . > > These changes will not be available to -alpha-1, obviously, but should > work on the svn-trunk in a few minutes. > > > Hope this clears things up somewhat. :) > > Cheers, > > -john > > > J. Matthew Pryor wrote: > > >>>From the docs here >>http://maven.apache.org/maven2/project-descriptor.html#Build about the >> element > >>Any local configuration for a given plugin will override the plugin's entire >>definition here. > >>So what constitutes 'local configuration'. If I am to reference the plugin, >>enough to invoke the configuration supplied in a parent , >>how do I do that without overriding the plugin's entire definition? > >>Also am I understanding correctly that setting are never >>inherited? > >>BTW I am making good progress writing all this up for the user docs. >>Definitely need this clarification > >>jmp > > > > >>>-Original Message- >>>From: Peter van de Hoef [mailto:[EMAIL PROTECTED] >>>Sent: Wednesday, April 27, 2005 6:32 PM >>>To: Maven Users List >>>Subject: Re: [m2] POM inheritance >>> >>>Hi John, >>> >>>Thanks for your help. So is used for >>>specifying plugin versions and configuration parameters, >>>whether they are used or not. This will be inherited by child >>>projects. The section is just a list of plugins >>>that will actually be used. This list has to be repeated in a >>>child project though, whenever a setting of build-section has >>>to be changed. >>> >>>Now, I have specified a section in the >>>parent POM, in the hope that it gets inherited by derived >>>projects, but it does not; in the child project, the java >>>compiler starts complaining about assertions again. >>> >>>The only way to solve this is to repeat myself by inserting a >>>copy of the section of the parent into the child. >>> >>>If I look at 'DefaultModelInheritanceAssembler.java' it >>>appears that the assemblePluginManagementInheritance() >>>function correctly takes care of sections >>>of the parent. >>>What is going wrong here? Did I miss something in the project defs? >>> >>>The parent POM looks like: >>> >>> >>> >>>Parent POM >>> >>>_test >>>parent >>>1.0 >>>pom >>> >>> >>>child >>> >>> >>> >>>src >>> >>> >>> >>> >>> >>>org.apache.maven.plugins >>> >>>maven-compiler-plugin >>> >>>1.0-alpha-2-SNAPSHOT >>> >>>1.5 >>>1.5 >>> >>> >>> >>> >>> >>> >>> >>> >>>org.apache.maven.plugins >>> >>>maven-compiler-plugin >>> >>> >>> >>> >>> >>> >>>And the child, which inherits from the parent: >>>The section is overridden with a different >>> and, since the of the parent gets >>>lost, it is repeated. >>> >>> >>> >>>Child POM >>> >>>_test >>>child >>>1.0 >>>pom >>> >>> >>>_test >>>parent >>>1.0 >>> >>> >>> >>>src2 >>> >>>
Re: [m2] POM inheritance
John has just made a final fix. So, to summarise the behaviour here: - is inherited - elements are merged together during inheritence - is NOT inherited - the final plugin management values are merged into the element of the POM being built. The downside here is that there is no way to exclude something that has already been declared in a parent. This is intended - if you come across the situation you can redefine it with a different value, or you should not inherit the value. Why was this chosen, given the downside? The downside of going the other direction (where configuration would completely replace anything given by the inherited version) was much more confusing: options set for inheritence would have disappeared from children. If anyone has any questions, please say so. J. Matthew Pryor has volunteered to help document this, so it should be available on the web site in time. Cheers, Brett On 4/28/05, Peter van de Hoef <[EMAIL PROTECTED]> wrote: > Hi John, > > I've been away for a while and see that a lot of activity has been going on > in the meantime! > Since I am just an m2 newbee, I cannot oversee if the issues arround > and sections have been > resolved now. So I filed the issue anyway > (http://jira.codehaus.org/browse/MNG-362). Please ignore it > if it has already been fixed now. > > I will try to build the latest from SVN and perform some tests with my own > projects. > > Thanks for all the good work. > Peter van de Hoef > > John Casey wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > I'm looking at: > > > > - - org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler > > - - org.apache.maven.project.injection.DefaultModelDefaultsInjector > > > > and here's what I see: > > > > - - Combination of inherited sections (both parent and > > child have stuff defined): > > - -- > > > > Everything is merged, with locally specified elements overriding > > ancestor-specified elements in the event of a tie. > > > > NOTE: There was a problem with the of a plugin not > > being merged. I'm fixing this as we speak, although it's not going to be > > in alpha-1 obviously... :) > > > > > > > > - - Combination of local POM's with [inherited] > > section: > > - -- > > > > HOW IT WORKS: elements (both on and on > > ) are combined, with ties going to the local configuration (if > > the elements collide, the local specification wins). The list of goals > > is accumulated, with the previous note applying to collisions of goals. > > That is, if the section specifies some goals and > > their configuration for a given plugin, and the section > > specifies some goals, the goal definitions from the > > section are merged into the one from the plugin specification itself. > > > > NOTE-TO-SELF: Now that I look at this, it might not be a Good Thing(tm). > > For instance, how would I suppress a goal that was declared in > > but allow other goals from that plugin to run? How > > would I suppress plugin configuration declared similarly? > > > > HOW I'M FIXING IT TO WORK: Any or element > > specified within a plugin in a local POM will negate the usage of the > > corresponding element in the section for that > > plugin. This allows users to specify local overrides without having to > > deal with the accumulation of common settings which are wrong for the > > local case but which are not overridden in the local POM. It also makes > > the override mechanism more consistent with . > > > > These changes will not be available to -alpha-1, obviously, but should > > work on the svn-trunk in a few minutes. > > > > > > Hope this clears things up somewhat. :) > > > > Cheers, > > > > - -john > > > > > > J. Matthew Pryor wrote: > > > >>>From the docs here > >>http://maven.apache.org/maven2/project-descriptor.html#Build about the > >> element > >> > >>Any local configuration for a given plugin will override the plugin's entire > >>definition here. > >> > >>So what constitutes 'local configuration'. If I am to reference the plugin, > >>enough to invoke the configuration supplied in a parent , > >>how do I do that without overriding the plugin's entire definition? > >> > >>Also am I understanding correctly that setting are never > >>inherited? >
Re: [m2] POM inheritance
Hi John, I've been away for a while and see that a lot of activity has been going on in the meantime! Since I am just an m2 newbee, I cannot oversee if the issues arround and sections have been resolved now. So I filed the issue anyway (http://jira.codehaus.org/browse/MNG-362). Please ignore it if it has already been fixed now. I will try to build the latest from SVN and perform some tests with my own projects. Thanks for all the good work. Peter van de Hoef John Casey wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm looking at: - - org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler - - org.apache.maven.project.injection.DefaultModelDefaultsInjector and here's what I see: - - Combination of inherited sections (both parent and child have stuff defined): - -- Everything is merged, with locally specified elements overriding ancestor-specified elements in the event of a tie. NOTE: There was a problem with the of a plugin not being merged. I'm fixing this as we speak, although it's not going to be in alpha-1 obviously... :) - - Combination of local POM's with [inherited] section: - -- HOW IT WORKS: elements (both on and on ) are combined, with ties going to the local configuration (if the elements collide, the local specification wins). The list of goals is accumulated, with the previous note applying to collisions of goals. That is, if the section specifies some goals and their configuration for a given plugin, and the section specifies some goals, the goal definitions from the section are merged into the one from the plugin specification itself. NOTE-TO-SELF: Now that I look at this, it might not be a Good Thing(tm). For instance, how would I suppress a goal that was declared in but allow other goals from that plugin to run? How would I suppress plugin configuration declared similarly? HOW I'M FIXING IT TO WORK: Any or element specified within a plugin in a local POM will negate the usage of the corresponding element in the section for that plugin. This allows users to specify local overrides without having to deal with the accumulation of common settings which are wrong for the local case but which are not overridden in the local POM. It also makes the override mechanism more consistent with . These changes will not be available to -alpha-1, obviously, but should work on the svn-trunk in a few minutes. Hope this clears things up somewhat. :) Cheers, - -john J. Matthew Pryor wrote: From the docs here http://maven.apache.org/maven2/project-descriptor.html#Build about the element Any local configuration for a given plugin will override the plugin's entire definition here. So what constitutes 'local configuration'. If I am to reference the plugin, enough to invoke the configuration supplied in a parent , how do I do that without overriding the plugin's entire definition? Also am I understanding correctly that setting are never inherited? BTW I am making good progress writing all this up for the user docs. Definitely need this clarification jmp -Original Message- From: Peter van de Hoef [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 27, 2005 6:32 PM To: Maven Users List Subject: Re: [m2] POM inheritance Hi John, Thanks for your help. So is used for specifying plugin versions and configuration parameters, whether they are used or not. This will be inherited by child projects. The section is just a list of plugins that will actually be used. This list has to be repeated in a child project though, whenever a setting of build-section has to be changed. Now, I have specified a section in the parent POM, in the hope that it gets inherited by derived projects, but it does not; in the child project, the java compiler starts complaining about assertions again. The only way to solve this is to repeat myself by inserting a copy of the section of the parent into the child. If I look at 'DefaultModelInheritanceAssembler.java' it appears that the assemblePluginManagementInheritance() function correctly takes care of sections of the parent. What is going wrong here? Did I miss something in the project defs? The parent POM looks like: Parent POM _test parent 1.0 pom child src org.apache.maven.plugins maven-compiler-plugin 1.0-alpha-2-SNAPSHOT
Re: [m2] POM inheritance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm looking at: - - org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler - - org.apache.maven.project.injection.DefaultModelDefaultsInjector and here's what I see: - - Combination of inherited sections (both parent and child have stuff defined): - -- Everything is merged, with locally specified elements overriding ancestor-specified elements in the event of a tie. NOTE: There was a problem with the of a plugin not being merged. I'm fixing this as we speak, although it's not going to be in alpha-1 obviously... :) - - Combination of local POM's with [inherited] section: - -- HOW IT WORKS: elements (both on and on ) are combined, with ties going to the local configuration (if the elements collide, the local specification wins). The list of goals is accumulated, with the previous note applying to collisions of goals. That is, if the section specifies some goals and their configuration for a given plugin, and the section specifies some goals, the goal definitions from the section are merged into the one from the plugin specification itself. NOTE-TO-SELF: Now that I look at this, it might not be a Good Thing(tm). For instance, how would I suppress a goal that was declared in but allow other goals from that plugin to run? How would I suppress plugin configuration declared similarly? HOW I'M FIXING IT TO WORK: Any or element specified within a plugin in a local POM will negate the usage of the corresponding element in the section for that plugin. This allows users to specify local overrides without having to deal with the accumulation of common settings which are wrong for the local case but which are not overridden in the local POM. It also makes the override mechanism more consistent with . These changes will not be available to -alpha-1, obviously, but should work on the svn-trunk in a few minutes. Hope this clears things up somewhat. :) Cheers, - -john J. Matthew Pryor wrote: >>From the docs here > http://maven.apache.org/maven2/project-descriptor.html#Build about the > element > > Any local configuration for a given plugin will override the plugin's entire > definition here. > > So what constitutes 'local configuration'. If I am to reference the plugin, > enough to invoke the configuration supplied in a parent , > how do I do that without overriding the plugin's entire definition? > > Also am I understanding correctly that setting are never > inherited? > > BTW I am making good progress writing all this up for the user docs. > Definitely need this clarification > > jmp > > >>-Original Message- >>From: Peter van de Hoef [mailto:[EMAIL PROTECTED] >>Sent: Wednesday, April 27, 2005 6:32 PM >>To: Maven Users List >>Subject: Re: [m2] POM inheritance >> >>Hi John, >> >>Thanks for your help. So is used for >>specifying plugin versions and configuration parameters, >>whether they are used or not. This will be inherited by child >>projects. The section is just a list of plugins >>that will actually be used. This list has to be repeated in a >>child project though, whenever a setting of build-section has >>to be changed. >> >>Now, I have specified a section in the >>parent POM, in the hope that it gets inherited by derived >>projects, but it does not; in the child project, the java >>compiler starts complaining about assertions again. >> >>The only way to solve this is to repeat myself by inserting a >>copy of the section of the parent into the child. >> >>If I look at 'DefaultModelInheritanceAssembler.java' it >>appears that the assemblePluginManagementInheritance() >>function correctly takes care of sections >>of the parent. >>What is going wrong here? Did I miss something in the project defs? >> >>The parent POM looks like: >> >> >> >> Parent POM >> >> _test >> parent >> 1.0 >> pom >> >> >> child >> >> >> >> src >> >> >> >> >> >>org.apache.maven.plugins >> >>maven-compiler-plugin >> >>1.0-alpha-2-SNAPSHOT >> >> 1.5 >>
RE: [m2] POM inheritance
>From the docs here http://maven.apache.org/maven2/project-descriptor.html#Build about the element Any local configuration for a given plugin will override the plugin's entire definition here. So what constitutes 'local configuration'. If I am to reference the plugin, enough to invoke the configuration supplied in a parent , how do I do that without overriding the plugin's entire definition? Also am I understanding correctly that setting are never inherited? BTW I am making good progress writing all this up for the user docs. Definitely need this clarification jmp > -Original Message- > From: Peter van de Hoef [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 27, 2005 6:32 PM > To: Maven Users List > Subject: Re: [m2] POM inheritance > > Hi John, > > Thanks for your help. So is used for > specifying plugin versions and configuration parameters, > whether they are used or not. This will be inherited by child > projects. The section is just a list of plugins > that will actually be used. This list has to be repeated in a > child project though, whenever a setting of build-section has > to be changed. > > Now, I have specified a section in the > parent POM, in the hope that it gets inherited by derived > projects, but it does not; in the child project, the java > compiler starts complaining about assertions again. > > The only way to solve this is to repeat myself by inserting a > copy of the section of the parent into the child. > > If I look at 'DefaultModelInheritanceAssembler.java' it > appears that the assemblePluginManagementInheritance() > function correctly takes care of sections > of the parent. > What is going wrong here? Did I miss something in the project defs? > > The parent POM looks like: > > > > Parent POM > > _test > parent > 1.0 > pom > > > child > > > > src > > > > > > org.apache.maven.plugins > > maven-compiler-plugin > > 1.0-alpha-2-SNAPSHOT > > 1.5 > 1.5 > > > > > > > > > org.apache.maven.plugins > > maven-compiler-plugin > > > > > > > And the child, which inherits from the parent: > The section is overridden with a different > and, since the of the parent gets > lost, it is repeated. > > > > Child POM > > _test > child > 1.0 > pom > > > _test > parent > 1.0 > > > > src2 > > > > org.apache.maven.plugins > > maven-compiler-plugin > > > > > > Thanks in advance, > Peter van de Hoef > > John Casey wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > > > Sorry, I forgot all about the design decisions surrounding > this... :) > > > > Actually, our original decision was to disallow inheritance of any > > plugin configuration, since plugin configuration can (and usually > > will) modify the build lifecycle for that project. In light > of this, > > inherited plugin configuration could lead to somewhat > > counter-intuitive build behavior. > > > > We have a section of the POM for common > > configuration of plugins for use within a typical > multiproject-style > > setup. It would be used like this: > > > > parent-pom.xml > > - --- > > ... > > > > > > > > org.apache.maven.plugin > > maven-something-plugin > > 1.4 > > > > someValue > > > > > > > > > > ... > > - --- > > > > child-pom.xml > > - --- > > ... > > > > test > > &
Re: [m2] POM inheritance
That's all right, no problem. In that way I can add a small contribution to the
great work you are doing!
I will add some test files as attachment.
John Casey wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'll try to put together a test and fix whatever's causing this. Hate to
say this again, but would you mind submitting a JIRA issue for it? :)
That'll remind me.
Peter van de Hoef wrote:
Hi John,
Thanks for your help. So is used for specifying
plugin versions and configuration parameters, whether they are used or
not. This will be inherited by child projects. The section is
just a list of plugins that will actually be used. This list has to be
repeated in a child project though, whenever a setting of build-section
has to be changed.
Now, I have specified a section in the parent POM, in
the hope that it gets inherited by derived projects, but it does not; in
the child project, the java compiler starts complaining about assertions
again.
The only way to solve this is to repeat myself by inserting a copy of
the section of the parent into the child.
If I look at 'DefaultModelInheritanceAssembler.java' it appears that the
assemblePluginManagementInheritance() function correctly takes care of
sections of the parent.
What is going wrong here? Did I miss something in the project defs?
The parent POM looks like:
Parent POM
_test
parent
1.0
pom
child
src
org.apache.maven.plugins
maven-compiler-plugin
1.0-alpha-2-SNAPSHOT
1.5
1.5
org.apache.maven.plugins
maven-compiler-plugin
And the child, which inherits from the parent:
The section is overridden with a different
and, since the of the parent gets lost, it is repeated.
Child POM
_test
child
1.0
pom
_test
parent
1.0
src2
org.apache.maven.plugins
maven-compiler-plugin
Thanks in advance,
Peter van de Hoef
John Casey wrote:
Sorry, I forgot all about the design decisions surrounding this... :)
Actually, our original decision was to disallow inheritance of any
plugin configuration, since plugin configuration can (and usually will)
modify the build lifecycle for that project. In light of this, inherited
plugin configuration could lead to somewhat counter-intuitive build
behavior.
We have a section of the POM for common
configuration of plugins for use within a typical multiproject-style
setup. It would be used like this:
parent-pom.xml
---
...
org.apache.maven.plugin
maven-something-plugin
1.4
someValue
...
---
child-pom.xml
---
...
test
...
org.apache.maven.plugin
...
---
If you need to override some setting from the pluginManagement section,
just specify it locally; more local specification in an inheritance
hierarchy wins.
Will this solve your problem?
HTH,
john
Peter van de Hoef wrote:
Thanks for your reply.
Now I see why the complete section is inherited when it is
absent in the child:
*if* ( childBuild == *null* )
{
child.setBuild( parentBuild );
}
*else*
{
/// A lot of fields are inherited, except
/}
I understand that inheriting plugins is problematic, since Maven does
not 'know' about the plugin parameters and cannot decide their
inheritance rules.
Wouldn't it be possible to inherit the complete section if it
is not specified in the child, just like you do with and
?
That seems IMHO more in line with the situation where there is no
section at all. In that way it is possible to 'tweak' the build
settings slightly without losing the major build logic.
- Peter
Jason van Zyl wrote:
On Tue, 2005-04-26 at 21:00 +0200, Peter van de Hoef wrote:
Hi all,
I have a question about which elements of the POM are inherited by
derived POM's.
The law on inheritance resides here:
http://svn.apache.org/viewcvs.cgi/maven/components/trunk/maven-
project/src/main/java/org/apache/maven/project/inheritance/DefaultModelInheritanceAssembler.java?rev=164217&sortdir=down&view=log
In my parent POM I have a section which specifies the source
directory and some parameters for the java compiler:
src
org.apache.maven.plugins
maven-compiler-plugin
1.0-alpha-2-SNAPSHOT
1.5
1.5
In a derived POM, the source directoriy is different, so a new
section is specified:
module/src
The overridden source directory is effectuated in this sec
Re: [m2] POM inheritance
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'll try to put together a test and fix whatever's causing this. Hate to
say this again, but would you mind submitting a JIRA issue for it? :)
That'll remind me.
Peter van de Hoef wrote:
> Hi John,
>
> Thanks for your help. So is used for specifying
> plugin versions and configuration parameters, whether they are used or
> not. This will be inherited by child projects. The section is
> just a list of plugins that will actually be used. This list has to be
> repeated in a child project though, whenever a setting of build-section
> has to be changed.
>
> Now, I have specified a section in the parent POM, in
> the hope that it gets inherited by derived projects, but it does not; in
> the child project, the java compiler starts complaining about assertions
> again.
>
> The only way to solve this is to repeat myself by inserting a copy of
> the section of the parent into the child.
>
> If I look at 'DefaultModelInheritanceAssembler.java' it appears that the
> assemblePluginManagementInheritance() function correctly takes care of
> sections of the parent.
> What is going wrong here? Did I miss something in the project defs?
>
> The parent POM looks like:
>
>
>
> Parent POM
>
> _test
> parent
> 1.0
> pom
>
>
> child
>
>
>
> src
>
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 1.0-alpha-2-SNAPSHOT
>
> 1.5
> 1.5
>
>
>
>
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
>
>
>
>
>
>
> And the child, which inherits from the parent:
> The section is overridden with a different
> and, since the of the parent gets lost, it is repeated.
>
>
>
> Child POM
>
> _test
> child
> 1.0
> pom
>
>
> _test
> parent
> 1.0
>
>
>
> src2
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
>
>
>
>
>
> Thanks in advance,
> Peter van de Hoef
>
> John Casey wrote:
>
>
> Sorry, I forgot all about the design decisions surrounding this... :)
>
> Actually, our original decision was to disallow inheritance of any
> plugin configuration, since plugin configuration can (and usually will)
> modify the build lifecycle for that project. In light of this, inherited
> plugin configuration could lead to somewhat counter-intuitive build
> behavior.
>
> We have a section of the POM for common
> configuration of plugins for use within a typical multiproject-style
> setup. It would be used like this:
>
> parent-pom.xml
> ---
> ...
>
>
>
> org.apache.maven.plugin
> maven-something-plugin
> 1.4
>
> someValue
>
>
>
>
> ...
> ---
>
> child-pom.xml
> ---
> ...
>
> test
>
> ...
>
>
>
> org.apache.maven.plugin
>
> ...
> ---
>
> If you need to override some setting from the pluginManagement section,
> just specify it locally; more local specification in an inheritance
> hierarchy wins.
>
> Will this solve your problem?
>
> HTH,
>
> john
>
>
> Peter van de Hoef wrote:
>
Thanks for your reply.
Now I see why the complete section is inherited when it is
absent in the child:
*if* ( childBuild == *null* )
{
child.setBuild( parentBuild );
}
*else*
{
/// A lot of fields are inherited, except
/}
I understand that inheriting plugins is problematic, since Maven does
not 'know' about the plugin parameters and cannot decide their
inheritance rules.
Wouldn't it be possible to inherit the complete section if it
is not specified in the child, just like you do with and
?
That seems IMHO more in line with the situation where there is no
section at all. In that way it is possible to 'tweak' the build
settings slightly without losing the major build logic.
- Peter
Jason van Zyl wrote:
> On Tue, 2005-04-26 at 21:00 +0200, Peter van de Hoef wrote:
>
>
>
>> Hi all,
>>
>> I have a question about which elements of the POM are inherited by
>> derived POM's.
>>
>
>
>
> The law on inheritance resides here:
>
> http://svn.apache.org/viewcvs.cgi/maven/components/trunk/maven-
> project/src/main/java/org/apache/maven/project/inheritance/DefaultModelInheritanceAssembler.java?rev=164217&sortdir=down&view=log
>
>
Re: [m2] POM inheritance
Hi John,
Thanks for your help. So is used for specifying plugin versions and configuration parameters, whether
they are used or not. This will be inherited by child projects. The section is just a list of plugins that
will actually be used. This list has to be repeated in a child project though, whenever a setting of build-section has
to be changed.
Now, I have specified a section in the parent POM, in the hope that it gets inherited by derived
projects, but it does not; in the child project, the java compiler starts complaining about assertions again.
The only way to solve this is to repeat myself by inserting a copy of the section of the parent into
the child.
If I look at 'DefaultModelInheritanceAssembler.java' it appears that the assemblePluginManagementInheritance() function
correctly takes care of sections of the parent.
What is going wrong here? Did I miss something in the project defs?
The parent POM looks like:
Parent POM
_test
parent
1.0
pom
child
src
org.apache.maven.plugins
maven-compiler-plugin
1.0-alpha-2-SNAPSHOT
1.5
1.5
org.apache.maven.plugins
maven-compiler-plugin
And the child, which inherits from the parent:
The section is overridden with a different and, since the of the parent gets lost,
it is repeated.
Child POM
_test
child
1.0
pom
_test
parent
1.0
src2
org.apache.maven.plugins
maven-compiler-plugin
Thanks in advance,
Peter van de Hoef
John Casey wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sorry, I forgot all about the design decisions surrounding this... :)
Actually, our original decision was to disallow inheritance of any
plugin configuration, since plugin configuration can (and usually will)
modify the build lifecycle for that project. In light of this, inherited
plugin configuration could lead to somewhat counter-intuitive build
behavior.
We have a section of the POM for common
configuration of plugins for use within a typical multiproject-style
setup. It would be used like this:
parent-pom.xml
- ---
...
org.apache.maven.plugin
maven-something-plugin
1.4
someValue
...
- ---
child-pom.xml
- ---
...
test
...
org.apache.maven.plugin
...
- ---
If you need to override some setting from the pluginManagement section,
just specify it locally; more local specification in an inheritance
hierarchy wins.
Will this solve your problem?
HTH,
john
Peter van de Hoef wrote:
Thanks for your reply.
Now I see why the complete section is inherited when it is
absent in the child:
*if* ( childBuild == *null* )
{
child.setBuild( parentBuild );
}
*else*
{
/// A lot of fields are inherited, except
/}
I understand that inheriting plugins is problematic, since Maven does
not 'know' about the plugin parameters and cannot decide their
inheritance rules.
Wouldn't it be possible to inherit the complete section if it
is not specified in the child, just like you do with and
?
That seems IMHO more in line with the situation where there is no
section at all. In that way it is possible to 'tweak' the build
settings slightly without losing the major build logic.
- Peter
Jason van Zyl wrote:
On Tue, 2005-04-26 at 21:00 +0200, Peter van de Hoef wrote:
Hi all,
I have a question about which elements of the POM are inherited by
derived POM's.
The law on inheritance resides here:
http://svn.apache.org/viewcvs.cgi/maven/components/trunk/maven-
project/src/main/java/org/apache/maven/project/inheritance/DefaultModelInheritanceAssembler.java?rev=164217&sortdir=down&view=log
In my parent POM I have a section which specifies the source
directory and some parameters for the java compiler:
src
org.apache.maven.plugins
maven-compiler-plugin
1.0-alpha-2-SNAPSHOT
Re: [m2] POM inheritance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I think those are perfect places to start, and we're working in xdoc. dunno if you're familiar with that from m1, but it's a modified version of html with some shorthands for document layout...let me know if you have questions. Brett, any other thoughts? - -john J. Matthew Pryor wrote: > Tell me when we should take this off-list, but are: > > # plugin management > # plugin configuration > > safe areas to work? That is the basic topic we were > discussing. > > Also what format should I work in? > > Cheers, > jmp > > --- John Casey <[EMAIL PROTECTED]> wrote: > > I've started writing a large-project management > overview, and I'm queued > up on the managedDependencies doc (I have a blog > entry waiting to go out > for when it's done ;) > > Beyond that, pleased to have the help! > > -john > > Brett Porter wrote: > >>>Being practical, out in the wild is out in the > > wild and no amount of hand > >>>waving and beta-warning will prevent some people > > from forming impressions. > >>>I think it is fair to say that the importance of > > great documentation can't > >>>be over-estimated so I'd be happy to help out > > anywhere it might be needed. > > >>We'll take you up on that - thanks for the offer. >>http://maven.apache.org/maven2/docs-required.html >>Just let us know what you'd like to work on so we > > make sure we aren't > >>conflicting. John, have you started on the > > management doco already? > > >>>Imagine beta-software with release quality docs > > ;-) > > >>Sure - we've made a commitment to work on that. > >>- Brett > > > >> - > >>To unsubscribe, e-mail: > > [EMAIL PROTECTED] > >>For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCbwsvK3h2CZwO/4URAkrgAJ49L/pG8BG/iwYZjIC0AYhrsLzluQCfeYsz jBr1m6EGfq+qUjxEXLBvY6U= =hIRH -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] POM inheritance
Tell me when we should take this off-list, but are: # plugin management # plugin configuration safe areas to work? That is the basic topic we were discussing. Also what format should I work in? Cheers, jmp --- John Casey <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I've started writing a large-project management > overview, and I'm queued > up on the managedDependencies doc (I have a blog > entry waiting to go out > for when it's done ;) > > Beyond that, pleased to have the help! > > - -john > > Brett Porter wrote: > >>Being practical, out in the wild is out in the > wild and no amount of hand > >>waving and beta-warning will prevent some people > from forming impressions. > >> > >>I think it is fair to say that the importance of > great documentation can't > >>be over-estimated so I'd be happy to help out > anywhere it might be needed. > > > > > > We'll take you up on that - thanks for the offer. > > http://maven.apache.org/maven2/docs-required.html > > Just let us know what you'd like to work on so we > make sure we aren't > > conflicting. John, have you started on the > management doco already? > > > > > >>Imagine beta-software with release quality docs > ;-) > > > > > > Sure - we've made a commitment to work on that. > > > > - Brett > > > > > - > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.2.6 (GNU/Linux) > > iD8DBQFCbtFhK3h2CZwO/4URAjEiAJ44+WkP0cmlvXGHA9bmM0a7lJ8SEQCfaPhe > 2yeRuUS3fypHL0uNsL7BXms= > =ef31 > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] POM inheritance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've started writing a large-project management overview, and I'm queued up on the managedDependencies doc (I have a blog entry waiting to go out for when it's done ;) Beyond that, pleased to have the help! - -john Brett Porter wrote: >>Being practical, out in the wild is out in the wild and no amount of hand >>waving and beta-warning will prevent some people from forming impressions. >> >>I think it is fair to say that the importance of great documentation can't >>be over-estimated so I'd be happy to help out anywhere it might be needed. > > > We'll take you up on that - thanks for the offer. > http://maven.apache.org/maven2/docs-required.html > Just let us know what you'd like to work on so we make sure we aren't > conflicting. John, have you started on the management doco already? > > >>Imagine beta-software with release quality docs ;-) > > > Sure - we've made a commitment to work on that. > > - Brett > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCbtFhK3h2CZwO/4URAjEiAJ44+WkP0cmlvXGHA9bmM0a7lJ8SEQCfaPhe 2yeRuUS3fypHL0uNsL7BXms= =ef31 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] POM inheritance
> Being practical, out in the wild is out in the wild and no amount of hand > waving and beta-warning will prevent some people from forming impressions. > > I think it is fair to say that the importance of great documentation can't > be over-estimated so I'd be happy to help out anywhere it might be needed. We'll take you up on that - thanks for the offer. http://maven.apache.org/maven2/docs-required.html Just let us know what you'd like to work on so we make sure we aren't conflicting. John, have you started on the management doco already? > > Imagine beta-software with release quality docs ;-) Sure - we've made a commitment to work on that. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] POM inheritance
> I actually am working on doco for the various management > features. I know this is vital, and it's not escaping in the > confusion. The documentation is coming, please bear with us. > This is still pre-beta software, after all... Totally understood, hence the offer of help. I very much appreciate that you guys are doing a stellar job here. Being practical, out in the wild is out in the wild and no amount of hand waving and beta-warning will prevent some people from forming impressions. I think it is fair to say that the importance of great documentation can't be over-estimated so I'd be happy to help out anywhere it might be needed. Imagine beta-software with release quality docs ;-) Matthew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] POM inheritance
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I actually am working on doco for the various management features. I
know this is vital, and it's not escaping in the confusion. The
documentation is coming, please bear with us. This is still pre-beta
software, after all...
- -john
J. Matthew Pryor wrote:
> As this *VITAL* information flies by on the mailing list, is there anyone
> updating the docs.
>
> I'd be happy to work up some of it into confluence or some such if that will
> help
>
> Matthew
>
>
>>-Original Message-
>>From: John Casey [mailto:[EMAIL PROTECTED]
>>Sent: Wednesday, April 27, 2005 8:14 AM
>>To: Maven Users List
>>Subject: Re: [m2] POM inheritance
>>
>
> Sorry, I forgot all about the design decisions surrounding this... :)
>
> Actually, our original decision was to disallow inheritance
> of any plugin configuration, since plugin configuration can
> (and usually will) modify the build lifecycle for that
> project. In light of this, inherited plugin configuration
> could lead to somewhat counter-intuitive build behavior.
>
> We have a section of the POM for common
> configuration of plugins for use within a typical
> multiproject-style setup. It would be used like this:
>
> parent-pom.xml
> ---
> ...
>
>
>
> org.apache.maven.plugin
> maven-something-plugin
> 1.4
>
> someValue
>
>
>
>
> ...
> ---
>
> child-pom.xml
> ---
> ...
>
> test
>
> ...
>
>
>
> org.apache.maven.plugin
>
> ...
> ---
>
> If you need to override some setting from the
> pluginManagement section, just specify it locally; more local
> specification in an inheritance hierarchy wins.
>
> Will this solve your problem?
>
> HTH,
>
> john
>
>
> Peter van de Hoef wrote:
>
>>Thanks for your reply.
>>Now I see why the complete section is inherited when it is
>>absent in the child:
>
>> *if* ( childBuild == *null* )
>> {
>> child.setBuild( parentBuild );
>> }
>> *else*
>> {
>> /// A lot of fields are inherited, except
>>/}
>
>>I understand that inheriting plugins is problematic, since
>
> Maven does
>
>>not 'know' about the plugin parameters and cannot decide their
>>inheritance rules.
>>Wouldn't it be possible to inherit the complete
>
> section if
>
>>it is not specified in the child, just like you do with
>>and ?
>>That seems IMHO more in line with the situation where there is no
>> section at all. In that way it is possible to 'tweak' the
>>build settings slightly without losing the major build logic.
>>- Peter
>
>>Jason van Zyl wrote:
>
>
>>>On Tue, 2005-04-26 at 21:00 +0200, Peter van de Hoef wrote:
>>>
>
>
>>>>Hi all,
>>>>
>>>>I have a question about which elements of the POM are
>
> inherited by
>
>>>>derived POM's.
>>>>
>
>
>>>The law on inheritance resides here:
>
>>>http://svn.apache.org/viewcvs.cgi/maven/components/trunk/maven-
>
>
> project/src/main/java/org/apache/maven/project/inheritance/DefaultMod
>
>>>elInheritanceAssembler.java?rev=164217&sortdir=down&view=log
>
>
>>>
>
>
>>>>In my parent POM I have a section which specifies
>
> the source
>
>>>>directory and some parameters for the java compiler:
>>>>
>>>>
>>>> src
>>>>
>>>>
>>>> org.apache.maven.plugins
>>>> maven-compiler-plugin
>>>> 1.0-alpha-2-SNAPSHOT
>>>>
>>>> 1.5
>>>> 1.5
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>In a derived POM, the source directoriy is different, so a new
>>>> section is specified:
>>>>
>>>>
>>>> module/src
>>>>
>>>>
>>>>The overridden source directory is effectuated in this
>
> second POM,
>
>>>>but it appears that the java compiler settings have
>
> disappeared (it
>
>>>>s
RE: [m2] POM inheritance
As this *VITAL* information flies by on the mailing list, is there anyone
updating the docs.
I'd be happy to work up some of it into confluence or some such if that will
help
Matthew
> -Original Message-
> From: John Casey [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, April 27, 2005 8:14 AM
> To: Maven Users List
> Subject: Re: [m2] POM inheritance
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> Sorry, I forgot all about the design decisions surrounding this... :)
>
> Actually, our original decision was to disallow inheritance
> of any plugin configuration, since plugin configuration can
> (and usually will) modify the build lifecycle for that
> project. In light of this, inherited plugin configuration
> could lead to somewhat counter-intuitive build behavior.
>
> We have a section of the POM for common
> configuration of plugins for use within a typical
> multiproject-style setup. It would be used like this:
>
> parent-pom.xml
> - ---
> ...
>
>
>
> org.apache.maven.plugin
> maven-something-plugin
> 1.4
>
> someValue
>
>
>
>
> ...
> - ---
>
> child-pom.xml
> - ---
> ...
>
> test
>
> ...
>
>
>
> org.apache.maven.plugin
>
> ...
> - ---
>
> If you need to override some setting from the
> pluginManagement section, just specify it locally; more local
> specification in an inheritance hierarchy wins.
>
> Will this solve your problem?
>
> HTH,
>
> john
>
>
> Peter van de Hoef wrote:
> > Thanks for your reply.
> > Now I see why the complete section is inherited when it is
> > absent in the child:
> >
> >*if* ( childBuild == *null* )
> >{
> >child.setBuild( parentBuild );
> >}
> >*else*
> >{
> >/// A lot of fields are inherited, except
> > /}
> >
> > I understand that inheriting plugins is problematic, since
> Maven does
> > not 'know' about the plugin parameters and cannot decide their
> > inheritance rules.
> > Wouldn't it be possible to inherit the complete
> section if
> > it is not specified in the child, just like you do with
> > and ?
> > That seems IMHO more in line with the situation where there is no
> > section at all. In that way it is possible to 'tweak' the
> > build settings slightly without losing the major build logic.
> > - Peter
> >
> > Jason van Zyl wrote:
> >
> >> On Tue, 2005-04-26 at 21:00 +0200, Peter van de Hoef wrote:
> >>
> >>
> >>> Hi all,
> >>>
> >>> I have a question about which elements of the POM are
> inherited by
> >>> derived POM's.
> >>>
> >>
> >>
> >> The law on inheritance resides here:
> >>
> >> http://svn.apache.org/viewcvs.cgi/maven/components/trunk/maven-
> >>
> project/src/main/java/org/apache/maven/project/inheritance/DefaultMod
> >> elInheritanceAssembler.java?rev=164217&sortdir=down&view=log
> >>
> >>
> >>
> >>
> >>> In my parent POM I have a section which specifies
> the source
> >>> directory and some parameters for the java compiler:
> >>>
> >>>
> >>>src
> >>>
> >>>
> >>>org.apache.maven.plugins
> >>>maven-compiler-plugin
> >>>1.0-alpha-2-SNAPSHOT
> >>>
> >>>1.5
> >>>1.5
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> In a derived POM, the source directoriy is different, so a new
> >>> section is specified:
> >>>
> >>>
> >>>module/src
> >>>
> >>>
> >>> The overridden source directory is effectuated in this
> second POM,
> >>> but it appears that the java compiler settings have
> disappeared (it
> >>> starts e.g. complaining about JDK 1.4 features like
> assertions). If
> >>> I do not specify a sectio
Re: [m2] POM inheritance
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sorry, I forgot all about the design decisions surrounding this... :)
Actually, our original decision was to disallow inheritance of any
plugin configuration, since plugin configuration can (and usually will)
modify the build lifecycle for that project. In light of this, inherited
plugin configuration could lead to somewhat counter-intuitive build
behavior.
We have a section of the POM for common
configuration of plugins for use within a typical multiproject-style
setup. It would be used like this:
parent-pom.xml
- ---
...
org.apache.maven.plugin
maven-something-plugin
1.4
someValue
...
- ---
child-pom.xml
- ---
...
test
...
org.apache.maven.plugin
...
- ---
If you need to override some setting from the pluginManagement section,
just specify it locally; more local specification in an inheritance
hierarchy wins.
Will this solve your problem?
HTH,
john
Peter van de Hoef wrote:
> Thanks for your reply.
> Now I see why the complete section is inherited when it is
> absent in the child:
>
>*if* ( childBuild == *null* )
>{
>child.setBuild( parentBuild );
>}
>*else*
>{
>/// A lot of fields are inherited, except
> /}
>
> I understand that inheriting plugins is problematic, since Maven does
> not 'know' about the plugin parameters and cannot decide their
> inheritance rules.
> Wouldn't it be possible to inherit the complete section if it
> is not specified in the child, just like you do with and
> ?
> That seems IMHO more in line with the situation where there is no
> section at all. In that way it is possible to 'tweak' the build
> settings slightly without losing the major build logic.
> - Peter
>
> Jason van Zyl wrote:
>
>> On Tue, 2005-04-26 at 21:00 +0200, Peter van de Hoef wrote:
>>
>>
>>> Hi all,
>>>
>>> I have a question about which elements of the POM are inherited by
>>> derived POM's.
>>>
>>
>>
>> The law on inheritance resides here:
>>
>> http://svn.apache.org/viewcvs.cgi/maven/components/trunk/maven-
>> project/src/main/java/org/apache/maven/project/inheritance/DefaultModelInheritanceAssembler.java?rev=164217&sortdir=down&view=log
>>
>>
>>
>>
>>> In my parent POM I have a section which specifies the source
>>> directory and some parameters for the java compiler:
>>>
>>>
>>>src
>>>
>>>
>>>org.apache.maven.plugins
>>>maven-compiler-plugin
>>>1.0-alpha-2-SNAPSHOT
>>>
>>>1.5
>>>1.5
>>>
>>>
>>>
>>>
>>>
>>> In a derived POM, the source directoriy is different, so a new
>>> section is specified:
>>>
>>>
>>>module/src
>>>
>>>
>>> The overridden source directory is effectuated in this second POM,
>>> but it appears that the java compiler settings have disappeared (it
>>> starts e.g. complaining about JDK 1.4 features like assertions). If I
>>> do not specify a section in the derived POM, the settings of
>>> the base POM are inherited.
>>>
>>> It appears that the section is (completely) inherited if it
>>> is not present in the derived POM, but if a section is
>>> specified in the derived POM, everything from the base POM is thrown
>>> away and only the settings of the derived POM are used.
>>> Is this correct?
>>>
>>
>>
>> We selectively choose what to inherit and the configuration for the
>> plug-ins are a little trickier because they free form configurations
>> essentially. We need to do a more careful merge of the configurations
>> but this might not work generally so if we need to allow the plugin to
>> determine how a configuration should be inherited then we'll probably
>> have to come up with some way to decide this using notations we have for
>> plugins. Anyway, I see you posted a JIRA issue so we'll take a look at
>> it.
>>
>>
>>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFCbr0UK3h2CZwO/4URAqFHAJ0ay0AvjZ6oniTE+FY2m+jNMqG76QCfVpxi
LNQUjh/RIpyil4bX6nB7RhE=
=rNwb
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] POM inheritance
Thanks for your reply.
Now I see why the complete section is inherited when it is
absent in the child:
*if* ( childBuild == *null* )
{
child.setBuild( parentBuild );
}
*else*
{
/// A lot of fields are inherited, except
/}
I understand that inheriting plugins is problematic, since Maven does
not 'know' about the plugin parameters and cannot decide their
inheritance rules.
Wouldn't it be possible to inherit the complete section if it
is not specified in the child, just like you do with and
?
That seems IMHO more in line with the situation where there is no
section at all. In that way it is possible to 'tweak' the build
settings slightly without losing the major build logic.
- Peter
Jason van Zyl wrote:
On Tue, 2005-04-26 at 21:00 +0200, Peter van de Hoef wrote:
Hi all,
I have a question about which elements of the POM are inherited by
derived POM's.
The law on inheritance resides here:
http://svn.apache.org/viewcvs.cgi/maven/components/trunk/maven-
project/src/main/java/org/apache/maven/project/inheritance/DefaultModelInheritanceAssembler.java?rev=164217&sortdir=down&view=log
In my parent POM I have a section which specifies the source
directory and some parameters for the java compiler:
src
org.apache.maven.plugins
maven-compiler-plugin
1.0-alpha-2-SNAPSHOT
1.5
1.5
In a derived POM, the source directoriy is different, so a new
section is specified:
module/src
The overridden source directory is effectuated in this second POM, but
it appears that the java compiler settings have disappeared (it starts
e.g. complaining about JDK 1.4 features like assertions). If I do not
specify a section in the derived POM, the settings of the base
POM are inherited.
It appears that the section is (completely) inherited if it is
not present in the derived POM, but if a section is specified in
the derived POM, everything from the base POM is thrown away and only
the settings of the derived POM are used.
Is this correct?
We selectively choose what to inherit and the configuration for the
plug-ins are a little trickier because they free form configurations
essentially. We need to do a more careful merge of the configurations
but this might not work generally so if we need to allow the plugin to
determine how a configuration should be inherited then we'll probably
have to come up with some way to decide this using notations we have for
plugins. Anyway, I see you posted a JIRA issue so we'll take a look at
it.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] POM inheritance
On Tue, 2005-04-26 at 21:00 +0200, Peter van de Hoef wrote: > Hi all, > > I have a question about which elements of the POM are inherited by > derived POM's. The law on inheritance resides here: http://svn.apache.org/viewcvs.cgi/maven/components/trunk/maven- project/src/main/java/org/apache/maven/project/inheritance/DefaultModelInheritanceAssembler.java?rev=164217&sortdir=down&view=log > In my parent POM I have a section which specifies the source > directory and some parameters for the java compiler: > > > src > > > org.apache.maven.plugins > maven-compiler-plugin > 1.0-alpha-2-SNAPSHOT > > 1.5 > 1.5 > > > > > > In a derived POM, the source directoriy is different, so a new > section is specified: > > > module/src > > > The overridden source directory is effectuated in this second POM, but > it appears that the java compiler settings have disappeared (it starts > e.g. complaining about JDK 1.4 features like assertions). If I do not > specify a section in the derived POM, the settings of the base > POM are inherited. > > It appears that the section is (completely) inherited if it is > not present in the derived POM, but if a section is specified in > the derived POM, everything from the base POM is thrown away and only > the settings of the derived POM are used. > Is this correct? We selectively choose what to inherit and the configuration for the plug-ins are a little trickier because they free form configurations essentially. We need to do a more careful merge of the configurations but this might not work generally so if we need to allow the plugin to determine how a configuration should be inherited then we'll probably have to come up with some way to decide this using notations we have for plugins. Anyway, I see you posted a JIRA issue so we'll take a look at it. -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] POM inheritance
Okay, I have added the issue: http://jira.codehaus.org/browse/MNG-357 Thanks for your time! - Peter John Casey wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It's entirely possible that our inheritance mechanism isn't completely right on this...can you please file a JIRA issue, and I'll look at it when I have some slack time. Thanks, - -john Peter van de Hoef wrote: Hi all, I have a question about which elements of the POM are inherited by derived POM's. In my parent POM I have a section which specifies the source directory and some parameters for the java compiler: src org.apache.maven.plugins maven-compiler-plugin 1.0-alpha-2-SNAPSHOT 1.5 1.5 In a derived POM, the source directoriy is different, so a new section is specified: module/src The overridden source directory is effectuated in this second POM, but it appears that the java compiler settings have disappeared (it starts e.g. complaining about JDK 1.4 features like assertions). If I do not specify a section in the derived POM, the settings of the base POM are inherited. It appears that the section is (completely) inherited if it is not present in the derived POM, but if a section is specified in the derived POM, everything from the base POM is thrown away and only the settings of the derived POM are used. Is this correct? Thanks in advance. Peter van de Hoef - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCbpDFK3h2CZwO/4URAiSnAJ9PEOiV+B3sG8oLg7dYQb/v8eSYHgCfYYdi jEQmZWa6JwLyEDZhSoYiw3E= =gP0+ -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] POM inheritance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It's entirely possible that our inheritance mechanism isn't completely right on this...can you please file a JIRA issue, and I'll look at it when I have some slack time. Thanks, - -john Peter van de Hoef wrote: > Hi all, > > I have a question about which elements of the POM are inherited by > derived POM's. > > In my parent POM I have a section which specifies the source > directory and some parameters for the java compiler: > > >src > > >org.apache.maven.plugins >maven-compiler-plugin >1.0-alpha-2-SNAPSHOT > >1.5 >1.5 > > > > > > In a derived POM, the source directoriy is different, so a new > section is specified: > > >module/src > > > The overridden source directory is effectuated in this second POM, but > it appears that the java compiler settings have disappeared (it starts > e.g. complaining about JDK 1.4 features like assertions). If I do not > specify a section in the derived POM, the settings of the base > POM are inherited. > > It appears that the section is (completely) inherited if it is > not present in the derived POM, but if a section is specified in > the derived POM, everything from the base POM is thrown away and only > the settings of the derived POM are used. > Is this correct? > > Thanks in advance. > Peter van de Hoef > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCbpDFK3h2CZwO/4URAiSnAJ9PEOiV+B3sG8oLg7dYQb/v8eSYHgCfYYdi jEQmZWa6JwLyEDZhSoYiw3E= =gP0+ -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] POM inheritance
Hi all, I have a question about which elements of the POM are inherited by derived POM's. In my parent POM I have a section which specifies the source directory and some parameters for the java compiler: src org.apache.maven.plugins maven-compiler-plugin 1.0-alpha-2-SNAPSHOT 1.5 1.5 In a derived POM, the source directoriy is different, so a new section is specified: module/src The overridden source directory is effectuated in this second POM, but it appears that the java compiler settings have disappeared (it starts e.g. complaining about JDK 1.4 features like assertions). If I do not specify a section in the derived POM, the settings of the base POM are inherited. It appears that the section is (completely) inherited if it is not present in the derived POM, but if a section is specified in the derived POM, everything from the base POM is thrown away and only the settings of the derived POM are used. Is this correct? Thanks in advance. Peter van de Hoef - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
