Can we create our own, new API that plugins should use for this? Eventually all of Maven could use that instead of Aether directly.
Ralph On Jul 30, 2011, at 10:25 AM, John Casey wrote: > On 7/30/11 9:00 AM, Stephen Connolly wrote: >> well it seems to me that we need to ensure that aether is not leaking into >> our public api. if it is entirely private from plugins, then i really don't >> care if it is epl or dual... > > I agree completely. > > But, how can we keep it from leaking into plugins, when it's using the same > plexus component system as the rest of Maven? > > This has long been a problem inside Maven, namely that we can't control > _which_ components plugin devs have access to, and therefore we have an > extremely difficult time deprecating/removing old components or reworking the > internal design. > > Maybe firewalling and restricting the list of core components available to > plugin devs is what we really need to address in order to address this > concern. > > dual would be nicer, and truer to the original >> plan whereby the code would be developed at github for speed, and then given >> back to maven. that plan changed, and now the code is (likely) ending up at >> eclipse... Jason has reasons for eclipse... that is just reality. personally >> i feel that it is another merit hurdle to have the code at eclipse, but then >> having maven at apache is a legal pain for m2eclipse because of eclipse's ip >> review policy, so i can see why Jason would want as much of the code >> m2eclipse depends on at eclipse. >> >> in any case, let's wait > > +1 > > I want to at least see Aether in a stable location with some real bylaws and > culture before I'll be okay with it. This was supposed to happen long ago, > and as I remember it, that promise is a big part of why we adopted Aether... > > That, and this argument that we should give in to whatever demands are made > by the People Who Are Getting Things Done Around Here. > > Now, we see that the pressure is off to follow up on these promises, as long > as we keep agreeing to adopt versions developed without corresponding > movement on the promises. I think we have to take some sort of stand, or this > will not improve. > > Words are nice, but action is better. > >> >> - Stephen >> >> --- >> Sent from my Android phone, so random spelling mistakes, random nonsense >> words and other nonsense are a direct result of using swype to type on the >> screen >> On 30 Jul 2011 12:47, "Benson Margulies"<bimargul...@gmail.com> wrote: >>> I'd like to to try to put a little oxygen into this thread now, given >>> the rather clear results of the vote thread. >>> >>> Ralph posed the following question on Legal Discuss: 'Can the Maven >>> PMC pull a dual-licensed version of AEther back into Apache without a >>> grant from Sonatype?' >>> >>> The answer was, "legally yes, but it is counter to long-established >>> policy, and strongly discouraged by a number of senior ASF people >>> (including a board member or two)". >>> >>> So, the community has some choices. It seems to me that the viability >>> of these different choices depends on the viability of walking away >>> from AEther. In practical terms, the choices are: >>> >>> a) Use versions of AEther controlled by 'someone else'. >>> b) Create our own 'someone else' at apache-extras or elsewhere. >>> c) Go down the path of becoming an exception to the policy and take on >>> reworking AEther from the last dual-licensed version. >>> d) Start All Over Again from Maven 2.2. >>> >>> From the vote comments, it seemed to me that a plurality of people >>> felt that EPL at Eclipse was tolerable. So that argues for sitting >>> still for now. I offer only the observation that forking into >>> apache-extras 'works' the same way today, or after the code appears in >>> Eclipse. In other words, adopting what's out there today only makes >>> choice (c) harder, it doesn't have any impact that I see on a, b, or >>> d. However, a 'no' vote is a 'no' vote, so this is all just food for >>> thought. >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> > > -- > John Casey > Developer, PMC Chair - Apache Maven (http://maven.apache.org) > Blog: http://www.johnofalltrades.name/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
