On 22/04/2007, at 4:58 PM, Jason van Zyl wrote:
- require the version in plugin definitions in the POM from
modelVersion 4.1.0+ (for 4.0.0 modelVersions, continue to allow
the RELEASE as the version).
+1
- externalise all packagings/lifecycle definitions (with the
exception of 'pom', perhaps)
What does that mean exactly?
Take them out of core's components.xml and into the plugins.
- make the user declare the plugin that contains the packaging
they want, including it's version (a plugin may contain more than
one packaging)
- make the packaging plugin declare the versions of the other
lifecycle plugins it uses (in the lifecycle itself, not the
plugins pom)
- same for any overlaid lifecycles in plugins
- declared plugins and pluginManagement in the POM always wins
over the lifecycle.
- running from the CLI behaves as it does now
Now, while this could mean the jar packaging is in maven-jar-
plugin, etc. I would suggest that's too many plugins to change
when the compile plugin changes. So instead we could have the
maven-java-packages-plugin, v1.0 that has jar, war, ear, ejb,
compile, surefire, etc. all pinned to a known, tested set. If a
user needs one of them newer: plugin management.
I think that's that's just way to coupled. I think providing the
latest releases that are available in an easy way when people get
started is the key but then the versions used must be easily
visible somewhere so they can be changed because the second some
one finds a bug and needs to change a version of something they
will need an easy way to change this. Having to then build the
maven-java-packages with altered versions would be not fun.
I was suggesting that using pluginManagement for an individual plugin
would still work. Would this resolve the objection?
I think publishing the laundry list of a usable set and making a
simple plugin to have that easily consumable is a great idea.
Plugins depending on another artifact for version binding I think
is bad. I think we need to publish releases, make them easy to find
an be absorbed which leaves us in the situation of providing up-to-
date information coupled with getting that information easily to
users and then the user is in charge of version selection.
Seems like another good way. So a plugin takes a descriptor with a
set of artifacts (with versions) and pulls them all into the build
together (unless they already exist in plugin management which always
wins)?
I agree this is a better refinement of the same idea since it's
easier to construct. It might be best to take it to the next level
and build this in to Maven rather than it being a plugin for
consuming it (for ease of use). But that can also be a separate next
step.
We should note that this does not tightly couple plugins in the
same way it has before which was problematic in m1.
If you bind that packaging set into the version resolution you are.
That version set must be made available as a means for people to
manage their own versions easily. We can update that often, and let
people know, make tools, but ultimately you have to specify
literally what you want so that when bad things happen there is
only _one_ place to look to see how the version is resolved and
that's the POM. Not some version set buried in a JAR file file
somewhere, but the POMs used in your build. Period.
We are still "programming to interfaces" - but the metadata wires
up the right versions of things.
-1
That will need to severe maintenance problems.
The POM becomes the authority. How we help people get the right
versions can range from simple to complex, but ultimately any
tooling done ultimately manifests itself as versions that land in
the users POM.
I'm not really sure we understand each other here, since I am also
advocating the POM being the final authority, and we are both
proposing at least one level of indirection (one in plugin metadata,
one in a 'laundry list'). I think it's the same solution.
So the difference may seem slight where the list is in a JAR,
versus some resource in the repository but it means people can look
at it with a web browser, cut and paste (eek) if they like, but
most likely use a plugin to incorporate that into their build.
Ok, that makes sense. I agree having it easier to access is better.
So, it seems you are in general agreement with the proposal,
substituting the built plugin packs with a plugin that consumes
metadata and incorporates those versions into the build?
Diverging off this topic into the more general stuff...
But the vast majority of our users are in a group situation and
will have a parent POM with this information. If the
pluginManagement section is more verbose then we can come up with
something else.
Having to bump the parent POM all the time is an equal maintenance
nightmare that needs to be resolved.
The bottom line is that I'm for less magic internally, betting
tooling for initial setup, and making the POM more literal. By that
I mean if someone specified a version of something there would be
no strange reason that a different version was yanked in. For it to
become the only source of version information and I think that's
the only way things will be truly deterministic.
No disagreement there.
Even if it become something where defaults were taken by reference
and not resolution. And by that I mean versions of anything could
be pulled in by consuming a reference to an xml file containing
versions of things versus versions of artifacts requiring artifact
resolution itself. And this would really only be required for first
time users in the archetype:create and play scenerio. Anyone with a
real build would specify everything.
This sounds way to extreme and limiting. You seem to be extending the
necessity to be explicit on plugin versions to the whole dependency
mechanism which I don't believe is true. But let's tackle these one
at a time.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
