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
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
http://maven.apache.org/developers/dependency-policies
On 17 July 2011 15:02, Mark Struberg strub...@yahoo.de 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
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
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
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
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]
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
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 vote
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
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
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
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
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
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
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 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 Aether
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
'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 bimargul...@gmail.com wrote:
From:
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 once
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
kristian.rosenv...@gmail.com
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?
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?
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
OK, I'm willing to write what I think I understood.
2011/7/17 Arnaud Héritier aherit...@gmail.com:
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
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 aherit...@gmail.com:
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
26 matches
Mail list logo
