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
<plugin><groupId><artifactId><version></plugin> 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 <d...@andersonvaz.com> 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://stackoverflow.com/questions/1231561/how-to-share-common-properties-among-several-maven-projects/1265428#1265428
> >
>
> Thanks!
>
>
>
> --
> View this message in context:
> http://mojo.10943.n7.nabble.com/Build-Helper-Maven-Plugin-Build-MetaData-Maven-Plugin-tp39569p39681.html
> Sent from the Developer mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
