Hi Benson!
Txs for pushing that, looks really good!.
As for compat:
I read your proposal this way: pom5 projects can only be built with mvn3.1 or
mvn4 (or whatever we call it) but while installing/deploying, a pom-4.0 will be
created which can be _consumed_ as dependencies even by mvn2 and/or
I won't fight about it but I dislike the idea of providing web links in
error messages. In a few years from now they might not exist any more or
provide irrelevant information. A stack trace is not pretty but google
doesn't mind that. At least log the stack trace at debug level if you
Thx for your work Benson
I'll read and comment your document ASAP
About new elements we already discussed to add there was the
project/build/encoding
It may me think that we need to define about the compatibility management
we'll have to setup for plugins
For now we can say that a plugin works
Nice work. I somehow think that the starting point for this disucssion
should be the intended functionality of such a change; so I'd like to
start the discussion with the use cases.
One very simple use case which I personally would appreciate is more
compact pom format; less bloat. I could see
Folks,
A general theme of these comments is, 'and what are we going to put in
our new pom version?'
I didn't go there in my writeup, since I was concerned with the
mechanics of 'how do we have a new POM *at all*'. But I see the point;
we can't make a new pom model every week, so we need to
Hey guys,
I really don't have problem with lack of commit access to maven repository.
I know how ASF work and I don't expect write access to your repository at
early stage of cooperation. :) I can do patches on my github fork and let
you cherry-picking changes instead of merging them from svn
Maven PMC,
Benjamin and I would like to make a distribution available that addresses
several issues with the Apache Maven 3.0.3 release. We have pushed back all
bugfixes that do not involve Eclipse Aether[a] and Eclipse Sisu[b] as their
incorporation into the mainline and an official release
Vincent that seems like a mistake. Why add more specific elements like Wiki
and API. Why make the POM syntax this specific. Why not make it free
from, something like:
resource type=wiki
url!--- some Wiki URL --/url
/resource
Which you could compact down in some groovy syntax to something
On Wed, Jul 27, 2011 at 10:05 PM, Ansgar Konermann
ansgar.konerm...@googlemail.com wrote:
Am 27.07.2011 08:16, schrieb Kasun Gajasinghe:
We don't allow downloading of different versions of same plugin which
in most cases does the 'same' job! So, we need the ability to set a
default plugin
On Wed, Jul 27, 2011 at 7:45 PM, Tim O'Brien tobr...@discursive.com wrote:
Vincent that seems like a mistake. Why add more specific elements like
Wiki
and API. Why make the POM syntax this specific. Why not make it free
from, something like:
resource type=wiki
url!--- some Wiki URL
As per the approved policy, this message opens a vote to allow Maven
releases to depend on EPL (and thus Category B) versions of Aether.
The vote will be open for 72 hours and the results determined
according to the policy. Discussion on this question took place on a
thread labelled '[DISCUSS]
as long as it's not over at Eclipse.org it's a
-1
from me.
LieGrue,
strub
--- On Wed, 7/27/11, Benson Margulies bimargul...@gmail.com wrote:
From: Benson Margulies bimargul...@gmail.com
Subject: [VOTE] Incorporate EPL Ether in Maven Releases
To: Maven Developers List dev@maven.apache.org
-1
I can wait too.
Kristian
Den 27. juli 2011 kl. 20:55 skrev Mark Struberg strub...@yahoo.de:
as long as it's not over at Eclipse.org it's a
-1
from me.
LieGrue,
strub
--- On Wed, 7/27/11, Benson Margulies bimargul...@gmail.com wrote:
From: Benson Margulies bimargul...@gmail.com
There are 3 weeks left for community review, another week for the creation
review, and another for the provisioning. So it's 5 weeks tops.
http://eclipse.org/proposals/technology.aether/
On Jul 27, 2011, at 2:58 PM, Kristian Rosenvold wrote:
-1
I can wait too.
Kristian
Den 27. juli
-1
Definitely not until it's all the way moved to Eclipse...and even then,
I'm personally reluctant.
I'd much prefer to see Aether's functionality moved back into Maven, and
streamlined to the point where it's easier to maintain.
On 7/27/11 2:45 PM, Benson Margulies wrote:
As per the
be glued together via a
parent pom.
I don't see why not. Consider the following example:
http://img.skitch.com/20110727-b3j3j8fk2rg4s2h9exm225skyd.png You just
need to have a hierarchy of parent poms.
Sure, if you update the top Corporate Super-Pom, you will then need to
update the other parent poms
Le mercredi 27 juillet 2011, Lukas Theussl a écrit :
I won't fight about it
sure, we won't fight :)
but I dislike the idea of providing web links in
error messages. In a few years from now they might not exist any more or
provide irrelevant information.
ok, I understand: I have idea on how
-1 for the same reasons.
On Wednesday, July 27, 2011, John Casey jdca...@commonjava.org wrote:
-1
Definitely not until it's all the way moved to Eclipse...and even then,
I'm personally reluctant.
I'd much prefer to see Aether's functionality moved back into Maven, and
streamlined to the
Yea, that sounds good!
Thanks for the update!
LieGrue,
strub
--- On Wed, 7/27/11, Jason van Zyl ja...@sonatype.com wrote:
From: Jason van Zyl ja...@sonatype.com
Subject: Re: [VOTE] Incorporate EPL Ether in Maven Releases
To: Maven Developers List dev@maven.apache.org
Date: Wednesday, July
-1 for same reasons, but I'd be happy to switch to a +1 if the license was
changed back to dual Eclipse/Apache AND it gets to Eclipse.
Dan
On Wednesday, July 27, 2011 3:04:42 PM John Casey wrote:
-1
Definitely not until it's all the way moved to Eclipse...and even then,
I'm personally
just for the record, -1 too
waiting for Eclipse release, which is coming soon: great!
Regards,
Hervé
Le mercredi 27 juillet 2011, Benson Margulies a écrit :
As per the approved policy, this message opens a vote to allow Maven
releases to depend on EPL (and thus Category B) versions of Aether.
Le mercredi 27 juillet 2011, Tim O'Brien a écrit :
Vincent that seems like a mistake. Why add more specific elements like
Wiki and API. Why make the POM syntax this specific. Why not make it
free from, something like:
resource type=wiki
url!--- some Wiki URL --/url
/resource
Which
-1 too and same reasons.
--
Olivier
Le 27 juil. 2011 21:05, John Casey jdca...@commonjava.org a écrit :
-1
Definitely not until it's all the way moved to Eclipse...and even then,
I'm personally reluctant.
I'd much prefer to see Aether's functionality moved back into Maven, and
streamlined
As long as 1.12+ of Aether makes it into the 3.0.4 release:
+1 NON Binding
Without it Maven quite easily gets seriously broken :(
On 28/07/2011, at 6:45 AM, Benson Margulies wrote:
As per the approved policy, this message opens a vote to allow Maven
releases to depend on EPL (and thus
Without it Maven quite easily gets seriously broken :(
Thats exactly the reason. Do you like to have the Apache Maven project
depending on a part which you have no control over? Which might change in a way
which just doesn't fit for Maven?
Remember: all this used to be just a part of
On Jul 27, 2011, at 4:32 PM, Mark Derricutt wrote:
As long as 1.12+ of Aether makes it into the 3.0.4 release:
+1 NON Binding
What I would consider to be the fix set for 3.0.4 is here:
http://people.apache.org/~jvanzyl/
Benjamin and I will continue to support these builds and push back
A point of process. If this vote goes negative, I'll just throw
another one when the code is live at Eclipse.org.
To Dan's point: I posted an analysis to the effect that the
dual-license has no benefit to us, and no one offered any
counter-argument. Perhaps Dan or someone else would care to offer
And was just as broken in 2.2.x with the exact same problem from what I've been
told by Richard who diagnosed and raised the JIRA ticket.
On 28/07/2011, at 8:46 AM, Mark Struberg wrote:
Remember: all this used to be just a part of maven-core in v2...
Also .. from what I understand Maven and core plugins depend on a whole
bunch of other libraries that are not in Maven and/or not in Apache so as
long as there is license compatibilitys I am sure the Maven devs can work
with upstream projects like Aether just like others like commons* or
whatever
I found the culprit: MNG-5140
and the impact is reduced: only reports in a reportSet are affected
Given this, I think it is safe to keep the fix
Regards,
Hervé
Le mercredi 27 juillet 2011, Hervé BOUTEMY a écrit :
I still need to investigate what's happenning with m-site-p 2.3 and Maven
2.2
On Thu, Jul 28, 2011 at 7:34 AM, Manfred Moser manf...@mosabuam.com wrote:
Also .. from what I understand Maven and core plugins depend on a whole
bunch of other libraries that are not in Maven and/or not in Apache so as
long as there is license compatibilitys I am sure the Maven devs can work
I did send this to the users list, but got no response in over a week.
I know dev lists are not a magical escalation path, but this might be
a better venue for this email.
I have an example project at https://gist.github.com/1090223
This project has both a JUnit test and a TestNG test.
32 matches
Mail list logo
