You can, but I don't know at all we setup such rights :-)
Even PMCs aren't admin of the space.
I don't know how it is setup but I would hope that pmc group in ldap was
admin and dev group users of this space.
Brett, others ?
Any ideas of the process to give access to Benson.
On Mon, Jul 18, 2011 a
I don't seem to have karma for
https://cwiki.apache.org/confluence/display/MAVEN/Proposals?showChildren=true#children.
Can I?
2011/7/17 Arnaud Héritier :
> For me the first thing is to push some ideas in the wiki and make them
> challenged by developpers
> I'm not so sure that there is a consensus
OK, I'm willing to write what I think I understood.
2011/7/17 Arnaud Héritier :
> For me the first thing is to push some ideas in the wiki and make them
> challenged by developpers
> I'm not so sure that there is a consensus and a real proposal to solve that
> upgrade taking care of all use cases
For me the first thing is to push some ideas in the wiki and make them
challenged by developpers
I'm not so sure that there is a consensus and a real proposal to solve that
upgrade taking care of all use cases (previous/future versions of maven,
transitive dependencies, depMgt import, inheritence .
Many threads lead back to the recent discussion, and all of its
predecessors, about preparing for a new version of the pom by allowing
for backwards compatibility.
How do we start this? There seemed a consensus on the design. Do we
need some branches of things?
---
Since I've gone and given myself a crash course in Aether, I wondered
if I could do something about the dependency plugin issue (of
disagreeing with maven proper). I didn't get very far; I can't even
figure out which JIRA in MDEP corresponds to it. Could someone please
send me a pointer?
-
kristian, I want to repeat that b.b. has been perfectly hospitable
about my little patch and proposal for a bigger one. your message,
with which I have no disagreement, might give a casual reader another
impression.
On Jul 17, 2011, at 4:35 PM, Kristian Rosenvold
wrote:
> sø., 17.07.2011 kl. 09.
sø., 17.07.2011 kl. 09.26 -0400, skrev Benson Margulies:
> After re-reading the ASF legal licensing policy, I'm starting this
> thread to formally propose that the Maven incorporate versions of
> Aether that are EPL without an AL dual-license. As per convention,
> someone can make a VOTE thread on
'central' is defined in pom-4.0.0.xml [1] which resides in maven core.
LieGrue,
strub
[1]
http://svn.apache.org/repos/asf/maven/maven-3/trunk/maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml
--- On Sun, 7/17/11, Benson Margulies wrote:
> From: Benson Margulies
> Su
There's a technical point of interest here. Aether has a very
extensive separation of interface and implementation. So, there's a
great deal that we could do unilaterally while still using the EPL
core. The existence of 'central', I'm reasonably sure, is not inside
of Aether itself at all. I don't
On Jul 17, 2011, at 9:08 AM, Benson Margulies wrote:
>>
>> I think you are going to have to. Mark isn't the only one who has expressed
>> the sentiment. Some of the discussions I've seen on changing the
>> relationship Maven has with repository managers would surely require changes
>> at the
Hi Jason!
Eclipse doesn't have problems with consuming ALv2 dependencies because ALv2
explicitly allows sublicensing - but EPL doesn't!
So this is an unidirectional way and exactly the reason why we imo cannot do
this.
Btw, you should know exactly how hard it is to pass Eclipse' IP review and
On Jul 17, 2011, at 11:55 AM, Mark Struberg wrote:
> Sure, those are only my personal .02!
> It's a majority vote so it's not black/white of course.
>
> It's also not a problem with EPL but just my personal thoughts about our (the
> Apache Maven projects) ability to maintain Maven if a bug gets
Sure, if aether gets back being dual licensing then all would be fine.
The Maven project has good relationship with Sonatype so I'm sure the EPL is
not a problem today. But if the license is not a CategoryA license, then we
cannot make sure it will not become a problem in the future. Because we
OK, I got it. Without plugin-plugin 2.8, the plugin-info doesn't appear.
I've restaged.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Lukas,
My brain hurts.
I republished http://maven.apache.org/staging/plugins/maven-jxr-plugin/
from the tag via
/opt/apache-maven-2.2.1/bin/mvn clean install site site:stage-deploy -Preporting
I bumped site plugin to 2.3 to avoid authentication issues.
plugin-info.html is still missing in ther
>
> I think you are going to have to. Mark isn't the only one who has expressed
> the sentiment. Some of the discussions I've seen on changing the relationship
> Maven has with repository managers would surely require changes at the Aether
> layer.
I don't follow your last sentence. I just subm
Sure, those are only my personal .02!
It's a majority vote so it's not black/white of course.
It's also not a problem with EPL but just my personal thoughts about our (the
Apache Maven projects) ability to maintain Maven if a bug gets found.
In my opinion we just cannot guarantee that bugs in M
On Jul 17, 2011, at 7:45 AM, Benson Margulies wrote:
> So, the document states that the PMC decided that category B's are
> acceptable by majority vote. As per standard ASF community norms, it's
> better to give people a chance to achieve consensus and vote to affirm
> it than to just stage a vot
Lukas,
I'm beginning to think that I did something specially stupid when I
staged the site for the vote, like forget -Preporting. On the other
hand, the additional commentary on the deprecated parameter wasn't
there until about 2 minutes ago.
I'm going to go to target/checkout and redo things and
Here's a dilemma. With -Preporting, I get the following when trying to
build both sites at the same time, since the plugin tries to use a jxr
report of itself. Maybe I just stick to one site at a time?
[ERROR] BUILD FAILURE
[INFO] ---
Benson: I have locally built and staged the site before and after this
commit and I don't see any of the mentioned issues. Have you actually
checked your local site? Did you run the site phase or the site:site
goal? Anyway, with site-plugin-2.3 the locally built and
stage(-deployed) sites sho
So, the document states that the PMC decided that category B's are
acceptable by majority vote. As per standard ASF community norms, it's
better to give people a chance to achieve consensus and vote to affirm
it than to just stage a vote straight off, so here we are.
I do not think that Mark's vie
as an option, eclipse has allowed dual licensed code before, namely
jetty so there is precedent for aether to be dual licensed if they so
desire..
http://www.eclipse.org/jetty/licenses.php
cheers,
jesse
--
jesse mcconnell
jesse.mcconn...@gmail.com
On Sun, Jul 17, 2011 at 09:15, Stephen Connol
http://maven.apache.org/developers/dependency-policies
On 17 July 2011 15:02, Mark Struberg wrote:
> Actually the discussions I remember have explicitly favoured (3) (forking the
> last ALv2 version) if no ALv2 licensed version is available anymore. There
> are 2 arguments for that: it's not on
Actually the discussions I remember have explicitly favoured (3) (forking the
last ALv2 version) if no ALv2 licensed version is available anymore. There are
2 arguments for that: it's not only aether, it's also sisu and the other guice
stuff.
Aether and likes are core maven parts which are utt
After re-reading the ASF legal licensing policy, I'm starting this
thread to formally propose that the Maven incorporate versions of
Aether that are EPL without an AL dual-license. As per convention,
someone can make a VOTE thread once voices have been heard here.
EPL is 'Category B'. Binary redi
27 matches
Mail list logo