Re: [mojo-dev] Re: Build-Helper-Maven-Plugin / Build-MetaData-Maven-Plugin
Hi Stephen & everyone, As always, thanks for your comments and blog posts! I really appreciate all the time you pour into this community. > People having to use ${basedir}/../.. and feeling uneasy about it... > to my mind that is the perfect balance. It's quick... it's dirty... > you know it's a hack... you know you should do better... you have the > job done for now... SPOT ON In this particular case, I am one of those people currently using the "${basedir}/.." hack but a bit dissatisfied with it, while feeling rather confident that plugins like maven-remote-resources-plugin [1] are not the solution here. (And I don't know what is.) For reference, my project's hack can be seen at e.g.: * https://github.com/imagej/imagej/blob/v2.0.0-beta6/pom.xml#L32 * https://github.com/imagej/imagej/blob/v2.0.0-beta6/core/core/pom.xml#L42 Where the "project.rootdir" property (probably stupid & wrong that I called it that, but that's a separate issue) is explicitly defined in *every* leaf POM of my multi-module build. The main reasons for bothering to define that property are two-fold: 1) https://github.com/imagej/imagej/blob/v2.0.0-beta6/app/src/main/assembly/application.xml#L54 2) https://github.com/imagej/imagej/commit/7f9345c3 The first reason is to bring together some files from the root of the repository into an application bundle created by maven-assembly-plugin. This includes things like the README which obviously sit in the root, and would be silly to duplicate in the app module's subtree. The second reason is for license-maven-plugin, to reuse the same license resolver for all submodules of the multi-module build. (Since the project is licensed under BSD-2, we cannot use one of the built-in licenses of license-maven-plugin.) This works really nicely, but requires the "${basedir}/.." hack. I briefly looked at that "sharing resources" page of maven-remote-resources-plugin since it sounded like a good potential fit to eliminate the "${basedir}/.." hack. But IMO the sheer amount of POM boilerplate needed is off-putting; it is completely in line with your point that "Every line you add ... is moving further from the Maven Way™". I am open to alternate suggestions for these and similar use cases, but from my current (naive) perspective, a built-in Maven property for the root directory of a multi-module project [2] would be exceedingly simpler and more convenient, while not necessarily driving anyone down the path of destruction. Regards, Curtis [1] http://maven.apache.org/plugins/maven-remote-resources-plugin/examples/sharing-resources.html [2] Admittedly, this property would need to be smart; "root" does not mean "the folder where I typed mvn" in the case of building a subtree of a multi-module project structure. It really means something like "recursively follow the parents until they stop resolving in the file system". On Mon, Apr 15, 2013 at 10:38 AM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > CC'ing users@maven because I think my point applies to the entire Maven > community: > > Well my view is that such practice is bad practice, there are good ways to > do things and bad ways to do things. Hard-coding references between > projects using the file system is bad practice. For one thing it fails to > take into account the reactor mode and how people may not want the > filesystem changes being picked up when using the reactor mode (it's not > just build speed that draws people to the reactor mode of building) > > Now if there are specific use cases for these things, then I think it is > better to ask why they think they need to use the filesystem to resolve > their intra-module stuff and why they cannot use the reactor as was > intended. > > My conjecture is 90% of the time an existing plugin can provide what they > need while using the reactor metaphor. > > The remaining 10% is divided between things [one should not be doing/one is > only doing this once] and [things that need a new maven plugin] > > Additionally, of the 90% there's maybe 20-30% where the existing plugin > could be re-engineered or replaced to do things better. > > A case in point of the improving (though not related to the idea of being > able to get a property exposing the root (never mind the which root: > reactor/inheritence/inheritence within reactor) but more related to > re-engineering to make life easier) is the templating maven pluging. In the > case of templating java source, one could do that already... just with > about 30-50 lines of pom.xml config... now with the templating plugin > you're looking at about 5-10 lines and 5 of those are just the standard > boilerplate. > > My worry in providing such a property is that we enable people to hack > together something, instead of them screaming for a better way to do XYZ > and then the community providing that solution. > > I do think it is sad that the Maven community has focused too much on reuse > for reuse's sake irrespective of the pom-bloat cost. > >
Re: [mojo-dev] Re: Build-Helper-Maven-Plugin / Build-MetaData-Maven-Plugin
http://developer-blog.cloudbees.com/2013/04/the-maven-way.html On 16 April 2013 16:16, Stephen Connolly wrote: > > > > On 16 April 2013 16:11, Mark H. Wood wrote: > >> On Mon, Apr 15, 2013 at 09:48:35PM +0100, Stephen Connolly wrote: >> [snip] >> > The reality is that the true goal of the Maven Way™ is that your pom >> should >> > be as close as possible to the following >> > >> > >> > ... >> > ... >> > ... >> > ... >> > >> > ... >> > >> > >> > >> > Every line you add to the above is moving further from the Maven Way™ >> >> Brilliant. The above describes what the project *is*. The more you >> have to tinker with plugins and the like, the more likely you are >> describing *how the project should be built*. But if I have >> understood the situation, Maven exists to figure out *how* after you >> have told it *what*. >> > > Yep, exactly! > > >> >> -- >> Mark H. Wood, Lead System Programmer mw...@iupui.edu >> Machines should not be friendly. Machines should be obedient. >> > >
Re: [mojo-dev] Re: Build-Helper-Maven-Plugin / Build-MetaData-Maven-Plugin
On 16 April 2013 16:11, Mark H. Wood wrote: > On Mon, Apr 15, 2013 at 09:48:35PM +0100, Stephen Connolly wrote: > [snip] > > The reality is that the true goal of the Maven Way™ is that your pom > should > > be as close as possible to the following > > > > > > ... > > ... > > ... > > ... > > > > ... > > > > > > > > Every line you add to the above is moving further from the Maven Way™ > > Brilliant. The above describes what the project *is*. The more you > have to tinker with plugins and the like, the more likely you are > describing *how the project should be built*. But if I have > understood the situation, Maven exists to figure out *how* after you > have told it *what*. > Yep, exactly! > > -- > Mark H. Wood, Lead System Programmer mw...@iupui.edu > Machines should not be friendly. Machines should be obedient. >
Re: [mojo-dev] Re: Build-Helper-Maven-Plugin / Build-MetaData-Maven-Plugin
On Mon, Apr 15, 2013 at 09:48:35PM +0100, Stephen Connolly wrote: [snip] > The reality is that the true goal of the Maven Way™ is that your pom should > be as close as possible to the following > > > ... > ... > ... > ... > > ... > > > > Every line you add to the above is moving further from the Maven Way™ Brilliant. The above describes what the project *is*. The more you have to tinker with plugins and the like, the more likely you are describing *how the project should be built*. But if I have understood the situation, Maven exists to figure out *how* after you have told it *what*. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient. signature.asc Description: Digital signature
Re: [mojo-dev] Re: Build-Helper-Maven-Plugin / Build-MetaData-Maven-Plugin
On 15 April 2013 20:42, Karl Heinz Marbaise wrote: > A case in point of the improving (though not related to the idea of being >> able to get a property exposing the root (never mind the which root: >> reactor/inheritence/**inheritence within reactor) but more related to >> re-engineering to make life easier) is the templating maven pluging. In >> the >> case of templating java source, one could do that already... just with >> about 30-50 lines of pom.xml config... now with the templating plugin >> you're looking at about 5-10 lines and 5 of those are just the standard >> <**version> boilerplate. >> > > I made often the experience that there is always a solution but often it's > not really short > > And those cases are the warning shots that the Maven community is letting its users down. Where there is a Maven Way™ solution, we should be making that solution as easy and pain free as possible. Too often we have taken easy ways out by saying things like: "Use these 5 plugins in your pom and attach them to the following 5 phases like so for reasons of magic and you are following the Maven Way™" "Add this pile of boilerplate and lay your folders out like so, that's the Maven Way™" The reality is that the true goal of the Maven Way™ is that your pom should be as close as possible to the following ... ... ... ... ... Every line you add to the above is moving further from the Maven Way™ Some additions are necessary, and don't move you more than 1mm, such as the reference, or adding an to support a custom packaging type. Some move you 1m or so, such as adding additional definitions Some move you 1,000km, such as Some move you 500m or so, such as adding additional definitions with multiple with their own and a default When you are building a new type of project it is to be expected that you will be moved far from the Maven Way™ *because* it is a new type of project and we have not discovered the way *yet*, such explorers wander far from the Maven Way™ and then they find their way back again and tell us the paths to follow... at that point we should be stepping up and creating packaging types or well written plugins that enable people to build that type of project as close to the minimal pom as possible. The power of Maven comes from the minimal pom with just dependencies, where a project is just set out on disk according to convention and everything just works. I think we have forgotten that...
Re: [mojo-dev] Re: Build-Helper-Maven-Plugin / Build-MetaData-Maven-Plugin
Hi, based on the requirement which has been made to introduce a new property for the root of the reactor I 100% agree with Stephens argumentation. I have taken a look into those question on SO and all of those things can be solved in better ways than suggested on SO, cause many people didn't understand Maven and it's concepts...sorry to say that in that harsh way...I have to admit those concepts are not that simple... A case in point of the improving (though not related to the idea of being able to get a property exposing the root (never mind the which root: reactor/inheritence/inheritence within reactor) but more related to re-engineering to make life easier) is the templating maven pluging. In the case of templating java source, one could do that already... just with about 30-50 lines of pom.xml config... now with the templating plugin you're looking at about 5-10 lines and 5 of those are just the standard boilerplate. I made often the experience that there is always a solution but often it's not really short My worry in providing such a property is that we enable people to hack together something, instead of them screaming for a better way to do XYZ and then the community providing that solution. Yes... People having to use ${basedir}/../.. and feeling uneasy about it... to my mind that is the perfect balance. It's quick... it's dirty... you know it's a hack... you know you should do better... you have the job done for now... SPOT ON Yeah that's a good point ! If we have an "official" (because that's what mojo is... the "offical" side project for plugins) plugin that gives the property they want... well people will now have the quick and dirty hack and the job done for now, but they won't know it's a hack, they won't know they should do better... and we have lost another user's use case to assist. That's exactly the consequence out of it... Kind regards Karl-Heinz Marbaise -- SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl-Heinz MarbaiseICQ#: 135949029 Hauptstrasse 177 USt.IdNr: DE191347579 52146 Würselen http://www.soebes.de - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [mojo-dev] Re: Build-Helper-Maven-Plugin / Build-MetaData-Maven-Plugin
CC'ing users@maven because I think my point applies to the entire Maven community: Well my view is that such practice is bad practice, there are good ways to do things and bad ways to do things. Hard-coding references between projects using the file system is bad practice. For one thing it fails to take into account the reactor mode and how people may not want the filesystem changes being picked up when using the reactor mode (it's not just build speed that draws people to the reactor mode of building) Now if there are specific use cases for these things, then I think it is better to ask why they think they need to use the filesystem to resolve their intra-module stuff and why they cannot use the reactor as was intended. My conjecture is 90% of the time an existing plugin can provide what they need while using the reactor metaphor. The remaining 10% is divided between things [one should not be doing/one is only doing this once] and [things that need a new maven plugin] Additionally, of the 90% there's maybe 20-30% where the existing plugin could be re-engineered or replaced to do things better. A case in point of the improving (though not related to the idea of being able to get a property exposing the root (never mind the which root: reactor/inheritence/inheritence within reactor) but more related to re-engineering to make life easier) is the templating maven pluging. In the case of templating java source, one could do that already... just with about 30-50 lines of pom.xml config... now with the templating plugin you're looking at about 5-10 lines and 5 of those are just the standard boilerplate. My worry in providing such a property is that we enable people to hack together something, instead of them screaming for a better way to do XYZ and then the community providing that solution. I do think it is sad that the Maven community has focused too much on reuse for reuse's sake irrespective of the pom-bloat cost. The point of trying to reuse is to keep the standard way of doing things... but once we know the standard way, we should codify that standard way into a simple to use plugin and let people use that instead... * hacking around 3rd party jars which you cannot get into a repo => non-maven-jar-maven-plugin (saves tons of xml lines) * templating in .java source code => templating maven plugin (saves 100kg of xml lines) By all means we need to direct people to best practice... and my all means we should try to get out of the way when people need to "*Get Things Done*™" but if staying out of the way means that they get to leave the technical debt there and not know its technical debt... then we have not been kind to them. People having to use ${basedir}/../.. and feeling uneasy about it... to my mind that is the perfect balance. It's quick... it's dirty... you know it's a hack... you know you should do better... you have the job done for now... SPOT ON If we have an "official" (because that's what mojo is... the "offical" side project for plugins) plugin that gives the property they want... well people will now have the quick and dirty hack and the job done for now, but they won't know it's a hack, they won't know they should do better... and we have lost another user's use case to assist. We can do better as a community, and we should. That means that we need to spot when somebody is involved in a *Get Things Done*™ mode and help them get the damn thing working with the least pain, but the proviso that they know and acknowledge this is technical debt that they are building and once the time pressure is off, they should help us help them remove the technical debt by finding a more *Maven Way*™ to do it. -Stephen On 15 April 2013 16:00, avaz wrote: > Hi, > > As suggestion, this plugin could have a goal that set's the 'root parent > dir', I see this pretty useful for sharing plugin configuration based in > properties files located in the main parent in a multi module projets. > There is a lot of anxiety of it around web as can be seen: > > > http://stackoverflow.com/questions/1012402/maven2-property-that-indicates-the-parent-directory > < > http://stackoverflow.com/questions/1012402/maven2-property-that-indicates-the-parent-directory > > > > > http://stackoverflow.com/questions/3084629/finding-the-root-directory-of-a-multi-module-maven-reactor-project > < > http://stackoverflow.com/questions/3084629/finding-the-root-directory-of-a-multi-module-maven-reactor-project > > > > > http://stackoverflow.com/questions/8700097/how-to-get-the-super-pom-basedir-in-a-child-module-pom > < > http://stackoverflow.com/questions/8700097/how-to-get-the-super-pom-basedir-in-a-child-module-pom > > > > http://stackoverflow.com/questions/4146638/maven-variable-for-reactor-root > < > http://stackoverflow.com/questions/4146638/maven-variable-for-reactor-root > > > > > http://stackoverflow.com/questions/1231561/how-to-share-common-properties-among-several-maven-projects/1265428#1265428 > < > http://stackoverflo