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
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 iss
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
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 somethi
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
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 m
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
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
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.
I
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-p
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, D
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'
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 wrot
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 exampl
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 artifa
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,
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 th
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
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 enc
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?ver
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
21 matches
Mail list logo
