Le jeudi 18 août 2011, jdca...@apache.org a écrit :
> Author: jdcasey
> Date: Thu Aug 18 02:25:18 2011
> New Revision: 1158995
>
> URL: http://svn.apache.org/viewvc?rev=1158995&view=rev
> Log:
> reverting to vanilla sisu,
great!
I don't really know why this modified sisu was needed in the first pl
+1 NON BINDING. Current maven remains fundamentally broken WITHOUT the newer
Aether libs, forking/rewriting would just cause delays, and/or even more bugs.
On 18/08/2011, at 2:19 AM, Arnaud HERITIER wrote:
> [+1] I'm in favor to use as Maven core dependencies SISU and AETHER
> libraries publ
+1 from me
I am ok with EPL licensed dependencies for the project and being at
Eclipse gives me security about how those artifacts will be managed,
an avenue for us to provide patches and see them included, etc.
Wayne
On Wed, Aug 17, 2011 at 9:20 AM, Arnaud HERITIER wrote:
> My vote :
>
> +1 a
I can make a maven specific staging group that will always contain the
staged stuff.
2011/8/17 Arnaud Héritier :
>>
>>
>>
>> That's what I was going to suggest in response to Hervé's last message.
>> Instead of bumping to a new snapshot immediately, it'd be better if the CI
>> system could see the
+1 (non-binding)
/Anders
On Wed, Aug 17, 2011 at 16:19, Arnaud HERITIER wrote:
> Hi all,
>
> Next releases of SISU and Aether will be done at Eclipse.org under EPL 1.0
> license.
> Before they were published under ASL or dual ASL/EPL licenses thus as
> defined in our policy [1] this change put
>
>
>
> That's what I was going to suggest in response to Hervé's last message.
> Instead of bumping to a new snapshot immediately, it'd be better if the CI
> system could see the staging repositories (assuming the local repos are
> periodically cleaned so any failed releases don't stick around).
>
+1 (non-binding)
We have started to use Aether in the upcoming Maven Android Plugin and it
already fixes a bunch of issues related to inclusion of native
dependencies.
And as a user I am concerned that Maven needs to keep moving forward asap
to avoid more mindshare loss on cutting edge/power user
That's one of the reasons why we've arranged 2 staging URL's at Codehaus.
* 1 general URL, so we don't have to adjust our profile every time when testing
a new staged project.
* 1 exclusive URL if you want to be sure you're only testing this staged
project.
-Robert
--
On Wed, Aug 17, 2011 at 2:54 PM, Brett Porter wrote:
>
> On 18/08/2011, at 2:39 AM, Benson Margulies wrote:
>
>> Unless we made use of a 'mirror trick'? I'm not sure that the
>> following hangs together. What if there was a repo group for us at
>> repository.apache.org that aggregated the staging
On Aug 17, 2011, at 2:58 PM, Baptiste MATHUS wrote:
> +1 (non-binding)
>
> Though I'm not sure I'm even entitled to vote.
>
I think it's good that users express what they would like.
> For kind of the same reasons Arnaud gave: though certainly being the best
> solution in the world, it's at l
+1 (non-binding)
Though I'm not sure I'm even entitled to vote.
For kind of the same reasons Arnaud gave: though certainly being the best
solution in the world, it's at least one that shows Maven keeps going
forward...
Cheers
Le 17 août 2011 17:59, "Jesse McConnell" a
écrit :
> +1 (non-binding)
On 18/08/2011, at 2:39 AM, Benson Margulies wrote:
> Unless we made use of a 'mirror trick'? I'm not sure that the
> following hangs together. What if there was a repo group for us at
> repository.apache.org that aggregated the staging repos for a flock of
> pom changes, and maven developers knew
staging repos are always visible to the public also (if they know the URL).
I for one have a -Pstaging profile in my settings.xml which I (re-)use for that
kind of stuff. Cheap enough...
LieGrue,
strub
--- On Wed, 8/17/11, Benson Margulies wrote:
> From: Benson Margulies
> Subject: Re: Must
On Wed, Aug 17, 2011 at 11:51 AM, Stephen Connolly
wrote:
> Well look all we need to do is say that for pom releases the vote can
> be as short as getting 3 binding +1's and it can be guillotined once
> those three binding +1's have been cast. That could give you the
> release in short time. In an
+1 (non-binding) I am good with EPL stuff :)
cheers,
jesse
--
jesse mcconnell
jesse.mcconn...@gmail.com
On Wed, Aug 17, 2011 at 09:20, Arnaud HERITIER wrote:
> My vote :
>
> +1 as I don't see for now (sadly it is sure) another good solution to
> serve ours users.
>
> Arnaud
>
> On Wed, Aug 1
Well look all we need to do is say that for pom releases the vote can
be as short as getting 3 binding +1's and it can be guillotined once
those three binding +1's have been cast. That could give you the
release in short time. In any case you cannot commit to the next
release version without fear o
Yes, but imo that has a very welcome side effect that people are adding the
staging repo and testing those upcoming releases properly ;)
That's what I meant with 'increasing visibility' :)
LieGrue,
strub
--- On Wed, 8/17/11, Benson Margulies wrote:
> From: Benson Margulies
> Subject: Re: Mus
On Wed, Aug 17, 2011 at 11:15 AM, Mark Struberg wrote:
> Maybe I'm missing something, but why you cannot checkin the upgrade to the
> non-yet-released parent? Ok, our ITs would be broken, but else?
Not only the ITs, but the private builds of everyone who does an svn
up between the checkin and th
Maybe I'm missing something, but why you cannot checkin the upgrade to the
non-yet-released parent? Ok, our ITs would be broken, but else?
Devs of course should test the new parent upgrade anyway, so the build is not
accidentally 'broken'.
LieGrue,
strub
--- On Wed, 8/17/11, Benson Margulies
I don't see how. If I want to change the plugins parent to refer to a
new version of the global maven parent, I can't even check in that
change to svn until the new global parent is deployed to a repository.
Now, we might imagine using an extra repository for this, I guess ...
On Wed, Aug 17, 2011
But we can do this all in one go, isn't?
Just stage the projects locally and call Votes which are depending on each
other.
LieGrue,
strub
--- On Wed, 8/17/11, Benson Margulies wrote:
> From: Benson Margulies
> Subject: Re: Must a pom release be an ASF release?
> To: "Maven Developers List"
On Wed, Aug 17, 2011 at 10:45 AM, Brian Fox wrote:
> Benson, what problem exactly are you trying to solve here?
1) If you want to make a set of coordinated changes up the chain of
poms, it's extremely time-consuming, with a 3-day vote at each step.
2) Our automated builds break during the 3-day
Benson, what problem exactly are you trying to solve here?
On Wed, Aug 17, 2011 at 7:50 AM, Benson Margulies wrote:
> This tees off of a remark in the recent vote thread about the
> disruption to CI of pom releases.
>
> I don't believe that we need the full ASF release voting process for
> our in
My vote :
+1 as I don't see for now (sadly it is sure) another good solution to
serve ours users.
Arnaud
On Wed, Aug 17, 2011 at 4:19 PM, Arnaud HERITIER wrote:
> Hi all,
>
> Next releases of SISU and Aether will be done at Eclipse.org under EPL
> 1.0 license.
> Before they were published
Hi all,
Next releases of SISU and Aether will be done at Eclipse.org under EPL 1.0
license.
Before they were published under ASL or dual ASL/EPL licenses thus as
defined in our policy [1] this change put them in Category B [2] and we need
to validate this change by a vote with a majority of th
ok, thus we loose again some time for nothing.
Thus now that Aether and Sisu will be published soon from Eclipse.org with
EPL license we need to launch a vote to validate their inclusion ?
http://maven.apache.org/developers/dependency-policies.html
I will launch the vote. At least we'll be able to
Yes, we can go on with releasing 3.0.4.
The SCM-Url thingy was decided to be postponed until we have a clear
understanding how we cope with pom-4.0.1 (use of xml attributes).
LieGrue,
strub
--- On Tue, 8/16/11, Arnaud Héritier wrote:
> From: Arnaud Héritier
> Subject: Re: Apache Maven distri
On Aug 16, 2011, at 10:21 AM, Arnaud Héritier wrote:
> And thus, what's new ???
> 3.0.4 is again lost somewhere ...
> Mark did you have the opportunity to work on the fix you wanted to ?
>
The release is still ready to go. I'm not sure where the vote stands on the EPL
licensed 3rd party librari
nah, you are right.
Especially given that those master-pom releases should have _especially_ good
visibility in the community.
Because just upgrading to a newer version might give you completely different
behaviour!
So I'd say we should stick with the official vote.
LieGrue,
strub
--- On Wed,
On 17 August 2011 13:00, Benson Margulies wrote:
> On Wed, Aug 17, 2011 at 7:57 AM, Stephen Connolly
> wrote:
>> I take the simple view that if it ends up in
>> https://repository.apache.org/content/repositories/releases/ then it
>> is a release therefore the release voting rules apply... But I a
On Wed, Aug 17, 2011 at 7:57 AM, Stephen Connolly
wrote:
> I take the simple view that if it ends up in
> https://repository.apache.org/content/repositories/releases/ then it
> is a release therefore the release voting rules apply... But I am
> willing to accept if the majority want to put a diffe
On Wed, Aug 17, 2011 at 7:55 AM, Stephen Connolly
wrote:
> That assumes that nobody outside of Apache inherits from these shared poms...
>
> A scary assumption to make IMHO
I don't see why it has to be scary. First of all, from a legal
standpoint, these guys would get covered by votes on things t
I take the simple view that if it ends up in
https://repository.apache.org/content/repositories/releases/ then it
is a release therefore the release voting rules apply... But I am
willing to accept if the majority want to put a different criteria on
what constitutes a release
On 17 August 2011 12:
That assumes that nobody outside of Apache inherits from these shared poms...
A scary assumption to make IMHO
On 17 August 2011 12:50, Benson Margulies wrote:
> This tees off of a remark in the recent vote thread about the
> disruption to CI of pom releases.
>
> I don't believe that we need the
This tees off of a remark in the recent vote thread about the
disruption to CI of pom releases.
I don't believe that we need the full ASF release voting process for
our internal shared POMs.
I reason as follows:
The Apache release process creates a particular legal status for a
body of code. Thi
Hi Mark,
Below is my structure of the project.
/opt/project
--> src/main/cpp
--> pom.xml
--> aol.properties -- new file I created for overriding the
existing properties.
I will be running the pom.xml which is available under /opt/project.
I
36 matches
Mail list logo
