from:"kenney"


Yeah that would settle this once and for all ;)

Except you probably have to be able to specify the delimiters per
resource set sigh.

John Casey wrote:
I've seen several unix commands that allow configurable 
delimiters...maybe that would be a better option?


-john


On Jul 10, 2007, at 12:55 PM, Kenney Westerhof wrote:




Daniel Kulp wrote:

Personally, I was thinking of just doing $$ -> $.


Yah, that's already in place for plugin parameters.


Thus, if you want ${pom.version} outputted, it would be $${pom.version}.
I think @@ also needs to be done.


Yup.

My original idea was to use both by default but allow them to be 
configurable,
so you could use @foo@ for filtering and leave ${foo} alone or vice 
versa.

Doesn't cover the case where you want both @foo@ and ${foo} to be left
alone, but @bar@ and ${bar} interpolated, though.

So:

 $${foo} -> ${foo}
 ${foo} -> value_of_foo

 @@ -> @@ (or @?)
 @@foo@ -> @foo@  (or @@foo@@ -> @foo@ ?)
 @foo@  -> value_of_foo
 @foo@@ -> value_of_foo@, or @foo@, or @foo@@ ?

Maybe it's better if we leave the @foo@ interpretation as-is. ;)

-- Kenney


Dan
On Tuesday 10 July 2007 12:05, John Casey wrote:

Yeah, escaping makes more sense to me, too. IMO it's a bit of a duct-
tape solution to say this is only applicable in {archetype,
appserver, other-limited-effect-plugins...} when those are the
examples given... People can use filtering for just about anything,
and they may use the '${...}' format for their own expression
handling, which has nothing to do with Maven at all.

The question is: what escape sequence/character is safe to use?

-john

On Jul 10, 2007, at 9:17 AM, Andrew Williams wrote:

It's not just archetype - this has come up in appserver too, where
you need some properties in a file escaped and others left.
I suspect adding escape handling to the InterpolationFilterReader
might be a good way to go.

Andy

On 10 Jul 2007, at 11:35, Kenney Westerhof wrote:

Daniel Kulp wrote:

On Monday 09 July 2007 19:08, Kenney Westerhof wrote:

Daniel Kulp wrote:

On Monday 09 July 2007 14:42, Kenney Westerhof wrote:

Daniel Kulp wrote:

Yep.   That's the #1 issue.I've completely given up on
trying to
get the string "${pom.version}" outputted into the file.

Ok, but why are you filtering a file with that in there? Do you
need
filtering at all, or do you only want some things filtered?

You can exclude specific files from filtering; doesn't that
solve your
problem?

It has to do with creating an archtype.   The pom.xml that we
want the archtype to create needs to have certain versions pushed
in, but other things in the pom should be left as is (or allow us
to escape it).
The other thing we want to do is push some values INTO a resource
that eventually is a velocity template.  (actually, that's what
an archtype is anyway).   For those, we need the ability to not
have some thing substituted in.

Ok, so it's archetype stuff. Well, the archetype resources
should be velocity templates anyway, and processed with velocity.
It should -not- use filtering, just pure velocity. Then you can
use the velocity escaping mechanisms to leave certain expressions
untouched.

So for the short run I think updating archetype itself is the
safest..


Maybe just adding escaping to interpolationfilterreader is much
simpler than all of this, wdyt?

Probably yes, but would you consider that backwords compatible?
I have no problems with going that route if people don't think it
would seriously impact people.

Depends on how we'll be escaping I guess..

-- Kenney


Dan


The other thing I'd like to do is conditional filtering based on
whether the version is a SNAPSHOT or not.   Kind of like:
(pseudocode, not sure on the velocity syntax)

#if ${pom.version}.indexOf("SNAPSHOT") != -1
version.message=Version ${pom.version} - Use at your own risk.
#else
version.message=Version ${pom.version}
#fi

Why would you want that? :)

-- Kenney


2) The next option would be to add a filterType configuration
property onto the resources plugin itself.   You would need to
configure the plugin to use it.   Also, it would apply to all
resources with filtering=true.We could combine this with
(1) and instead of making "simple" the default if not
specified in the
resource, whatever this option is set to is the default.

This is a better option. the plugin can be configured with
resource
sets, which are just initialized from the pom itself.
perhaps 'src/main/velocity/' could be checked by default and
velocity-copied.

The problem is the "Resource" object that the resources plugin
uses
is maven-model defined.   Not something that's extensible as
that requires a schema change.I suppose what COULD work well
is to add: velocityResources = List
configuration to the resources plugin (and if list is empty,
look for the default of src/main/velocity)

Re: Version ranges and snapshots

Max Bowsher wrote:

Kenney Westerhof wrote:

Patrick Schneider wrote:

For now, I'm a fan of disallowing snapshots when they are not
explicitly in
the boundary, as per the patch.

In my mind, the problem with a profile flag is that it's an
all-or-nothing
proposition. Any released artifacts with version ranges will also
start to
pull in snapshots. There wouldn't be enough control, IMO.

You can always exclude snapshots explicitly:

[1.0,1.1-SNAPSHOT),(1.1-SNAPSHOT,1.1]

Snapshots are valid versions in a range [1.0, 1.1], or even [1.0, 1.1).

Personally I'm +1 for updating the docs, and let the presence of
snapshot repo's
and valid snapshot artifacts there determine wheter snapshots are used
or not.

Not only is the syntax above very cumbersome, but what about the
possibility of 1.0.1-SNAPSHOT, etc?

Ah. Yes indeed. That'll be really cumbersome.

Controlling this through snapshot repo presence/absence would be rather
suboptimal, because you couldn't pull in a snapshot for one particular
artifact without possibly getting unwanted snapshots for other
dependency artifacts published in the same repo.

True, though the proposed change will only affect version ranges, not versions.

I think snapshots are a different aspect, outside of version ranges. Version
ranges are meant to specify a range of versions. Snapshots fit perfectly
in a version range.

So you want to prevent accidental use of snapshots when released versions
are available in the given range.

Having a mechanism in place to explicitly state what dependencies can be
resolved
to snapshot versions, and what dependencies cannot is certainly useful

So what we're dealing here is a way to do that. This has nothing to do with
version
ranges but with being able to say that you don't want snapshots for a certain
artifact. Specifying a normal version (without SNAPSHOT) is not going to be resolved to a snapshot,
unless there's another declaration that does mention it, and with version ranges that could happen.
The current resolution mechanism uses the first match, so it's pretty random
(the order of the searched repositories is important here).

If someone specifies a version range, he doesn't care about the version except
that it must
be in that range because he knows those versions work. SNAPSHOTs that fall into
that range
are compatible, so why can't they be used?
What about other dependencies that _are_ declared as a snapshot and bring in a
SNAPSHOT version
also declared somewhere else with a SNAPSHOT-excluding range? Should the build
fail then?

Most importantly, making this change prevents snapshots from being used in
version ranges.
Sure, you can explicitly mention them in the range, but you'd have the same
problem
as the other way around: specifying 1.0.1-SNAPSHOT, 1.0.2-SNAPSHOT etc..

It seems we want more fine grained control on this matter.
We could change the order of resolution to first check for non-snapshots,
then for snapshots, so a non-snapshot will be used when it's possible. That
would solve the problem,
except for people who want to use snapshots.
Another solution would be to somehow mark wheter a dependency or version range
should
include or exclude snapshots, or add information to repositories specifying the
groupid/artifactids
they provide or must not provide. That way you can declare the same repo twice,
once with snapshots enabled
and once without, listing the dependencies.

Not sure if this is worth the trouble though..

Anyway, we could just 'assume' that when people specify version ranges they
don't want
snapshots and apply this change. I'm just worried about the side effects, since
A (using snapshots
in ranges) is possible now and B (excluding snapshots in ranges) is cumbersome,
but when we apply this, B is possible but A is even more cumbersome.

Ow, just thought of something - have 'processing instructions' or similar in
the version ranges,
like [1.0,2.0){snapshots=off} (or just use xml attributes ofcourse ;))

-- Kenney

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Version ranges and snapshots




Patrick Schneider wrote:

For now, I'm a fan of disallowing snapshots when they are not explicitly in
the boundary, as per the patch.

In my mind, the problem with a profile flag is that it's an all-or-nothing
proposition.  Any released artifacts with version ranges will also start to
pull in snapshots.  There wouldn't be enough control, IMO.



You can always exclude snapshots explicitly:

[1.0,1.1-SNAPSHOT),(1.1-SNAPSHOT,1.1]

Snapshots are valid versions in a range [1.0, 1.1], or even [1.0, 1.1).

Personally I'm +1 for updating the docs, and let the presence of snapshot repo's
and valid snapshot artifacts there determine wheter snapshots are used or not.

-- Kenney




Patrick

On 7/6/07, Mark Hobson <[EMAIL PROTECTED]> wrote:


Hi,

Whilst attempting to fix MNG-2994, I discovered MNG-3092 that was
contrary to the 2.0 design docs:

http://jira.codehaus.org/browse/MNG-3092

Brett, Kenney and myself had a brief discussion on IRC about this:
Kenney says that the behaviour is theoretically correct (which it is),
although I feel it goes against the practical usage described in the
docs.  The two main choices I can see are:

1) We stick to the design docs and disallow snapshots in ranges when
they aren't an explicit boundary, as per the MNG-3092 patch.

2) We reconsider the design docs and leave range resolution behaving
as it is, then use profiles to enable or disable snapshot repositories
at build time.

Any thoughts?

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]

Re: Resource filtering thoughts...




Daniel Kulp wrote:

Personally, I was thinking of just doing $$ -> $.


Yah, that's already in place for plugin parameters.



Thus, if you want ${pom.version} outputted, it would be $${pom.version}.

I think @@ also needs to be done.


Yup.

My original idea was to use both by default but allow them to be configurable,
so you could use @foo@ for filtering and leave ${foo} alone or vice versa.
Doesn't cover the case where you want both @foo@ and ${foo} to be left
alone, but @bar@ and ${bar} interpolated, though.

So:

 $${foo} -> ${foo}
 ${foo} -> value_of_foo

 @@ -> @@ (or @?)
 @@foo@ -> @foo@  (or @@foo@@ -> @foo@ ?)
 @foo@  -> value_of_foo
 @foo@@ -> value_of_foo@, or @foo@, or @foo@@ ?

Maybe it's better if we leave the @foo@ interpretation as-is. ;)

-- Kenney



Dan



On Tuesday 10 July 2007 12:05, John Casey wrote:

Yeah, escaping makes more sense to me, too. IMO it's a bit of a duct-
tape solution to say this is only applicable in {archetype,
appserver, other-limited-effect-plugins...} when those are the
examples given... People can use filtering for just about anything,
and they may use the '${...}' format for their own expression
handling, which has nothing to do with Maven at all.

The question is: what escape sequence/character is safe to use?

-john

On Jul 10, 2007, at 9:17 AM, Andrew Williams wrote:

It's not just archetype - this has come up in appserver too, where
you need some properties in a file escaped and others left.
I suspect adding escape handling to the InterpolationFilterReader
might be a good way to go.

Andy

On 10 Jul 2007, at 11:35, Kenney Westerhof wrote:

Daniel Kulp wrote:

On Monday 09 July 2007 19:08, Kenney Westerhof wrote:

Daniel Kulp wrote:

On Monday 09 July 2007 14:42, Kenney Westerhof wrote:

Daniel Kulp wrote:

Yep.   That's the #1 issue.I've completely given up on
trying to
get the string "${pom.version}" outputted into the file.

Ok, but why are you filtering a file with that in there? Do you
need
filtering at all, or do you only want some things filtered?

You can exclude specific files from filtering; doesn't that
solve your
problem?

It has to do with creating an archtype.   The pom.xml that we
want the archtype to create needs to have certain versions pushed
in, but other things in the pom should be left as is (or allow us
to escape it).
The other thing we want to do is push some values INTO a resource
that eventually is a velocity template.  (actually, that's what
an archtype is anyway).   For those, we need the ability to not
have some thing substituted in.

Ok, so it's archetype stuff. Well, the archetype resources
should be velocity templates anyway, and processed with velocity.
It should -not- use filtering, just pure velocity. Then you can
use the velocity escaping mechanisms to leave certain expressions
untouched.

So for the short run I think updating archetype itself is the
safest..


Maybe just adding escaping to interpolationfilterreader is much
simpler than all of this, wdyt?

Probably yes, but would you consider that backwords compatible?
I have no problems with going that route if people don't think it
would seriously impact people.

Depends on how we'll be escaping I guess..

-- Kenney


Dan


The other thing I'd like to do is conditional filtering based on
whether the version is a SNAPSHOT or not.   Kind of like:
(pseudocode, not sure on the velocity syntax)

#if ${pom.version}.indexOf("SNAPSHOT") != -1
version.message=Version ${pom.version} - Use at your own risk.
#else
version.message=Version ${pom.version}
#fi

Why would you want that? :)

-- Kenney


2) The next option would be to add a filterType configuration
property onto the resources plugin itself.   You would need to
configure the plugin to use it.   Also, it would apply to all
resources with filtering=true.We could combine this with
(1) and instead of making "simple" the default if not
specified in the
resource, whatever this option is set to is the default.

This is a better option. the plugin can be configured with
resource
sets, which are just initialized from the pom itself.
perhaps 'src/main/velocity/' could be checked by default and
velocity-copied.

The problem is the "Resource" object that the resources plugin
uses
is maven-model defined.   Not something that's extensible as
that requires a schema change.I suppose what COULD work well
is to add: velocityResources = List
configuration to the resources plugin (and if list is empty,
look for the default of src/main/velocity) and use that.In
that case,
"regular" resources can be configured just in build/resources
and build/testResources, but the velocity based ones would need
a full plugin configuration.   A bit inconsistent, but
acceptable.


After thinking about this a bit more, I wonder if it makes more
sense to just create a "maven

Re: [VOTE] Configure IDE plugins to download sources by default within Maven projects




Brian E. Fox wrote:

So I propose:



- if -DdownloadSources is specified, download sources and fallback to javadoc, 
just as it is now
- if -DdownloadJavaDoc is specified, download javadoc (possibly fallback to 
sources)
- if both are specified, download both.



And:



- don't make this a default; the default behaviour of attaching
 either source or javadoc when it's present in the local repo
 is fine though, but turning this on by default is just too slow.


This is already done in Eclipse 2.4 although it doesn't fallback to the javadoc.


Cool though the fallback has been there a long time ago, and still was until a 
few days ago
(just svn upped and it was gone; a few days ago this still was present...).

Guess the fallback isn't really required so it's fine like this imho.



http://jira.codehaus.org/browse/MECLIPSE-292

--Brian



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Proposal: Required declaration of properties in pom.xml




Jochen Kuhnle wrote:

Hi,

currently, Maven does not require declaration of properties used in 
the pom, you just use them anywhere you like. Usually, if a property 
is missing, bad things tend to happen because it is replaced with the 
string "null". On a good day, resources from "translations-null-null" 


When/where is it null?

aren't included in the build, on bad days it's worse... And when you 
find the missing property in a pom you haven't written, you have to 
figure out what "${lopt}" means and what its legal values are...


True, but proper defaults should be specified in the pom itself using
the normal properties tag. Commandline, profiles, and settings
can override these. A pom should just work out of the box. If you
want to customize it you'll have to read the pom to see what can be customized;
there should be a readme or documentation in the pom for that.

There's lots of cases where properties are used - pom interpolation,
plugin configuration, filtering.. which one are you talking about?

For pom interpolation, you may not always want properties evaluated.
In any case, if the property can't be evaluated, the ${expression} is 
left intact. So the null case doesn't apply here..


For plugin configuration, you cannot possibly list all properties for all
plugins out there.

For filtering, you may just want to print a warning or fail; this could
be configured in the resources plugin.

So how/when do you get the 'translations-null-null' problem exactly?

I don't like the proposal as it's way too verbose and as others have said
only fixes a small set of problems you may have, but doesn't cover all
cases.

There's an issue out there to make all property references/declarations
in the pom the same, preferrably value. 


Perhaps a '' section is more appropriate? :)



So instead typing


en_US


this proposal wants you to write



lopt
en_US
true
Locale to use


de_DE
Use German locale






This is rather verbose. Do you really want to list all locales in this case?



Of course, Maven should display an error if a required variable is 
missing. And it would be nice to have "help:describe-properties"...


-- Kenney




Regards,
Jochen



-
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]

Re: [VOTE] Configure IDE plugins to download sources by default within Maven projects



Ok, if you really need both sources and javadoc then that should
be possible. I never heard of the shift-f2 but indeed it doesn't work here.
I either use the tooltip when I hover over an element and possibly f2 for focus,
or open the javadoc view which displays the javadoc as soon as I select any 
element, which
does work with sources - no javadoc needed. This seems more of a bug
in eclipse than anything else though.

So I propose:

- if -DdownloadSources is specified, download sources and fallback to javadoc, 
just as it is now
- if -DdownloadJavaDoc is specified, download javadoc (possibly fallback to 
sources)
- if both are specified, download both.

And:

- don't make this a default; the default behaviour of attaching
 either source or javadoc when it's present in the local repo
 is fine though, but turning this on by default is just too slow.

-- Kenney


Mark Hobson wrote:

On 05/07/07, Cabasson Denis <[EMAIL PROTECTED]> wrote:

Well, I kinda changed the suject of the discussion.

The matter here is whether the eclipse-plugin should be able to 
download "sources AND javadoc" or only (as is the cas right now) 
"sources, and only javadoc as a fallback if sources are missing". I'd 
like to get the plugin download and link both for me.


But I agree with you on the matter that is not the original 
discussion, but it's closely related.
I don't really see how the original discussion could do with the 
actual version of the plugin BTW.


I agree that the eclipse plugin should be able to attach source jars,
javadoc jars or both (MECLIPSE-292), but I think the original
proposition proved to be too contentious.  I'm happy to leave it to
users' discretion for now.

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]

Re: Resource filtering thoughts...




Daniel Kulp wrote:

On Monday 09 July 2007 19:08, Kenney Westerhof wrote:

Daniel Kulp wrote:

On Monday 09 July 2007 14:42, Kenney Westerhof wrote:

Daniel Kulp wrote:

Yep.   That's the #1 issue.I've completely given up on trying to
get the string "${pom.version}" outputted into the file.

Ok, but why are you filtering a file with that in there? Do you need
filtering at all, or do you only want some things filtered?

You can exclude specific files from filtering; doesn't that solve your
problem?


It has to do with creating an archtype.   The pom.xml that we want the 
archtype to create needs to have certain versions pushed in, but other 
things in the pom should be left as is (or allow us to escape it).


The other thing we want to do is push some values INTO a resource that 
eventually is a velocity template.  (actually, that's what an archtype 
is anyway).   For those, we need the ability to not have some thing 
substituted in.




Ok, so it's archetype stuff. Well, the archetype resources
should be velocity templates anyway, and processed with velocity.
It should -not- use filtering, just pure velocity. 
Then you can use the velocity escaping mechanisms to leave certain 
expressions untouched.


So for the short run I think updating archetype itself is the safest..


Maybe just adding escaping to interpolationfilterreader is much
simpler than all of this, wdyt?


Probably yes, but would you consider that backwords compatible?   

I have no problems with going that route if people don't think it would 
seriously impact people.  


Depends on how we'll be escaping I guess..

-- Kenney



Dan



The other thing I'd like to do is conditional filtering based on
whether the version is a SNAPSHOT or not.   Kind of like: 
(pseudocode, not sure on the velocity syntax)


#if ${pom.version}.indexOf("SNAPSHOT") != -1
version.message=Version ${pom.version} - Use at your own risk.
#else
version.message=Version ${pom.version}
#fi

Why would you want that? :)

-- Kenney


2) The next option would be to add a filterType configuration
property onto the resources plugin itself.   You would need to
configure the plugin to use it.   Also, it would apply to all
resources with filtering=true.We could combine this with (1)
and instead of making "simple" the default if not specified in the
resource, whatever this option is set to is the default.

This is a better option. the plugin can be configured with resource
sets, which are just initialized from the pom itself.
perhaps 'src/main/velocity/' could be checked by default and
velocity-copied.

The problem is the "Resource" object that the resources plugin uses
is maven-model defined.   Not something that's extensible as that
requires a schema change.I suppose what COULD work well is to
add: velocityResources = List
configuration to the resources plugin (and if list is empty, look
for the default of src/main/velocity) and use that.In that case,
"regular" resources can be configured just in build/resources and
build/testResources, but the velocity based ones would need a full
plugin configuration.   A bit inconsistent, but acceptable.


After thinking about this a bit more, I wonder if it makes more
sense to just create a "maven-velocity-plugin" and ignore resources
all-together? That would be super quick to write.(I'd still like
to see the escaping issue fixed.  :-) We already have the plexus
VelocityComponent.   Would take very little work to wire it into a
plugin.


Anyway, what are peoples thoughts on this?Any other options?
What direction do people feel is the best way to proceed? I
personally would like to go with Option #1 and require Maven 2.0.8
if you want to use the advanced filtering, but I know some people
are totally against schema changes.

Well, if there's a good reason to change the schema then I'm all
for it. Maybe we should just add  again to dependencies
and resource sets, so the resource plugin can look at the
resourceset property 'filterType' or something, if it's set.

Either way, changes to the model won't happen until 2.1.

So, what's the problem with the filtering?

Getting any of the normal pom properties outputted to the target
file seems to be impossible.

-
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]

Re: Resource filtering thoughts...

2007-07-09 Thread Kenney Westerhof




Daniel Kulp wrote:

On Monday 09 July 2007 14:42, Kenney Westerhof wrote:

Daniel Kulp wrote:

After battling with the braindead resource filtering once again for
the ump-teenth time, I've decided I need to do something about
it

You dissin' my code huh? :)


The main thing I'd like to do is allow use of a better filter engine
(like velocity) that would provide much more flexibility.   The
issue is how to do it without breaking all the existing builds that
are out there.   Here are my thoughts

I'd very much like to know what the problems are. Probably the fact
that escaping is missing?


Yep.   That's the #1 issue.I've completely given up on trying to get 
the string "${pom.version}" outputted into the file.




Ok, but why are you filtering a file with that in there? Do you need filtering
at all, or do you only want some things filtered?

You can exclude specific files from filtering; doesn't that solve your problem?

Maybe just adding escaping to interpolationfilterreader is much simpler
than all of this, wdyt?



The other thing I'd like to do is conditional filtering based on whether 
the version is a SNAPSHOT or not.   Kind of like:  (pseudocode, not sure 
on the velocity syntax)


#if ${pom.version}.indexOf("SNAPSHOT") != -1 
version.message=Version ${pom.version} - Use at your own risk.

#else
version.message=Version ${pom.version}
#fi


Why would you want that? :)

-- Kenney





2) The next option would be to add a filterType configuration
property onto the resources plugin itself.   You would need to
configure the plugin to use it.   Also, it would apply to all
resources with filtering=true.We could combine this with (1) and
instead of making "simple" the default if not specified in the
resource, whatever this option is set to is the default.

This is a better option. the plugin can be configured with resource
sets, which are just initialized from the pom itself.
perhaps 'src/main/velocity/' could be checked by default and
velocity-copied.


The problem is the "Resource" object that the resources plugin uses is 
maven-model defined.   Not something that's extensible as that requires 
a schema change.I suppose what COULD work well is to add:

velocityResources = List
configuration to the resources plugin (and if list is empty, look for the 
default of src/main/velocity) and use that.In that case, "regular" 
resources can be configured just in build/resources and 
build/testResources, but the velocity based ones would need a full 
plugin configuration.   A bit inconsistent, but acceptable.



After thinking about this a bit more, I wonder if it makes more sense to 
just create a "maven-velocity-plugin" and ignore resources all-together?   
That would be super quick to write.(I'd still like to see the 
escaping issue fixed.  :-) We already have the plexus 
VelocityComponent.   Would take very little work to wire it into a 
plugin.



Anyway, what are peoples thoughts on this?Any other options? 
What direction do people feel is the best way to proceed? I

personally would like to go with Option #1 and require Maven 2.0.8
if you want to use the advanced filtering, but I know some people
are totally against schema changes.

Well, if there's a good reason to change the schema then I'm all for
it. Maybe we should just add  again to dependencies and
resource sets, so the resource plugin can look at the resourceset
property 'filterType' or something, if it's set.

Either way, changes to the model won't happen until 2.1.

So, what's the problem with the filtering?


Getting any of the normal pom properties outputted to the target file 
seems to be impossible.   



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Resource filtering thoughts...

2007-07-09 Thread Kenney Westerhof




Daniel Kulp wrote:
After battling with the braindead resource filtering once again for the 
ump-teenth time, I've decided I need to do something about it   



You dissin' my code huh? :)

The main thing I'd like to do is allow use of a better filter engine 
(like velocity) that would provide much more flexibility.   The issue is 
how to do it without breaking all the existing builds that are out 
there.   Here are my thoughts


I'd very much like to know what the problems are. Probably the fact
that escaping is missing?

1) Ideally to me, we'd add a "filterType" element to the Resource type in 
maven-model.   It would default to "simple" (the existing 
implementation) if unspecified.   We could support "velocity" and others 
in the future.  This way, a single project could have some resource 
directories filtering with velocity, others with the old stuff, etc...  
You also wouldn't need to configure the resources plugin directly just 
like you don't need to now.   The major downside to this is it requires 
a (backwords compatible) change to the schema and of course would 
require maven 2.0.8 (assuming it's in place before 2.0.8 is released). 

2) The next option would be to add a filterType configuration property 
onto the resources plugin itself.   You would need to configure the 
plugin to use it.   Also, it would apply to all resources with 
filtering=true.We could combine this with (1) and instead of 
making "simple" the default if not specified in the resource, whatever 
this option is set to is the default.


This is a better option. the plugin can be configured with resource sets,
which are just initialized from the pom itself.
perhaps 'src/main/velocity/' could be checked by default and velocity-copied.

3) The other option would be to try something "automatic".   Example:  if 
the file ends in ".vm", strip the .vm and filter with velocity. I 
REALLY don't like this option (and it's also not really backwords 
compatible).   


No it isn't.. usually .vm files are used by the application itself so this
is definitely not the way. Even files with other extensions
may be used by the application itself as velocity templates.

Anyway, what are peoples thoughts on this?Any other options?  What 
direction do people feel is the best way to proceed? I personally 
would like to go with Option #1 and require Maven 2.0.8 if you want to 
use the advanced filtering, but I know some people are totally against 
schema changes.


Well, if there's a good reason to change the schema then I'm all for it.
Maybe we should just add  again to dependencies and resource
sets, so the resource plugin can look at the resourceset property 'filterType'
or something, if it's set. 


Either way, changes to the model won't happen until 2.1.

So, what's the problem with the filtering? 


-- Kenney

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Wagon-webdav

2007-07-08 Thread Kenney Westerhof


Hi,

I recently fixed 2 bugs in wagon-webdav rc1-snapshot
that make it possible to use it with maven 2.1 and 2.0.6/2.0.7.

One bug was the addition of the omitted and required plexus-utils
dependency - the code directly uses it. Since 2.0.6, plexus-utils
is shaded and plugins and extensions are required to list plexus-utils
as a direct dependency if they use it.

The second bug I fixed was that the 'isCollection' call looked
at a DAV property that was not retrieved - only the name property
was retrieved. I changed the preceding call to retrieve the name property
to retriev the default properties.

I'd like to see wheter it's feasible to release this wagon provider
separately as rc1, or wheter we have to release the entire wagon
stack.

The problem is that everything that uses a dav repository (like codehaus)
now requires to list the apache snapshot repository in order to use the fixed
wagon-webdav.

WDYT?

-- Kenney


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: finding maven.home in the invoker

2007-07-08 Thread Kenney Westerhof




Brian E. Fox wrote:

I recently had some trouble with the invoker getting a good maven.home
value from the mvn script. I came across this code in the eclipse tests
that seems to work pretty well. Is there any objection to moving this
code into the invoker in a fall back scenario? (ie if the executable
can't be found via the normal means, try this) The code is basically
walking through the path to find mvn...in most cases a user will have
mvn on their path so it seems like a good assumption.


The code below is bad. The system path is NOT set in java.library.path - this
is for dll/so files (jni stuff).

Assuming maven is in the path when no env var can be found is ok though,
i'm not sure why the maven home is even needed.

Btw, i already updated both the invoker and the verifier to also
check the M2_HOME env var, which should fix things on some installations.

Back to the code below. If it's changed to 'path = System.getenv( "PATH" )
it may work.

However, if you look at the 'mvn' script, it sets the maven.home variable:

exec "$JAVACMD" \
 $MAVEN_OPTS \
 -classpath "${M2_HOME}"/lib/maven-embedder-*.jar \
 "-Dclassworlds.conf=${M2_HOME}/bin/m2.conf" \
 "-Dmaven.home=${M2_HOME}"  \
 ${CLASSWORLDS_LAUNCHER} $QUOTED_ARGS

so ideally the maven.home property should just work. I don't know why it 
doesn't,
but maybe we should look into that as maven just provides this information
since version 2.0.

-- Kenney



 


String mavenHome = System.getProperty( "maven.home" );

 


// maven.home is set by surefire when the test is run with
maven, but better make the test run in IDEs without

// the need of additional properties

if ( mavenHome == null )

{

String path = System.getProperty( "java.library.path" );

String[] paths = StringUtils.split( path,
System.getProperty( "path.separator" ) );

for ( int j = 0; j < paths.length; j++ )

{

String pt = paths[j];

if ( new File( pt, "mvn" ).exists() )

{

System.setProperty( "maven.home", new File( pt
).getAbsoluteFile().getParent() );

break;

}

 


}

}




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] maven-eclipse-plugin 2.4


Final update: I checked out the tag cleanly, ran another build
and it passed fine.
The build took 9 mins 37 seconds. Ridiculous, but:

+1

Kenney Westerhof wrote:

Update:

It seems i was impatient, it took almost 3 minutes to run that single test.
After that it continued (on 2.0.7), but I got a failure:

--- 


Test set: org.apache.maven.plugin.eclipse.EclipsePluginMasterProjectTest
--- 

Tests run: 6, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 39.878 
sec <<< FAILURE!
testModule1Project(org.apache.maven.plugin.eclipse.EclipsePluginMasterProjectTest)  
Time elapsed: 11.979 sec  <<< ERROR!
org.apache.maven.plugin.eclipse.ExecutionFailedException: Failed to 
execute build.
POM: 
/vol/home/forge/work/opensource-rw/maven-trunks/plugins/maven-eclipse-plugin/target/test-classes/projects/master-test/pom.xml 

Goals: org.apache.maven.plugins:maven-eclipse-plugin:test:clean, 
org.apache.maven.plugins:maven-eclipse-plugin:test:eclipse

Exit Code: 1
Error: null
Build Log: 
file:/vol/home/forge/work/opensource-rw/maven-trunks/plugins/maven-eclipse-plugin/target/surefire-reports/build-output/org.apache.maven.plugin.eclipse.EclipsePluginMasterProjectTest_testModule1Project.build.log 


(Resulting exit code: 1)
   at 
org.apache.maven.plugin.eclipse.AbstractEclipsePluginTestCase.executeMaven(AbstractEclipsePluginTestCase.java:309) 



Last part of the file:/ indicated above:

[ERROR] BUILD ERROR
[INFO] 

[INFO] Internal error in the plugin manager executing goal 
'org.apache.maven.plugins:maven-eclipse-plugin:test:eclipse': Unable to 
find the mojo 
'org.apache.maven.plugins:maven-eclipse-plugin:test:eclipse' in the 
plugin 'org.apache.maven.plugins:maven-eclipse-plugin'
Component descriptor cannot be found in the component repository: 
org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-eclipse-plugin:test:eclipse. 

[INFO] 


[DEBUG] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Internal error 
in the plugin manager executing goal 
'org.apache.maven.plugins:maven-eclipse-plugin:test:eclipse': Unable to 
find the mojo 
'org.apache.maven.plugins:maven-eclipse-plugin:test:eclipse' in the 
plugin 'org.apache.maven.plugins:maven-eclipse-plugin'
   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:543) 

   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) 

   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) 

   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) 

   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) 

   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) 


   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
   at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 

   at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 


   at java.lang.reflect.Method.invoke(Method.java:585)
   at 
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)

   at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
   at 
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)

   at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.PluginManagerException: Unable to 
find the mojo 
'org.apache.maven.plugins:maven-eclipse-plugin:test:eclipse' in the 
plugin 'org.apache.maven.plugins:maven-eclipse-plugin'
   at 
org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:571) 

   at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:421) 

   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) 


   ... 16 more
Caused by: 
org.codehaus.plexus.component.repository.exception.ComponentLookupException: 
Component descriptor cannot be found in the component repository: 
org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-eclipse-plugin:test:eclipse. 

   at 
org.codehaus.plexus.DefaultPlexusContainer.look

Re: [VOTE] maven-eclipse-plugin 2.4

  at 
org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:562)
   ... 18 more
[INFO] 
[INFO] Total time: 9 seconds


btw, tests take about 7 minutes whereas bootstrapping maven itself takes only 3 
minutes.

my -1 stands, unless I'm the only one where this fails.

-- Kenney

Kenney Westerhof wrote:

I assume this is a vote to _release_ maven-eclipse-plugin 2.4.

-1 until the tests are fixed:


[INFO] [surefire:test]
[INFO] Surefire report directory: 
/vol/home/forge/work/opensource-rw/maven-trunks/plugins/maven-eclipse-plugin/target/surefire-reports 



---
T E S T S
---
Running org.apache.maven.plugin.eclipse.AddMavenRepoMojoTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.899 sec
Running 
org.apache.maven.plugin.eclipse.writers.EclipseOSGiManifestWriterTest

Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec
Running org.apache.maven.plugin.eclipse.RadPluginTest
*** Running test builds; output will be directed to: 
target/surefire-reports/build-output


[INFO] Installing target/maven-eclipse-plugin-test.jar to 
/vol/home/forge/work/opensource-rw/maven-trunks/plugins/maven-eclipse-plugin/target/test-classes/m2repo/org/apache/maven/plugins/maven-eclipse-plugin/test/maven-eclipse-plugin-test.jar 

[INFO] Installing ../pom.xml to 
/vol/home/forge/work/opensource-rw/maven-trunks/plugins/maven-eclipse-plugin/target/test-classes/m2repo/org/apache/maven/plugins/maven-plugins/9-SNAPSHOT/maven-plugins-9-SNAPSHOT.pom 

[INFO] Installing ../../pom/maven/pom.xml to 
/vol/home/forge/work/opensource-rw/maven-trunks/plugins/maven-eclipse-plugin/target/test-classes/m2repo/org/apache/maven/maven-parent/6-SNAPSHOT/maven-parent-6-SNAPSHOT.pom 

[INFO] Installing ../../pom/maven/../asf/pom.xml to 
/vol/home/forge/work/opensource-rw/maven-trunks/plugins/maven-eclipse-plugin/target/test-classes/m2repo/org/apache/apache/5-SNAPSHOT/apache-5-SNAPSHOT.pom 

*** Installed test-version of the Eclipse plugin to: 
/vol/home/forge/work/opensource-rw/maven-trunks/plugins/maven-eclipse-plugin/target/test-classes/m2repo 



and it indefinitely hangs at this point, no cpu load.


Tested with maven 2.1 and 2.0.7.
Otherwise the plugin works great.

-- Kenney

Brian E. Fox wrote:

It's been about 5 months since an eclipse plugin release and we have
lots of fixes and a handful of enhancements:

Bug
* [MECLIPSE-108] - .wtpmodules with version 2.4 for
javax.servlet:servlet-api:2.3
* [MECLIPSE-109] - .component wb-resource source path incorrect for ear
packaging
* [MECLIPSE-151] - Incorrect name for test sources jars
* [MECLIPSE-198] - EJB version is not resloved
* [MECLIPSE-215] - WTP 1.5 Documentation
* [MECLIPSE-220] - Incorrect eclipse facet information when doing mvn
eclipse:eclipse for war and ejb projects.
* [MECLIPSE-225] - Invalid .classpath Entries.
* [MECLIPSE-233] - Manifest attributes incorrectly treated as
case-sensitive
* [MECLIPSE-234] - [PATCH] EclipsePlugin.extractResourceDirs() reuses
String method argument causing maven-eclipse.xml copy-resources problems
* [MECLIPSE-236] - eclipse:make-artifacts should preserve the
resolution:=optional directive
* [MECLIPSE-237] - unsafe EclipseSourceDir.equals() method
* [MECLIPSE-241] - Compiler settings in pluginManagement aren't used in
wtp facet
* [MECLIPSE-243] - The last 2.4 SNAPSHOT forbid Apache Directory Server
to be built
* [MECLIPSE-248] - Eclipse plugin looks for pom version "test"
* [MECLIPSE-255] - WTP Settings does not use servlet-api version defined
in pom.xml
* [MECLIPSE-263] - Project Facet 'Java' set to 1.4 instead of 5.0 in a
Java 5.0 project
* [MECLIPSE-278] - duplicated classpathentries
* [MECLIPSE-279] - PDE projects should be considered java projects in
all cases
* [MECLIPSE-287] - Regression - fails to correctly construct classpath
containing dependencies with classifiers
Improvement
* [MECLIPSE-207] - Add supprt for arbitrary facets, like JSF
* [MECLIPSE-267] - Resolve version ranges in make-artifacts
* [MECLIPSE-268] - [eclipse:rad goal] Make customization of servlet
version, jsp version, ... possible through pom configuration
* [MECLIPSE-286] - Ability to skip generated-resources/rad6 folder
creation while executing eclipse:rad
New Feature
* [MECLIPSE-119] - Allow custom project name for eclipse projects
* [MECLIPSE-189] - addVersionToProjectName property
* [MECLIPSE-251] - Allows prefixing of eclipse project name
* [MECLIPSE-271] - Ability to skip

The site has been updated:
http://maven.apache.org/plugins/maven-eclipse-plugin

Plugin is staged here:
http://people.apache.org/~brianf/staging-repository/

Vote is open for 72hrs.

+1


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail

Re: [VOTE] maven-eclipse-plugin 2.4


I assume this is a vote to _release_ maven-eclipse-plugin 2.4.

-1 until the tests are fixed:


[INFO] [surefire:test]
[INFO] Surefire report directory: 
/vol/home/forge/work/opensource-rw/maven-trunks/plugins/maven-eclipse-plugin/target/surefire-reports

---
T E S T S
---
Running org.apache.maven.plugin.eclipse.AddMavenRepoMojoTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.899 sec
Running org.apache.maven.plugin.eclipse.writers.EclipseOSGiManifestWriterTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec
Running org.apache.maven.plugin.eclipse.RadPluginTest
*** Running test builds; output will be directed to: 
target/surefire-reports/build-output

[INFO] Installing target/maven-eclipse-plugin-test.jar to 
/vol/home/forge/work/opensource-rw/maven-trunks/plugins/maven-eclipse-plugin/target/test-classes/m2repo/org/apache/maven/plugins/maven-eclipse-plugin/test/maven-eclipse-plugin-test.jar
[INFO] Installing ../pom.xml to 
/vol/home/forge/work/opensource-rw/maven-trunks/plugins/maven-eclipse-plugin/target/test-classes/m2repo/org/apache/maven/plugins/maven-plugins/9-SNAPSHOT/maven-plugins-9-SNAPSHOT.pom
[INFO] Installing ../../pom/maven/pom.xml to 
/vol/home/forge/work/opensource-rw/maven-trunks/plugins/maven-eclipse-plugin/target/test-classes/m2repo/org/apache/maven/maven-parent/6-SNAPSHOT/maven-parent-6-SNAPSHOT.pom
[INFO] Installing ../../pom/maven/../asf/pom.xml to 
/vol/home/forge/work/opensource-rw/maven-trunks/plugins/maven-eclipse-plugin/target/test-classes/m2repo/org/apache/apache/5-SNAPSHOT/apache-5-SNAPSHOT.pom
*** Installed test-version of the Eclipse plugin to: 
/vol/home/forge/work/opensource-rw/maven-trunks/plugins/maven-eclipse-plugin/target/test-classes/m2repo

and it indefinitely hangs at this point, no cpu load.


Tested with maven 2.1 and 2.0.7.
Otherwise the plugin works great.

-- Kenney

Brian E. Fox wrote:

It's been about 5 months since an eclipse plugin release and we have
lots of fixes and a handful of enhancements:

Bug
* [MECLIPSE-108] - .wtpmodules with version 2.4 for
javax.servlet:servlet-api:2.3
* [MECLIPSE-109] - .component wb-resource source path incorrect for ear
packaging
* [MECLIPSE-151] - Incorrect name for test sources jars
* [MECLIPSE-198] - EJB version is not resloved
* [MECLIPSE-215] - WTP 1.5 Documentation
* [MECLIPSE-220] - Incorrect eclipse facet information when doing mvn
eclipse:eclipse for war and ejb projects.
* [MECLIPSE-225] - Invalid .classpath Entries.
* [MECLIPSE-233] - Manifest attributes incorrectly treated as
case-sensitive
* [MECLIPSE-234] - [PATCH] EclipsePlugin.extractResourceDirs() reuses
String method argument causing maven-eclipse.xml copy-resources problems
* [MECLIPSE-236] - eclipse:make-artifacts should preserve the
resolution:=optional directive
* [MECLIPSE-237] - unsafe EclipseSourceDir.equals() method
* [MECLIPSE-241] - Compiler settings in pluginManagement aren't used in
wtp facet
* [MECLIPSE-243] - The last 2.4 SNAPSHOT forbid Apache Directory Server
to be built
* [MECLIPSE-248] - Eclipse plugin looks for pom version "test"
* [MECLIPSE-255] - WTP Settings does not use servlet-api version defined
in pom.xml
* [MECLIPSE-263] - Project Facet 'Java' set to 1.4 instead of 5.0 in a
Java 5.0 project
* [MECLIPSE-278] - duplicated classpathentries
* [MECLIPSE-279] - PDE projects should be considered java projects in
all cases
* [MECLIPSE-287] - Regression - fails to correctly construct classpath
containing dependencies with classifiers
Improvement
* [MECLIPSE-207] - Add supprt for arbitrary facets, like JSF
* [MECLIPSE-267] - Resolve version ranges in make-artifacts
* [MECLIPSE-268] - [eclipse:rad goal] Make customization of servlet
version, jsp version, ... possible through pom configuration
* [MECLIPSE-286] - Ability to skip generated-resources/rad6 folder
creation while executing eclipse:rad
New Feature
* [MECLIPSE-119] - Allow custom project name for eclipse projects
* [MECLIPSE-189] - addVersionToProjectName property
* [MECLIPSE-251] - Allows prefixing of eclipse project name
* [MECLIPSE-271] - Ability to skip

The site has been updated:
http://maven.apache.org/plugins/maven-eclipse-plugin

Plugin is staged here:
http://people.apache.org/~brianf/staging-repository/

Vote is open for 72hrs.

+1


-
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]

Re: invoker test failure


Try again, I just committed a fix.

-- Kenney

Brian E. Fox wrote:

I'm getting an error building the 2.0.7-snapshot invoker:

Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 11.861
sec <<< FAILURE!
testBuildShouldFail(org.apache.maven.shared.invoker.DefaultInvokerTest)
Time elapsed: 3.782 sec  <<< FAILURE!
junit.framework.AssertionFailedError: expected:<1> but was:<0>


InvocationResult result = invoker.execute( request );

assertEquals( 1, result.getExitCode() );



I'm using m2.0.7 to run this on XP. I know there were some issues around
2.0.7 at one point not returning the correct exit code. Is anyone else
seeing this issue with Invoker?

BTW..I'm really just trying to dig into the invoker to test why it fails
to find the maven executable when running through cygwin on windows:

Tests run: 29, Failures: 0, Errors: 29, Skipped: 0, Time elapsed: 4.689
sec <<< FAILURE!
testProject01(org.apache.maven.plugin.eclipse.EclipsePluginTest)  Time
elapsed: 0.126 sec  <<< ERROR!
java.lang.NullPointerException
at
org.apache.maven.shared.invoker.MavenCommandLineBuilder.findMavenExecuta
ble(MavenCommandLineBuilder.java:367)
at
org.apache.maven.shared.invoker.MavenCommandLineBuilder.build(MavenComma
ndLineBuilder.java:33)
at
org.apache.maven.shared.invoker.DefaultInvoker.execute(DefaultInvoker.ja
va:88)
at
org.apache.maven.shared.test.plugin.BuildTool.executeMaven(BuildTool.jav
a:89)



-
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]

Re: [VOTE] Configure IDE plugins to download sources by default within Maven projects




Cabasson Denis wrote:

About this link, why couldn't we have a consistent behaviour for javadoc and 
sources jar?

Why not adding a downloadJavadoc property, which, when set to true, would 
download and attach the javadoc to the dependency.

I don't really see why javadoc should be a fallback if sources are not 
available.


I wrote that, so I'll comment.

You do NOT need javadoc if you have sources available in eclipse. Eclipse will 
use the javadoc
from the sources.

-1 on all votes btw. If you want sources, tell the plugin. It will get _all_ 
sources
(and possibly _all_ javadocs if you want that), which can take a few hours to 
do on
a reasonably sized project. If you really need to, or want to, make a profile 
in settings.xml
or config in a root pom.

-- Kenney




Some developpers might prefer to have javadoc linked, some sources linked and 
some both. Shouldn't the eclipse plugin allow for all the possiblities instead 
of stating that the preferred option is always to get the sources instead of 
the Javadoc?

To be followed in :
http://jira.codehaus.org/browse/MECLIPSE-292

Denis.
 


-Message d'origine-
De : Mark Hobson [mailto:[EMAIL PROTECTED] 
Envoyé : Tuesday, July 03, 2007 4:08 PM

À : Maven Developers List
Objet : Re: [VOTE] Configure IDE plugins to download sources 
by default within Maven projects


On 03/07/07, Brett Porter <[EMAIL PROTECTED]> wrote:

+1 to Javadoc

-1 to sources (just a vote, not a veto :)

In the eclipse plugin, the downloadSources flag controls them both:
http://maven.apache.org/plugins/maven-eclipse-plugin/faq.html#
import-javadoc

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]

Re: [m2] Conflict resolvers

2007-06-29 Thread Kenney Westerhof


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  a bit, like this:


 
   
   
   
   
   
   
 


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:


   x
   y
   z


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:


 x,y,z


Whereas in 2.1.x the property syntax will be supported but deprecated
and we'll use the following preferred syntax:


 x
 y
 z


Possibly as a child element of .

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]

Re: Contextualizable implemented, but not invoked

2007-06-27 Thread Kenney Westerhof



That must be it then, though I don't know how you get a mojo
to be run, declared as an extension..


Btw, i hoped for the output to name the realm, but this apparently is
maven 2.0.x. if you could typecast the classloader to ClassRealm
and then call 'getId()' on it, I think you'll find it prints 'extensions' or 
similar.

So it looks like the filtering isn't applied to the extensions, only to 
plugins..

-- Kenney



Jochen Wiedmann wrote:

More info: I cannot reproduce the problem with another Mojo, which
isn't declared as an extension.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Question regarding 2.1 Versioning

2007-06-27 Thread Kenney Westerhof


Hi,


Timothy Reilly wrote:

I just read: http://docs.codehaus.org/display/MAVEN/Versioning Nice
document btw, well thought out.


Thanks ;)


I have a curiosity question...Under: Make version handling pluggable

Is this saying I would have to define version schemas using a
xsd/schema, or is it saying the versionScheme artifact is a java
artifact that implements the required interfaces (like a plugin) and the
default implementation uses xsd/schema?


It's a proposal document, so neither is currently implemented.

The Java artifact approach is the most feasible using the 
mechanism in the POM, and this will probably be implemented in 2.1.

The XSD or XML approach will most likely be too slow for Maven to use, and
I'm still not sure if it's feasible to create a standard grammar that'll work
for all version schemes. Though having something like that would certainly
make automating version comparison for non-java applications using Maven 
metadata
possible.


I think the schema approach addresses my current nit (managing third
party jars with xx.xx.xx.xx versioning scheme), but was interested in
how this will work.


Would this be the OSGi versioning scheme? What are the problems you're 
experiencing
atm. using maven's built-in versioning?

There's still some work to be done here. The solutions specified there are
not implemented yet, and won't be until 2.1. 


-- Kenney

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Contextualizable implemented, but not invoked

2007-06-26 Thread Kenney Westerhof




Jochen Wiedmann wrote:

On 6/26/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:


It must be being pulled in by a dep in the mojo. Is this something
that I can see?


Unfortunately not yet. Shall I file a Jira issue with some sample code?



Can you add

static { System.out.println( "XXX " + Contextualizable.class + ": " + 
Contextualizable.class.getClassLoader() ); }

to your mojo and see what it prints?

-- Kenney




Thanks,

Jochen




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [m2] Conflict resolvers

2007-06-25 Thread Kenney Westerhof

Mark Hobson wrote:

On 22/06/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:

On 22 Jun 07, at 3:15 AM 22 Jun 07, Mark Hobson wrote:
> As mentioned above, this requires a change in the Maven installation
> rather than the POM.  Obviously far from ideal, but I'm happy to live
> with this for the huge gain in productivity.

So how exactly does this help with your situation as I'm looking for
details as I'm loathe to put this in 2.0.x.

Okay, imagine a project with a deep dependency tree where many
dependencies bring in common dependencies at various levels.
Initially, let's say there are no version conflicts amongst the
dependencies.  Now, a bug fix version of a common dependency is
released and updated in the most appropriate place within the
dependency tree.  We now have a conflict and it is purely down to the
depth of the updated dependency as to whether it is propagated through
the whole project.

Now, there are three solutions: 1) Update all other components that
also depend on this dependency so there are no version conflicts; 2)
Add the bug fix version to the main project's depMan; 3) Rely on the
conflict resolution strategy to resolve the required version.

(1) becomes extremely impractical in large projects; (2) works, but
over time, as more and more versions are fixed in depMan, it starts to
resemble Maven 1's flattened list of dependencies, thus causing even
more maintenance problems; (3) seems like the most natural place to
make these decisions.

2 doesn't work without stripping all version tags on that dependency from
all modules, as depMan only provides defaults for direct deps. 
3 doesn't always work - if you build a sub-tree of modules that doesn't

have any dep with the bugfix version you still get the older one, so, what
version you'll get will depend on where you build (how big the reactor is).

-- Kenney

This is basically our situation and why we need a more intuitive
conflict resolver than nearest-wins.  You can see that the concept of
nearness becomes more and more arbitrary as the dependency tree grows.

From here, the plan is to supplement the highest-wins conflict

resolution with version ranges to restrict mediation and release POMs
for reproducibility, hence my work in this area too.

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]

Re: Encoding issues for 2.0.8

2007-06-23 Thread Kenney Westerhof




Hervé BOUTEMY wrote:

Le samedi 23 juin 2007, Brett Porter a écrit :

We shouldn't permit relative entities in the POM - it would cause
grief when deployed to the repository.

- Brett

ok, then the target API is read(InputStream)
I won't add read(URL).


I think read(URL) is actually the only good API to add.
I'm not sure how rome does it - pushbackstream or whatever, but an URL has 2 
advantages:
- you can re-open the url to start reading again
- you have the location present to do relative resolution if necessary (outside 
of modello).

We could also just use the xml api's for this, since they're designed for it: 
javax.xml.transform.Source
and implementations (StreamSource comes to mind).

-- Kenney



regards,

Hervé


On 23/06/2007, at 5:29 AM, Hervé BOUTEMY wrote:

Le vendredi 22 juin 2007, Arnaud HERITIER a écrit :

Be careful, because when you read an xml file with a reader (or an
inputstream) instead of a path (or an url) you can't use relative
entities
in xml (because the parser can't know where the main doc is).

yes, read(InputStream) is better than read(Reader) for encoding,
but does not
help for relative entities.
Do you want that I add read(URL) at the same time, and document it
as the
preferred way of getting the model read? At the first time, for
compatibility
reasons, it would call read(InputStream) then read(Reader), but in
the long
term, it could be coded to permit relative entities.
WDYT?

Hervé


This is not a problem because we discourage the usage of xml
entities in
our xml documents, but we have to continue to say it !!!

Arnaud

On 22/06/07, Hervé BOUTEMY <[EMAIL PROTECTED]> wrote:

Le vendredi 22 juin 2007, Kenney Westerhof a écrit :

Hi,

Hi,


indeed, it's a case of doing new XXXInputstream( something,
"encoding"

),


or a reader. Some work has been done on this, IIRC.

The problem is that you need to prescan the xml declaration, so you

start


parsing until you get the first xml language element that is not a

comment,


(an xml element, in which case encoding is utf8, or
 a doctype declaration, encoding is utf8, or
 a processing instruction, and if it's the xml processing
instruction

parse


the encoding attribute and use that, otherwise it's utf8).

This isn't too hard to do, except you need to restart reading
the xml

file


from start, if the encoding is not utf-8. The real problem is in
the

API's;


you cannot take a reader and restart that, since you cannot
change the
encoding on an instantiated reader, and you certainly don't want to
wrap it. You'd need access to a raw inputstream that doesn't apply
encoding transformations to the bytes, and wrap that in a Pushback
something and then rewrap it if you found the encoding.

exactly, this is the job done by XmlReader in Rome:

https://rome.dev.java.net/apidocs/0_5/com/sun/syndication/io/
XmlReader.ht
ml

I have the class, well written and tested by Rome developers. My
first
question is then: where to put it, to be able to use it in a lot of
places where there are Readers instanciated for XML streams?
plexus-utils? or make a dependency on Rome? or another place?


I'm a bit fuzzy on all the java.io api's, so we'll have to find the

proper


class to use in the API so we can do this; a File would work.

Anyway, I once tried to fix this issue but the api had to be
changed
and there were just too many changes across plexus and maven at the
time to push this through.

With this class available, the change to Maven model can be backward
compatible:
- the old read(Reader) API remains for compatibility, but is
deprecated
- a new read(InputStream) API is added, which calls read(new
XmlReader(in))
The whole Maven code can then slowly migrate from deprecated
Reader API
to the
new InputStream one, or use XmlReader if it is too hard to switch to
InputStream.
The only change is that there is a new dependency to this XmlReader
class: I
don't know if it is a real problem or not.

I searched a little bit, this new API addition could be done
individually
in
each .mdo file. But of course integrating it the code generation
mechanism of
Modello would be a lot better: Jason, if your proposal to have
access to
Modello is still valid, I'm interested.

Regards

Hervé


-- Kenney

Hervé BOUTEMY wrote:

Le jeudi 21 juin 2007, Jason van Zyl a écrit :

It seems like there are many problems with encoding that could be
easily solved with a couple tweaks to modello, specifically the
reader and writing so I've scheduled these for 2.0.8. There some
patches for these and hopefully Herve will work his magic with
his
suggested fix. I like the idea of borrowing the idea from the
Rome
IO utils to find the right encoding by default. That could
easily be
integrated into modello. Herve if you need access to Modello
we can
set you up.

I'm interested at working on that. Do I need Modello access, or
other
components? I don't r

Re: Surefire report failure.

It seems to run the 2.0 version of the report plugin, which is quite old.
Try setting the version for surefire and the report plugin to 2.3 or later
snapshots.

The surefire artifacts on central haven't been updated since feb 28 2007,
so there haven't been any deployments lately.
Did you mean the snapshot repository? If so, what's broken there?

-- Kenney

Ole-Martin Mørk wrote:

I am having the same problem. Just appeared today out of blue..

What has happened with the surefire plugins lately? It seems like people
are

deploying a lot of broken surefire artifacts to the central repository..

-olemartin

2007/6/15, Jon Strayer <[EMAIL PROTECTED]>:

I have a main project with two subprojects. Both of the subprojects use
the
surefire report. The main project does not. I can run mvn:site on
either

of the subprojects and it works fine. But when I run on the main project
it
fails with this error message:

[INFO] Error getting reports from the plugin '
org.apache.maven.plugins:maven-surefire-report-plugin': Unable to find
the
mojo
'org.apache.maven.plugins:maven-surefire-report-plugin:2.0:report' in

the plugin 'org.apache.maven.plugins:maven-surefire-report-plugin'
Component descriptor cannot be found in the component repository:
org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-surefire-report

-plugin:2.0:report.

Look at the component repository:

org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-surefire-report-plugin:2.0:report

When I search the mailing list for "Mojoorg" I get a lot of hits, but
nobody
seems to be paying attention to it. Is it a bad error message or is
it a

clue to my problem?

--
Esse Quam Videre
To Be, rather than to Seem

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: .isSnapshot changes version

Hervé BOUTEMY wrote:

Le mercredi 20 juin 2007, Kenney Westerhof a écrit :

Also see

https://svn.apache.org/repos/asf/maven/surefire/trunk/maven-surefire-plugin
/src/main/java/org/apache/maven/plugin/surefire/SurefirePlugin.java

line 494.

I tried to fix this a while back but it's a big mess and has a lot of
unwanted side effects.

Accessors shouldn't change a property, but this one does because only when
you really need the version, it's resolved (lazy init). Though I don't
understand why X-SNAPSHOT needs to be resolved to the timestamped version
to determine wheter it is a snapshot..

btw, baseversion is the version containing the SNAPSHOT keyword,
version is the one containing the timestamp-buildernumber IIRC.

ok,
so I think that if a transformation has to be done from xxx-timestamp into
xxx-SNAPHOT, then it should be in the setBaseVersion() method, so the
baseVersion attribute is directly set to xxx-SNAPSHOT and never changed
after, even if the parameter during the call was xxx-timestamp.

Is this ok to do so, or should we investigate why it is called sometimes with
a timestamped version and not -SNAPSHOT?

Well, just looked at the code and it's a mess. Here are the problems:

* The isSnapshot method does a regexp on the version for the timestamp, and if
it matches,
replaces the baseversion with -SNAPSHOT. If it doesn't match, checks for
'endswith(SNAPSHOT)'.
So this method changes the baseversion on some occasions.

* The above means that calling isSnapshot on an artifact with baseversion
'1SNAPSHOT' or 'SNAPSHOT' is
considered a snapshot IFF the baseversion is not timestamp-resolved yet.
So, it'll return true for non-timestamp resolved artifacts, but
it'll return false if they have. This is because the regexp checks for ^(.*)-(\d\d\detc)',
so the timestamp has to be preceded by '-'.

* LATEST is also considered a snapshot, if the version has not been resolved.
If it has been resolved
to a real version (1.0 for instance), it won't be a snapshot. I'm not sure if
this is a problem,
if only snapshots are considered in resolution. Shouldn't LATEST resolve to
non-snapshots?
Ah, they do: AbstractVersionTransformation:

// Don't use snapshot metadata for LATEST (which isSnapshot returns true
for)
if ( !artifact.isSnapshot() || Artifact.LATEST_VERSION.equals(
artifact.getBaseVersion() ) )
{
metadata = new ArtifactRepositoryMetadata( artifact );
}
else
{
metadata = new SnapshotArtifactRepositoryMetadata( artifact );
}

This needs to be fixed - i'm sure there's a reason for LATEST being treated
like snapshots at some
places, and not at later places. As soon as LATEST is resolved it's no longer
a snapshot, surely this
causes problems?

* There are multiple methods for version modification/retrieval:

* resolved version (setter only - sets version)
* version (sets version, baseversion, and versionrange; gets version)
* base version (sets base version, gets baseversion or version if baseversion
null)
* version range (sets versionrange, and sets version and baseversion either to
null or a recommeded version; gets versionrange)
* available versions
* selectVersion (sets version and baseversion)
* updateVersion (sets version and file)

These can be set independently and can result in an inconsistent state.
Documentation lacks to describe
which you can and which you cannot call in what sequences.

* isRelease is a boolean that has nothing to do with versions. I'd figure that
if something wasn't a snapshot,
it'd be a release. Guess not. Or maybe it is, but then the logic is someplace
else.

Simplifying this should make a whole lot of difference.

For now, we should update the setters to immediately update baseversion to
-SNAPSHOT,
so that even when you don't call isSNapshot, getBaseVersion is ok. Just
updating setBaseVersion isn't enough,
but it's a start. If you do setBaseVersion(timestamp) it'll discard the real
value and replace it with -SNAPSHOT.

Ideally I'd like to NOT use the regexps to find out if something is a snapshot,
but use the repository
metadata for that. Maybe some company uses timestamps for releases, who knows..

-- Kenney

Hervé

-- Kenney

Hervé BOUTEMY wrote:

Le mercredi 20 juin 2007, Brian E. Fox a écrit :

I discovered http://jira.codehaus.org/browse/MNG-2961 while working on
mdep a while back.

same for me while working on http://jira.codehaus.org/browse/MANTTASKS-18

It should be an easy fix but I'm pondering what the
least intrusive fix is.

thought it would be easy too, but as you mention, it must be the least
intrusive: that's the hard part.

Clearly calling a Boolean method shouldn't
result in a change to some other variable so we should do something.

Changing it to always

Re: Sequence of events to ramping up Maven 2.1




Jason van Zyl wrote:

[snip]


I will coalesce these three pages to mesh:

http://docs.codehaus.org/display/MAVEN/Taxonomy
http://docs.codehaus.org/display/MAVEN/Maven+Taxonomy
http://docs.codehaus.org/display/MAVEN/Architectural+Goals+for+Maven+2.1



I you mean 'merging' by 'coalesce', please also incorporate

http://docs.codehaus.org/display/MAVEN/Maven+2.1+Design+Documents

I'm a bit confused between the difference of that one and the Architectural 
goals.
There's too many pages floating around now, and I wish subpages were used 
properly
to put documents in the proper scope. Either there are duplicate children,
or they are referred to by seveal pages (the pages listed by the 'children' 
feature
refer to 'top level' documents...?)

-- Kenney

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Encoding issues for 2.0.8



Hi,

indeed, it's a case of doing new XXXInputstream( something, "encoding" ),
or a reader. Some work has been done on this, IIRC.

The problem is that you need to prescan the xml declaration, so you start
parsing until you get the first xml language element that is not a comment,
(an xml element, in which case encoding is utf8, or
a doctype declaration, encoding is utf8, or
a processing instruction, and if it's the xml processing instruction parse the 
encoding
attribute and use that, otherwise it's utf8).

This isn't too hard to do, except you need to restart reading the xml file from
start, if the encoding is not utf-8. The real problem is in the API's; you 
cannot
take a reader and restart that, since you cannot change the encoding on an 
instantiated
reader, and you certainly don't want to wrap it. You'd need access to a raw
inputstream that doesn't apply encoding transformations to the bytes, and wrap 
that
in a Pushback something and then rewrap it if you found the encoding.

I'm a bit fuzzy on all the java.io api's, so we'll have to find the proper
class to use in the API so we can do this; a File would work. 


Anyway, I once tried to fix this issue but the api had to be changed and there 
were
just too many changes across plexus and maven at the time to push this through.

-- Kenney

Hervé BOUTEMY wrote:

Le jeudi 21 juin 2007, Jason van Zyl a écrit :

It seems like there are many problems with encoding that could be
easily solved with a couple tweaks to modello, specifically the
reader and writing so I've scheduled these for 2.0.8. There some
patches for these and hopefully Herve will work his magic with his
suggested fix. I like the idea of borrowing the idea from the Rome IO
utils to find the right encoding by default. That could easily be
integrated into modello. Herve if you need access to Modello we can
set you up.
I'm interested at working on that. Do I need Modello access, or other 
components? I don't really know, these Modello things are the parts I didn't 
really dive into for the moment.
The magic of the idea is that the encoding handling is not done by the parser, 
but by the reader. Then, the code that has to change is the code creating the 
Reader from a File: it must be changed from "new FileReader(file)" to "new 
XmlReader(file)".


We need to:
1. choose where we put the XmlReader so that any code can use it when 
necessary. Or have a dependency on Rome: but all Rome for only 1 class (even 
if this class is really great)...

2. change every code that creates a Reader for XML parsing

WDYT?

Thanks,

Jason

--
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
--




-
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]

Re: [m2] Conflict resolvers

Mark Hobson wrote:

On 22/06/07, Brett Porter <[EMAIL PROTECTED]> wrote:

It's never been an alternative, but it was implemented as "newest
wins" in an early alpha.

Curse the person who switched to nearest! ;)

:)

It should be nearest though, with a fallback to newest if there are 2 
nodes at the same depth. I think it's random right now.

> How would anyone select a different strategy? This would require a
> change to the POM to even turn on any alternatives. Even if the API
> for the resolution was completely hidden something fundamental
> would have to change i.e. the POM in order to activate it. No?

Yes, I think it'd require a POM change to activate, so I'm more in
favour of it being a starting point in 2.1.

As mentioned above, this requires a change in the Maven installation
rather than the POM.  Obviously far from ideal, but I'm happy to live
with this for the huge gain in productivity.

Yup, you don't need to change the pom, you can just use either extensions
to plug in alternatives, or use the plugin framework, which is _the_ way
to configure builds, though it doesn't allow for pre-reactor execution atm,
but that could be made to work without pom changes, though i'd favour some 
plugin
configuration outside the  tag for that since this effects resolution
and is not necessarily used by maven to build stuff, but can be used by other 
applications
to compute a graph.

Basically, use  and add a  section to it 
would work?

Btw, since plugging in alternatives affects the entire graph, I wonder what will
happen if some random module changes the defaults... they're obviously not 
meant to
apply to the entire graph, but a sub-graph. I can imagine that some transitive 
dep
would specify a conflicting resolution scheme, and I wonder if that could cause 
problems.

Perhaps this should/could be reactor-global - add some special commandline 
parameters to tune
maven, much like the -javaagent args that 'tune' the jvm.
For instance, '--dep-version-conflict-resolution nearest,newest',
which looks for an artifact in a predefined groupId with 
dep-version-conflict-resolution- ?

Or, if we do this in 2.1, we can use the api/impl mechanism in a pom/reactor 
global way,
outside of build.

Just throwing this out here - it's been discussed offline now and then and 
we've got
a place reserved for this in the wiki, but there are too much options to choose 
from
to really write something ;)

-- Kenney

[snip]

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]

Re: .isSnapshot changes version

2007-06-20 Thread Kenney Westerhof

Also see

https://svn.apache.org/repos/asf/maven/surefire/trunk/maven-surefire-plugin/src/main/java/org/apache/maven/plugin/surefire/SurefirePlugin.java

line 494.

I tried to fix this a while back but it's a big mess and has a lot of unwanted
side effects.

Accessors shouldn't change a property, but this one does because only when you
really need the version, it's resolved (lazy init). Though I don't understand
why X-SNAPSHOT needs to be resolved to the timestamped version to determine
wheter it is a snapshot..

btw, baseversion is the version containing the SNAPSHOT keyword,
version is the one containing the timestamp-buildernumber IIRC.

-- Kenney

Hervé BOUTEMY wrote:

Le mercredi 20 juin 2007, Brian E. Fox a écrit :

I discovered http://jira.codehaus.org/browse/MNG-2961 while working on
mdep a while back.

same for me while working on http://jira.codehaus.org/browse/MANTTASKS-18

It should be an easy fix but I'm pondering what the
least intrusive fix is.
thought it would be easy too, but as you mention, it must be the least
intrusive: that's the hard part.

Clearly calling a Boolean method shouldn't
result in a change to some other variable so we should do something.

Changing it to always returns xxx-SNAPSHOT as it does after calling
isSnapshot has the potential to break things depending on existing
behavior. The cleanest way forward is most likely to not have isSnapshot
modify the version, and to create a new method that returns xxx-SNAPSHOT
and leave getBaseVersion to return just the xxx-timestamp. (not sure
what this method would be called...getNonResolvedBaseVersion)

WDYT?
creating a new method is intrusive since this new method has to be used now:
in this case, I know of
o.a.m.artifact.repository.layout.DefaultRepositoryLayout.pathOf(), but I
suppose there are others.

To avoid a change in the API, I was thinking at modifying setVersion() and
setBaseVersion() to do the job actually done in isSnapshot(). But I don't
really understand the semantics of setBaseVersion(): as you noted, this has
the potential to break things.

To make a good decision, I think the first thing is to clearly describe the
semantics of version and baseVersion: perhaps it is already clearly explained
somewhere, but I don't know where. Depending the result, we'll be able to
decide if the API has to be extended, or only the implementation fixed (and
assume if it breaks something that works now but shouldn't because
baseVersion had been used where version should have).

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: what mailing list does jira notify on? I cannot remember.

2007-06-19 Thread Kenney Westerhof


John Casey wrote:
Sorry, I just realized that in my recent email shuffling, I lost one 
of the
mailing lists. Which one does JIRA send notifications on? Is there a 
list of

the maven MLs somewhere?

-j


[EMAIL PROTECTED]

-- Kenney

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: DefaultArtifactCollector event change

2007-06-19 Thread Kenney Westerhof


Jason van Zyl wrote:


On 18 Jun 07, at 10:43 PM 18 Jun 07, Ralph Goers wrote:


Jason van Zyl wrote:


And I'm still trying to get all the "getting prepared for 2.1" 
before I start fleshing out any specs. But the artifact resolution 
in 2.0.x is fundamentally wrong in not making a graph of the 
metadata before the artifacts are materialized so don't be overly 
surprised if much of the structure there gets wiped out in 2.1.


You and I discussed this before. Has any of the code been written to 
do this?  While I have to agree that not creating the graph before 
processing has fundamental problems, I'm also concerned about what 
kind of performance impact this might have.




I do, but as I told brett (who also asked) what I have is an 
implementation that is agnostic to policy. What that means is that the 
spec is required and we need to work on that first. I'm just swamped 
with client work, the release and generally trying to clean up the 
wiki and jira but i'll make an attempt this weekend to drop some code.


That's cool, that it's agnostic to policy, That way we can apply the 
policy afterwards and show what the policy in effect does.
We can also have a mojo apply several policies, producing several output 
graphs/trees to illustrate the differences,
or we can split off the policies into smaller pieces so we can 
sequentially apply them - one for scope filtering, one for depMgt
application, one for transitive deps maybe, one for snapshot handling, 
one for including optional dependencies based on code requirements 
(maybe), one for conflict resolution (latest/oldest for 2 nodes at the 
same depth). We can even flatten the structure
so that we only have 1 version of a dep left in the module hierarchy in 
the reactor, or let each module use whatever version their

subscope tells them to use (so versions can differ per module).

I think having something policy-agnostic and filtering it out later is 
the best way to go - divide and conquer. So what you have doesn't 
necesarily need the spec applied to - we may just need to add another 
processing step after it that implements the spec. Whenever
we change/improve the spec, it'll be an easy adjustment since it's not 
hardcoded in the dep resoluion, and we can simply apply

different strategies for different versions of the poms/maven versions.

-- Kenney

Ralph

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Thanks,

Jason

--
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
--




-
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]

Re: Expression evaluation




Jason van Zyl wrote:


On 16 Jun 07, at 9:57 AM 16 Jun 07, Kenney Westerhof wrote:



So before I write something down that's more to the point than an 
enumeration of
the flaws in the current implementation and the problems it gives us, 
I'd like to

get concensus about the proper way to do it..


People won't pay attention or won't have time and if you don't write 
down the initial thoughts as a basis it won't go anywhere. It will 
happen in bursts when people have time, enumerate the problems and when 
it's linked off that entry point in the wiki people will find it.




Ok, I'll write what I think should happen then and people can comment/object ;)
Didn't have much luck with the dep resolution stuff though.. 


Thanks,

Jason

--
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
--




-
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]

Re: Expression evaluation

Jason van Zyl wrote:

On 16 Jun 07, at 1:18 AM 16 Jun 07, Kenney Westerhof wrote:

Hi,

where's the spec for this?

I'm working on MNG-2651 and similar, and I'm a bit at a loss as how to
proceed.

What does the 'env.' prefix do? System props, env props, or project
props?

Should 'pom.' be the same as 'project.' or should one use the Model
and the other MavenProject?

If someone specifies a pom property (in ) like
1.1,

and the pom's version is 1.0, what should ${pom.version} evaluate to?

Idem for ${version} and a 1.1I've written a little test and it's not good. Right now, the 'context'
parameter

of the evaluation takes precedence.

My suggestion:
1) for pom.* ONLY use reflection
2) for project.* FIRST use reflection, and if that fails, goto 4
3) for env.* use System.getEnv()
4) for the rest, first check the context (system props, -D args),
5) then model properties.
6) legacy fallback: for things like ${version}, ${groupId},
${artifactId}, if the above

steps fail, prepend "pom." and try again, and log a warning.

I'll write a spec on this in 2.1 design docs if we decide on one,
since this is probably turning out to be incompatible with 2.0.x.

We can always fallback to legacy behaviour if the previous steps fail,
so that the broken poms in the repo's I've seen mentioned in the code
still work.
But the order of checking would be changed (for pom.* and project.*)
so results may

vary.

It basically comes down to: we have these pom.*, project.* and env.*
prefixes, but they aren't used at all.

Hope to get some feedback soon,

Drop "env.*" as we just shouldn't deal with envars in the core. They
should go no further then the CLI.

doesn't do anything now, but since we can access sysprops I think it's handy
to also be able to access env vars, for instance to detect certain environments

or applications that have configuration there.

For consistency in 2.1 we should deprecate "pom.*" and just use "project.*"

Yup, I agree.

Put this in a document here:
http://docs.codehaus.org/display/MAVEN/Taxonomy

Make a section for POM :: Interpolation i.e. for just make an
"Interpolation" document and link it from here:
http://docs.codehaus.org/display/MAVEN/Architectural+Goals+for+Maven+2.1

I'm going to make another pass through all the docs again today.

I want to write something, but I want to discuss the proper behaviour first,
and maybe we can even fix this in 2.0.x since right now it's a mess.
I closed about 10 issues all mentioning the same problem, and since this is
not a feature change (though we will do it better in 2.1 which _will_ be a
feature change)
but a formalization of a rather pooly documented/implemented feature, i think
we can improve 2.0.x too.

So before I write something down that's more to the point than an enumeration of
the flaws in the current implementation and the problems it gives us, I'd like
to
get concensus about the proper way to do it..

-- Kenney

Kenney

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Thanks,

Jason

--
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
--

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: depMgt (mng-1577 again....)




Ralph Goers wrote:

Kenney Westerhof wrote:


This somewhat describes the situation:
- depMgt for artifact X is used to provide defaults for direct 
dependencies of artifact X,

 and for overrides of transitive dependencies on X,
 unless there's also a direct dependency on X in which case the direct 
dependency is used.



I'm sure this is not intended, so what should the intended behaviour be?
Actually, from the discussions that occurred while this was being 
developed what you are describing is exactly what was intended.


  1. Before the fix depMgt only provided defaults for direct artifacts
 and had no impact on transitive dependencies.
  2. The first version of my path overrode both direct and transitive
 dependencies. Objections were raised to it doing that so it was
 modified to its current behavior.
  3. This is OK because you have control over your depMgt and your
 direct dependencies. You can choose (or not) to specify versions
 in the dependencies. You have no such control over transitive
 dependencies.



Either we keep the 'child overrides' that's globally present in all of 
maven, so that dependencies
can override depMgt, as is the case now, and also apply that to 
transitive deps,
This doesn't work. It was essentially how things worked in 2.0.6. You 
will never have a clue what you are going to get as you have no way to 
control what transitive dependencies bring in, except by artificially 
declaring them in projects that don't really need them.

OR we let depMgt override both local and transitive deps.

See above.


I think you're misreading (or I am). What's the problem with depMgt ALWAYS 
overriding?
At least that's consistent.

-- Kenney



Or, is this the intended behaviour after all?

Yes

Ralph

-
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]

Re: depMgt (mng-1577 again....)




Jörg Schaible wrote:

Kenney Westerhof wrote:


Hi,

Just did some test wrt MNG-2340 (using maven 2.0.7 and 2.0.6), and this is
what I found:

P with dependencyManagement for lucene 1.3
|
+ my-dep with dependency on lucene 1.4.3
+ my-app with dependency on my-dep

(I modified the attached project locally; rename my-app to my-dep and add
my-app with a dep on my-dep).

When building my-dep, after installing P, I get lucene 1.4.3, so depMgt is
used for DEFAULTS for direct dependencies.

When building my-app, after installing P and my-dep, I get lucene 1.3. So
depMgt is used as OVERRIDE for transitive dependencies.


Yes.
 

When I add a dep on lucene without a version in my-app, I get 1.3 aswell.

When I add a dep on lucene 1.4.2 in my-app I get lucene 1.4.2.

(luckily this also happens when building from the reactor).


This is one of the many possible implementations I described in


http://docs.codehaus.org/display/MAVEN/Maven+2.1+Artifact+Resolution+Specification,

and it's one that I don't think we should support.

The meaning of depMgt is different, applied to either local deps or
transitive deps, and it's not consistent.

This somewhat describes the situation:
- depMgt for artifact X is used to provide defaults for direct
dependencies of artifact X,
  and for overrides of transitive dependencies on X,
  unless there's also a direct dependency on X in which case the direct
  dependency is used.


I'm sure this is not intended, so what should the intended behaviour be?


No, this was *exacltly* the intended behaviour! Do you know, how often we
have to add direct deps simply because depMgmt did not override the
transitive deps? 


Ok, so you wanna be able to override transitive deps, that's fine; a good 
usecase.

[snip]


Everytime a third-party dep is upgraded, you have to check all its
dependencies again. You never know in your EJB if the local deps are there
to override transitive one or if they are really necessary.


You have to do that too now, for your modules. If one module defines a 
dependency
with a version different from your depMgt, you won't get the version specified 
in depMgt.
You're shifting the problem with this solution..


Even worse, the transitive deps can change simply by adding a complete
unrelated dep in your component. All because the sequence the deps are
processed seems to be an iterator over a hash map. We had cases, were
adding a *unrelated* dep caused the compilation of an project to fail,
since suddenly a transitive dep was resolved in a different version.


Yeah, that's fixed since 2.0.5; when 2 deps at the same depth have different 
versions,
a 'random' one is chosen, depending on the hash or set implementation of your 
JRE.


Either we keep the 'child overrides' that's globally present in all of
maven, so that dependencies can override depMgt, as is the case now, and
also apply that to transitive deps, OR we let depMgt override both local
and transitive deps.

Or, is this the intended behaviour after all?


Yes, it is. Definitely for me and I reported 1577. Thanks again for those
guys who implemented it.


I'm ok with the fact that depMgt overrides versions. I just expected it to do 
just that,
and not be a 'default' or 'override' depending on how many resolution nodes 
away a dependency
was. 
Say project A extends P where P declares depmgt for B 1.0,

and A needs B 2.0. Since dependency versions are 'hints' anyway, they shouldn't 
be used to override
something that's designed to override; just use the override mechanism already 
there - the depMgt.
Inheritance will make sure that any depMgt section in A overrides depMgt 
sections in P, so you
still can have what you want.


If I see a depMgt section now, I have no clue what the intent was - defaults or 
overrides?
I'd have to scan the entire module tree to find out; and even then, it could be 
that for a subset
of modules it was meant as an override, and for another subset as defaults.
The project as a whole will have problems since there are 2 versions for a 
given artifact, and
depending on the depth, one of them will be chosen. This is very bad imho.

-- Kenney



- Jörg


-
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]

Re: depMgt (mng-1577 again....)




Brian E. Fox wrote:

I think you're questioning if you have this:


 
  
   foo
   com
   1
  
 



  
   foo
   com
   2
  
 

Should you get 1 or 2? Without the direct dependency, you should get 1 if pulled in transitively. 
With the direct dependency as shown, you should get 2. I think you always need to maintain the 
ability to override at a child level if needed. 


No i'm not questioning that. With maven 2.0.5 and before you'd get 1, with 
2.0.6 and later you get 2.

I'm questioning the dubious meaning of depMgt. you cannot tell wheter it was 
created to declare overrides
for transitive deps, or wheter it was meant as defaults for direct deps. Either 
way, as soon
as a direct dep is added resp. removed in any child module at any depth, the 
meaning changes and you get a
different version. It's inconsistent, and you cannot tell what a 
dependencyManagement section does (which version
of the dep you're goanna get) without looking at the entire module tree.


This has some consequences if the depMgt was inherited and sibling dependencies 
are used since they
would ignore the declared direct dependency in some cases.
Is that why you think the behavior is wrong?


Exactly; they'd honor the direct dep, but if it's absent and there's a 
transitive one, that one may win,
depending on how far the dep is away from a module.

P depMgt for E at 1.0
|
+ A dep on B, dep on C
+ B dep on C, dep on E 3.0
+ C dep on E version 2.0
+ D dep on E, no version
+ X dep on A, B, C, D

D would get E 1.0
C would get E 2.0
B would get E 3.0
A would get either 3.0 or 2.0
( A -> B -> E 3.0
 A -> C -> E 2.0 )

X would get:
X -> A -> B -> E 3.0
X -> A -> C -> E 2.0
X -> B -> E 3.0
X -> B -> C -> E 2.0
X -> C -> E 2.0
X -> D -> E 1.0

Shortest paths are through B, C and D, so can get either 1.0, 2.0 or 3.0. Which is it? 
According to my tests on 3 simple projects, since E is not a direct dep from X, the depMgt overrides

kick in and I should get E 1.0 on X, right?

It's way to confusing this way and totally not straightforward. An element can 
change semantics
by something far away; that's not descriptive or deterministic or repeatable.

If we need 2 different ways to handle versions:
1) declare defaults for direct dependencies
2) declare overrides for transitive ones
we need a new element, like 'transitiveDependencyManagement'.

This is something I hope we won't support in 2.1...

-- Kenney



-Original Message-
From: Kenney Westerhof [mailto:[EMAIL PROTECTED] 
Sent: Saturday, June 16, 2007 7:06 AM

To: Maven Developers List
Subject: depMgt (mng-1577 again)

Hi,

Just did some test wrt MNG-2340 (using maven 2.0.7 and 2.0.6), and this is what 
I found:

P with dependencyManagement for lucene 1.3
|
+ my-dep with dependency on lucene 1.4.3
+ my-app with dependency on my-dep

(I modified the attached project locally; rename my-app to my-dep and add 
my-app with a dep on my-dep).

When building my-dep, after installing P, I get lucene 1.4.3, so depMgt is used 
for DEFAULTS for direct dependencies.

When building my-app, after installing P and my-dep, I get lucene 1.3. So 
depMgt is used as OVERRIDE
for transitive dependencies.

When I add a dep on lucene without a version in my-app, I get 1.3 aswell.

When I add a dep on lucene 1.4.2 in my-app I get lucene 1.4.2.

(luckily this also happens when building from the reactor).


This is one of the many possible implementations I described in 
http://docs.codehaus.org/display/MAVEN/Maven+2.1+Artifact+Resolution+Specification,

and it's one that I don't think we should support.

The meaning of depMgt is different, applied to either local deps or transitive 
deps,
and it's not consistent.

This somewhat describes the situation:
- depMgt for artifact X is used to provide defaults for direct dependencies of 
artifact X,
  and for overrides of transitive dependencies on X,
  unless there's also a direct dependency on X in which case the direct 
dependency is used.


I'm sure this is not intended, so what should the intended behaviour be?

Either we keep the 'child overrides' that's globally present in all of maven, 
so that dependencies
can override depMgt, as is the case now, and also apply that to transitive deps,
OR we let depMgt override both local and transitive deps.

Or, is this the intended behaviour after all?

-- Kenney


-
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]

depMgt (mng-1577 again....)


Hi,

Just did some test wrt MNG-2340 (using maven 2.0.7 and 2.0.6), and this is what 
I found:

P with dependencyManagement for lucene 1.3
|
+ my-dep with dependency on lucene 1.4.3
+ my-app with dependency on my-dep

(I modified the attached project locally; rename my-app to my-dep and add 
my-app with a dep on my-dep).

When building my-dep, after installing P, I get lucene 1.4.3, so depMgt is used 
for DEFAULTS for direct dependencies.

When building my-app, after installing P and my-dep, I get lucene 1.3. So 
depMgt is used as OVERRIDE
for transitive dependencies.

When I add a dep on lucene without a version in my-app, I get 1.3 aswell.

When I add a dep on lucene 1.4.2 in my-app I get lucene 1.4.2.

(luckily this also happens when building from the reactor).


This is one of the many possible implementations I described in 
http://docs.codehaus.org/display/MAVEN/Maven+2.1+Artifact+Resolution+Specification,

and it's one that I don't think we should support.

The meaning of depMgt is different, applied to either local deps or transitive 
deps,
and it's not consistent.

This somewhat describes the situation:
- depMgt for artifact X is used to provide defaults for direct dependencies of 
artifact X,
 and for overrides of transitive dependencies on X,
 unless there's also a direct dependency on X in which case the direct 
dependency is used.


I'm sure this is not intended, so what should the intended behaviour be?

Either we keep the 'child overrides' that's globally present in all of maven, 
so that dependencies
can override depMgt, as is the case now, and also apply that to transitive deps,
OR we let depMgt override both local and transitive deps.

Or, is this the intended behaviour after all?

-- Kenney


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Expression evaluation


Hi,

where's the spec for this?

I'm working on MNG-2651 and similar, and I'm a bit at a loss as how to proceed.

What does the 'env.' prefix do? System props, env props, or project props?

Should 'pom.' be the same as 'project.' or should one use the Model
and the other MavenProject?

If someone specifies a pom property (in ) like 
1.1,
and the pom's version is 1.0, what should ${pom.version} evaluate to?

Idem for ${version} and a 1.1We can always fallback to legacy behaviour if the previous steps fail, so that 
the broken poms in the repo's I've seen mentioned in the code still work.

But the order of checking would be changed (for pom.* and project.*) so results 
may
vary.

It basically comes down to: we have these pom.*, project.* and env.* prefixes, 
but they aren't used at all. 


Hope to get some feedback soon,

Kenney

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: maven-dependency-tree changes for 1.1



Hi,

Just a quick question as to what this is for? 
Is it used in 'help:dependencies'?
Is it/will it be used in maven-core? 
I see the dependency plugin uses both dependency-tree and dependency-analyzer,

what's the relation?
If maven core eventually uses this, shouldn't it be moved into maven-components?

The help:dependencies goal shows a tree of dependencies, and it didn't work too
well because the algorithm used there didn't match the internal algorithm from
maven itself, so the report was quite useless. Is this an attempt to fix that?

-- Kenney

Mark Hobson wrote:

Hi there,

I've been working on dependency tree diagnostic tools and as a
consequence have made substantial changes to maven-dependency-tree.  A
brief synopsis of changes are:

- support for node states: included, omitted for conflict, etc.
- node filter API and various implementations for pruning the tree
- node visitor API and various implementations for processing the tree
(esp. serializing visitor for pretty printing the tree, complete with
ascii art :)

There's a few API changes for the better, but I assume that's okay.

So the question is: can this be submitted as a big patch, or must I
painstakingly reverse engineer each change into a set of accumulative
patches..  (hint: big patch)

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]

Re: Deployed attached snapshot artifacts have version number one higher than expected.


Hi,

haven't tested this myself with 2.0.6, but take a look at
some other plugins that attach artifacts (javadoc, source,
assembly:attached etc) to see what the differences are.
Those plugins use the ProjectHelper to attach an artifact:

   /**
* Used for attaching the artifact in the project
*
* @component
*/
   private MavenProjectHelper projectHelper;



   projectHelper.attachArtifact( project, "javadoc", 
"javadoc", outputFile );

for instance. Perhaps the Artifact you created is not constructed properly.
If you could try this approach and it still creates the wrong 
timestamp/buildnumber
then you've found a bug.

-- Kenney


Mark Donszelmann wrote:

Hi

I am attaching artifacts to the main (jar) artifact in my plugin for 
maven. All works fine for versioned plugins,

but for SNAPSHOTS I see the following behavior:

1. mvn install

installs the SNAPSHOT correctly in my local repository (correctly).

2. mvn deploy

-retrieves the latest build number from the remote repository (lets say 2).
-deploys the main SNAPSHOT artifact with build number 3 (correctly).
-deploys the pom SNAPSHOT with build number 3 (correctly).
-retrieves the latest build number again (now 3, incorrectly, it should 
not have retrieved it).
-deploys the attached SNAPSHOT artifact with build numb er 4 (should 
have been 3, but got confused with the previous call).


this uses mvn 2.0.6 and attaches the extra artifact with a call to

project.addAttachedArtifact(artifact);

in the "package" phase.

The standard deploy plugin and deploy goal is used.

any idea why maven looks up the latest build number twice? Did I order 
some calls wrongly?


Regards
Mark Donszelmann







-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Adding wildcards to IncludesArtifactFilter




Mark Hobson wrote:

Hi,

I need an ArtifactFilter that supports wildcards and have patched
IncludesArtifactFilter accordingly, but then saw MNG-2621.  I
implemented wildcards slightly stricter than allowing arbitrary
regular expressions - from the Javadoc:


The artifact pattern syntax is of the form:

[groupId]:[artifactId]:[type]:[version]

Where each pattern segment is optional and supports full and partial * 
wildcards.

An empty pattern segment is treated as an implicit wildcard.

For example, org.apache.* would match all artifacts whose group id 
started with

org.apache., and :::*-SNAPSHOT would match all snapshot artifacts.


Would this be acceptable?  If not, we could either add a flag in the
constructor to signify whether wildcards are to be supported, or
subclass IncludesArtifactFilter to add wildcard support.  Let me know
what's preferable and I'll submit a patch.


I think it's safest to assume no regexps at all, so your solution looks fine.

Jason, you said in MNG-2621 it could wreak havoc - how so? I think it's safer 
to not
allow * for partial matches too, but we have no choice in the version
tag, or we should write a more complex ArtifactMatcher system...

Cheers,

Kenney



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]

Re: svn commit: r547483 - in /maven/plugins/trunk/maven-dependency-plugin: ./ src/test/java/org/apache/maven/plugin/dependency/ src/test/java/org/apache/maven/plugin/dependency/testUtils/ src/test/jav


Yup, I did the same change locally to test something.

Normally we don't want to depend on plexus snapshots since it imposes a 
restriction
on the ability to release.

I think we should add the repo in the pom where we need a plexus snapshot, and 
remove it
as soon as the dependency is released. Putting it in a parent or root pom will
promote use of snapshots.

my 2 cents,

    Kenney

Mark Hobson wrote:

On 15/06/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

Author: brianf
Date: Thu Jun 14 18:50:14 2007
New Revision: 547483

URL: http://svn.apache.org/viewvc?view=rev&rev=547483
Log:
MDEP-59: updated dependencies to get the new unarchiver for rar. Had 
to move around the tests to avoid new heap size issues.


Added:

maven/plugins/trunk/maven-dependency-plugin/src/test/java/org/apache/maven/plugin/dependency/TestUnpackDependenciesMojo2.java 


Modified:
maven/plugins/trunk/maven-dependency-plugin/pom.xml

maven/plugins/trunk/maven-dependency-plugin/src/test/java/org/apache/maven/plugin/dependency/TestUnpackDependenciesMojo.java 


maven/plugins/trunk/maven-dependency-plugin/src/test/java/org/apache/maven/plugin/dependency/testUtils/ArtifactStubFactory.java 


maven/plugins/trunk/maven-dependency-plugin/src/test/java/org/apache/maven/plugin/dependency/utils/filters/TestTypeFilter.java 



Modified: maven/plugins/trunk/maven-dependency-plugin/pom.xml
URL: 
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-dependency-plugin/pom.xml?view=diff&rev=547483&r1=547482&r2=547483 

== 


--- maven/plugins/trunk/maven-dependency-plugin/pom.xml (original)
+++ maven/plugins/trunk/maven-dependency-plugin/pom.xml Thu Jun 14 
18:50:14 2007

@@ -138,13 +138,18 @@
org.apache.maven.shared

maven-plugin-testing-harness

test
-   1.0-beta-1
+   1.1-SNAPSHOT


org.codehaus.plexus
plexus-archiver
-   1.0-alpha-8
+   1.0-alpha-9-SNAPSHOT

[snip]

Should we not add the codehaus snapshot repo to the poms somewhere?  A
fresh checkout doesn't build since it can't find plexus snapshots.

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]

Re: JIRA Smackdown


Hi,

I'd like to ask that issues reported by PMC members and core developers
get less strict reviews.
When I find an issue that's rather complex I usually describe
how to reproduce it, but I lack the time to write sample projects, at
least when reporting. When i get around to it I reproduce the issue and fix
it in svn - I normally don't attach tests since I can commit in core, and i 
think
that goes for more developers.

Anyway, the incomplete resolution is fine, but closing them will make them 
rather hard to find back. Maybe we could just assign these issues to the

reporters instead, status to 'feedback' or 'incomplete', 'on hold' or whatever.

In the future I'll try to attach the tests as I create the issue, though that'll
take me 30 mins more and when I'm in time pressure I feel it's better to report
the issue so it doesn't slip my mind, than to not do it at all because of the 
high
overhead.

wdyt?

-- Kenney

Jason van Zyl wrote:

Hi,

The 2.0.7 release will go out tomorrow, and in order to get some decent 
vote feedback it would be good to clean up JIRA so that we have an 
accurate 2.0.x list people can vote on for issues they would like fixed 
in 2.0.8. I created a "Documentation" version so that technical issues 
wouldn't be polluted by documentation issues. I also created a "Reviewed 
Pending Version Assignment" where I put everything that's probably been 
looked at (probably not entirely true) so that anything coming in from 
now on in the unscheduled we can process. I think between all of us we 
can probably keep that empty most weeks by assigning a version, closing 
if duplicated, or closing due to being incomplete.


Some simple things you can do if you have a few minutes to spare:

- look in the reviewed pending version assignment and try to put the 
issue in 2.0.x or 2.1.x

- pick your favorite component and look for duplicates
- issues describing a remotely complicated problem without a sample 
project get close as incomplete
- look at issues you've reported and check and see if they have been 
resolved
- linking issues up that look similiar so we can close issues together 
if they are resolved.


Even if we get rid of the complete cruft like already resolved, dupes, 
and incomplete issues that will greatly help.


Thanks,

Jason

--
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
--




-
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]

Re: [VOTE] Release Maven 2.0.7




Brett Porter wrote:
I've successfully done deployments with 2.0.6 elsewhere, but I get the 
same problem on utils. I get different failures with dav in earlier 
versions so I think this is just a problem deploying p-utils and the 
container since they are in use and not properly separated.




Indeed. I can succesfully deploy other stuff. That's so weird,
why does the artifact to be deployed end up in the plugin classpath?

And where does the webdav provider come from? All that wagon stuff is 
downloaded,
yet not present with -X. If it's in the core, and filtered out, why is it 
downloaded...

Anyway, I'm revoking my -1 and changing it to +1, though not being able to 
deploy
p-c-d or p-u is a serious drawback. But i guess it doesn't matter as 2.0.6 has 
the
same problems so it's not worse ;)

-- Kenney


- Brett

On 14/06/2007, at 2:32 AM, Kenney Westerhof wrote:


Jason van Zyl wrote:

tentative -1 for releasing as is:

I found a serious bug in maven 2.0.6 and 2.0.7 (2.0.5 works fine):

mvn clean deploy on plexus-utils fails (stacktrace and output below) 
due to a NoClassDefFound

on IOUtil in plexus-utils.

I'm using released versions of wagon and the deploy plugin (cleaned 
local repo).


This happens inside the webdav wagon, of which there is no sign 
anywhere in the debug output.
I think it's due to the fact tha wagon alpha-5 is used, instead of 
beta-2, which does not have the dep on p-u yet

(in wagon-api).

Anyway, we can't release this version without upgrading the deps to 
wagon, I think.


Unless ofcourse there's something very nasty going on on my machine, 
which is likely because I really don't

think that nobody did a deploy using 2.0.6.

Can anybody confirm?

Here's the output using 2.0.7:
[DEBUG] 
org.apache.maven.plugins:maven-deploy-plugin:maven-plugin:2.3:runtime 
(selected for runtime)
[DEBUG]   org.apache.maven:maven-artifact-manager:jar:2.0:runtime 
(selected for runtime)
[DEBUG] org.apache.maven:maven-repository-metadata:jar:2.0:runtime 
(selected for runtime)
[DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime 
(selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime 
(selected for runtime)
[DEBUG] org.apache.maven:maven-artifact:jar:2.0:runtime (selected 
for runtime)
[DEBUG] 
org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-8:runtime 
(selected for runtime)

[DEBUG]   junit:junit:jar:3.8.1:runtime (selected for runtime)
[DEBUG]   classworlds:classworlds:jar:1.1-alpha-2:runtime 
(selected for runtime)
[DEBUG] 
org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5:runtime 
(selected for runtime)
[DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (removed 
- nearer found: 1.1)
[DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.1:runtime (selected 
for runtime)
[DEBUG]   org.apache.maven:maven-project:jar:2.0:runtime (selected for 
runtime)
[DEBUG] org.apache.maven:maven-profile:jar:2.0:runtime (selected 
for runtime)
[DEBUG]   org.apache.maven:maven-model:jar:2.0:runtime (selected 
for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime 
(removed - nearer found: 1.1)
[DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime 
(removed - nearer found: 1.1)
[DEBUG] org.apache.maven:maven-model:jar:2.0:runtime (selected for 
runtime)
[DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime 
(removed - nearer found: 1.1)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime 
(removed - nearer found: 1.1)
[DEBUG]   org.apache.maven:maven-artifact:jar:2.0:runtime (selected 
for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime 
(removed - nearer found: 1.1)

[DEBUG] Adding managed dependencies for org.apache.maven:maven-core
[DEBUG]   org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-8
[DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.0.4
[DEBUG]   org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5
[DEBUG]   org.apache.maven.wagon:wagon-ssh:jar:1.0-alpha-5
[DEBUG]   org.apache.maven.wagon:wagon-file:jar:1.0-alpha-5
[DEBUG]   org.apache.maven.wagon:wagon-http-lightweight:jar:1.0-alpha-5
[DEBUG]   org.apache.maven:maven-core:jar:2.0:runtime (selected for 
runtime)

[DEBUG] Adding managed dependencies for unknown:maven-settings
[DEBUG]   org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-8
[DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.0.4
[DEBUG]   org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5
[DEBUG]   org.apache.maven.wagon:wagon-ssh:jar:1.0-alpha-5
[DEBUG]   org.apache.maven.wagon:wagon-file:jar:1.0-alpha-5
[DEBUG]   org.apache.maven.wagon:wagon-http-lightweight:jar:1.0-alpha-5
[DEBUG] org.apache.maven:maven-settings:jar:2.0:runtime (selected 
for runtime)
[DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime 
(removed - nearer found: 1.1)
[DEBUG] org.apache.maven.wagon:wagon

Re: [VOTE] Release Maven 2.0.7


Brett Porter wrote:
I don't really grok why this set of problems have come up now, but I 
don't agree with requiring a surefire plugin upgrade to upgrade to 
2.0.7. We've been advocating pinning the version of plugins - that 
would be nastiness to have to go and change them.


If 2.1.3 or 2.2 or 2.3 of surefire work with 2.0.6, then they should 
work with 2.0.7. Just take 2.3.1-SNAPSHOT and 2.4-SNAPSHOT right out 
of the equation.


Yup. We've established that 2.3 works fine with 2.0.7, though still 
contains very old bugs that have long been resolved.

We can release 2.0.7 before surefire 2.3.1.


- Brett

On 14/06/2007, at 1:08 AM, Jason van Zyl wrote:

If you can try this with the latest snapshot of surefire that would 
be greatly appreciated.


I know what the problem is inside Maven, but if Surefire is loading 
the same problem classes in a different way then we are going to have 
a problem.


So if you can do a quick check using the snapshot of surefire then we 
can work from there to make them work together. Kenney can help you 
track it down and we'll fix the problem. If necessary we'll try to 
accelerate the release of Surefire and get that out before we push 
2.0.7 into the wild.


On 13 Jun 07, at 1:08 AM 13 Jun 07, Mark Donszelmann wrote:


Hi

tried 2.0.7 on FreeHEP, seems to work on most parts, except it tells 
me following in one case:


RUN ABORTED
java.lang.LinkageError
org.apache.maven.surefire.Runner
An exception or error caused a run to abort.
Class org/codehaus/plexus/util/xml/Xpp3Dom violates loader constraints

running with -e gives me:

org.apache.maven.lifecycle.LifecycleExecutionException: There are 
test failures.
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) 

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) 

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) 

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) 

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) 

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) 

at 
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)

at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 

at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 


at java.lang.reflect.Method.invoke(Method.java:585)
at 
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)

at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at 
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)

at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: There are 
test failures.
at 
org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:389)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) 

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) 


... 16 more

I have seen this error before on 2.0.6 which refrained me from using 
it.

2.0.5 works fine though. Any idea?

Do ot let me hold up the release, I am sure it is a config error on 
my side, but if you have a hint, let me know.


Regards
Mark Donszelmann



On Jun 12, 2007, at 10:12 PM, Jason van Zyl wrote:


Hi,

The release notes are here:

http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&styleName=Html&version=13138 



The tag is here:

http://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.7/

Staging repository:

http://people.apache.org/~jvanzyl/maven-2.0.7-staging-repository/

And the distros you are interested in are here:

http://people.apache.org/~jvanzyl/maven-2.0.7/

Thanks,

Jason.



-
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]




Thanks,

Jason

--
Jason van Zyl
Founde

Re: [VOTE] Release Maven 2.0.7


Jason van Zyl wrote:

tentative -1 for releasing as is:

I found a serious bug in maven 2.0.6 and 2.0.7 (2.0.5 works fine):

mvn clean deploy on plexus-utils fails (stacktrace and output below) due 
to a NoClassDefFound

on IOUtil in plexus-utils.

I'm using released versions of wagon and the deploy plugin (cleaned 
local repo).


This happens inside the webdav wagon, of which there is no sign anywhere 
in the debug output.
I think it's due to the fact tha wagon alpha-5 is used, instead of 
beta-2, which does not have the dep on p-u yet

(in wagon-api).

Anyway, we can't release this version without upgrading the deps to 
wagon, I think.


Unless ofcourse there's something very nasty going on on my machine, 
which is likely because I really don't

think that nobody did a deploy using 2.0.6.

Can anybody confirm?

Here's the output using 2.0.7:
[DEBUG] 
org.apache.maven.plugins:maven-deploy-plugin:maven-plugin:2.3:runtime 
(selected for runtime)
[DEBUG]   org.apache.maven:maven-artifact-manager:jar:2.0:runtime 
(selected for runtime)
[DEBUG] org.apache.maven:maven-repository-metadata:jar:2.0:runtime 
(selected for runtime)
[DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime 
(selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (selected 
for runtime)
[DEBUG] org.apache.maven:maven-artifact:jar:2.0:runtime (selected 
for runtime)
[DEBUG] 
org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-8:runtime 
(selected for runtime)

[DEBUG]   junit:junit:jar:3.8.1:runtime (selected for runtime)
[DEBUG]   classworlds:classworlds:jar:1.1-alpha-2:runtime (selected 
for runtime)
[DEBUG] 
org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5:runtime 
(selected for runtime)
[DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (removed - 
nearer found: 1.1)
[DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.1:runtime (selected for 
runtime)
[DEBUG]   org.apache.maven:maven-project:jar:2.0:runtime (selected for 
runtime)
[DEBUG] org.apache.maven:maven-profile:jar:2.0:runtime (selected for 
runtime)
[DEBUG]   org.apache.maven:maven-model:jar:2.0:runtime (selected for 
runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime 
(removed - nearer found: 1.1)
[DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime 
(removed - nearer found: 1.1)
[DEBUG] org.apache.maven:maven-model:jar:2.0:runtime (selected for 
runtime)
[DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime 
(removed - nearer found: 1.1)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (removed 
- nearer found: 1.1)
[DEBUG]   org.apache.maven:maven-artifact:jar:2.0:runtime (selected for 
runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (removed 
- nearer found: 1.1)

[DEBUG] Adding managed dependencies for org.apache.maven:maven-core
[DEBUG]   org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-8
[DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.0.4
[DEBUG]   org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5
[DEBUG]   org.apache.maven.wagon:wagon-ssh:jar:1.0-alpha-5
[DEBUG]   org.apache.maven.wagon:wagon-file:jar:1.0-alpha-5
[DEBUG]   org.apache.maven.wagon:wagon-http-lightweight:jar:1.0-alpha-5
[DEBUG]   org.apache.maven:maven-core:jar:2.0:runtime (selected for runtime)
[DEBUG] Adding managed dependencies for unknown:maven-settings
[DEBUG]   org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-8
[DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.0.4
[DEBUG]   org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5
[DEBUG]   org.apache.maven.wagon:wagon-ssh:jar:1.0-alpha-5
[DEBUG]   org.apache.maven.wagon:wagon-file:jar:1.0-alpha-5
[DEBUG]   org.apache.maven.wagon:wagon-http-lightweight:jar:1.0-alpha-5
[DEBUG] org.apache.maven:maven-settings:jar:2.0:runtime (selected 
for runtime)
[DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime 
(removed - nearer found: 1.1)
[DEBUG] org.apache.maven.wagon:wagon-file:jar:1.0-alpha-5:runtime 
(selected for runtime)
[DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime 
(removed - nearer found: 1.1)
[DEBUG] Adding managed dependencies for 
unknown:maven-plugin-parameter-documenter

[DEBUG]   org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-8
[DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.0.4
[DEBUG]   org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5
[DEBUG]   org.apache.maven.wagon:wagon-ssh:jar:1.0-alpha-5
[DEBUG]   org.apache.maven.wagon:wagon-file:jar:1.0-alpha-5
[DEBUG]   org.apache.maven.wagon:wagon-http-lightweight:jar:1.0-alpha-5
[DEBUG] 
org.apache.maven:maven-plugin-parameter-documenter:jar:2.0:runtime 
(selected for runtime)
[DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime 
(removed - nearer found: 1.1)
[DEBUG] 
org.apache.maven.wagon:wagon-http-lightweight:jar:1.0-alpha-5:runtime 
(selected for runtime)
[DEBUG]   org.codehaus.plexus:plexus-utils:ja

Re: AW: [VOTE] Release Maven 2.0.7 - surefire problem


Steinhauer, Frank wrote:
 
I got the same error just some hours ago, using maven 2.0.6 and the surefire-plugin 2.3 . And yes, adding a dependcy to junit solved the problem. 

Yup, this is an old bug I remember fixing a while back.
Only thing is, I don't use any unit tests in that project (used only to build a Jboss SAR file), so this behaviour seems a bit strange to me 
  

According to the old code, the surefirebooter is constructed if:
- the 'test' parameter (-Dmaven.test.skip or from config) is not false, and
- the testclassesdirectory exists, wheter it has testclasses or not.
Testclassesdirectory (target/test-classes) is created by the compiler 
plugin, ONLY if the testsourceroot

exists (src/test/java).

So, remove your empty src/test/java/ directory and it's fixed. Or use 
the latest 2.3.1 or 2.4 snapshots for surefire.


At least, this is not a problem that's due to maven-2.0.7.


It seems the test phase always requires the junit dependency (I don't call it 
explicitly in the POM).

Cheers,

Frank

-Ursprüngliche Nachricht-
Von: Kenney Westerhof [mailto:[EMAIL PROTECTED] 
Gesendet: Mittwoch, 13. Juni 2007 17:13

An: Maven Developers List
Betreff: Re: [VOTE] Release Maven 2.0.7 - surefire problem

Mark Donszelmann wrote:
  

Hi Kenney,



Hi Mark,

  
I was using 2.1.3 for surefire. Changed it to 2.3, and still get error 
(slightly different):




Hi,

this is fixed later on; i think you're missing a dependency on junit.

Let me know if this is the case. Can't be due to 2.0.7 though, unless 
this works in 2.0.6?


If there's no released version (2.3) that works for 2.0.7 then we need 
to release 2.3.1 asap.


-- Kenney
  

java.lang.NullPointerException
at 
org.apache.maven.plugin.surefire.SurefirePlugin.constructSurefireBooter(SurefirePlugin.java:594) 

at 
org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:391) 

at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) 

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) 

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) 

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) 

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) 

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) 

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) 


at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 

at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 


at java.lang.reflect.Method.invoke(Method.java:585)
at 
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)

at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at 
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)

at org.codehaus.classworlds.Launcher.main(Launcher.java:375)

My pom (fragment):

  
maven-surefire-plugin
2.3

  pertest
  
**/*TestSuite.java
  
  
**/TestSuite.java
  

  


Could not test SNAPSHOTs yet.

Regards
Mark Donszelmann


On Jun 13, 2007, at 6:18 AM, Kenney Westerhof wrote:



Hi,

can you find the surefire plugin version you're using? I've fixed this
problem in the latest snapshots. Only the snapshots were faulty,
latest release should be fine.
If that one is broken too, can you try one of the latest snapshots 
(2.4-snapshot
or 2.3.1-snapshot), so we can determine wheter it's a fault in 
surefire or in

maven 2.0.7?

Thanks,

Kenney

Mark Donszelmann wrote:
  

Hi
tried 2.0.7 on FreeHEP, seems to work on most parts, except it tells 
me following in one case:

RUN ABORTED
java.lang.LinkageError
org.apache.maven.surefire.Runner
An exception or error caused a run to abort.
Class org/codehaus/plexus/util/xml/Xpp3Dom violates loader constraints
running with -e gives me:
org.apache.maven.lifecycle.LifecycleExecutionException: There are 
test failures.
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) 
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal

Re: [VOTE] Release Maven 2.0.7 - surefire problem


Mark Donszelmann wrote:

Hi Kenney,


Hi Mark,



I was using 2.1.3 for surefire. Changed it to 2.3, and still get error 
(slightly different):



Hi,

this is fixed later on; i think you're missing a dependency on junit.

Let me know if this is the case. Can't be due to 2.0.7 though, unless 
this works in 2.0.6?


If there's no released version (2.3) that works for 2.0.7 then we need 
to release 2.3.1 asap.


-- Kenney

java.lang.NullPointerException
at 
org.apache.maven.plugin.surefire.SurefirePlugin.constructSurefireBooter(SurefirePlugin.java:594) 

at 
org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:391) 

at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) 

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) 

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) 

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) 

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) 

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) 

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) 


at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 

at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 


at java.lang.reflect.Method.invoke(Method.java:585)
at 
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)

at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at 
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)

at org.codehaus.classworlds.Launcher.main(Launcher.java:375)

My pom (fragment):

  
maven-surefire-plugin
2.3

  pertest
  
**/*TestSuite.java
  
  
**/TestSuite.java
  

  


Could not test SNAPSHOTs yet.

Regards
Mark Donszelmann


On Jun 13, 2007, at 6:18 AM, Kenney Westerhof wrote:



Hi,

can you find the surefire plugin version you're using? I've fixed this
problem in the latest snapshots. Only the snapshots were faulty,
latest release should be fine.
If that one is broken too, can you try one of the latest snapshots 
(2.4-snapshot
or 2.3.1-snapshot), so we can determine wheter it's a fault in 
surefire or in

maven 2.0.7?

Thanks,

Kenney

Mark Donszelmann wrote:

Hi
tried 2.0.7 on FreeHEP, seems to work on most parts, except it tells 
me following in one case:

RUN ABORTED
java.lang.LinkageError
org.apache.maven.surefire.Runner
An exception or error caused a run to abort.
Class org/codehaus/plexus/util/xml/Xpp3Dom violates loader constraints
running with -e gives me:
org.apache.maven.lifecycle.LifecycleExecutionException: There are 
test failures.
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) 
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) 
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) 
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) 
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) 
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) 
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)

at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 
at java.lang.reflect.Method.invoke(Method.java:585)
at 
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)

at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at 
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)

at org.codehaus.classworlds.Launcher.mai

Re: [VOTE] Release Maven 2.0.7 - surefire problem



Hi,

can you find the surefire plugin version you're using? I've fixed this
problem in the latest snapshots. Only the snapshots were faulty,
latest release should be fine.
If that one is broken too, can you try one of the latest snapshots (2.4-snapshot
or 2.3.1-snapshot), so we can determine wheter it's a fault in surefire or in
maven 2.0.7?

Thanks,

Kenney

Mark Donszelmann wrote:

Hi

tried 2.0.7 on FreeHEP, seems to work on most parts, except it tells me 
following in one case:


RUN ABORTED
java.lang.LinkageError
org.apache.maven.surefire.Runner
An exception or error caused a run to abort.
Class org/codehaus/plexus/util/xml/Xpp3Dom violates loader constraints

running with -e gives me:

org.apache.maven.lifecycle.LifecycleExecutionException: There are test 
failures.
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) 

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) 

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) 

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) 

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) 

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) 


at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 

at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 


at java.lang.reflect.Method.invoke(Method.java:585)
at 
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)

at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at 
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)

at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: There are 
test failures.
at 
org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:389)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) 

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) 


... 16 more

I have seen this error before on 2.0.6 which refrained me from using it.
2.0.5 works fine though. Any idea?

Do ot let me hold up the release, I am sure it is a config error on my 
side, but if you have a hint, let me know.


Regards
Mark Donszelmann



On Jun 12, 2007, at 10:12 PM, Jason van Zyl wrote:


Hi,

The release notes are here:

http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&styleName=Html&version=13138 



The tag is here:

http://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.7/

Staging repository:

http://people.apache.org/~jvanzyl/maven-2.0.7-staging-repository/

And the distros you are interested in are here:

http://people.apache.org/~jvanzyl/maven-2.0.7/

Thanks,

Jason.



-
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]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [m2] Artifact filtering in DefaultArtifactCollector

Mark Hobson wrote:

Hi Brett,

On 06/06/07, Mark Hobson <[EMAIL PROTECTED]> wrote:

On 06/06/07, Brett Porter <[EMAIL PROTECTED]> wrote:
> My recollection would be that some artifacts are filtered out but
> their transitive dependencies still needed to be taken into
> consideration for version calculations, so this could be the reason
> for this.

If an artifact is filtered out then why would it's transitive
dependencies impact upon the resolved artifacts?  The filtering
performed by DefaultArtifactCollector.filterTrail appears to snip the
branch at any filtered artifact.

Any insight into this?  I feel the artifacts should be filtered during
DefaultArtifactCollector.recurse.

AFAIK filtering is only used to filter out core artifacts (so that plugins
don't get ClassCastexceptions etc), but I'm not entirely
sure. If that's the case, then indeed I don't see the need to apply filtering
after the resolution, unless there are plugins that transitively depend on 
artifacts
through core artifacts that aren't shaded.

If filtering is used for other purposes than to filter core artifacts then maybe 
transitive resolution needs to take place before filtering. I can think of one such

example, being the  tag (or ; I always mix them up) in 
dependencies.
If they mean "don't include this artifact anywhere in the transitive dependency 
trails",
then filtering needs to take place after resolution.
If they mean "don't include this artifact AND it's dependencies anywhere in the 
transitive
dependency trails", then filtering can occur before resolution.

btw, which one is it? I need to doc that in the wiki [1].

Cheers,

Kenney

[1] 
http://docs.codehaus.org/display/MAVEN/Maven+2.1+Artifact+Resolution+Specification

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]

Re: Problems with release:prepare

2007-06-12 Thread Kenney Westerhof




Graham Leggett wrote:

On Fri, June 8, 2007 12:16 pm, David Moss wrote:


[INFO] Executing: svn --username username --password *
--non-interactive
copy --file C:\DOCUME~1\DAVID~1.MOS\LOCALS~1\T
emp\maven-scm-403689689.commit . svn://SERVER001/tags/product-4.0



The svn tag command failed.
Command output:
svn: Commit failed (details follow):
svn: Source url 'svn://server001/trunk/product' is from different
repository


This seems to be a subversion problem, as the error message is from
subversion.

Another potential issue is the SERVER001 compared with server001, it's
quite possible svn is treating these as two different servers.

Always be consistent with your naming.


Yup, that could be it, though I don't think so, since svn uses a special ID for
repositories (can't think of the name but it's some windows ID like 
{--ccc-ddd etc}.

Try 'svn info' and look at the URL and see if it matches 
svn://server001/trunk/product.

-- Kenney



Regards,
Graham
--



-
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]

Re: Idea for enhancement

2007-06-09 Thread Kenney Westerhof


I'm basically against this idea.

It can result in polluted jars very easily. Even if you 
have 2 poms in the same dir, both specifying different source directories,

the files in target/ will overlap. the second executed pom will also contain
the files from the first executed pom.

Unless the target directory is changed too.

So you'd have to change _all_ configuration elements in both
poms that point to directories. It's much cleaner to split things up into
two trees.

I think I'll only vote +0/+1 on this feature if someone can show me a good 
usecase
for this. And 'corporate policy' or 'I cannot change the repository structure'
aren't good arguments since they go against maven principles.

A module has always been a subdirectory tree with a pom; all of the 
subdirectories
in the directory containing the pom belong to the module.

The java+dotnet in 1 module is just bad practice - they have to very distinct
packagings and cannot even have compile-time dependencies AFAIK.

src/java/
src/dotnet/

could become

src/main/java
src/main/dotnet

or even 


src/m1/main/java/
src/m2/main/dotnet/

or

m1/src/main/java
m2/src/main/dotnet, which solves the problem.

-- Kenney


Brett Porter wrote:


On 07/06/2007, at 10:11 AM, Deacon, Brian wrote:


But does the Maven Jedi Council have any problem in principal with
allowing the  element to specify the name of the pom file?


Thought of it already someone has, ? 
http://jira.codehaus.org/browse/MNG-1493


I'd actually be happy with treating a file reference in the manner you 
described these days (despite what I said in the issue).


Cheers,
Brett

-
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]

Re: When There's No More Room In Jiragoon, The Closed Will Walk Among Us: Dawn of the MNG-1577!

2007-06-09 Thread Kenney Westerhof

Arnaud HERITIER wrote:

Instead of writing specifications couldn't we write tests ? There's no/few
doubts with tests ;-)
(But we'll also write a complete documentation about that ...)

1) First we write the specification - what the software is supposed to do.
2) Then we write the design of the implementation - architecture, how it is 
supposed to do it.
3) Then we write tests to check if the implementation follows the specification.
4) Then we write the implementation.

3 and 4 can be swapped or done simultaneously. You cannot write a test if you 
don't
know the correct behaviour. The tests should be kept up to date with the specs, 
and
reflect them. Tests themselves are poorly documented right now, and don't test 
for
everything, because there is no specification.

So yes, tests are needed, but they are only an 'aid' in telling us wheter we 
live
up to the spec; it cannot be the spec itself. Tests can contain bugs too, or 
don't test
all cases. Writing good tests is the hardest part in software developement 
processes,
apart from writing a good specification.

-- Kenney

Arnaud

On 07/06/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:

Ultimately the short answer is who cares what 2.0.x does.

Why?

Because we didn't write the spec first and anything that has been
done has been embodied in code and subject to changes like MNG-1577.

We need a spec, define the behavior and then write to that. Trying to
do anything with 2.0.x or the artifact resolution mechanism as it
stands is a complete waste of time. Decide the behavior amongst
ourselves and then make the new mechanism work that way. I've already
run into a half dozen cases where what I worked on doesn't work
generally and so I'm convinced all that matters is the spec. I have a
technically better implementation at the plexus level but how POMs
are read, where repositories can be injected, how profiles are
injected, at what level and how scopes can change all need to be
nailed down.

It's obvious from just this short thread people have differing opinions.

On 6 Jun 07, at 12:35 PM 6 Jun 07, Joakim Erdfelt wrote:

> Sorry for the 1950's Horror Movie Catchphrase. I'm just odd like
> that. ;-)
>
> The following has been filed as http://jira.codehaus.org/browse/
> MNG-3038
> and I encourage discussion on this.
>
> I was recently working out some discrepancies between what maven
> client, mpir and archiva show as dependency tree's on some
> projects, and discovered something.
>
> MNG-1577 as discussed isn't done (yet).
>
> I created the teeny example project following the example that
> Carlos described on
>  http://www.nabble.com/Re%3A--vote--MNG-1577-as-the-default-
> behavior-p9506667s177.html
>
> | What about this use case for transitive dependencyManagement? has
> been tested?
> |
> | A -> B -> C -> D
> |
> | C depends on D 1.0
> | B has D 2.0 in dependencyManagement, no D in dependencies
> |
> | A should get D 2.0
>
> Source for project:
>  http://joakim.erdfelt.com/maven/carlos_transitive_version.tar.gz
>
> I found that maven 2.0.6 does not handle this use case.
>
> When working on project A, i was expecting to see module D version
> 2.0 in use, but didn't.
> Here's what I see in mvn -X clean package of module A.
>
> [DEBUG] net.example:A:jar:1.0 (selected for null)
> [DEBUG] Adding managed depedendencies for net.example:B
> [DEBUG]   net.example:D:jar:2.0
> [DEBUG]   net.example:B:jar:1.0:compile (selected for compile)
> [DEBUG] net.example:C:jar:1.0:compile (selected for compile)
> [DEBUG]   net.example:D:jar:1.0:compile (selected for compile)
>
> That shows that D:2.0 is identified as being part of depMan.
>
> [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-compiler-
> plugin:2.0.2:compile' -->
> [DEBUG]   (f) basedir = /home/joakim/code/experiments/deptree-
> mng-1577/carlos_transitive_version/A
> [DEBUG]   (f) buildDirectory = /home/joakim/code/experiments/
> deptree-mng-1577/carlos_transitive_version/A/target
> [DEBUG]   (f) classpathElements = [/home/joakim/code/experiments/
> deptree-mng-1577/carlos_transitive_version/A/target/classes, /home/
> joakim/.m2/repository/net/example/D/1.0/D-1.0.jar,
> /home/joakim/.m2/repository/net/example/B/1.0/B-1.0.jar, /home/
> joakim/.m2/repository/net/example/C/1.0/C-1.0.jar]
> [DEBUG]   (f) compileSourceRoots = [/home/joakim/code/experiments/
> deptree-mng-1577/carlos_transitive_version/A/src/main/java]
> [DEBUG]   (f) compilerId = javac
> [DEBUG]   (f) debug = true
>
> That shows that the compiler plugin is using D:1.0 as part of the
> compiler plugin.
>
> This has been reviewed by Carlos and Brian on irc as not

Re: When There's No More Room In Jiragoon, The Closed Will Walk Among Us: Dawn of the MNG-1577!

2007-06-07 Thread Kenney Westerhof

Hi,

I've written something here:
http://docs.codehaus.org/display/MAVEN/Maven+2.1+Artifact+Resolution+Specification

The title of the document does not match the first chapter, which is 
'Dependency Conflict Resolution',
as that's what I'm talking about in that page. I think artifact resolution is a 
different
topic alltogether, though related (artifact resolution deals with repositories 
whereas
dependency conflict resolution deals with dependency information location).

It's just a start, still have to address several other issues.
I think this is more readable than my braindump below, even though it's almost 
as late
as yesterday. This one took me much longer to write ;)

I'd love some feedback, preferrably here.

Joakim: I didn't explicitly include your 'diamond graph' there, since I found a 
more
generic example to illustrate the problem.

I didn't answer any questions yet in the wiki page. I'm hoping to decide on 
those by looking
at a bunch of real-world examples and expectations. First thing is to see 
wheter the proposed algorithms
will allow all these cases, and if we want to support them. If my proposal 
can't support them,
then things will get too complicated to maintain, I'm afraid.

That was one of the main points I tried to make there - how complex this 
problem is. My proposal
will reduce the complexity by a factor of roughly 500 (still have to do the 
math :)).
(btw, 'My proposal' simply means the stuff I wrote down - it's probably already 
implemented,
or somebody else already thought of this solution - I don't mean to offend 
anybody by calling it that).

Thanks,

Kenney

Jason van Zyl wrote:

On 7 Jun 07, at 8:01 AM 7 Jun 07, Kenney Westerhof wrote:

I wanted to get some feedback first, flesh it out on the dev list and 
then

jot it down. Need some feedback as to how it's supposed to work now
and what we want.

As long as you keep track of it that's fine. Eventually shove it here:

http://docs.codehaus.org/display/MAVEN/Maven+2.1+Artifact+Resolution+Specification 

I'll clean up the organization later. I'm doing some wiki work today 
anyway. But on that front-page it's highly visible.

If there's no response within a reasonable amount of time I'll just put
it in the wiki.

Thanks,

 Kenney

Jason van Zyl wrote:
For the love of god put this in the wiki. Use it as the start of the 
spec.

On 6 Jun 07, at 9:46 PM 6 Jun 07, Kenney Westerhof wrote:

I think it's a matter of scope and ordering.

Some brainstorming on specifying this out to the letter:

> > > | A -> B -> C -> D
> > > |
> > > | C depends on D 1.0
> > > | B has D 2.0 in dependencyManagement, no D in dependencies
> > > |

B uses depMgt to say D has to be 2.0. What for?
1) for poms extending B, to specify a default or override
2) since depMgt also applies to transitive deps, it's to say 
'whatever any transitive deps bring in, if they use D, it needs to 
be 2.0'.

C depends on D, either by having the version directly in the dep, or 
in depmgt, doesn't matter.

C's definition conflicts with B's.
Let's assume none of the poms extend from one another.

Here's the question: while traversing the dependency trail from A to 
D, should

earlier depMgt declarations take precedence over later onces?

Maven 2.0.6 inverted the behaviour that was here earlier 
(depMgt/deps later in the trail take precedence),
to earlier in the trail overrides later deps (at least that's what 
it's supposed to do, afaik).

As C declares a direct dep on D, whereas A nor B do, should we 
interpret that as more

strict than a depMgt declaration in A?

There's no concrete solution though. The problems arise because 
depMgt is used for 2 things:

1) specifying defaults and overrides for child poms
2) overriding transitive deps
(they seem similar, but when resolving dependencies, the path from 
an artifact to such a depMgt

declaration is quite different in both cases:
- in the first case a path orthogonal to the dep trail is taken, say 
from D not back to A (the deptrail),

  but to X, the parent of D.
- in the second case, the normal dependency trail is followed, where 
parent poms are merged as normal.
  This is effectively the same path as 1), except _ALSO_ the depMgt 
in the dependency trail is

  used. here's where the 'merge' problem occurs:
 - wheter to use the pom of the artifact (D) itself,
   or one of it's parents (which parent gets precedence, topmost 
or nearest to D?

 - dependency trail (which one gets precedence, nearest to D?)
  and ofcourse, we combine those 2 to an even more complex decision 
graph.

)

A little picture to illustrate the problem:
 P1   P2(parents)
 ^^ ( ^  = extends)
 A -> B -> C( -> = depends)

Say a

Re: When There's No More Room In Jiragoon, The Closed Will Walk Among Us: Dawn of the MNG-1577!

2007-06-07 Thread Kenney Westerhof

I wanted to get some feedback first, flesh it out on the dev list and then
jot it down. Need some feedback as to how it's supposed to work now
and what we want.

If there's no response within a reasonable amount of time I'll just put
it in the wiki.

Thanks,

 Kenney

Jason van Zyl wrote:

For the love of god put this in the wiki. Use it as the start of the spec.

On 6 Jun 07, at 9:46 PM 6 Jun 07, Kenney Westerhof wrote:

I think it's a matter of scope and ordering.

Some brainstorming on specifying this out to the letter:

> > > | A -> B -> C -> D
> > > |
> > > | C depends on D 1.0
> > > | B has D 2.0 in dependencyManagement, no D in dependencies
> > > |

B uses depMgt to say D has to be 2.0. What for?
1) for poms extending B, to specify a default or override
2) since depMgt also applies to transitive deps, it's to say 'whatever 
any transitive deps bring in, if they use D, it needs to be 2.0'.

C depends on D, either by having the version directly in the dep, or 
in depmgt, doesn't matter.

C's definition conflicts with B's.
Let's assume none of the poms extend from one another.

Here's the question: while traversing the dependency trail from A to 
D, should

earlier depMgt declarations take precedence over later onces?

Maven 2.0.6 inverted the behaviour that was here earlier (depMgt/deps 
later in the trail take precedence),
to earlier in the trail overrides later deps (at least that's what 
it's supposed to do, afaik).

As C declares a direct dep on D, whereas A nor B do, should we 
interpret that as more

strict than a depMgt declaration in A?

There's no concrete solution though. The problems arise because depMgt 
is used for 2 things:

1) specifying defaults and overrides for child poms
2) overriding transitive deps
(they seem similar, but when resolving dependencies, the path from an 
artifact to such a depMgt

declaration is quite different in both cases:
- in the first case a path orthogonal to the dep trail is taken, say 
from D not back to A (the deptrail),

  but to X, the parent of D.
- in the second case, the normal dependency trail is followed, where 
parent poms are merged as normal.
  This is effectively the same path as 1), except _ALSO_ the depMgt in 
the dependency trail is

  used. here's where the 'merge' problem occurs:
 - wheter to use the pom of the artifact (D) itself,
   or one of it's parents (which parent gets precedence, topmost 
or nearest to D?

 - dependency trail (which one gets precedence, nearest to D?)
  and ofcourse, we combine those 2 to an even more complex decision 
graph.

)

A little picture to illustrate the problem:
 P1   P2(parents)
 ^^ ( ^  = extends)
 A -> B -> C( -> = depends)

Say all of P1, P2, A and B declare both a dependency AND depMgt on C, 
all with conflicting values.
So we have 2 versions (the one in the dependency, and the one in the 
depMgt) per POM.

We have 4 poms. That makes a total of 8 versions to consider for C.

All possible versions for D are:
Ad|Am|P1d|P1m|Bm|Bd|P2d|P2m.

Choice 1: parent overrides child or vice versa:
P1d|P1m|P2d|P2m
 or Ad|Am|Bd|Bm

Choice 2: depMgt overrides a dep or vice versa
P1m|Am|P2m|Bm
 or P1d|Ad|P2d|Bd

Choice 3: nearer to A wins, or nearer to C wins
P1m|P1d|Am|Ad
 or P2m|P2d|Bm|Bd

The final version is the union of each choice. We have 2^3 = 8 
rulesets (same as the number

of versions to consider, but that's a coincidence).

One of the 8 possible choices we can make would be:
 choice1(parent) ^ choice2(depMgt) ^ choice3(A) =
{P1d|P1m|P2d|P2m} ^ {P1m|Am|P2m|Bm} ^ {P1m|P1d|Am|Ad} = P1m

(note that I didn't even get into profiles, which adds a 4th choice, 
property interpolation order,
which adds another choice, and I probably forget some variables. we 
have at least 2^5 = 32 possible

rulesets. Sigh.)

If we make this user configurable, we're really flexible, but also 
very deeply

in trouble because of all the weird bugreports we'll be getting.

So, 6 questions:
1) what is the intended behaviour now?
2) do the current implementations handle this properly or do we still 
have bugs?   (i hope that even if the current impls don't handle 1), 
that it at least conforms

  to one of the 8 possible rulesets above).
3) What do we want it to be?
4) do we want this user configurable?
5) do we want an extra choice/rule, that depMgt only takes precedence 
if there's also

  a direct dependency declared?
6) Did I miss anything else?

Thanks for reading this far - it's pretty late, so this is basically a 
dd if=/dev/ram0 ;)

-- Kenney

Carlos Sanchez wrote:

but you depend on B, so you want B, not C ;)
On 6/6/07, Patrick Schneider <[EMAIL PROTECTED]> wrote:
Right -- but B has no dependency on D, whereas C does.  And C was 
builds

with 1.0.

On 6/6/07, Carlos Sanchez <

Re: svn commit: r544891 - /maven/components/branches/maven-2.0.x/pom.xml



Ok, retested and it does work with 2.3. Guess it was me..

Anyway, you didn't set the version back, you set it to something specific - 
before
it didn't specify any version so whatever was installed was used. I think it 
used
2.2 here here or something, which is awful. 


Anyway thanks, 2.3 is fine for maven core apparently. Not sure about the IT's 
though,
but I'm sure continuum will tell us.

-- Kenney

Vincent Siveton wrote:

Thanks!

Vincent

2007/6/6, Brett Porter <[EMAIL PROTECTED]>:

Hi Vincent,

I'm aware of that (the snapshot plugin repo probably isn't declared).
I was asking whether it really needed to be 2.3.1-SNAPSHOT, since 2.3
works just fine :)

I'll set the version back until Kenney says otherwise in the
interests of fixing the build.

- Brett

On 07/06/2007, at 10:51 AM, Vincent Siveton wrote:

> Hi Brett,
>
> See Continuum log:
> http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-
> build-log-20070607.001504.txt
>
> Cheers,
>
> Vincent
>
> 2007/6/6, Brett Porter <[EMAIL PROTECTED]>:
>> Are you sure? I just flipped the version to 2.3 and it built just
>> fine.
>>
>> On 07/06/2007, at 3:34 AM, [EMAIL PROTECTED] wrote:
>>
>> > Author: kenney
>> > Date: Wed Jun  6 10:34:14 2007
>> > New Revision: 544891
>> >
>> > URL: http://svn.apache.org/viewvc?view=rev&rev=544891
>> > Log:
>> > Make surefire version explicit; this is the minimum version that is
>> > deemed stable
>> >
>> > Modified:
>> > maven/components/branches/maven-2.0.x/pom.xml
>> >
>> > Modified: maven/components/branches/maven-2.0.x/pom.xml
>> > URL: http://svn.apache.org/viewvc/maven/components/branches/
>> > maven-2.0.x/pom.xml?view=diff&rev=544891&r1=544890&r2=544891
>> >
>> =
>> =
>> > 
>> > --- maven/components/branches/maven-2.0.x/pom.xml (original)
>> > +++ maven/components/branches/maven-2.0.x/pom.xml Wed Jun  6
>> > 10:34:14 2007
>> > @@ -62,6 +62,10 @@
>> >2.2-beta-1
>> >  
>> >  
>> > +  maven-surefire-plugin
>> > +  2.3.1-SNAPSHOT
>> > +
>> > +
>> >maven-release-plugin
>> >
>> >  https://svn.apache.org/repos/asf/maven/
>> > components/tags
>> >
>>
>> -
>> 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]




-
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]

Re: svn commit: r544891 - /maven/components/branches/maven-2.0.x/pom.xml


I deployed all of it way before I committed this.
Continuum shouldn't complain ;)

Maybe we need to add some pluginrepo somewhere?

It'd be temporarily, i've got a feeling 2.3.1 will be released asap
as it contains major bugfixes. I just couldn't build it with 2.2.

-- Kenney

Vincent Siveton wrote:

Hi Kenney,

Could you deploy a snapshot of surefire? Continuum complains...

Thanks,

Vincent

2007/6/6, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:

Author: kenney
Date: Wed Jun  6 10:34:14 2007
New Revision: 544891

URL: http://svn.apache.org/viewvc?view=rev&rev=544891
Log:
Make surefire version explicit; this is the minimum version that is 
deemed stable


Modified:
maven/components/branches/maven-2.0.x/pom.xml

Modified: maven/components/branches/maven-2.0.x/pom.xml
URL: 
http://svn.apache.org/viewvc/maven/components/branches/maven-2.0.x/pom.xml?view=diff&rev=544891&r1=544890&r2=544891 

== 


--- maven/components/branches/maven-2.0.x/pom.xml (original)
+++ maven/components/branches/maven-2.0.x/pom.xml Wed Jun  6 10:34:14 
2007

@@ -62,6 +62,10 @@
   2.2-beta-1
 
 
+  maven-surefire-plugin
+  2.3.1-SNAPSHOT
+
+
   maven-release-plugin
   
 
https://svn.apache.org/repos/asf/maven/components/tags






-
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]

Re: When There's No More Room In Jiragoon, The Closed Will Walk Among Us: Dawn of the MNG-1577!

I think it's a matter of scope and ordering.

Some brainstorming on specifying this out to the letter:

> > > | A -> B -> C -> D
> > > |
> > > | C depends on D 1.0
> > > | B has D 2.0 in dependencyManagement, no D in dependencies
> > > |

B uses depMgt to say D has to be 2.0. What for?
1) for poms extending B, to specify a default or override
2) since depMgt also applies to transitive deps, it's to say 'whatever any 
transitive deps bring in, if they use D, it needs to be 2.0'.

C depends on D, either by having the version directly in the dep, or in depmgt, 
doesn't matter.

C's definition conflicts with B's. 

Let's assume none of the poms extend from one another.

Here's the question: while traversing the dependency trail from A to D, should
earlier depMgt declarations take precedence over later onces?

Maven 2.0.6 inverted the behaviour that was here earlier (depMgt/deps later in 
the trail take precedence),
to earlier in the trail overrides later deps (at least that's what it's 
supposed to do, afaik).

As C declares a direct dep on D, whereas A nor B do, should we interpret that 
as more
strict than a depMgt declaration in A?

There's no concrete solution though. The problems arise because depMgt is used 
for 2 things:
1) specifying defaults and overrides for child poms
2) overriding transitive deps
(they seem similar, but when resolving dependencies, the path from an artifact 
to such a depMgt
declaration is quite different in both cases:
- in the first case a path orthogonal to the dep trail is taken, say from D not 
back to A (the deptrail),
  but to X, the parent of D.
- in the second case, the normal dependency trail is followed, where parent 
poms are merged as normal.
  This is effectively the same path as 1), except _ALSO_ the depMgt in the 
dependency trail is
  used. here's where the 'merge' problem occurs:
 - wheter to use the pom of the artifact (D) itself,
   or one of it's parents (which parent gets precedence, topmost or nearest 
to D?
 - dependency trail (which one gets precedence, nearest to D?)
  and ofcourse, we combine those 2 to an even more complex decision graph.
)

A little picture to illustrate the problem:

 P1   P2(parents)
 ^^ ( ^  = extends)
 A -> B -> C( -> = depends)

Say all of P1, P2, A and B declare both a dependency AND depMgt on C, all with 
conflicting values.
So we have 2 versions (the one in the dependency, and the one in the depMgt) 
per POM.
We have 4 poms. That makes a total of 8 versions to consider for C.

All possible versions for D are:
Ad|Am|P1d|P1m|Bm|Bd|P2d|P2m.

Choice 1: parent overrides child or vice versa:
P1d|P1m|P2d|P2m
 or Ad|Am|Bd|Bm

Choice 2: depMgt overrides a dep or vice versa
P1m|Am|P2m|Bm
 or P1d|Ad|P2d|Bd

Choice 3: nearer to A wins, or nearer to C wins
P1m|P1d|Am|Ad
 or P2m|P2d|Bm|Bd

The final version is the union of each choice. We have 2^3 = 8 rulesets (same 
as the number
of versions to consider, but that's a coincidence).

One of the 8 possible choices we can make would be:
 choice1(parent) ^ choice2(depMgt) ^ choice3(A) =
{P1d|P1m|P2d|P2m} ^ {P1m|Am|P2m|Bm} ^ {P1m|P1d|Am|Ad} = P1m

(note that I didn't even get into profiles, which adds a 4th choice, property 
interpolation order,
which adds another choice, and I probably forget some variables. we have at 
least 2^5 = 32 possible
rulesets. Sigh.)

If we make this user configurable, we're really flexible, but also very deeply
in trouble because of all the weird bugreports we'll be getting.

So, 6 questions:
1) what is the intended behaviour now?
2) do the current implementations handle this properly or do we still have bugs? 
  (i hope that even if the current impls don't handle 1), that it at least conforms

  to one of the 8 possible rulesets above).
3) What do we want it to be?
4) do we want this user configurable?
5) do we want an extra choice/rule, that depMgt only takes precedence if 
there's also
  a direct dependency declared?
6) Did I miss anything else?

Thanks for reading this far - it's pretty late, so this is basically a dd 
if=/dev/ram0 ;)

-- Kenney

Carlos Sanchez wrote:

but you depend on B, so you want B, not C ;)

On 6/6/07, Patrick Schneider <[EMAIL PROTECTED]> wrote:

Right -- but B has no dependency on D, whereas C does.  And C was builds
with 1.0.

On 6/6/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
>
> B builds with 2.0, if you use B you should use it with whatever it was
> built. I think it's clear that B should use 2.0, or you are not using
> the "right" B
>
> On 6/6/07, Patrick Schneider <[EMAIL PROTECTED]> wrote:
> > I guess I am on the fence as to whether 2.0 is the correct version 
of D

> for
> > A to get.
> >
> > While B declares version 2.0

bugfix update



As stated in maven-dev, I think both 2.3.1 and 2.4 are pretty stable now.

The plugins and surefire booter should be up to date for 2.4,
and everything should be up to date for 2.3.1, in the snapshot repo.

I also changed the parent pom in 2.4 as it used ${project.version}, which 
doesn't
work well with different timestamps on snapshots. I could just deploy the whole 
tree each
time but this is safer.

We still need some integration tests to test all possible combinations of
forkMode and useSystemClassLoader (and possibly others).

So if there are still any regressions or other problems, please let me know.

Cheers,
 Kenney

Re: Surefire (Fwd: NoSuchMethodError with surefire-booter-2.3.1-20070606.032942-4)


Hi,

I just found and fixed the bug after doing some testing of all possible config 
values
for 2.3.1-snap and 2.4-snap.

fix is in svn, i redeployed surefirebooter for 2.4 and 2.3.1, so everything 
should
be peachy now.

Turns out the '!' character was missing somewhere ;)

-- Kenney


Jason van Zyl wrote:
Just making sure Kenney and Brett see this as I'm currently trying to 
find a problem with surefire and 2.0.7 which is a show stopper.


Begin forwarded message:


From: "Ole-Martin Mørk" <[EMAIL PROTECTED]>
Date: June 6, 2007 5:26:03 AM EDT (CA)
To: "Maven Users List" <[EMAIL PROTECTED]>
Subject: NoSuchMethodError with surefire-booter-2.3.1-20070606.032942-4
Reply-To: "Maven Users List" <[EMAIL PROTECTED]>

[INFO] Trace
java.lang.NoSuchMethodError:
org.apache.maven.surefire.booter.SurefireBooter.setUseSystemClassLoader(Z)V 


   at
org.apache.maven.plugin.surefire.SurefirePlugin.constructSurefireBooter(
SurefirePlugin.java:684)
   at org.apache.maven.plugin.surefire.SurefirePlugin.execute(
SurefirePlugin.java:391)
   at org.apache.maven.plugin.DefaultPluginManager.executeMojo(
DefaultPluginManager.java:412)
   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(

DefaultLifecycleExecutor.java:534)
   at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle 


(DefaultLifecycleExecutor.java:475)
   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(

DefaultLifecycleExecutor.java:454)
   at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures 


(DefaultLifecycleExecutor.java:306)
   at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(
DefaultLifecycleExecutor.java:273)
   at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(
DefaultLifecycleExecutor.java:140)
   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
   at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java
:315)
   at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
   at 
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java

:430)
   at org.codehaus.classworlds.Launcher.main(Launcher.java:375)

Maven version: 2.0.4

java version "1.6.0_01"
Java(TM) SE Runtime Environment (build 1.6.0_01-b06)
Java HotSpot(TM) Client VM (build 1.6.0_01-b06, mixed mode, sharing)

AND

java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing)

--
Regards, Ole-Martin Mørk.


Thanks,

Jason

--
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
--




-
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]

Re: Surefire (Fwd: NoSuchMethodError with surefire-booter-2.3.1-20070606.032942-4)


I'm on top of it, thanks for the pointer.

I think someone deployed the booter and not the plugin or vice versa.
just redeployed 2.3.1-snappy

-- Kenney

Jason van Zyl wrote:
Just making sure Kenney and Brett see this as I'm currently trying to 
find a problem with surefire and 2.0.7 which is a show stopper.


Begin forwarded message:


From: "Ole-Martin Mørk" <[EMAIL PROTECTED]>
Date: June 6, 2007 5:26:03 AM EDT (CA)
To: "Maven Users List" <[EMAIL PROTECTED]>
Subject: NoSuchMethodError with surefire-booter-2.3.1-20070606.032942-4
Reply-To: "Maven Users List" <[EMAIL PROTECTED]>

[INFO] Trace
java.lang.NoSuchMethodError:
org.apache.maven.surefire.booter.SurefireBooter.setUseSystemClassLoader(Z)V 


   at
org.apache.maven.plugin.surefire.SurefirePlugin.constructSurefireBooter(
SurefirePlugin.java:684)
   at org.apache.maven.plugin.surefire.SurefirePlugin.execute(
SurefirePlugin.java:391)
   at org.apache.maven.plugin.DefaultPluginManager.executeMojo(
DefaultPluginManager.java:412)
   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(

DefaultLifecycleExecutor.java:534)
   at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle 


(DefaultLifecycleExecutor.java:475)
   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(

DefaultLifecycleExecutor.java:454)
   at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures 


(DefaultLifecycleExecutor.java:306)
   at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(
DefaultLifecycleExecutor.java:273)
   at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(
DefaultLifecycleExecutor.java:140)
   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
   at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java
:315)
   at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
   at 
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java

:430)
   at org.codehaus.classworlds.Launcher.main(Launcher.java:375)

Maven version: 2.0.4

java version "1.6.0_01"
Java(TM) SE Runtime Environment (build 1.6.0_01-b06)
Java HotSpot(TM) Client VM (build 1.6.0_01-b06, mixed mode, sharing)

AND

java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing)

--
Regards, Ole-Martin Mørk.


Thanks,

Jason

--
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
--




-
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]

Re: Plugin parameter missing

2007-06-03 Thread Kenney Westerhof




Hi,

Timothy Reilly wrote:

I'm not sure how to tell what happened, or if this is intended behavior / 
keywords in plugin parameters?
 
 
Within my FoobarMojo I declare:
 
/**

*  @parameter expression="${ws.config.root" default-value="${was.home}/config"


   ^ missing } here


*/
 
protected String wsConfigRoot
 
And when I run mvn -X FoobarMojo:compile  .. I do not see the DEBUG (f) wasConfigRoot = XYZ it seems to be missing. But, by changing the parameter to .dir instead of .root .
 
/**

*  @parameter expression="${ws.config.dir}" default-value="${was.home}/config"
*/
protected String wsConfigDir
 
 
Everything is okay.
 
DEBUG (f) wasConfigDir = XYZ
 
Is root is a reserved parameter name?


Nope, see typo above.

-- Kenney

 
TIA




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jira] Closed: (MNG-2203) Problem with duplicates

2007-06-03 Thread Kenney Westerhof


I agree, this is definitely an issue.
If you specify the same dep (a:a) twice in the same pom,
maven doesn't say anything, but takes the last one.

Brett Porter wrote:
Is this still an issue though? Maybe it should be left open for a 
simpler fix.


- Brett

On 01/06/2007, at 2:19 PM, Jason van Zyl (JIRA) wrote:



 [ 
http://jira.codehaus.org/browse/MNG-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel 
]


Jason van Zyl closed MNG-2203.
--

  Assignee: (was: Maria Odea Ching)
Resolution: Won't Fix

That patch is way to complicated for finding duplicates. We really 
should fail on duplicate entries.



Problem with duplicates
---

Key: MNG-2203
URL: http://jira.codehaus.org/browse/MNG-2203
Project: Maven 2
 Issue Type: Bug
 Components: Dependencies
   Affects Versions: 2.0-alpha-1, 2.0.3
Environment: Windows XP SP 2 - JDK 1.5.06 - Maven 2.1-SNAPSHOT
   Reporter: Francesco Tinti
Fix For: 2.0.x

Attachments: MNG-2203-maven.patch, pomerr.zip

 Time Spent: 1 day, 6 hours, 30 minutes
 Remaining Estimate: 0 minutes

Declare in POM a duplicate group-artifact dependency but with 
different versions.: there's no log of duplicate entry.
Maven will also take care only of the latest dependency, so if the 
version is ancient of the other, you can obtain (of course) 
compilation error.
In attachment a simple demonstration with a specific commons-io 1.2 
function.


--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the 
administrators: http://jira.codehaus.org/secure/Administrators.jspa

-
For more information on JIRA, see: http://www.atlassian.com/software/jira




-
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]

Re: Archetype packaging

2007-05-30 Thread Kenney Westerhof



Hi,

That kind of metadata is not handled by packaging, but by the artifact manager.

What do you need this for?  


If it's to automatically list all available archetypes, that would be great.
We should generalize that by having a special kind of metadata in special 
groups,
like org/apache/maven/metadata/(metadata-group)/ or similar, so we can centrally
store package handlers, plugin metadata, archetypes etc. spanning different 
groupId's.
There'd be a central place (groupid) in each repository for storing that 
information.

If you need this for something totally different, then n/m the above, just 
wanted to
pitch this in since it's been on my mind for a while now.

-- Kenney

Raphaël Piéroni wrote:

Hi

if i would create a new packaging for archetypes,
what is the way (i don't need doco link about lifecycle hook
of a mojo, i already know it ;) )
to have a specific metadata uploaded as long with the
artifact during the install and deploy phases.

My point is how to create metadata and how to
have them automagically uploaded;

for a group, say org.apache.maven.archetypes,
and an archetype, quickstart-archetype, at version 1.0
i need a metadata in the org/apache/maven/archetypes
directory, and in org/apache/maven/archetypes/quickstart-archetype
just like the maven-plugins.

Many thanks for any help.

Regards

Raphaël



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: {SPAM 4.4} Maven 2.0.4 Checkout tag

2007-04-01 Thread Kenney Westerhof



use 


svn co https://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.4

and fix your smtp server ;)

Peter Anning wrote:

Spam detection software, running on the system "fire.homenet.neonics.com", has
identified this incoming email as possible spam.  The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email.  If you have any questions, see
the administrator of that system for details.

Content preview:  Hi, I am trying to build maven from source. I used the
  following svs command to get the stable 2.0.4 release but I got
  2.0.5-SNAPSHOT instead? svn co
  https://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x
  maven-2.0.4 [...] 


Content analysis details:   (4.4 points, 4.0 required)

 pts rule name  description
 -- --
-2.6 BAYES_00   BODY: Bayesian spam probability is 0 to 1%
[score: 0.]
 5.0 RCVD_IN_BLCSMA RBL: Received via a blocked site in bl.csma.biz
[203.202.39.222 listed in bl.csma.biz]
 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
[Blocked - see ]






Subject:
Maven 2.0.4 Checkout tag
From:
"Peter Anning" <[EMAIL PROTECTED]>
Date:
Mon, 27 Nov 2006 16:32:35 +1000
To:


To:



Hi,

I am trying to build maven from source. I used the following svs command
to get the stable 2.0.4 release but I got 2.0.5-SNAPSHOT instead?

svn co
https://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x
maven-2.0.4

Thanks

Peter

-
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]

Re: MNG-2433

2007-03-19 Thread Kenney Westerhof


I know that legacy repositories keep getting pinged on each
build, even if they're just updated. Is there also no
network traffic when legacy repo's are in the repo list?

-- Kenney

Brett Porter wrote:


On 19/03/2007, at 11:36 AM, Jason van Zyl wrote:

Yah, I saw the logging which is why I used the network monitors so the 
only thing I could think of is a plugin grabbing the WagonManager and 
turning it back online which I consider someone else's problem.


I think from the test below it's clear that's not happening though. So 
I'd say move the issue to later as a minor issue because of the 
misleading logging.




Jason.


I just did mvn -o -X clean install on archiva, and see this:

--->8---

[INFO] snapshot 
org.codehaus.plexus:plexus-appserver-maven-plugin:2.0-alpha-8-SNAPSHOT: 
checking for updates from apache.snapshots

[DEBUG] System is offline. Cannot resolve metadata:

Repository Metadata
--
GroupId: org.codehaus.plexus
ArtifactId: plexus-appserver-maven-plugin
Metadata Type: 
org.apache.maven.artifact.repository.metadata.SnapshotArtifactRepositoryMetadata 



--->8---

The info line is misleading when you don't have debug mode on. It 
doesn't actually go to the network.


you can reproduce by doing this first:
touch -t '20070101' 
~/.m2/repository/org/codehaus/plexus/plexus-appserver-maven-plugin/2.0-alpha-8-SNAPSHOT/maven-metadata-apache.snapshots.xml 



On 19/03/2007, at 11:07 AM, Jason van Zyl wrote:


Hi,

Just seeing if anyone can reproduce this:

http://jira.codehaus.org/browse/MNG-2433

I can't so I want to close it. I've used truss, TPIMon, and ktrace 
on the Linux, Window, and OS X and I see no network traffic on a 
simple project but I'm wondering if it's some plugin turning on the 
Wagon Manager or something.


Jason.

-
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]


-
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]

Re: Relocations for existing artifacts in the repo

2007-03-17 Thread Kenney Westerhof

Hi,

well, this is indeed a problem..

I don't understand the second option: if you stop relocating
(not done by maven, but by the pom deployers, right?) when a version exists,
that means you can never relocate. It's no use to
relocate unreleased poms since they won't be present in the repository. So this makes

no sense to me. What didn't I understand?

Option one:
What happened to the deployment management section in the pom?
Where it states 'deployed' or 'manually checked' or something like that.
Maven does support checking for updates on non-snapshot poms, so
users don't necessarily have to clean up their local repository.

I see no harm in updating released poms with the relocation tag; we could
update the warning message to say that a relocation has been detected,
and you should run with -... hey, there's no option for that!
(-U for snapshots, which is always, i was looking for something
similar for releases...)

We could ofcourse fix maven to be more aware of the relocation; when it finds a
relocation for any dependency
it should treat the old and the new g:a as equal to avoid duplicates, but
keeping track
of which version is linked to which g:a when it's time to resolve.
This is probably impossible. It would require major refactoring, since all
artifacts
uniqueness is checked using versionlesskey strings. If it were some sort of
ArtifactId
object it's equals method could say 'yes' for both the new and the old artifact
id's.
Maven 3.0? :)

So I guess we're probably stuck with making the warning extremely clear. Maven
could abort the build when the relocation tag is found, and force users to update their poms, since maven can't guarantee artifact uniqueness anymore. The downside is that this breaks old builds, but they probably all have fixed versions anyway. Adding a parameter/argument/sysprop

to override this would at least let people be aware that there can be unexpected
results.

tough one ;)

-- Kenney

Fabrizio Giustina wrote:

Hi,
I would like to start a discussion on how relocations in the central
repo should be handled.

I recently noticed more and more artifacts partially relocated in the
repo in case of a new upload. With *partially* relocated I means the
case of a new version of an existing artifact uploaded with a new
groupId, and with a relocation pom added only for such new version.

A recent example has been tracked at
http://jira.codehaus.org/browse/MAVENUPLOAD-1419
(freemarker 2.3.9 uploaded with the groupId org.freemarker, while
versions < 2.3.9 keep the "freemaker" groupId without a relocation)

From my experience uploading a new version and relocating *that

version only* will substantially break any build where transitive deps
use the new different groupId.
With this concrete example, when I have freemarker:freemarker:2.3.8 in
my build and a transitive deps starts using
org.freemarker:freemarker:2.3.9 my build will be broken by a duplicate
dependency (both jars will end up in my war)
I saw similar problems in the past, for example when ehcache has been
relocated to net.sf.ehcache ( http://jira.codehaus.org/browse/MEV-427
)... anybody depending on hibernate could have been easily hit by
this.

IMHO having an artifacts which is only partially relocated is
something that should never be allowed. We have two options:
- relocate any existing versions together (but this means that only
people which delete their local copy will see the change)
- stop relocating at all when a version already exists!

Since the relocation concept has always been broken by the fact that
maven has no way for check for relocations automatically, probably the
second option is better. Due to relocations or duplicate artifacts in
different groupIds the repository is recently becoming less consistent
than ever :/

Thoughts?

fabrizio

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] MNG-1577 as the default behavior




Fabrizio Giustina wrote:

A big +1 for making it a default

I am also +1 on adding this to 2.0.6: for me this would just mean
removing tons of unneeded/workaround dependency from tons of poms. I
agree that, although consistent for some time, this behavior
introduces so much problems that should be considered a bug and not a
behavior.

Since anyway this is a important change and so many people are worried
about it, I would just propose to label 2.0.6 as 2.1 (trunk will
become 2.2). That should the reason for version numbers, right? We
shouldn't wait for trunk to be ready to name a release 2.1 and if we
introduce a change we should label it appropriately...


-1, because with this next release as 2.1, the 2.0 branch will no longer
be supported. What you're saying is basically 'we name the next release of
'2.0.x' '2.1''. What's the point of that? That's just the type of thing
that happens in commercial environments to satisfy PR and management.
So dropping 2.0.x and making 2.0.6 the next 2.1 is not an option.

Second option would be to keep 2.0.x in place and make 2.0.5 the starting
point of 2.1, with this patch in place. That would mean we still
have to support 2.0.x, and 2.1, which is no different from 2.0.x
except for MNG-1577, and the 2.1, what is now 2.1.
That's not an option either, since this little issue, although higly debated,
does not warrant a minor version update. yes, it changes behaviour. But fixing
a bug also changes behaviour.

Third option: keep 2.0.x buggy and only apply to 2.1.

Fourth option: apply to both 2.0.x and 2.1.

My vote goes to 4, after ofcourse we've tested a release candidate of 2.0.6.

-- Kenney



fabrizio



On 3/16/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:

Hi,

After working with it a little this week I would like to propose to
make MNG-1577 behavior introduced the default. Builds are completely
and totally unpredictable without this behavior. The behavior in
2.0.5 is fundamentally broken. To are totally prey to any dependency
introduced by a dependency which makes no sense and completely
counter intuitive. I stabilized a massive build this week simply by
using the behavior present in the 2.0.x branch. I don't think we're
doing anyone any favors leaving the old behavior in. After watching a
disaster be recovered by using this new behavior I feel that the
patch should go in as is and become the default behavior. This puts
the user in control which is the way it should be.

I propose we make this the default behavior. Can anyone think of a
case where this degree of control would break an existing build?

This patch saved my bacon this week, I think this behavior makes a
world of difference to users.

Jason.





-
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]

Re: [vote] MNG-1577 as the default behavior




Carlos Sanchez wrote:

On 3/16/07, Kenney Westerhof <[EMAIL PROTECTED]> wrote:



Carlos Sanchez wrote:

> now poms in the repo that have dependencyManagement sections will
> start to change the behavior of current builds and people with 2.0.5
> will get very different results than people with 2.0.6 which i don't
> think it's acceptable for 2.0.x

How? a pom in the repo with a depMgt section will only affect it's own
dependencies, not the project depending on that pom in that repo.
If it didn't already specify a depMgt it will be unpredictable, and if 
it does,

then this change has no effect, since to fix a transitive dep's version
the dependency has to be specified in that pom too; so it'll contain both
a depMgt _and_ a dependency.


you have to make dependencyManagement transitive, if i publish B
depending on C saying in the depMng that C must be 2.0, A depending on
B has to get that C, so you need transitive dependencyManagement


Yup. Each dep is resolved from the scope it's defined in.

So we've established that this bugfix is something we want and it 
should go in

2.1, 2.2 etc. So why try to support the unpredictable behaviour in 2.0.x?
I simply cannot understand how we can make 2.0.6 or newer behave in 
the same
unpredictable way (the case where the dependency is NOT specified to 
override

the depMgt section). That's just unsupportable.


I don't think it's unpredictable at all, counter intuitive sure, but
not unpredictable.


You're only describing the case where you override the version by specifying
a transitive dep directly. If you don't, then it's unpredictable.
If I say in my pom 'i want junit 4 for my modules' and some transitive dep has 
junit 3
my build can break because i get the wrong dep.



It's not acceptable for 2.0.6 to have a very different behavior than 2.0.5
my 2 cents



-- Kenney

>
>
> On 3/16/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
>>
>> On 16 Mar 07, at 1:35 PM 16 Mar 07, Carlos Sanchez wrote:
>>
>> > I agree with Brett, this is a 2.1 change, not a 2.0.x
>> >
>>
>> Do you fully understand what the current behavior is and what this
>> patch fixes? You are essentially condemning users to complete
>> unpredictability. I really think that a build should be staged and
>> explain to users what the change is and let people build with it. If
>> we don't get enough feedback or there is a consensus that they think
>> it's not good then we don't put it in. But we already have many users
>> who are suffering and asking for this to be the default behavior.
>>
>> Jason.
>>
>> > Now as Jochen says, nothing prevents pushing stuff from 2.1 to 
2.2 and

>> > get an earlier 2.1, i though we were going to do it anyway.
>> >
>> >
>> > On 3/16/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
>> >> On 3/16/07, Brett Porter <[EMAIL PROTECTED]> wrote:
>> >>
>> >> > Our users must be able to trust point releases are safe upgrades.
>> >> > Let's start moving on putting out 2.1 milestone releases instead.
>> >>
>> >> Agreed. On the other hand, most others seem to consider this
>> >> change important.
>> >>
>> >> So, why not simply renaming 2.0.6 to 2.1 and 2.1 to 2.2? Should
>> >> satisfy all.
>> >>
>> >> Jochen
>> >>
>> >> --
>> >> Emacs 22 will support MacOS and CygWin. It is not yet decided,
>> >> whether
>> >> these will be used to run Emacs or the other way round.
>> >>
>> >> 
-

>> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >> For additional commands, e-mail: [EMAIL PROTECTED]
>> >>
>> >>
>> >
>> >
>> > --
>> > I could give you my word as a Spaniard.
>> > No good. I've known too many Spaniards.
>> > -- The Princess Bride
>> >
>> > 
-

>> > 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]







-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] MNG-1577 as the default behavior

Carlos Sanchez wrote:

it's not unpredictable at all, it is pretty clear that to force a
version in a project you need to add it in your pom and
dependencyManagement doesn't affect transitive dependencies, it's in
the documentation,

Where?

and even in the jira issue Brett says that it was
done on purpose.

http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html 

Nothing about this mentioned there..

now poms in the repo that have dependencyManagement sections will
start to change the behavior of current builds and people with 2.0.5
will get very different results than people with 2.0.6 which i don't
think it's acceptable for 2.0.x

How? a pom in the repo with a depMgt section will only affect it's own
dependencies, not the project depending on that pom in that repo. 
If it didn't already specify a depMgt it will be unpredictable, and if it does,

then this change has no effect, since to fix a transitive dep's version
the dependency has to be specified in that pom too; so it'll contain both
a depMgt _and_ a dependency.

I'm not against the fix, and I wouldn't really care if this is shipped
next week as 2.1 and current 2.1 is moved to 2.2, or even better get
2.1 alpha now with this fix (+100!)

It's a bugfix, I don't see why this can't be applied to the version that 
contains
the bug, but this bug has to be supported throughout the 2.0.x line.

So we've established that this bugfix is something we want and it should go in
2.1, 2.2 etc. So why try to support the unpredictable behaviour in 2.0.x? 
I simply cannot understand how we can make 2.0.6 or newer behave in the same

unpredictable way (the case where the dependency is NOT specified to override
the depMgt section). That's just unsupportable.

-- Kenney

On 3/16/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:

On 16 Mar 07, at 1:35 PM 16 Mar 07, Carlos Sanchez wrote:

> I agree with Brett, this is a 2.1 change, not a 2.0.x
>

Do you fully understand what the current behavior is and what this
patch fixes? You are essentially condemning users to complete
unpredictability. I really think that a build should be staged and
explain to users what the change is and let people build with it. If
we don't get enough feedback or there is a consensus that they think
it's not good then we don't put it in. But we already have many users
who are suffering and asking for this to be the default behavior.

Jason.

> Now as Jochen says, nothing prevents pushing stuff from 2.1 to 2.2 and
> get an earlier 2.1, i though we were going to do it anyway.
>
>
> On 3/16/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
>> On 3/16/07, Brett Porter <[EMAIL PROTECTED]> wrote:
>>
>> > Our users must be able to trust point releases are safe upgrades.
>> > Let's start moving on putting out 2.1 milestone releases instead.
>>
>> Agreed. On the other hand, most others seem to consider this
>> change important.
>>
>> So, why not simply renaming 2.0.6 to 2.1 and 2.1 to 2.2? Should
>> satisfy all.
>>
>> Jochen
>>
>> --
>> Emacs 22 will support MacOS and CygWin. It is not yet decided,
>> whether
>> these will be used to run Emacs or the other way round.
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
> -- The Princess Bride
>
> -
> 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]

Re: [vote] MNG-1577 as the default behavior



I think it won't break builds at all.
I think that people have lots of workarounds in their poms right now
to overcome this problem - specifying transitive dependencies directly,
which they don't directly use, but just to enforce that version being used. I've
done so myself quite a few times. Those builds will not fail since the
extra dependency will be redundant.

What could be a possible usecase where a build will break?

I agree with the fact that we need to test this thorougly.
Our integration tests are way too simplistic to test this so we definitely
need to test this against 'real life' complex builds.
The best way to do that I think is to apply it to 2.0.x and let people test it
on their builds for a while.
If it's breaking more than it fixes we can always roll back before the release.

-- Kenney

Brett Porter wrote:
-1, at this point. I'd like to look at some specific test cases to see 
how badly it might break a build - so I could be convinced.


No matter how bad the existing behaviour, it is consistent once in 
place. I think it's unacceptable to drop this into a .0.x release, no 
matter what the release notes say. Even if it makes it better for new 
builds, the people that have their current one mysteriously break will 
be rightly livid. I think we suffered this a little earlier when we 
enforced order when it wasn't deterministic - I think this would be more 
confusing than in that instance.


Our users must be able to trust point releases are safe upgrades. Let's 
start moving on putting out 2.1 milestone releases instead.


- Brett

On 16/03/2007, at 11:33 AM, Jason van Zyl wrote:


Hi,

After working with it a little this week I would like to propose to 
make MNG-1577 behavior introduced the default. Builds are completely 
and totally unpredictable without this behavior. The behavior in 2.0.5 
is fundamentally broken. To are totally prey to any dependency 
introduced by a dependency which makes no sense and completely counter 
intuitive. I stabilized a massive build this week simply by using the 
behavior present in the 2.0.x branch. I don't think we're doing anyone 
any favors leaving the old behavior in. After watching a disaster be 
recovered by using this new behavior I feel that the patch should go 
in as is and become the default behavior. This puts the user in 
control which is the way it should be.


I propose we make this the default behavior. Can anyone think of a 
case where this degree of control would break an existing build?


This patch saved my bacon this week, I think this behavior makes a 
world of difference to users.


Jason.





-
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]

Re: forceVersion for maven-install-plugin?



Ok, we've got different approaches here. I'll line them out to summarize:

Mine:
- use an integration testing plugin like maven-it-plugin to run test projects
 placed in src/it/*/pom.xml against the current artifact, which is not installed
 in any repository yet.
- The embedder is fed the current artifact and the src/it/* projects in the 
reactor,
 where the current artifact is marked to be skipped during the build.

Note: the IT projects don't have to specify a  for any  
they're testing,
 since the version tag is optional. If absent, the latest version will be used,
 or the version from the reactor. MNG-1677 currently prevents maven from using 
a plugin
 from  the reactor, though normal artifacts work.

Your approach:
- bind a modified install plugin to the pre-integration-test phase to install
 the artifact with a different version in the local repository
- run the invoker plugin to fork maven to build src/it/*.pom, using the local 
repository,
 remote repositories etc (IMHO an uncontrolled environment).

If your approach works, go for it. Here are some other comments wrt. your 
problems:
- use the install:install-file mojo; you can specify the path to the artifact 
in target/
 and the version you want to use - no need for a forceVersion parameter.
- if you hardcode the version to install ('testing') in the pom, i see no harm
 in specifying that version in src/it/*/pom.xml aswell
- perhaps the staging mojo (can't remember which plugin) is of use; it 
temporarily
 installs the plugin in the local repository, backing up what's there;
 after the integration test, it restores the local repository.

Jason Dillon wrote:

On Mar 15, 2007, at 2:38 AM, Kenney Westerhof wrote:

Jason Dillon wrote:
How does a test repository help?  I still need to configure in my 
src/it/*/pom.xml the version of the plugin I'm testing.


The latest plugin will be used, which is usually what you're testing.
If the test repository does not contain other versions of the plugin,
the one you're testing will be used.


Yes, I know... *BUT* that means the current version must be configured 
in the src/it/* poms... which I do not want to have to maintain/update.  
And when there is no artifact for that version already in the repo then 
execution of src/it will fail when executed from the integration-test 
phase.




Maybe I don't understand what you mean by "test repositories".


It's basically -Dmaven.repo.local=/tmp/foo/ - an empty repository
only used for the build.


Right, that doesn't help solve any problem.


Sure it does, it solves the problem you described above: having to specify
a version in the src/it/ poms. If there's only 1 version available in the
local repository (/tmp/foo), that one will be used. so you don't have to
specify the version.

I just want my src/it/*/pom.xml to *always* use the right version of 
the plugin (ie. that which was just compiled).  I don't want to have 
to go updating poms each time I make a new release to use the new 
version.


This has nothing to do with versions, actually. See below.


See comment above... it has everything to do with versions. :-P


See comment above. ;)


Maven is very careful
not to make artifacts available that have failing tests.
If test fails, package won't run.
If integration-test fails (after package), install won't run.


Right... and I like that *feature* but to run integration tests my 
plugin I need it to be in the repository so it will resolve...


With your approach, requiring the use of the local repo, yes. With
mine, no. ;)

The problem here is MNG-2677 (originally MNG-870): maven can't resolve 
plugins

from the reactor.


Um... no... I agree MNG-2677 is a problem... and I'm still waiting for 
that to get fixed for the Geronimo build... but that is *not* the 
problem here.  src/it/* tests are *not* run from the reactor, nor do I 
want them to be run from the reactor.


There are 2 reactors: the main build reactor, and the reactor created
by the maven-it-plugin which contains the artifact to test and the test 
projects.
So then it _is_ a problem if you take that approach.


I wrote the maven-it-plugin a while ago (at the time of writing MNG-870),
which will run an embedded maven on src/it/*/pom.xml (which was later 
turned
into the embedder). This embedded maven would recognize the just built 
plugin

from the reactor, and not use the version from the local repository.


I'm using the maven-invoker-plugin and aside from this version issue I'm 
really happy with it.


Ok. You could also use the verifier (shared/maven-verifier). That one also
forks maven (or runs it embedded if you choose). We use it in the 
core-integration-tests.

>>> If you can explain a better way to achieve the desired result I'm all 
ears... but so far this is the only solution I can think of which 
will work 100% of the time.


The proper way would be

Re: maven-metadata.xml in version level repository directory?



It's only available in snapshot version directories and contains a list of all
the snapshot versions there and names the latest version. So it's useful for 
snapshots.

Ole Ersoy wrote:

Hi,

Just wondering if there is a purpose to having maven-metadata.xml in the 
version directories (The directories that also contain the pom for the 
project) of the maven repository?


Thanks,
- Ole





-
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]

Re: version range question



I think it makes more sense to let 2.0.5 mean [2.0.5,), not [2.0.5].
If you'd do the latter we'd definitely have a problem. There are lots of
places where maven-model 2.0 is used, and also lots of places where 2.0.3 or 
later
is used. Having this restriction will cause maven's build to fail..

So I'd try restriction(process, true, null, false)..

Brian E. Fox wrote:

I'll try doing that. Strictly speaking though, I think the only thing
that makes sense is 2.0.5 = [2.0.5]. In fact, the javadoc for
createFromVersionSpec says this:1.0 Version 1.0.
Also, when you think about this class by itself, we are testing a range.
How maven decides to handle the results of that test are separate from
how this object should behave. That being said, I do agree we need to be
carefull. 



My patch only fixes the contains method because I couldn't fix the
construction of the restrictions without breaking other tests, even
though I believe the root of the problem is the restriction created. The
code is quite clear here:
else
{
version = new DefaultArtifactVersion( process );
restrictions.add( Restriction.EVERYTHING );
}
That the intent is to include everything for a singular version. I think
this should be
else
{
version = new DefaultArtifactVersion( process );
restrictions.add( new
Restriction(process,true,process,true) 
}


But doing this breaks other unit tests.

I'll make an IT test and see what happens just patching the contains
method.

-Original Message-
From: Kenney Westerhof [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 15, 2007 9:18 AM

To: Maven Developers List
Subject: Re: version range question



Brian E. Fox wrote:

Well, I made the change and all the IT tests pass. I'm not surprised

because when I searched for the use of that VersionRange.contains() it's
only used in one place, so it's entirely likely this is not working and
no one noticed.

It could very well be that there's no it for it.
Try creating one with this structure:

ROOT/
  A/ dep on FOO 1.0 and B
  B/ dep on C
  C/ dep on FOO 2.0

FOO can be any artifact where a class exists in 2.0 but not in 1.0.
For instance plexus-utils 1.0 and a later version. 
C should use a class in FOO 2.0 that's not there in 1.0.


Then maven _should_ use FOO 1.0 for A, B and C, causing C not to
compile, if your patch is applied. Otherwise, the patch isn't good
enough probably becuase there's other code that does not honor 2.0.5 NOT
being in 2.0.6...

-- Kenney


It's easy to tweak my patch so that contains treats "2.0.5" ==

"[2.0.5,)", I just need to change =0 to >=0 because I use the
compareto() method for singular versions. Which should it be? The
alternative is I just take this contains code and move it into my plugin
to work correctly, but that doesn't do much to solve the real problem.

-Original Message-
From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 15, 2007 8:46 AM
To: Maven Developers List
Subject: Re: version range question



Brian E. Fox wrote:

The problem is that I assumed "2.0.5" == "[2.0.5,)". I can understand

how it is when I see it and I can work with that. The problem now is
that createFromVersionSpec doesn't create any restrictions and
restrictions.contains returns true by default. If I add the test as
shown below, it fails here:assertFalse( enforceVersion( "2.0.6",
actualVersion ) );

This is saying that 2.0.6 contains 2.0.5 which should be false.

Indeed, my last statement wasn't entirely correct.

"2.0.6" is not "[2.0.6,)". It's merely a suggestion. In maven, the 
closest dependency wins, even if it's an older version. The "2.0.6" is


treated as a 'recommended version', not the lower limit. So if you 
want to force versions to be 'at least X', you'll have to specify

[X,).

I know that's what people *think* X means, but it

doesn't.

I'm not sure if we can change this - a lot of builds will fail, though



it'll certainly meet expectations better.

-- Kenney


public void testContains() throws

InvalidVersionSpecificationException

{
ArtifactVersion actualVersion = new DefaultArtifactVersion(

"2.0.5" );

assertTrue( enforceVersion( "2.0.5", actualVersion ) );
assertTrue( enforceVersion( "2.0.4", actualVersion ) );
assertTrue( enforceVersion( "[2.0.5]", actualVersion ) );
assertFalse( enforceVersion( "2.0.6", actualVersion ) );
assertFalse( enforceVersion( "[2.0.6]", actualVersion ) );
assertTrue( enforceVersion( "[2.0,2.1]", actualVersion ) );
assertFalse( enforceVersion(

Re: version range question




Brian E. Fox wrote:

Well, I made the change and all the IT tests pass. I'm not surprised because 
when I searched for the use of that VersionRange.contains() it's only used in 
one place, so it's entirely likely this is not working and no one noticed.


It could very well be that there's no it for it.
Try creating one with this structure:

ROOT/
 A/ dep on FOO 1.0 and B
 B/ dep on C
 C/ dep on FOO 2.0

FOO can be any artifact where a class exists in 2.0 but not in 1.0.
For instance plexus-utils 1.0 and a later version. 
C should use a class in FOO 2.0 that's not there in 1.0.


Then maven _should_ use FOO 1.0 for A, B and C, causing C not to compile, if 
your patch
is applied. Otherwise, the patch isn't good enough probably becuase there's 
other code
that does not honor 2.0.5 NOT being in 2.0.6...

-- Kenney



It's easy to tweak my patch so that contains treats "2.0.5" == "[2.0.5,)", I just 
need to change =0 to >=0 because I use the compareto() method for singular versions. Which should 
it be? The alternative is I just take this contains code and move it into my plugin to work correctly, 
but that doesn't do much to solve the real problem.

-Original Message-
From: Kenney Westerhof [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 15, 2007 8:46 AM

To: Maven Developers List
Subject: Re: version range question



Brian E. Fox wrote:

The problem is that I assumed "2.0.5" == "[2.0.5,)". I can understand how it is when I 
see it and I can work with that. The problem now is that createFromVersionSpec doesn't create any 
restrictions and restrictions.contains returns true by default. If I add the test as shown below, it fails 
here:assertFalse( enforceVersion( "2.0.6", actualVersion ) );

This is saying that 2.0.6 contains 2.0.5 which should be false.


Indeed, my last statement wasn't entirely correct.

"2.0.6" is not "[2.0.6,)". It's merely a suggestion. In maven, the closest 
dependency
wins, even if it's an older version. The "2.0.6" is treated as a 'recommended 
version',
not the lower limit. So if you want to force versions to be 'at least X',
you'll have to specify [X,). 
I know that's what people *think* X means, but it doesn't.


I'm not sure if we can change this - a lot of builds will fail, though it'll 
certainly
meet expectations better.

-- Kenney


public void testContains() throws InvalidVersionSpecificationException
{
ArtifactVersion actualVersion = new DefaultArtifactVersion( "2.0.5" );
assertTrue( enforceVersion( "2.0.5", actualVersion ) );
assertTrue( enforceVersion( "2.0.4", actualVersion ) );
assertTrue( enforceVersion( "[2.0.5]", actualVersion ) );
assertFalse( enforceVersion( "2.0.6", actualVersion ) );
assertFalse( enforceVersion( "[2.0.6]", actualVersion ) );
assertTrue( enforceVersion( "[2.0,2.1]", actualVersion ) );
assertFalse( enforceVersion( "[2.0,2.0.3]", actualVersion ) );
assertTrue( enforceVersion( "[2.0,2.0.5]", actualVersion ) );
assertFalse( enforceVersion( "[2.0,2.0.5)", actualVersion ) );
}

public boolean enforceVersion( String requiredVersionRange, ArtifactVersion 
actualVersion )
throws InvalidVersionSpecificationException
{
VersionRange vr = null;

vr = VersionRange.createFromVersionSpec( requiredVersionRange );

return vr.containsVersion( actualVersion );
}



-Original Message-
From: Kenney Westerhof [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 15, 2007 5:45 AM

To: Maven Developers List
Subject: Re: version range question

I'm sorry, what is the problem exactly?

createFromVersionSpec: treats version as a version range, so 2.0.5 is treated
as [2.0.5,).

createFromVersion: treats version as a single pinned version, so 2.0.5 is 
treated
as [2.0.5].

So, createFromVersionSpec("2.0.5").containsVersion( new 
DefaultArtifactVersion("2.0.6") )
is true since 2.0.6 is in [2.0.5,).

Or am I missing something here?

-- Kenney

Brian E. Fox wrote:

Done. I fixed the problem and added the tests to a branch described
here: http://jira.codehaus.org/browse/MNG-2876

Since it's very core (or maybe not if it's not really used) I'd like
someone to bless it.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos
Sanchez
Sent: Wednesday, March 14, 2007 1:06 AM
To: Maven Developers List
Subject: Re: version range question

I would create a jira issue with your tests as unit tests

then search for usages of createFromVersionSpec through the whole
maven and see how it's used

On 3/13/07, Brian E. Fox <[EMAIL PROTECTED]> wrote:

I

Re: Test failures in maven-source-plugin

Stephane Nicoll wrote:

I don't think so. sources and ear are for sure good candidates since I
wrote those tests. At some point, we decided to use that testing
technique and fix remaining issues (namely the local repo first
install story).

We need to discuss this because I'd like to work on the WAR plugin but
I want more tests before changing anything.

MNG-2677

-- Kenney

Stéphane

On 3/14/07, Wendy Smoak <[EMAIL PROTECTED]> wrote:

On 3/14/07, Kenney Westerhof <[EMAIL PROTECTED]> wrote:

> The problem is that it uses the Verifier to test.
> The Verifier uses the plugin from the local repo, not the current 
project.
> First, mvn clean install -Dmaven.test.skip=true, then mvn test and 
it'll work.
> I noticed this today.. there's about 4 plugins that won't install 
cleanly because of this.

Are the four maven-antrun-plugin, maven-eclipse-plugin,
maven-plugin-plugin and maven-source-plugin by any chance?  Those are
the four that are failing in Continuum here.

--
Wendy

-
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]

Re: version range question




Brian E. Fox wrote:

The problem is that I assumed "2.0.5" == "[2.0.5,)". I can understand how it is when I 
see it and I can work with that. The problem now is that createFromVersionSpec doesn't create any 
restrictions and restrictions.contains returns true by default. If I add the test as shown below, it fails 
here:assertFalse( enforceVersion( "2.0.6", actualVersion ) );

This is saying that 2.0.6 contains 2.0.5 which should be false.


Indeed, my last statement wasn't entirely correct.

"2.0.6" is not "[2.0.6,)". It's merely a suggestion. In maven, the closest 
dependency
wins, even if it's an older version. The "2.0.6" is treated as a 'recommended 
version',
not the lower limit. So if you want to force versions to be 'at least X',
you'll have to specify [X,). 
I know that's what people *think* X means, but it doesn't.


I'm not sure if we can change this - a lot of builds will fail, though it'll 
certainly
meet expectations better.

-- Kenney



public void testContains() throws InvalidVersionSpecificationException
{
ArtifactVersion actualVersion = new DefaultArtifactVersion( "2.0.5" );
assertTrue( enforceVersion( "2.0.5", actualVersion ) );
assertTrue( enforceVersion( "2.0.4", actualVersion ) );
assertTrue( enforceVersion( "[2.0.5]", actualVersion ) );
assertFalse( enforceVersion( "2.0.6", actualVersion ) );
assertFalse( enforceVersion( "[2.0.6]", actualVersion ) );
assertTrue( enforceVersion( "[2.0,2.1]", actualVersion ) );
assertFalse( enforceVersion( "[2.0,2.0.3]", actualVersion ) );
assertTrue( enforceVersion( "[2.0,2.0.5]", actualVersion ) );
assertFalse( enforceVersion( "[2.0,2.0.5)", actualVersion ) );
}

public boolean enforceVersion( String requiredVersionRange, ArtifactVersion 
actualVersion )
throws InvalidVersionSpecificationException
{
VersionRange vr = null;

vr = VersionRange.createFromVersionSpec( requiredVersionRange );

return vr.containsVersion( actualVersion );
}



-Original Message-
From: Kenney Westerhof [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 15, 2007 5:45 AM

To: Maven Developers List
Subject: Re: version range question

I'm sorry, what is the problem exactly?

createFromVersionSpec: treats version as a version range, so 2.0.5 is treated
as [2.0.5,).

createFromVersion: treats version as a single pinned version, so 2.0.5 is 
treated
as [2.0.5].

So, createFromVersionSpec("2.0.5").containsVersion( new 
DefaultArtifactVersion("2.0.6") )
is true since 2.0.6 is in [2.0.5,).

Or am I missing something here?

-- Kenney

Brian E. Fox wrote:

Done. I fixed the problem and added the tests to a branch described
here: http://jira.codehaus.org/browse/MNG-2876

Since it's very core (or maybe not if it's not really used) I'd like
someone to bless it.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos
Sanchez
Sent: Wednesday, March 14, 2007 1:06 AM
To: Maven Developers List
Subject: Re: version range question

I would create a jira issue with your tests as unit tests

then search for usages of createFromVersionSpec through the whole
maven and see how it's used

On 3/13/07, Brian E. Fox <[EMAIL PROTECTED]> wrote:

I'm still having trouble with this. I wrote a sample class to show my
problem. The issue is that all the contains calls are correct except
that a singular version ie "2.0.5" always returns true. Is this an
artifact bug, or am I doing something wrong? According to the javadoc
for the method (shown in my original post below) the singular version

is

allowed as a version range.

Output:
is 2.0.5 contained in 2.0.5 ->true  CORRECT
is 2.0.5 contained in 2.0.6 ->true  WRONG
is 2.0.5 contained in [2.0,2.1] ->true CORRECT
is 2.0.5 contained in [2.0,2.0.3] ->false CORRECT
is 2.0.5 contained in [2.0,2.0.5] ->true CORRECT
is 2.0.5 contained in [2.0,2.0.5) ->false CORRECT
Source:
/**
 *
 */
package org.apache.maven.plugin.enforcer;

import org.apache.maven.artifact.versioning.ArtifactVersion;
import org.apache.maven.artifact.versioning.DefaultArtifactVersion;
import


org.apache.maven.artifact.versioning.InvalidVersionSpecificationExceptio

n;
import org.apache.maven.artifact.versioning.VersionRange;
import org.apache.maven.plugin.MojoExecutionException;
import org.apache.maven.plugin.MojoFailureException;

/**
 * @author brianf
 *
 */
public class test
{
public static void main( String[] args )
throws MojoExecutionException, MojoFailureException,
InvalidVersionSpecificationException
{
ArtifactVersion actualVersion = new DefaultArtifactVersion(
&qu

Re: Test failures in maven-source-plugin




Wendy Smoak wrote:

On 3/14/07, Kenney Westerhof <[EMAIL PROTECTED]> wrote:


The problem is that it uses the Verifier to test.
The Verifier uses the plugin from the local repo, not the current 
project.
First, mvn clean install -Dmaven.test.skip=true, then mvn test and 
it'll work.
I noticed this today.. there's about 4 plugins that won't install 
cleanly because of this.


Are the four maven-antrun-plugin, maven-eclipse-plugin,
maven-plugin-plugin and maven-source-plugin by any chance?  Those are
the four that are failing in Continuum here.



Yup ;)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: version range question


I'm sorry, what is the problem exactly?

createFromVersionSpec: treats version as a version range, so 2.0.5 is treated
as [2.0.5,).

createFromVersion: treats version as a single pinned version, so 2.0.5 is 
treated
as [2.0.5].

So, createFromVersionSpec("2.0.5").containsVersion( new 
DefaultArtifactVersion("2.0.6") )
is true since 2.0.6 is in [2.0.5,).

Or am I missing something here?

-- Kenney

Brian E. Fox wrote:

Done. I fixed the problem and added the tests to a branch described
here: http://jira.codehaus.org/browse/MNG-2876

Since it's very core (or maybe not if it's not really used) I'd like
someone to bless it.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos
Sanchez
Sent: Wednesday, March 14, 2007 1:06 AM
To: Maven Developers List
Subject: Re: version range question

I would create a jira issue with your tests as unit tests

then search for usages of createFromVersionSpec through the whole
maven and see how it's used

On 3/13/07, Brian E. Fox <[EMAIL PROTECTED]> wrote:

I'm still having trouble with this. I wrote a sample class to show my
problem. The issue is that all the contains calls are correct except
that a singular version ie "2.0.5" always returns true. Is this an
artifact bug, or am I doing something wrong? According to the javadoc
for the method (shown in my original post below) the singular version

is

allowed as a version range.

Output:
is 2.0.5 contained in 2.0.5 ->true  CORRECT
is 2.0.5 contained in 2.0.6 ->true  WRONG
is 2.0.5 contained in [2.0,2.1] ->true CORRECT
is 2.0.5 contained in [2.0,2.0.3] ->false CORRECT
is 2.0.5 contained in [2.0,2.0.5] ->true CORRECT
is 2.0.5 contained in [2.0,2.0.5) ->false CORRECT
Source:
/**
 *
 */
package org.apache.maven.plugin.enforcer;

import org.apache.maven.artifact.versioning.ArtifactVersion;
import org.apache.maven.artifact.versioning.DefaultArtifactVersion;
import


org.apache.maven.artifact.versioning.InvalidVersionSpecificationExceptio

n;
import org.apache.maven.artifact.versioning.VersionRange;
import org.apache.maven.plugin.MojoExecutionException;
import org.apache.maven.plugin.MojoFailureException;

/**
 * @author brianf
 *
 */
public class test
{
public static void main( String[] args )
throws MojoExecutionException, MojoFailureException,
InvalidVersionSpecificationException
{
ArtifactVersion actualVersion = new DefaultArtifactVersion(
"2.0.5" );
enforceVersion( "2.0.5", actualVersion );
enforceVersion( "2.0.6", actualVersion );
enforceVersion( "[2.0,2.1]", actualVersion );
enforceVersion( "[2.0,2.0.3]", actualVersion );
enforceVersion( "[2.0,2.0.5]", actualVersion );
enforceVersion( "[2.0,2.0.5)", actualVersion );
}

public static void enforceVersion( String requiredVersionRange,
ArtifactVersion actualVersion )
throws MojoExecutionException, MojoFailureException,
InvalidVersionSpecificationException
{
VersionRange vr = null;

vr = VersionRange.createFromVersionSpec( requiredVersionRange

);

boolean result = vr.containsVersion( actualVersion );
System.out.println( "is "+actualVersion+" contained in
"+requiredVersionRange+" ->" + result );
}
}

-Original Message-
From: Brian E. Fox [mailto:[EMAIL PROTECTED]
Sent: Sunday, February 18, 2007 8:15 PM
To: Maven Developers List
Subject: version range question

According to the javadoc for VersionRange.createFromVersionSpec, a
singular version (ie "2.0.4") is allowed:



/**

 * Create a version range from a string representation

 *

 * Some spec examples are

 * 

 *   1.0 Version 1.0

 *   [1.0,2.0) Versions 1.0 (included) to 2.0

(not

included)

 *   [1.0,2.0] Versions 1.0 to 2.0 (both
included)

 *   [1.5,) Versions 1.5 and higher

 *   (,1.0],[1.2,) Versions up to 1.0 (included)
and 1.2 or higher

 * 

 *

 * @param spec string representation of a version or version range

 * @return a new [EMAIL PROTECTED] VersionRange} object that represents the
spec

 * @throws InvalidVersionSpecificationException

 */



However, if I create a version range using
createFromVersionSpec("2.0.4") and then call,

vr.containsVersion(2.0.5)

the result is true. However, if I use createFromVersion("2.0.4") and
then use vr.containsVersion("2.0.5"), I get the expected false.



So is this a bug in the Spec method? What is the difference between

the

two supposed to be? It seems like the fromVersion method can handle

the

spec strings also so I'm confused why there are two.



Thanks,

Brian




-
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]

Re: forceVersion for maven-install-plugin?