I think the extension points need to be configured by the pom, so
that projects build consistently on any installation. I continue to
think the 'build the project' POM is different to the 'represent the
project' POM that winds up in the repository and other places and
should be separated at some point.
I like the idea of adding configuration for extensions. I don't think
there should need to be any general built in configuration point as
that can generally be done by other aspects of the POM.
Sounds like a good one for the wiki :)
- Brett
On 30/06/2007, at 4:15 AM, Kenney Westerhof wrote:
Hi,
Just some thoughts here.
Maven can be customized with plugins. That is, the build currently is,
but what is the build? It seems dependency resolution is not part
of it.
What about we extend the <extensions> a bit, like this:
<extensions>
<extension>
<groupId/>
<artifactId/>
<version/>
<!-- so far no changes, but this is new: -->
<configuration>
</configuration>
</extension>
</extensions>
this way you can customize whatever components are present in the
extension.
for instance, a 'ConflictResolver' component.
This doesn't allow for built-in components to be customized
though.. and i'm not sure
we want that kind of info like this in the pom anyway - the system
behind it
should be totally hidden.
Perhaps something like configurable extension points would be
better. But we cannot
foresee all possible things to customize, like conflictresolvers
etc.. Within a short
amount of time the pom will become very complex and polluted...
Maybe allowing custom namespaces to extend the pom.. not too
portable either..
I'm just afraid we'll pollute the pom too much with all kinds of tags
for this and that; something more generic may be more future proof
and have
less changes to the pom.
-- Kenney
Mark Hobson wrote:
On 28/06/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
As long as you track this in your proposal and end result amounts to
what this is going to look like in a v4 POM in 2.1 where hopefully
we'll have something nicer like:
<conflictResolvers>
<conflictResolver>x</conflictResolver>
<conflictResolver>y</conflictResolver>
<conflictResolver>z</conflictResolver>
</conflictResolver>
And then in 2.1 if these strategies are employed we can look for the
property and map it into the POM before the build plan is executed.
Even though a graph will be used I don't think the identifiers
describing the strategy would need to change. So if this winds up
getting exposed in the POM lets pick some meaningful understandable
names before you put this in finally as if this goes in the POMs the
ids for the strategies at the very least should remain the same.
That's along the lines that I was thinking. So to summarise, in
2.0.x
we'd use the following syntax:
<properties>
<mavenConflictResolvers>x,y,z</mavenConflictResolvers>
</properties>
Whereas in 2.1.x the property syntax will be supported but deprecated
and we'll use the following preferred syntax:
<conflictResolvers>
<conflictResolver>x</conflictResolver>
<conflictResolver>y</conflictResolver>
<conflictResolver>z</conflictResolver>
</conflictResolver>
Possibly as a child element of <dependencies>.
The currently implemented conflict resolvers are named as follows
(descriptions copied from the Javadoc):
- nearest: Resolves conflicting artifacts by always selecting the
nearest declaration. Nearest is defined as the declaration that has
the least transitive steps away from the project being built.
- farthest: Resolves conflicting artifacts by always selecting the
farthest declaration. Farthest is defined as the declaration that has
the most transitive steps away from the project being built.
- newest: Resolves conflicting artifacts by always selecting the
newest declaration. Newest is defined as the declaration whose
version
is greater according to ArtifactVersion.compareTo.
- oldest: Resolves conflicting artifacts by always selecting the
oldest declaration. Oldest is defined as the declaration whose
version
is less according to ArtifactVersion.compareTo.
The default is nearest for backwards-compatibility.
If everyone is happy with the MNG-612 branch then I'd like to see it
land on 2.0.x and 2.1.x. See it0125 for an example of it in action.
Once the dust has settled on this discussion I'll wiki it up as
agreed. (Or should the proposal come first? ;)
I've got next week to continue on this and the other dependency tasks
I've been working on, so it'd be good to wrap this all up by then
before I have to move onto other work.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
