Re: Release of Maven 3.0-alpha-1

[Brian Fox]

Pretty sure that's when he's targeting the stage/vote.

--Brian (mobile)


On Dec 22, 2008, at 2:00 PM, "Jochen Wiedmann" > wrote:


On Mon, Dec 22, 2008 at 3:54 AM, Jason van Zyl  
 wrote:



I plan to release it January 5th.


Beg your pardon, but shouldn't there be a staging site and a vote? I
am asking, because that process is usually unable to propose a
specific release date in advance?

Jochen


--
I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out
how to use my telephone.

   -- (Bjarne Stroustrup,
http://www.research.att.com/~bs/bs_faq.html#really-say-that
  My guess: Nokia E50)

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Reports are fixed was Re: Reports are down

[Arnaud HERITIER]

Hi,

  I fixed some issues in swizzle and improved a little bit our reports :
http://www.sonatype.org/~j2ee-hudson/reports/maven-votes.html
http://www.sonatype.org/~j2ee-hudson/reports/plugin-votes.html
http://www.sonatype.org/~j2ee-hudson/reports/maven-plugins-fixed.html

You can see now which issue has a patch and/or a testcase (If you updated
issues in Jira).
It's easy to find issues which have most votes and which have a patch and/or
a testcase.

If you need something else, just ask.

cheers

Arnaud


On Fri, Dec 19, 2008 at 1:41 AM, Jason van Zyl  wrote:

> Cool. Nice.
>
>
> On 18-Dec-08, at 7:26 PM, Arnaud HERITIER wrote:
>
>  I improved a little bit the script
>> We have now only one task in the CI server :
>> https://ci.sonatype.org/view/Reports/job/Users%20votes%20in%20Jira/
>> The script needs to have the output directory for reports as a param.
>>
>> I added HTML versions of reports with link to issues :
>> http://www.sonatype.org/~j2ee-hudson/reports/maven-votes.html
>> http://www.sonatype.org/~j2ee-hudson/reports/plugin-votes.html
>> http://www.sonatype.org/~j2ee-hudson/reports/maven-plugins-fixed.html
>>
>> I hope it can help us to better serve our users.
>>
>> Cheers
>>
>> Arnaud
>>
>> On Thu, Dec 18, 2008 at 12:14 AM, Arnaud HERITIER > >wrote:
>>
>>  Be careful that actually the path were the report is generated is
>>> harcoded
>>> in shell scripts.
>>> We can change it to pass the path as parameter.
>>>
>>> cheers
>>>
>>> Arnaud
>>>
>>>
>>> On Thu, Dec 18, 2008 at 12:09 AM, Brian E. Fox >> >wrote:
>>>
>>>  John, can you sync those up and get it publishing from the grid master?

 -Original Message-
 From: Arnaud HERITIER [mailto:aherit...@gmail.com]
 Sent: Wednesday, December 17, 2008 6:02 PM
 To: Maven Developers List
 Subject: Re: Reports are down

 Patch proposed : http://jira.codehaus.org/browse/SWIZZLE-37

 Reports fixed :
 https://ci.sonatype.org/view/Reports/
 http://www.sonatype.org/~j2ee-hudson/reports/
 

 We'll have to see how to move them on the grid.

 Arnaud

 On Mon, Dec 8, 2008 at 4:11 PM, Arnaud HERITIER 
 wrote:

  Hi David,
>
>  Ok, I'll try to see what they changed in their remote API to propose
>
 to

> you a patch.
>
>  cheers.
>
> Arnaud
>
>
> On Mon, Dec 8, 2008 at 12:09 AM, David Blevins
>
 wrote:

>
>  A patch would be great!
>>
>> Sent from my iPhone
>>
>>
>> On Dec 7, 2008, at 1:36 AM, "Arnaud HERITIER" 
>> wrote:
>>
>> Hi,
>>
>>>
>>> Our reports on votes are down :
>>>
>>>  
>>> http://www.sonatype.org/~j2ee-hudson/reports/
 

 

> https://ci.sonatype.org/view/Reports/
>>>
>>> It's certainly a Jira upgrade which broke the xml-rpc API used in
>>> Swizzle
>>> but there was no activity on this project to fix the issue (and
>>>
>> since

> april).
>>> Is there someone who know the swizzle team ?
>>> Is it useful to spend time to provide a patch ?
>>>
>>> --
>>> ..
>>> Arnaud HERITIER
>>> 12 guidelines to boost your productivity with a Java software
>>>
>> factory -

> http://tinyurl.com/56s9tw
>>> ..
>>> OCTO Technology - aheritier AT octo DOT com
>>> www.octo.com | blog.octo.com
>>> ..
>>> ASF - aheritier AT apache DOT org
>>> www.apache.org | maven.apache.org
>>> ...
>>>
>>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
>>
>
> --
> ..
> Arnaud HERITIER
> 12 guidelines to boost your productivity with a Java software factory
>
 -

> http://tinyurl.com/56s9tw
> ..
> OCTO Technology - aheritier AT octo DOT com
> www.octo.com | blog.octo.com
> ..
> ASF - aheritier AT apache DOT org
> www.apache.org | maven.apache.org
> 

Re: Release of Maven 3.0-alpha-1

[Stephen Connolly]

I'm guessing he'll call the vote jan 2nd, 72h later and he is planning  
to release


Sent from my iPod

On 22 Dec 2008, at 19:00, "Jochen Wiedmann"  
 wrote:


On Mon, Dec 22, 2008 at 3:54 AM, Jason van Zyl  
 wrote:



I plan to release it January 5th.


Beg your pardon, but shouldn't there be a staging site and a vote? I
am asking, because that process is usually unable to propose a
specific release date in advance?

Jochen


--
I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out
how to use my telephone.

   -- (Bjarne Stroustrup,
http://www.research.att.com/~bs/bs_faq.html#really-say-that
  My guess: Nokia E50)

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: How Mercury resolution works?

[Oleg Gusakov]

This is an awesome question!

I have tons of ideas in the area, but decided to first make Mercury 
compliant with Maven2 scoping and make it works in Maven3, then we can 
move forward - see below.


Gilles Scokart wrote:

Cool,

One more question : how do you handle scopes?
In ivy, we have something called 'configuration' mapping in which you
can configure that when you ask for runtime dependency, you have to
take the compile+runtime transitive dependencies.  In maven, this
mapping is hard-coded.
  
I find an idea of "configuration" very cool, so I tried to make Mercury 
as indifferent to the scope impl. as possible and plan to implement 
similar concept as soon as Maven3 is stabilized. Developers should be 
free to define their scopes and scoping rules, and it's half-way there.



Also, in maven when you are resolving dependencies, you resolve all
scopes at once.  In ivy, we download each meta-file file once, but we
make one resolution per configuration (equivalent to scope).
How is it handled in Mercury?
  
Same idea: the call is made to resolve dependencies in a particular 
scope, so what I call "dirty tree" is in essence "scoped dirty tree". As 
a result of that - client wind up with a solution per each scope it asks 
for.


Each metadata is downloaded only once and cached for subsequent 
accesses. Maven is different as it has a concept of a SNAPSHOT, LATEST 
and RELEASE versions, these concepts clash with the idea of a cache and 
result is so called "repository update policy" which in it's default 
implementation, defines cached metadata TTL per remote repository.


Thanks,
Oleg

Gilles Scokart



2008/12/22 Oleg Gusakov :
  

Gilles Scokart wrote:


I have no doubt that SAT can resolve huge system of constraints, but I
fear that building the dirty tree migh be very heavy.  You may have to
download and parse plenty of pom (or other meta-data files).
BTW, when you download a pom, did you also download the jar, or did
you only download the jar whan you know you select the right version.



  

Mercury dependency resolver operates purely on the "light" metadata. Light
in a sense that is does not require full blown POM to do it's job. It only
needs:

1). complete content of the  element: GAV, classifier, type,
scope, optionality, inclusions/exclusions.
2). for each GAV it needs a list of dependencies in the format #1

This has been externalized into an interface, and the only implementation
(for now :) is Maven3 project builder that reads and interprets POMs,
returning back the processed dependencies.

This - btw - also opens a road towards separating dependency declarations
out of POM to any other storage mechanism - I remember there was a
discussion about it. So - this possibility exists.

Back to the question: Mercury calculates all the metadata (and also fills in
the metadata cache, so that on next invocation all metadata is readily
available). And returns back the resolved classpath as a list of metadata
objects. There is another call, that takes that list and actually reads the
binaries from the repositories.

mercury-plexus component combines the two calls into one:
resolveConflicts(). It first resolves the conflicts on the metadata level,
them reads actual binaries, so that returned metadata always points to local
file system for binary.


 An Ivy like function might be nice as well.;-)
  

Several aspects to this remark :)

* default Mercury behaves like that - see "optimization policy" in my
previous post.

* it is possible to implement a different dependency reader, so that we
change completely how dependencies are stored

* it is possible to access any other repository (GEM, CPAN), as soon as
there is a Mercury-compliant implementation. Mercury changed the way
repository behaves in order to allow this - it accepts GAV-only calls, makes
all the mappings inside, and returns metadata objects. Also see
http://docs.codehaus.org/display/MAVEN/Mercury

Thanks,
Oleg




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


  

Re: How Mercury resolution works?

[Gilles Scokart]

Cool,

One more question : how do you handle scopes?
In ivy, we have something called 'configuration' mapping in which you
can configure that when you ask for runtime dependency, you have to
take the compile+runtime transitive dependencies.  In maven, this
mapping is hard-coded.
Also, in maven when you are resolving dependencies, you resolve all
scopes at once.  In ivy, we download each meta-file file once, but we
make one resolution per configuration (equivalent to scope).
How is it handled in Mercury?

Gilles Scokart



2008/12/22 Oleg Gusakov :
>
>
> Gilles Scokart wrote:
>>
>>
>> I have no doubt that SAT can resolve huge system of constraints, but I
>> fear that building the dirty tree migh be very heavy.  You may have to
>> download and parse plenty of pom (or other meta-data files).
>> BTW, when you download a pom, did you also download the jar, or did
>> you only download the jar whan you know you select the right version.
>>
>>
>>
>
> Mercury dependency resolver operates purely on the "light" metadata. Light
> in a sense that is does not require full blown POM to do it's job. It only
> needs:
>
> 1). complete content of the  element: GAV, classifier, type,
> scope, optionality, inclusions/exclusions.
> 2). for each GAV it needs a list of dependencies in the format #1
>
> This has been externalized into an interface, and the only implementation
> (for now :) is Maven3 project builder that reads and interprets POMs,
> returning back the processed dependencies.
>
> This - btw - also opens a road towards separating dependency declarations
> out of POM to any other storage mechanism - I remember there was a
> discussion about it. So - this possibility exists.
>
> Back to the question: Mercury calculates all the metadata (and also fills in
> the metadata cache, so that on next invocation all metadata is readily
> available). And returns back the resolved classpath as a list of metadata
> objects. There is another call, that takes that list and actually reads the
> binaries from the repositories.
>
> mercury-plexus component combines the two calls into one:
> resolveConflicts(). It first resolves the conflicts on the metadata level,
> them reads actual binaries, so that returned metadata always points to local
> file system for binary.
>>
>>  An Ivy like function might be nice as well.;-)
>
> Several aspects to this remark :)
>
> * default Mercury behaves like that - see "optimization policy" in my
> previous post.
>
> * it is possible to implement a different dependency reader, so that we
> change completely how dependencies are stored
>
> * it is possible to access any other repository (GEM, CPAN), as soon as
> there is a Mercury-compliant implementation. Mercury changed the way
> repository behaves in order to allow this - it accepts GAV-only calls, makes
> all the mappings inside, and returns metadata objects. Also see
> http://docs.codehaus.org/display/MAVEN/Mercury
>
> Thanks,
> Oleg
>

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Release of Maven 3.0-alpha-1

[Jochen Wiedmann]

On Mon, Dec 22, 2008 at 3:54 AM, Jason van Zyl  wrote:

> I plan to release it January 5th.

Beg your pardon, but shouldn't there be a staging site and a vote? I
am asking, because that process is usually unable to propose a
specific release date in advance?

Jochen


-- 
I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out
how to use my telephone.

-- (Bjarne Stroustrup,
http://www.research.att.com/~bs/bs_faq.html#really-say-that
   My guess: Nokia E50)

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: How Mercury resolution works?

[Oleg Gusakov]

Gilles Scokart wrote:



I have no doubt that SAT can resolve huge system of constraints, but I
fear that building the dirty tree migh be very heavy.  You may have to
download and parse plenty of pom (or other meta-data files).
BTW, when you download a pom, did you also download the jar, or did
you only download the jar whan you know you select the right version.


  
Mercury dependency resolver operates purely on the "light" metadata. 
Light in a sense that is does not require full blown POM to do it's job. 
It only needs:


1). complete content of the  element: GAV, classifier, 
type, scope, optionality, inclusions/exclusions.

2). for each GAV it needs a list of dependencies in the format #1

This has been externalized into an interface, and the only 
implementation (for now :) is Maven3 project builder that reads and 
interprets POMs, returning back the processed dependencies.


This - btw - also opens a road towards separating dependency 
declarations out of POM to any other storage mechanism - I remember 
there was a discussion about it. So - this possibility exists.


Back to the question: Mercury calculates all the metadata (and also 
fills in the metadata cache, so that on next invocation all metadata is 
readily available). And returns back the resolved classpath as a list of 
metadata objects. There is another call, that takes that list and 
actually reads the binaries from the repositories.


mercury-plexus component combines the two calls into one: 
resolveConflicts(). It first resolves the conflicts on the metadata 
level, them reads actual binaries, so that returned metadata always 
points to local file system for binary.
  
An Ivy like function might be nice as well.;-)

Several aspects to this remark :)

* default Mercury behaves like that - see "optimization policy" in my 
previous post.


* it is possible to implement a different dependency reader, so that we 
change completely how dependencies are stored


* it is possible to access any other repository (GEM, CPAN), as soon as 
there is a Mercury-compliant implementation. Mercury changed the way 
repository behaves in order to allow this - it accepts GAV-only calls, 
makes all the mappings inside, and returns metadata objects. Also see 
http://docs.codehaus.org/display/MAVEN/Mercury


Thanks,
Oleg

NPE in MapperUtil

[jerome creignou]

Hello,

I'm trying to use  file mappers inside a maven plugin with the
file-management shared project.

I've added a fileset definition in the plugin's configuration as follow :
  
info.flex-mojos
flex-compiler-mojo
true
2.0M11-SNAPSHOT

  
${basedir}/src

  9.0.28
  
${basedir}/src

  **/*.mxml


flatten

  

  

Unfortunately, I get a NPE while trying to retrieve my mapper :

java.lang.NullPointerException
at
org.apache.maven.shared.model.fileset.mappers.MapperUtil.getFileNameMapper(MapperUtil.java:114)
at
info.rvin.mojo.flexmojo.compiler.ApplicationMojo.setUp(ApplicationMojo.java:194)
at
info.rvin.mojo.flexmojo.AbstractIrvinMojo.execute(AbstractIrvinMojo.java:178)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
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)

I've checked current trunk on shared/file-management, it seems that the
"initializeBuiltIns" call should initialize implementations but it does not.
I have enclosed a trivial patch which should fix this.

Am I missing something ? Is there a better way to handle mappers ?

Jerome.
Index: D:/Dt/jcreigno/workspaces/intranet-meta/file-management/src/main/java/org/apache/maven/shared/model/fileset/mappers/MapperUtil.java
===
--- D:/Dt/jcreigno/workspaces/intranet-meta/file-management/src/main/java/org/apache/maven/shared/model/fileset/mappers/MapperUtil.java	(revision 728728)
+++ D:/Dt/jcreigno/workspaces/intranet-meta/file-management/src/main/java/org/apache/maven/shared/model/fileset/mappers/MapperUtil.java	(working copy)
@@ -67,6 +67,7 @@
 try
 {
 props.load( stream );
+implementations = props;
 }
 catch ( IOException e )
 {
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: How Mercury resolution works?

[Oleg Gusakov]

Daniel Le Berre wrote:

Gilles Scokart a �crit :
  

An Ivy like function might be nice as well.;-)  But there is a piece
that I miss.  How did you handle conlicts? I means not multiple
possible solution, but real conflicts.  This seems to be incompatible
with a strtict system of constraints.

If I take the example :
A depends on B:1 and C:1
B:1 depends on C:2.

I think maven will take C:1 (first levle in the dependency tree), Ivy
would by default take C:2 (because it resolve conflicts by taking the
'latest' version).  What will mercury do?  My understanding is that
the SAT resolution will say there is no solution.  What practical
solution do you propose for Mercury users?  Do you ask them to fill a
DependencyManagment section for the the module that are in conflicts ?



>From a pure logical point of view, there is no solution to that system
if you add the constraints that you would like to install A and that C:1
and C:2 cannot be installed together.
  
Daniel is absolutely right, if the dirty tree looks like that, there is 
no solution, Because it represents the dependencies:

a:1 dep.on b:[1,1]
a:1 dep.on c:[1,1]
b:1 dep.on c:[2,2]

No solution, because both b1 and c1 are required for a1, c2 required for 
b1 and c1 contradicts c2. This picture would change if some dependencies 
are declared "optional", or there are "include/exclude" clauses in any 
dependency


But this illustrates an interesting rule we are dealing with:

b:1 as a dependency, could in interpreted in 3 different ways:

1).  b:1 = b:[1,1]
2).  b:1 = { b:x | x >= 1 } - OSGi standard definition
3).  b:1 = { b:x | x exists in the dirty tree } - a.k.a soft range, so 
it could be 0.9.7 or 1.3, depending on the tree and "optimization 
policy" - see below


Mercury can do all 3, default is #3, #2 could be enabled with an option.

#1 could easily be added, but is too restrictive and will break a lot of 
builds right away, so it's an exercise in completeness, not real life.



Now, since there is an optimization function, it is possible to encode
conflicts in the constraints:

A depends on (B:1 or ConflictB) and (C:1 or ConflictC)
B:1 depends on (C:2 or ConflictC)

And minimize the sum of conflicts in the optimization function.

With the optimization function provided earlier by Oleg, the selection
between C:1 and C:2 would be C:2, because it prefers latest versions,
like Ivy.
  
As Mercury is a library, the preference ("optimization policy") is 
passed in as a list of comparators, and those are used by [mercury] 
solver for multi-level sorting of GAVs in order to create the 
optimization function. If no comparators are supplied, Mercury uses a 
list of two default comparators: "shallowest", then "newest"


Thanks,
Oleg

Daniel
  

Re: svn commit: r728725 - in /maven/components/trunk/maven-project/src/test: java/org/apache/maven/project/builder/ resources-project-builder/merged-plugin-exec-goals-order/ resources-project-builder/

[Jason van Zyl]

Awesome, thanks.

On 22-Dec-08, at 11:59 AM, bentm...@apache.org wrote:


Author: bentmann
Date: Mon Dec 22 08:59:19 2008
New Revision: 728725

URL: http://svn.apache.org/viewvc?rev=728725&view=rev
Log:
o Created UT from MNG-3937

Added:
   maven/components/trunk/maven-project/src/test/resources-project- 
builder/merged-plugin-exec-goals-order/   (with props)
   maven/components/trunk/maven-project/src/test/resources-project- 
builder/merged-plugin-exec-goals-order/w-plugin-mngt/   (with props)
   maven/components/trunk/maven-project/src/test/resources-project- 
builder/merged-plugin-exec-goals-order/w-plugin-mngt/pom.xml   (with  
props)
   maven/components/trunk/maven-project/src/test/resources-project- 
builder/merged-plugin-exec-goals-order/w-plugin-mngt/sub/   (with  
props)
   maven/components/trunk/maven-project/src/test/resources-project- 
builder/merged-plugin-exec-goals-order/w-plugin-mngt/sub/pom.xml
(with props)
   maven/components/trunk/maven-project/src/test/resources-project- 
builder/merged-plugin-exec-goals-order/wo-plugin-mngt/   (with props)
   maven/components/trunk/maven-project/src/test/resources-project- 
builder/merged-plugin-exec-goals-order/wo-plugin-mngt/pom.xml
(with props)
   maven/components/trunk/maven-project/src/test/resources-project- 
builder/merged-plugin-exec-goals-order/wo-plugin-mngt/sub/   (with  
props)
   maven/components/trunk/maven-project/src/test/resources-project- 
builder/merged-plugin-exec-goals-order/wo-plugin-mngt/sub/pom.xml
(with props)

Modified:
   maven/components/trunk/maven-project/src/test/java/org/apache/ 
maven/project/builder/PomConstructionTest.java


Modified: maven/components/trunk/maven-project/src/test/java/org/ 
apache/maven/project/builder/PomConstructionTest.java

URL: 
http://svn.apache.org/viewvc/maven/components/trunk/maven-project/src/test/java/org/apache/maven/project/builder/PomConstructionTest.java?rev=728725&r1=728724&r2=728725&view=diff
= 
= 
= 
= 
= 
= 
= 
= 
==
--- maven/components/trunk/maven-project/src/test/java/org/apache/ 
maven/project/builder/PomConstructionTest.java (original)
+++ maven/components/trunk/maven-project/src/test/java/org/apache/ 
maven/project/builder/PomConstructionTest.java Mon Dec 22 08:59:19  
2008

@@ -178,6 +178,32 @@
}
//*/

+/* FIXME: cf. MNG-3937
+public void  
testOrderOfMergedPluginExecutionGoalsWithoutPluginManagement()

+throws Exception
+{
+PomTestWrapper pom = buildPom( "merged-plugin-exec-goals- 
order/wo-plugin-mngt/sub" );
+assertEquals( 5, ( (List) pom.getValue( "build/ 
plugins[1]/executions[1]/goals" ) ).size() );
+assertEquals( "child-a", pom.getValue( "build/plugins[1]/ 
executions[1]/goals[1]" ) );
+assertEquals( "merged", pom.getValue( "build/plugins[1]/ 
executions[1]/goals[2]" ) );
+assertEquals( "child-b", pom.getValue( "build/plugins[1]/ 
executions[1]/goals[3]" ) );
+assertEquals( "parent-b", pom.getValue( "build/plugins[1]/ 
executions[1]/goals[4]" ) );
+assertEquals( "parent-a", pom.getValue( "build/plugins[1]/ 
executions[1]/goals[5]" ) );

+}
+
+public void  
testOrderOfMergedPluginExecutionGoalsWithPluginManagement()

+throws Exception
+{
+PomTestWrapper pom = buildPom( "merged-plugin-exec-goals- 
order/w-plugin-mngt/sub" );
+assertEquals( 5, ( (List) pom.getValue( "build/ 
plugins[1]/executions[1]/goals" ) ).size() );
+assertEquals( "child-a", pom.getValue( "build/plugins[1]/ 
executions[1]/goals[1]" ) );
+assertEquals( "merged", pom.getValue( "build/plugins[1]/ 
executions[1]/goals[2]" ) );
+assertEquals( "child-b", pom.getValue( "build/plugins[1]/ 
executions[1]/goals[3]" ) );
+assertEquals( "parent-b", pom.getValue( "build/plugins[1]/ 
executions[1]/goals[4]" ) );
+assertEquals( "parent-a", pom.getValue( "build/plugins[1]/ 
executions[1]/goals[5]" ) );

+}
+//*/
+
private PomArtifactResolver artifactResolver( String basedir )
{
return new FileBasedPomArtifactResolver( new  
File( BASE_POM_DIR, basedir ) );


Propchange: maven/components/trunk/maven-project/src/test/resources- 
project-builder/merged-plugin-exec-goals-order/

--
   bugtraq:label = Enter issue ID:

Propchange: maven/components/trunk/maven-project/src/test/resources- 
project-builder/merged-plugin-exec-goals-order/

--
   bugtraq:message = Issue id: %BUGID%

Propchange: maven/components/trunk/maven-project/src/test/resources- 
project-builder/merged-plugin-exec-goals-order/

--
   bugtraq:number = false

Propchange: maven/components/trunk/maven-project/src/test/resources- 
project-builder/merged-plugin-exec-goals-order/

RE: [jira] Created: (MNG-3934) Get Nexus Pro building with Maven 3.x

[Brian E. Fox]

The nexus source is available for anyone to build with. He's trying to
make Maven 3 able to build Nexus, not the other way around, so there's
nothing here that anyone couldn't attempt if they were so inclined.

-Original Message-
From: Brett Porter [mailto:br...@apache.org] 
Sent: Sunday, December 21, 2008 8:17 PM
To: dev@maven.apache.org
Subject: Re: [jira] Created: (MNG-3934) Get Nexus Pro building with
Maven 3.x

Jason,

I'd rather we didn't have tasks in JIRA that most developers can't do  
anything about (and aren't descriptive of the actual problem - it  
makes for non-sensical release notes in the long run).

Is this a duplicate of MNG-3927?

Thanks,
Brett

On 22/12/2008, at 12:11 PM, Jason van Zyl (JIRA) wrote:

> Get Nexus Pro building with Maven 3.x
> -
>
> Key: MNG-3934
> URL: http://jira.codehaus.org/browse/MNG-3934
> Project: Maven 2
>  Issue Type: Bug
>Reporter: Jason van Zyl
>
>
> Nexus OSS is building fine, but we seem to have a change in the  
> plugin manager that is mistakenly claiming fields are read-only in  
> mojos when they aren't.
>
> -- 
> 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
>
>

--
Brett Porter
br...@apache.org
http://blogs.exist.com/bporter/


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [2.0.10 RC7] please test

[Brett Porter]

On 22/12/2008, at 11:07 PM, Brett Porter wrote:

I was looking at the regressions set down for 2.1.0-M1 and found  
this one that also effects 2.0.10:

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

It's related to relocation, so probably a result of this:
http://jira.codehaus.org/browse/MNG-3380


I've added an IT and confirmed that was the cause, but will have to  
come back to fixing it later (unless someone else feels inclined to  
take a look :)


- Brett

--
Brett Porter
br...@apache.org
http://blogs.exist.com/bporter/


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [2.0.10 RC7] please test

[Brett Porter]

I was looking at the regressions set down for 2.1.0-M1 and found this  
one that also effects 2.0.10:

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

It's related to relocation, so probably a result of this:
http://jira.codehaus.org/browse/MNG-3380

- Brett

On 18/12/2008, at 11:44 AM, Brian E. Fox wrote:


(once again with the right url)

This fixes the NPE reported in the last RC:
http://jira.codehaus.org/browse/MNG-3921 (Thanks Benjamin and  
Henrique)


Here's the list of issues fixed in 2.0.10:

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

And I've staged RC-6 here:

http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa
che-maven/2.0.10-RC7/



Please try it out and see if we have any remaining regressions over
2.0.9.

Thanks,
Brian


--
Brian Fox
Apache Maven PMC
http://blogs.sonatype.com/brian/

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



--
Brett Porter
br...@apache.org
http://blogs.exist.com/bporter/


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: How Mercury resolution works?

[Daniel Le Berre]

Gilles Scokart a écrit :
> An Ivy like function might be nice as well.;-)  But there is a piece
> that I miss.  How did you handle conlicts? I means not multiple
> possible solution, but real conflicts.  This seems to be incompatible
> with a strtict system of constraints.
> 
> If I take the example :
> A depends on B:1 and C:1
> B:1 depends on C:2.
> 
> I think maven will take C:1 (first levle in the dependency tree), Ivy
> would by default take C:2 (because it resolve conflicts by taking the
> 'latest' version).  What will mercury do?  My understanding is that
> the SAT resolution will say there is no solution.  What practical
> solution do you propose for Mercury users?  Do you ask them to fill a
> DependencyManagment section for the the module that are in conflicts ?

>From a pure logical point of view, there is no solution to that system
if you add the constraints that you would like to install A and that C:1
and C:2 cannot be installed together.

Now, since there is an optimization function, it is possible to encode
conflicts in the constraints:

A depends on (B:1 or ConflictB) and (C:1 or ConflictC)
B:1 depends on (C:2 or ConflictC)

And minimize the sum of conflicts in the optimization function.

With the optimization function provided earlier by Oleg, the selection
between C:1 and C:2 would be C:2, because it prefers latest versions,
like Ivy.

Daniel
-- 
 Daniel Le Berre mailto:lebe...@cril.univ-artois.fr
 MCF,CRIL-CNRS UMR 8188,Universite d'Artois
 http://www.cril.univ-artois.fr/~leberre

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: How Mercury resolution works?

[Daniel Le Berre]

Gilles Scokart a écrit :
> 2008/12/22 Daniel Le Berre :
>> Gilles,
>>
>> Representation #1 is used to compute which artifacts must be installed to
>> satisfy some artifact dependencies.
>>
>> With representation #2, Oleg only solve the problem of determining which
>> version of the available artifacts should be installed (at least, this is my
>> understanding of its encoding).
>>
>>Daniel
>>
> 
> Sorry, but I fail to see the difference.
> 
> Gilles
> 

in #1, you represent the whole dependencies in a file, and you let the
SAT solver do all the work for you (no need for a dirty tree).

in #2, you build the dirty tree and you feed the SAT solver only with
the information regarding versions of artifacts.

Daniel
-- 
 Daniel Le Berre mailto:lebe...@cril.univ-artois.fr
 MCF,CRIL-CNRS UMR 8188,Universite d'Artois
 http://www.cril.univ-artois.fr/~leberre

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: How Mercury resolution works?

[Gilles Scokart]

2008/12/22 Daniel Le Berre :
> Gilles,
>
> Representation #1 is used to compute which artifacts must be installed to
> satisfy some artifact dependencies.
>
> With representation #2, Oleg only solve the problem of determining which
> version of the available artifacts should be installed (at least, this is my
> understanding of its encoding).
>
>Daniel
>

Sorry, but I fail to see the difference.

Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: How Mercury resolution works?

[Gilles Scokart]

2008/12/20 Oleg Gusakov :
>>>
>>> Also, how do you solve the problem that different version might have
>>> dependency different tree?  Did you build the complete "dirty tree"
>>> (meanings that you look up for transitive dependencies of all old
>>> versions that will probably not be selected, an then resolve big the
>>> equations globaly), or did you proceeds somehow iteratively (resolving
>>> some equations to know which part of the tree to "dirty tree" to
>>> extends, update the dirty tree with dependencies of only resolved
>>> revisions, update the equations, solve equations again, ...).
>>>
>
> I create a full "dirty tree" for every version, then use them all in the
> generated system of inequavions. I tried to do some iterative optimizations
> in the process, but SAT does better job and it is also defined to work on
> the huge problems - ours is a toy for it.
>

I have no doubt that SAT can resolve huge system of constraints, but I
fear that building the dirty tree migh be very heavy.  You may have to
download and parse plenty of pom (or other meta-data files).
BTW, when you download a pom, did you also download the jar, or did
you only download the jar whan you know you select the right version.


> Manual intervention also proved turned sour because Mercury is flexible to
> allow different selection policies: default is "shallowest", then "newest",
> but it's all configurable with a set of comparators, passed to the solver.
> And if the need comes - we can cover a lot of exotic variations, the first
> one coming to mind - "maven2 compatibility mode" comparator. Maven2 selects
> the first version on the same level, Mercury - the newest.

An Ivy like function might be nice as well.;-)  But there is a piece
that I miss.  How did you handle conlicts? I means not multiple
possible solution, but real conflicts.  This seems to be incompatible
with a strtict system of constraints.

If I take the example :
A depends on B:1 and C:1
B:1 depends on C:2.

I think maven will take C:1 (first levle in the dependency tree), Ivy
would by default take C:2 (because it resolve conflicts by taking the
'latest' version).  What will mercury do?  My understanding is that
the SAT resolution will say there is no solution.  What practical
solution do you propose for Mercury users?  Do you ask them to fill a
DependencyManagment section for the the module that are in conflicts ?


Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

RE: Alternative to mojo-executor but with more control?

[De Smet Ringo]

Brett, 

> -Original Message-
> From: Brett Porter
> Sent: maandag 22 december 2008 1:02
> To: Maven Developers List
> Subject: Re: Alternative to mojo-executor but with more control?

> - write your own, use the maven-invoker to run the instances 
> of release:prepare / perform / clean

My idea was to create an invoker.properties file that just lists the sequence 
of release goals as separate runs on the current project, not some sort of IT 
project. Although the maven-invoker states that it can be used to run a set of 
Maven projects, and integration tests in specific, the rest of the 
implementation is too much focused on the integration testing thing. Default 
paths being src/it/... are not very helpful if you just want to run multiple 
goals on the current project. I think this is also the reason why the author of 
the mojo-executor started his project.

> - write your own, using the underlying release libraries 
> (you'll notice the release plugins are mostly delegating 
> options, so writing your own release mojo with fewer options 
> to wrap the libraries is pretty straightforward)

I think that will be the approach I will take, unfortunately...

Ringo
*

Dit e-mail bericht inclusief eventuele ingesloten bestanden kan informatie 
bevatten die vertrouwelijk is en/of beschermd door intellectuele 
eigendomsrechten. Dit bericht is uitsluitend bestemd voor de geadresseerde(n). 
Elk gebruik van de informatie vervat in dit bericht (waaronder de volledige of 
gedeeltelijke reproductie of verspreiding onder elke vorm) door andere personen 
dan de geadresseerde(n) is verboden. Indien u dit bericht per vergissing heeft 
ontvangen, gelieve de afzender hiervan te verwittigen en dit bericht te 
verwijderen. 

This e-mail and any attachment thereto may contain information which is 
confidential and/or protected by intellectual property rights and are intended 
for the sole use of the addressees. Any use of the information contained herein 
(including but not limited to total or partial reproduction or distribution in 
any form) by other persons than the addressees is prohibited. If you have 
received this e-mail in error, please notify the sender and delete its contents.

Ce courriel et les annexes éventuelles peuvent contenir des informations 
confidentielles et/ou protégées par des droits de propriété intellectuelle. Ce 
message est adressé exclusivement à son (ses) destinataire(s). Toute 
utilisation du contenu de ce message (y compris la reproduction ou diffusion 
partielle ou complète sous toute forme) par une autre personne que le(s) 
destinataire(s) est formellement interdite. Si vous avez reçu ce message par 
erreur, veuillez prévenir l'expéditeur du message et en détruire le contenu.

*

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: How Mercury resolution works?

[Daniel Le Berre]

Gilles,

Representation #1 is used to compute which artifacts must be installed 
to satisfy some artifact dependencies.


With representation #2, Oleg only solve the problem of determining which 
version of the available artifacts should be installed (at least, this 
is my understanding of its encoding).


Daniel

Gilles Scokart a écrit :

2008/12/20 Daniel Le Berre :

Oleg Gusakov a écrit :

The tree could be walked in two directions, and these approaches are
equivalent, except for b and c optionality:

Representation #1: P2

a1 -> b1 or b2 or b3
a1 -> c1 or c2

b1 + b2 + b3 <= 1  # this one implicates that b is optional
c1 + c2 <= 1   # this one implicates that c is optional


Representation #2: Mercury

b1 -> a1
b2 -> a1
b3 -> a1
c1 -> a1
c2 -> a1
b1 + b2 + b3 = 1
c1 + c2 + c3 = 1



In representation #1, I think you miss a1 = 1.  And I have the feeling
that representation #1 is easier to generalize than Representation #2.
 What happens if I have one level more.  Let say x having a dependency
on a version [1,2].
In representation #1, I keep the same equations :
a1 -> b1 or b2 or b3
a1 -> c1 or c2
b1 + b2 + b3 <= 1
c1 + c2 <= 1

and I add :
x -> a1 or a2  (dependency expressed)
a1 + a2 <= 1

Imagine that a2 has no dependencies, or worse that a2 just has a
dependency on b3.  With the representation #1, I can easily represent
that.
But with representation #2, I don't see what will be your system of
constraints ('b3 -> a1' and 'c1+c2=1'  is not correct anymore).


Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org





--
 Daniel Le Berre mailto:lebe...@cril.univ-artois.fr
 MCF,CRIL-CNRS UMR 8188,Universite d'Artois
 http://www.cril.univ-artois.fr/~leberre

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [2.0.10 RC7] please test

[Mauro Talevi]

No regressions found.

Cheers

Brian E. Fox wrote:

(once again with the right url)

This fixes the NPE reported in the last RC:
http://jira.codehaus.org/browse/MNG-3921 (Thanks Benjamin and Henrique)

Here's the list of issues fixed in 2.0.10:

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

And I've staged RC-6 here:

http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa
che-maven/2.0.10-RC7/



Please try it out and see if we have any remaining regressions over
2.0.9.

Thanks,
Brian


--
Brian Fox
Apache Maven PMC
http://blogs.sonatype.com/brian/



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: How Mercury resolution works?

[Gilles Scokart]

2008/12/20 Daniel Le Berre :
> Oleg Gusakov a écrit :
>> The tree could be walked in two directions, and these approaches are
>> equivalent, except for b and c optionality:
>>
>> Representation #1: P2
>>
>> a1 -> b1 or b2 or b3
>> a1 -> c1 or c2
>>
>> b1 + b2 + b3 <= 1  # this one implicates that b is optional
>> c1 + c2 <= 1   # this one implicates that c is optional
>>
>>
>> Representation #2: Mercury
>>
>> b1 -> a1
>> b2 -> a1
>> b3 -> a1
>> c1 -> a1
>> c2 -> a1
>> b1 + b2 + b3 = 1
>> c1 + c2 + c3 = 1
>>

In representation #1, I think you miss a1 = 1.  And I have the feeling
that representation #1 is easier to generalize than Representation #2.
 What happens if I have one level more.  Let say x having a dependency
on a version [1,2].
In representation #1, I keep the same equations :
a1 -> b1 or b2 or b3
a1 -> c1 or c2
b1 + b2 + b3 <= 1
c1 + c2 <= 1

and I add :
x -> a1 or a2  (dependency expressed)
a1 + a2 <= 1

Imagine that a2 has no dependencies, or worse that a2 just has a
dependency on b3.  With the representation #1, I can easily represent
that.
But with representation #2, I don't see what will be your system of
constraints ('b3 -> a1' and 'c1+c2=1'  is not correct anymore).


Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org