maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curtis Rueden <ctrue...@wisc.edu>
Subject Re: [mojo-dev] Re: Build-Helper-Maven-Plugin / Build-MetaData-Maven-Plugin
Date Thu, 18 Apr 2013 21:11:53 GMT
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.connolly@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
> <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 <dev@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
> >
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message