You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Stephen Connolly <st...@gmail.com> on 2013/04/15 17:38:05 UTC
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
<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 <de...@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
>
>
>
Re: [mojo-dev] Re: Build-Helper-Maven-Plugin / Build-MetaData-Maven-Plugin
Posted by Stephen Connolly <st...@gmail.com>.
http://developer-blog.cloudbees.com/2013/04/the-maven-way.html
On 16 April 2013 16:16, Stephen Connolly <st...@gmail.com>wrote:
>
>
>
> On 16 April 2013 16:11, Mark H. Wood <mw...@iupui.edu> 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
>> >
>> > <project>
>> > <groupId>...</groupId>
>> > <artifactId>...</artifactId>
>> > <version>...</version>
>> > <packaging>...</packaging>
>> > <dependencies>
>> > ...
>> > </dependencies>
>> > </project>
>> >
>> > 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 mwood@IUPUI.Edu
>> Machines should not be friendly. Machines should be obedient.
>>
>
>
Re: [mojo-dev] Re: Build-Helper-Maven-Plugin / Build-MetaData-Maven-Plugin
Posted by Stephen Connolly <st...@gmail.com>.
On 16 April 2013 16:11, Mark H. Wood <mw...@iupui.edu> 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
> >
> > <project>
> > <groupId>...</groupId>
> > <artifactId>...</artifactId>
> > <version>...</version>
> > <packaging>...</packaging>
> > <dependencies>
> > ...
> > </dependencies>
> > </project>
> >
> > 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 mwood@IUPUI.Edu
> Machines should not be friendly. Machines should be obedient.
>
Re: [mojo-dev] Re: Build-Helper-Maven-Plugin /
Build-MetaData-Maven-Plugin
Posted by "Mark H. Wood" <mw...@IUPUI.Edu>.
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
>
> <project>
> <groupId>...</groupId>
> <artifactId>...</artifactId>
> <version>...</version>
> <packaging>...</packaging>
> <dependencies>
> ...
> </dependencies>
> </project>
>
> 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 mwood@IUPUI.Edu
Machines should not be friendly. Machines should be obedient.
Re: [mojo-dev] Re: Build-Helper-Maven-Plugin / Build-MetaData-Maven-Plugin
Posted by Stephen Connolly <st...@gmail.com>.
On 15 April 2013 20:42, Karl Heinz Marbaise <kh...@gmx.de> 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
>> <plugin><groupId><artifactId><**version></plugin> 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
<project>
<groupId>...</groupId>
<artifactId>...</artifactId>
<version>...</version>
<packaging>...</packaging>
<dependencies>
...
</dependencies>
</project>
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
<parent> reference, or adding an <extension> to support a custom packaging
type.
Some move you 1m or so, such as adding additional <plugin> definitions
Some move you 1,000km, such as <profiles>
Some move you 500m or so, such as adding additional <plugin> definitions
with multiple <executions> with their own <configuration> and a default
<configuration>
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
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
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
> <plugin><groupId><artifactId><version></plugin> 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 Schulung Tel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl-Heinz Marbaise ICQ#: 135949029
Hauptstrasse 177 USt.IdNr: DE191347579
52146 Würselen http://www.soebes.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [mojo-dev] Re: Build-Helper-Maven-Plugin / Build-MetaData-Maven-Plugin
Posted by Curtis Rueden <ct...@wisc.edu>.
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 <de...@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
> >
> >
> >
>