Re: Need to load common goals from sub-projects maven.xml
1) no, it matches project.xml inheritence 2) as for 1 On Thu, 1 Jul 2004 10:08:06 +0100, Matt Read <[EMAIL PROTECTED]> wrote: > > Thanks for the insight, it all makes sense and as a Maven user I fully > support the principle of putting control of the cross-cutting in the hands > of the user. > > I'm still interested to know the answers to the following in the context of > Maven 1.0: > > 1. Does maven.xml inheritance currently only happen when sub-projects run > within the reactor? > > 2. Does project.properties and build.properties inheritance currently only > happen when sub-projects are run within the reactor? > > If so, what's the reasoning behind this decision? > > Thanks, > Matt. > > > > > -Original Message- > > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > > Sent: 01 July 2004 06:13 > > To: Maven Users List > > Subject: Re: Need to load common goals from sub-projects maven.xml > > > > On Thu, 2004-07-01 at 00:22, Dion Gillard wrote: > > > On Thu, 1 Jul 2004 13:16:02 +1000, Brett Porter > > <[EMAIL PROTECTED]> wrote: > > > > > > > > It's a bad thing inside plugins though as you have these things > > > > sneaking into your build process. > > > > > > If they do nothing when not needed, as most of these do, > > then where's the harm. > > > > The complexity involved in managing the dependencies among > > the plugins. > > Brett is the only person besides myself that understands the > > clusterfuck of code required to manage goal decoration > > amongst plugins. It was removed as an option in m2 for > > clarity: goal decoration is only within the purview of the > > user. This pattern is used in many of the plugins we have in > > maven1 but it's not enforced. Plugins like the antlr plugin > > do some magic with pregoals and it's not clear at all what's going on. > > Plugins of the form that Vincent tends to use are clear > > because it is soley up to the user to perform the goal > > decoration in order to harness the functionality of a plugin. > > > > Allowing plugins to decorate goals from other plugins can > > lead to undeterministic behaviour, especially when it is so > > easy in maven1 to frob the context wherever you like, affect > > parent contexts and access variables from other plugins. A > > user explicity stating what is to happen in a build prevents > > unwanted side effects from plugins being added to the system. > > Right now in maven1 I could right a plugin that could > > adversely affect every build. A case in point being the old > > AspectJ plugin which decorated the standard compile goals > > which caused the AspectJ jars to be downloaded. This is all > > easily avoided by putting the control in the hands of the > > user where it belongs. > > > > The code required to manage goal decoration amonst plugins in > > maven1 is nothing short of a ratfuck. Purely unmanageable and > > requires some pretty funky contortions to make it work. The > > harm is potentially vast. > > > > > > In m2 the model is more along the lines of registration into the > > > > build process at defined points (like how xdoc/site does the > > > > reports) > > > > > > That sounds awfully like pre/post goals to me. So plugins would > > > 'register' to be invoked as part of the process? > > > > No, the plugins would not 'register' anything. The whole > > point of the change is to make explicit from the user's end > > how the plugins interact. > > How Vincent tends to use the plugins is how things should > > work in maven1 where the functionality is provided in the > > plugin but it is the responsibility of the user to decorate > > any desired goals to invoke the plugin in question. > > > > Plugins should be entirely indifferent to the process. How > > they are combined should be explicity controlled by the user > > for the sake of clarity, ease of use, and ease of maintenance. > > > > -- > > jvz. > > > > Jason van Zyl > > [EMAIL PROTECTED] > > http://maven.apache.org > > > > happiness is like a butterfly: the more you chase it, the > > more it will elude you, but if you turn your attention to > > other things, it will come and sit softly on your shoulder ... > > > > -- Thoreau > > > > > > - > > 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]
RE: Need to load common goals from sub-projects maven.xml
Thanks for the insight, it all makes sense and as a Maven user I fully support the principle of putting control of the cross-cutting in the hands of the user. I'm still interested to know the answers to the following in the context of Maven 1.0: 1. Does maven.xml inheritance currently only happen when sub-projects run within the reactor? 2. Does project.properties and build.properties inheritance currently only happen when sub-projects are run within the reactor? If so, what's the reasoning behind this decision? Thanks, Matt. > -Original Message- > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > Sent: 01 July 2004 06:13 > To: Maven Users List > Subject: Re: Need to load common goals from sub-projects maven.xml > > On Thu, 2004-07-01 at 00:22, Dion Gillard wrote: > > On Thu, 1 Jul 2004 13:16:02 +1000, Brett Porter > <[EMAIL PROTECTED]> wrote: > > > > > > It's a bad thing inside plugins though as you have these things > > > sneaking into your build process. > > > > If they do nothing when not needed, as most of these do, > then where's the harm. > > The complexity involved in managing the dependencies among > the plugins. > Brett is the only person besides myself that understands the > clusterfuck of code required to manage goal decoration > amongst plugins. It was removed as an option in m2 for > clarity: goal decoration is only within the purview of the > user. This pattern is used in many of the plugins we have in > maven1 but it's not enforced. Plugins like the antlr plugin > do some magic with pregoals and it's not clear at all what's going on. > Plugins of the form that Vincent tends to use are clear > because it is soley up to the user to perform the goal > decoration in order to harness the functionality of a plugin. > > Allowing plugins to decorate goals from other plugins can > lead to undeterministic behaviour, especially when it is so > easy in maven1 to frob the context wherever you like, affect > parent contexts and access variables from other plugins. A > user explicity stating what is to happen in a build prevents > unwanted side effects from plugins being added to the system. > Right now in maven1 I could right a plugin that could > adversely affect every build. A case in point being the old > AspectJ plugin which decorated the standard compile goals > which caused the AspectJ jars to be downloaded. This is all > easily avoided by putting the control in the hands of the > user where it belongs. > > The code required to manage goal decoration amonst plugins in > maven1 is nothing short of a ratfuck. Purely unmanageable and > requires some pretty funky contortions to make it work. The > harm is potentially vast. > > > > In m2 the model is more along the lines of registration into the > > > build process at defined points (like how xdoc/site does the > > > reports) > > > > That sounds awfully like pre/post goals to me. So plugins would > > 'register' to be invoked as part of the process? > > No, the plugins would not 'register' anything. The whole > point of the change is to make explicit from the user's end > how the plugins interact. > How Vincent tends to use the plugins is how things should > work in maven1 where the functionality is provided in the > plugin but it is the responsibility of the user to decorate > any desired goals to invoke the plugin in question. > > Plugins should be entirely indifferent to the process. How > they are combined should be explicity controlled by the user > for the sake of clarity, ease of use, and ease of maintenance. > > -- > jvz. > > Jason van Zyl > [EMAIL PROTECTED] > http://maven.apache.org > > happiness is like a butterfly: the more you chase it, the > more it will elude you, but if you turn your attention to > other things, it will come and sit softly on your shoulder ... > > -- Thoreau > > > - > 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: Need to load common goals from sub-projects maven.xml
On Thu, 2004-07-01 at 00:22, Dion Gillard wrote: > On Thu, 1 Jul 2004 13:16:02 +1000, Brett Porter <[EMAIL PROTECTED]> wrote: > > > > It's a bad thing inside plugins though as you have these things > > sneaking into your build process. > > If they do nothing when not needed, as most of these do, then where's the harm. The complexity involved in managing the dependencies among the plugins. Brett is the only person besides myself that understands the clusterfuck of code required to manage goal decoration amongst plugins. It was removed as an option in m2 for clarity: goal decoration is only within the purview of the user. This pattern is used in many of the plugins we have in maven1 but it's not enforced. Plugins like the antlr plugin do some magic with pregoals and it's not clear at all what's going on. Plugins of the form that Vincent tends to use are clear because it is soley up to the user to perform the goal decoration in order to harness the functionality of a plugin. Allowing plugins to decorate goals from other plugins can lead to undeterministic behaviour, especially when it is so easy in maven1 to frob the context wherever you like, affect parent contexts and access variables from other plugins. A user explicity stating what is to happen in a build prevents unwanted side effects from plugins being added to the system. Right now in maven1 I could right a plugin that could adversely affect every build. A case in point being the old AspectJ plugin which decorated the standard compile goals which caused the AspectJ jars to be downloaded. This is all easily avoided by putting the control in the hands of the user where it belongs. The code required to manage goal decoration amonst plugins in maven1 is nothing short of a ratfuck. Purely unmanageable and requires some pretty funky contortions to make it work. The harm is potentially vast. > > In m2 the model is more along the lines of registration into the build > > process at defined points (like how xdoc/site does the reports) > > That sounds awfully like pre/post goals to me. So plugins would > 'register' to be invoked as part of the process? No, the plugins would not 'register' anything. The whole point of the change is to make explicit from the user's end how the plugins interact. How Vincent tends to use the plugins is how things should work in maven1 where the functionality is provided in the plugin but it is the responsibility of the user to decorate any desired goals to invoke the plugin in question. Plugins should be entirely indifferent to the process. How they are combined should be explicity controlled by the user for the sake of clarity, ease of use, and ease of maintenance. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Need to load common goals from sub-projects maven.xml
On Thu, 1 Jul 2004 13:16:02 +1000, Brett Porter <[EMAIL PROTECTED]> wrote: > > It's a bad thing inside plugins though as you have these things > sneaking into your build process. If they do nothing when not needed, as most of these do, then where's the harm. > In m2 the model is more along the lines of registration into the build > process at defined points (like how xdoc/site does the reports) That sounds awfully like pre/post goals to me. So plugins would 'register' to be invoked as part of the process? A rose by any other name... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Need to load common goals from sub-projects maven.xml
It's a bad thing inside plugins though as you have these things sneaking into your build process. In m2 the model is more along the lines of registration into the build process at defined points (like how xdoc/site does the reports) - Brett On Thu, 1 Jul 2004 08:33:59 +1000, Dion Gillard <[EMAIL PROTECTED]> wrote: > > On Wed, 30 Jun 2004 16:28:18 +0100, Matt Read <[EMAIL PROTECTED]> wrote: > > > > > From: Maczka Michal [mailto:[EMAIL PROTECTED] > > > > > > No! preGoals should not be used by plugins. > > > > Ok, so these aren't behaving themselves? > > > > cache\maven-antlr-plugin-1.2\plugin.jelly(59): > > cache\maven-antlr-plugin-1.2\plugin.jelly(63): > > cache\maven-html2xdoc-plugin-1.3\plugin.jelly(102): > name="xdoc:jelly-transform"> > > cache\maven-html2xdoc-plugin-1.3\plugin.jelly(108): > > cache\maven-latex-plugin-1.2\plugin.jelly(82): > > cache\maven-latex-plugin-1.2\plugin.jelly(86): > > Nope, they're doing exactly what they should do. That's what preGoals are for. > > > > - > 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: Need to load common goals from sub-projects maven.xml
On Wed, 30 Jun 2004 16:28:18 +0100, Matt Read <[EMAIL PROTECTED]> wrote: > > > From: Maczka Michal [mailto:[EMAIL PROTECTED] > > > > No! preGoals should not be used by plugins. > > Ok, so these aren't behaving themselves? > > cache\maven-antlr-plugin-1.2\plugin.jelly(59): > cache\maven-antlr-plugin-1.2\plugin.jelly(63): > cache\maven-html2xdoc-plugin-1.3\plugin.jelly(102): name="xdoc:jelly-transform"> > cache\maven-html2xdoc-plugin-1.3\plugin.jelly(108): > cache\maven-latex-plugin-1.2\plugin.jelly(82): > cache\maven-latex-plugin-1.2\plugin.jelly(86): Nope, they're doing exactly what they should do. That's what preGoals are for. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Need to load common goals from sub-projects maven.xml
> From: Maczka Michal [mailto:[EMAIL PROTECTED] > > No! preGoals should not be used by plugins. Ok, so these aren't behaving themselves? cache\maven-antlr-plugin-1.2\plugin.jelly(59): cache\maven-antlr-plugin-1.2\plugin.jelly(63): cache\maven-html2xdoc-plugin-1.3\plugin.jelly(102): cache\maven-html2xdoc-plugin-1.3\plugin.jelly(108): cache\maven-latex-plugin-1.2\plugin.jelly(82): cache\maven-latex-plugin-1.2\plugin.jelly(86): > > At the moment indeed the solution which involves plugin > requires very short duplicating blocks in maven.xml. > Probably we will be able to eliminate the need for most of > them and even maven.xml themselves if we will have workflow > which might be parametrized. E.g java:compile goal might > depend on java:runCodeGenerator goal which by default might be nop. > and you will be able to define alias java:runCodeGenerator - > > xdoclect:hibernatedoclet. > So in the such common cases no scripting will be ever needed. > But that's not yet official - that's just one of the possibilties. > > Michal This brings me back to my previous email. 1. Does maven.xml inheritance currently only happen when sub-projects run within the reactor? 2. Does project.properties and build.properties inheritance currently only happen when sub-projects are run within the reactor? If so, what's the reasoning behind this decision? Thanks, Matt. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Need to load common goals from sub-projects maven.xml
> > > No. Plugins are recommened way of doing this. > > I don't understand. Say I've got a persistence components > that requires > XDoclet to be run prior to compiling then I might do this in > my maven.xml: > > > > > > > > > > > So if I then create 2 more persistence components that need > the same thing > to happen then I might recognise a duplication and refactor > it out to a > plugin. However, would I still need to do the following in each of my > maven.xml's for my 3 components? > > > > > > If these components were running inside the reactor wouldn't > it be better to > simply put these lines in the parent project's maven.xml? > > To answer my own question, having looked at some other > plugin.jelly, it > seems that I could put the same preGoal into my plugin.jelly. > Is that what > you you were getting at? Sorry for being slow. > No! preGoals should not be used by plugins. At the moment indeed the solution which involves plugin requires very short duplicating blocks in maven.xml. Probably we will be able to eliminate the need for most of them and even maven.xml themselves if we will have workflow which might be parametrized. E.g java:compile goal might depend on java:runCodeGenerator goal which by default might be nop. and you will be able to define alias java:runCodeGenerator - > xdoclect:hibernatedoclet. So in the such common cases no scripting will be ever needed. But that's not yet official - that's just one of the possibilties. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Need to load common goals from sub-projects maven.xml
Alwyn Schoeman wrote on Wednesday, June 30, 2004 2:35 PM: > Is there any plan ever to have maven.xml scripts inherit in a > multiproject? ?? They do! -- Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Need to load common goals from sub-projects maven.xml
> From: Maczka Michal [mailto:[EMAIL PROTECTED] > > From: Matt Read [mailto:[EMAIL PROTECTED] > > > From: Maczka Michal [mailto:[EMAIL PROTECTED] > > > > From: Stefanutti, Mario [mailto:[EMAIL PROTECTED] > > > > > > > > Hi, > > > > > > > > I looking for a way to set some common goals for each > > > sub-project of a > > > > multiproject environment. > > > > > > > Simple soluton: create your own plugin. It is super > simple (example > > > can be found in Maven Wiki) > > > > > > Michal > > > > > > > I'm interested in this too. It appears the project's > inherit from the > > parent project's maven.xml. Even if one was to write a plugin to > > encapsulate common tasks they would still need to be called in the > > same way in each sub-project. I assume inheritance of > maven.xml is the > > recommended way to do this? > > No. Plugins are recommened way of doing this. I don't understand. Say I've got a persistence components that requires XDoclet to be run prior to compiling then I might do this in my maven.xml: So if I then create 2 more persistence components that need the same thing to happen then I might recognise a duplication and refactor it out to a plugin. However, would I still need to do the following in each of my maven.xml's for my 3 components? If these components were running inside the reactor wouldn't it be better to simply put these lines in the parent project's maven.xml? To answer my own question, having looked at some other plugin.jelly, it seems that I could put the same preGoal into my plugin.jelly. Is that what you you were getting at? Sorry for being slow. > > In Maven 2 inheritence uses the id of the parent project > instead of the relative path to parent pom > > > > foo > bba > 1.0 > > ... > > > Parent pom could be taken from local repository (and hence > downloaded there from remote repository) and most likly it > might be also provided by reactor when reactor powered build > will be used for building both child and parent projects > > > We still haven't decided if maven.xml will be also > uploaded/downloaded to/from the repository(ies) but at the > moment for sake of simplicity we are rather willing to push > all centralized goals to plugins. Plugins can be decalred as > any other dependenies in poms and automatically fetched by > maven. It means that for common scripts - you will need to > create one more project. In reactor powered builds which > will be way simpler than thay are now there should be really > no differnce as plugin project will be build in the same run > of maven and made directly visible to other projets. > > But this is the future :) > Sounds good though! > [..] > > Michal > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Need to load common goals from sub-projects maven.xml
> -Original Message- > From: Matt Read [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 30, 2004 2:36 PM > To: 'Maven Users List' > Subject: RE: Need to load common goals from sub-projects maven.xml > > > > From: Maczka Michal [mailto:[EMAIL PROTECTED] > > > > > From: Stefanutti, Mario [mailto:[EMAIL PROTECTED] > > > > > > Hi, > > > > > > I looking for a way to set some common goals for each > > sub-project of a > > > multiproject environment. > > > > > Simple soluton: create your own plugin. It is super simple > > (example can be found in Maven Wiki) > > > > Michal > > > > I'm interested in this too. It appears the project's inherit > from the parent > project's maven.xml. Even if one was to write a plugin to > encapsulate common > tasks they would still need to be called in the same way in each > sub-project. I assume inheritance of maven.xml is the > recommended way to do > this? No. Plugins are recommened way of doing this. In Maven 2 inheritence uses the id of the parent project instead of the relative path to parent pom foo bba 1.0 ... Parent pom could be taken from local repository (and hence downloaded there from remote repository) and most likly it might be also provided by reactor when reactor powered build will be used for building both child and parent projects We still haven't decided if maven.xml will be also uploaded/downloaded to/from the repository(ies) but at the moment for sake of simplicity we are rather willing to push all centralized goals to plugins. Plugins can be decalred as any other dependenies in poms and automatically fetched by maven. It means that for common scripts - you will need to create one more project. In reactor powered builds which will be way simpler than thay are now there should be really no differnce as plugin project will be build in the same run of maven and made directly visible to other projets. But this is the future :) [..] Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Need to load common goals from sub-projects maven.xml
> From: Maczka Michal [mailto:[EMAIL PROTECTED] > > > From: Stefanutti, Mario [mailto:[EMAIL PROTECTED] > > > > Hi, > > > > I looking for a way to set some common goals for each > sub-project of a > > multiproject environment. > > > Simple soluton: create your own plugin. It is super simple > (example can be found in Maven Wiki) > > Michal > I'm interested in this too. It appears the project's inherit from the parent project's maven.xml. Even if one was to write a plugin to encapsulate common tasks they would still need to be called in the same way in each sub-project. I assume inheritance of maven.xml is the recommended way to do this? On a related note, would I be right in thinking that although project.properties is inherited when projects are run inside the reactor, it is not inherited outside the reactor? If so, what's the reasoning behind this? Thanks, Matt. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Need to load common goals from sub-projects maven.xml
Is there any plan ever to have maven.xml scripts inherit in a multiproject? On Wed, 30 Jun 2004 13:18:25 +0200, Maczka Michal <[EMAIL PROTECTED]> wrote: > > > > > -Original Message- > > From: Stefanutti, Mario [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, June 30, 2004 1:16 PM > > To: Maven Users List > > Subject: Need to load common goals from sub-projects maven.xml > > > > > > Hi, > > > > I looking for a way to set some common goals for each sub-project of a > > multiproject environment. > > > Simple soluton: create your own plugin. It is super simple (example can be > found in Maven Wiki) > > Michal > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Alwyn Schoeman Mid-life crisis in action - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Need to load common goals from sub-projects maven.xml
> -Original Message- > From: Stefanutti, Mario [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 30, 2004 1:16 PM > To: Maven Users List > Subject: Need to load common goals from sub-projects maven.xml > > > Hi, > > I looking for a way to set some common goals for each sub-project of a > multiproject environment. > Simple soluton: create your own plugin. It is super simple (example can be found in Maven Wiki) Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
