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. Following
On Thu, Jul 28, 2011 at 7:34 AM, Manfred Moser 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
> with upstream pr
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
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 e
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...
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
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 bac
> 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 maven-cor
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 Cate
-1 too and same reasons.
--
Olivier
Le 27 juil. 2011 21:05, "John Casey" 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 to the point w
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:
>
>
>
>
>
> Which you could compact down in some groovy syntax t
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
-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
Yea, that sounds good!
Thanks for the update!
LieGrue,
strub
--- On Wed, 7/27/11, Jason van Zyl wrote:
> From: Jason van Zyl
> Subject: Re: [VOTE] Incorporate EPL Ether in Maven Releases
> To: "Maven Developers List"
> Date: Wednesday, July 27, 2011, 7:03 PM
> There are 3 weeks left for comm
-1 for the same reasons.
On Wednesday, July 27, 2011, John Casey 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 point where it's easie
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 ho
;
> Since these projects are unrelated, they can't 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 Co
-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 appro
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.
-1
I can wait too.
Kristian
Den 27. juli 2011 kl. 20:55 skrev Mark Struberg :
> 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 wrote:
>
>> From: Benson Margulies
>> Subject: [VOTE] Incorporate EPL Ether in Mave
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 wrote:
> From: Benson Margulies
> Subject: [VOTE] Incorporate EPL Ether in Maven Releases
> To: "Maven Developers List"
> Date: Wednesday, July 27, 2011, 6:45 PM
> As per the ap
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] inco
On Wed, Jul 27, 2011 at 7:45 PM, Tim O'Brien 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:
>
>
>
>
>
> Which you could compact down in some groovy syntax
On Wed, Jul 27, 2011 at 10:05 PM, Ansgar Konermann
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 versions that are available o
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:
Which you could compact down in some groovy syntax to something like
"wiki:"
I see a lot of people using Maven for proje
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 is
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 branc
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 combin
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
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 only
30 matches
Mail list logo