simon wrote:
On Sat, 2008-01-12 at 14:38 +0100, Dennis Lundberg wrote:
simon wrote:
On Sat, 2008-01-12 at 00:20 +0000, Niall Pemberton wrote:
On Jan 11, 2008 11:29 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
Jochen Wiedmann wrote:
On Jan 11, 2008 10:57 AM, Niall Pemberton <[EMAIL PROTECTED]> wrote:
Theres also the issue of specifying the "version" of the
remote-resources-plugin - which in previous discussions people
objected to. Please Note this is not configuring commons-parent to
*use* that plugin - but just to specify the version number *if* a
component does use it. I don't mind it going in and it has no impact
unless components use it. Does anyone still have a problem with doing
this? Also are there any other changes people think should be made
before trying to release commons-parent-7?
I have no particular problem with it, apart from the fact that I find
it pointless.
If there is some code that actually uses the plugin, then that makes
sense. This code might be contained in some profile, in other words,
not used unless explicitly requested. But just to fix a version
number? What for?
The reason is to have reproducible builds. It makes sure that, no matter
who is building component A, the end result will always be the same.
This is not quite the case - reproducability is the reason for
specifying the version, but not the reason for specifying the version
in the parent pom. The reason for specifying version numbers in the
parent is to not have to go through endless component poms updating
version numbers - maintain the version numbers in the parent and just
keep the commons-parent version up-to-date in the components.
It seems to me that specifying version numbers in parent poms is in fact
exactly the *wrong* thing to do, and *particularly* for plugins.
Instead, a version number should always be specified instead by the pom
that uses the plugin.
For a start, this is much easier to audit: any time a plugin is declared
in a pom, we can say that there *must* be a version value in the
declaration. Easy. But with "inherited" versions, we see poms with
missing version tags, and have to trace through the ancestry to see what
versions are used. Yes, things like the maven-enforcer-plugin can do
checks on this (once its new version is released) but obvious is still
better than unclear-in-source-but-automatically-validated.
Running 'mvn help:effective-pom' is a great help if you are ever in
doubt what the pom will look like after inheritance has been applied.
And why would we ever care that some modules use version X of a plugin,
and some use version Y? If a module declares it needs version X, and
builds correctly with version X, then it seems *bad* to me to force an
unnecessary change via inheriting new settings from a parent pom.
Plugins, like any piece of software, go through changes. That means that
you should try out a new version to make sure it works for your build.
To minimize this testing it is a good thing to standardize which version
to use.
I don't see the point of that at all. Commons-xxx projects do not exist
for the purposes of testing maven plugins. If commons-xxx can build
successfully with version N of a plugin, then there is no reason to ever
use any other version of the plugin.
Oh come on!!!
When did I ever say that "commons projects exist for the purposes of
testing maven plugins"? You are reading my comments like the devil reads
the bible.
Regarding versions, did you even read the thread???
See:
http://markmail.org/message/ui6bhy2akjckkdco
I have been saying *exactly* that.
This is it for me. Over and out!
Well, one minor case is with report plugins, so that the reports
generated by related modules look similar. But maven can't help with
that anyway, as it doesn't provide <pluginManagement>.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
