My experience is that a high barrier to committ access actually makes life harder for committers. I have commit access to Maven but not to plexus.... sometimes when working on Maven Plugins I've found I need to do something in plexus to resolve an issue, and I've hit the wall because I have to stop to get committ access or start submitting patches and fight for sponsors... next thing you know my momentum is gone, and I move on to something else.
If Aether has commit access for all Maven committers automatically, (and I'm not saying it doesn't) then a large part of my concerns can be removed... I recognise the p2 stuff as being a separate concern from the m2 repo stuff.... and if that's the case then you need to sell Aether as such and not try to sell it as a Maven Repo API. -Stephen On 4 August 2010 13:31, Stephen Connolly <stephen.alan.conno...@gmail.com>wrote: > I was saying that I see Guice as being different than Aether... the > plexus-guice shim though I see as being separate from Guice. > > I also said that I recognise that the bar for egtting committer access at > apache is probably a little too high for something like Aether. > > And, unlike others, I was only saying that I am uncomfortable. If work > committments had not been as pressing this last 8 months I would have been > more heavily involved in M3, but we can all sometimes make the mistake of > believing lies about effort now saving the site you work at ;-) > > -Stephen > > > On 4 August 2010 12:35, Jason van Zyl <ja...@sonatype.com> wrote: > >> >> On Aug 4, 2010, at 4:00 AM, Stephen Connolly wrote: >> >> > On 4 August 2010 08:06, Ralph Goers <ralph.go...@dslextreme.com> wrote: >> > >> >> I am torn on this as Brett clearly is. >> >> >> >> I haven't contributed much code in quite a while. The reasons are >> simple. >> >> Maven 2 is "stable" but has serious issues that can't be fixed without >> >> breaking compatibility. Maven 3 has been under development for years >> with >> >> parts being ripped out and redone several times. Maybe it is me but it >> seems >> >> like a lot of this work has been going on within Sonatype without a >> whole >> >> bunch of discussion here. In any case, I was just getting the feeling >> that >> >> Maven 3 is stable enough to start looking at when you announce that you >> want >> >> to make significant changes yet again. Not that they might not be >> >> warranted, but I am definitely not in favor of having core components >> of >> >> Maven hosted at a location that Maven committers don't have commit >> rights >> >> to. >> >> >> >> I find your pronouncement that it won't be here very troubling since >> you >> >> only have a single vote just as every other committer does. >> >> >> >> I'm going to have to give serious consideration as to whether I could >> >> accept this dependency without the code also residing at Apache. >> >> >> >> >> > I share concerns with respect to where the code is hosted. I recognise >> that >> > as Apache is a meritocracy, there is a barrier for other developers >> getting >> > involved. The Hudson model of "You want commit access, here you go" is >> a >> > tad too liberal for me, but the Apache model is too far the other way >> IMHO. >> > To some extend the codehaus model as practiced on mojo seems a good >> > compromise to me... but anyway aside from all that... >> > >> > Maven is hosted on Apache, therefore I feel that core Maven libraries >> should >> > be hosted on Apache until they have significant adoption elsewhere... >> the >> > Maven Repository API... well that kind of says it all as far as I'm >> > concerned with respect to where it should live. >> > >> > The Guice changes, well guice is widely adopted elsewhere, so I'm not >> > suggesting that Guice be relocated or forked into apache, but the Maven >> > specific parts of that integration.... hang about... "maven specific" >> says >> > it all again. >> >> > >> > I have always had concerns about plexus being pretty much only adopted >> by >> > Maven as far as I can see, and essentially being a maven core component, >> > except it isn't >> > >> >> The Guice-based container is really no different. It uses Guice as the >> core but we had to build the Plexus specific handling and that is a >> significant piece of code. It is for Plexus-based code and is being used for >> Maven and Nexus. Even though we will use JSR330 annotations at some point in >> the near future there are some Plexus-isms that will remain. It's not >> straight-up Guice, that simply wouldn't have worked. This code is general >> purpose, and I argue that so is Aether. >> >> Of course Maven was our first target, but the two repository types of any >> consequence are Maven and p2. No one here has likely ever worked with a p2 >> repository and likely doesn't care. p2 is critical for our work, Aether will >> adopt/change/merge p2 concepts and having written the library we will >> determine its fate and it needs to be in a place where it's accessible by >> others is of primary importance. >> >> During the course of development of Maven 3.x development only Kristian >> and Olivier have dug in. I honestly don't believe droves of people here are >> going to all of a sudden start making huge contributions to the effort. I >> want to lower the barriers for Aether's development. I believe that tools >> like Grade, SBT and many other integrators will adopt Aether very soon. >> >> Having several people who haven't been even remotely involved in the >> project over the last year tell me what we should do with the code we wrote >> doesn't sit very well with me philosophically to be perfectly frank. You do >> the work, you earn the merit, and therefore the right to decide the fate of >> the code. You don't think that's justified or fair? At least initially until >> there is a community built around it and nothing leads me to believe given >> the events over the last year that the best place to grow a community for >> Aether is Apache. >> >> > -Stephen >> > >> > Ralph >> >> >> >> >> >> On Aug 3, 2010, at 8:05 PM, Jason van Zyl wrote: >> >> >> >>> >> >>> On Aug 3, 2010, at 9:52 PM, Brett Porter wrote: >> >>> >> >>>> >> >>>> On 04/08/2010, at 4:21 AM, Jason van Zyl wrote: >> >>>> >> >>>>> Hi, >> >>>>> >> >>>>> We have two major pieces that we, Sonatype, would like to merge into >> >> Maven 3.x trunk. >> >>>> >> >>>> Are these reviewable distinctly? I only seem them mashed together in >> >> Benjamin's fork. >> >>>> >> >>> >> >>> The Guice changes are dependency changes only. All the magic happens >> in >> >> the container implementation. >> >>> >> >>>> >> >>>> The messages I'd seen so far seemed to indicate it would be heading >> back >> >> to Apache, before it was integrated into trunk. This caught me by >> surprise, >> >> and I'm disappointed that's not a consideration right now. >> >>>> >> >>> >> >>> Ultimately it's going to be more like p2 so ultimately if it moves >> >> anywhere it will be to Eclipse. >> >>> >> >>>> >> >>>> On the one hand, we have a repository indexing API eventually coming >> in, >> >> but the repository API itself going out - that seems a bit odd. There >> does >> >> seem to be a lot of "Mavenisms" in the code, at least at present, that >> would >> >> indicate it best fits here. On the other hand, I can see the value in >> having >> >> a broader group participating in this effort, and in parallel >> simplifying >> >> Maven core to focus on more directly build-related stuff, such that it >> makes >> >> sense for it to be a standalone project. >> >>>> >> >>> >> >>> Many other projects are going to be integrating this code and it's >> likely >> >> contributions from non-Maven developers will be high. I want to >> collaborate >> >> in easily, I want to release once a day if necessary to accommodate >> >> integrators, I want to use best practices for fully automated releases, >> and >> >> I want to be able to update the website instantly. Some of these issues >> are >> >> in never-ending discussion mode here, and some of these things will >> just >> >> never happen here. I don't want to argue, and I honestly believe Aether >> will >> >> be healthier for it. Maven is better here because it's adopted on >> slower >> >> cycles and people don't pick up experimental builds. Integrators will >> likely >> >> be riding the bleeding edge with Aether for a while. >> >>> >> >>>> My main concern is Maven chasing snapshots. For someone to address a >> bug >> >> or feature in Maven, they should not have to dive into a 3rd party >> project. >> >> I don't really know what would happen to our issue tracker as a result >> of >> >> this move. That problem bit me in a small way with the plexus-cipher, >> it has >> >> been an historical problem with Plexus itself, and I don't think >> "anyone can >> >> have access" really mitigates it. When 3.0 is still struggling for a >> final >> >> release, fragmenting issue tracking, communication and the limited >> >> documentation would seem problematic. >> >>> >> >>> I believe this is a non-issue. 3rd party dependencies are a fact of >> life, >> >> Maven is no different then anything else in the world. Everyone has to >> deal >> >> with snapshot dependencies or other dependency problems in lots of >> projects. >> >> Again I think Aether will be healthier having more external parties >> >> involved. For working on a library it's honestly nice not having all >> the >> >> overhead Apache brings to the table. Apache is great for overarching >> >> products like Maven, but not so much for a sub-parts. Maybe if Apache >> >> evolved in its approach to development I might think differently in the >> >> future but that's not the experience now. We need to respond very >> quickly to >> >> users and integrators. >> >>> >> >>>> >> >>>> From a technical standpoint - I'd need more time to review, if >> >> applicable. Knowing that Benjamin does good work, I'd expect it's >> superior >> >> to what we have and worth moving forward with, and agree with doing >> that >> >> soon so that the end is in sight for 3.0. I spent a lot of time >> reviewing >> >> Mercury to no avail (as you similarly highlighted in your blog post), >> but >> >> perhaps some of the comments still apply. At a glance, my first comment >> is >> >> that I can't see where the line is between the Maven bits and the >> generic >> >> bits. For instance, if I wanted to change how the local repository >> works - >> >> is that pluggable from Maven, or wholly within the library? >> >>>> >> >>> >> >>> You can look at the demo to see how all the pieces fit together: >> >>> >> >>> >> >> >> http://github.com/sonatype/sonatype-aether/blob/master/aether-demo/src/main/java/demo/RepoSys.java >> >>> >> >>>> I really only see the question of the location of the development to >> >> decide. My opinion would be to bring it here, alongside the indexer, as >> a >> >> subproject. >> >>> >> >>> I truly believe more people will be involved in Aether if it's not >> here. >> >> I don't believe it's in the best interest of the development of Aether >> to be >> >> at Apache. If I'm wrong we can move it in the future but it honestly >> doesn't >> >> make any difference now from a practical stand point. >> >>> >> >>>> Get all the effort on getting 3.0 out focused in one place, but have >> a >> >> clear scope to where they might go later. However, I'm not putting up >> any >> >> roadblocks here. The time I would have had to work on this over the >> last few >> >> years since trunk split off has pretty much evaporated. I'd love to get >> back >> >> into this particular code if it ended up somewhere I could contribute. >> But >> >> for now, I mostly want to encourage those who are still here to think >> >> through the implications for developing Maven. >> >>>> >> >>> >> >>> Fair enough. >> >>> >> >>>> Thanks, >> >>>> Brett >> >>>> >> >>>> -- >> >>>> Brett Porter >> >>>> br...@apache.org >> >>>> http://brettporter.wordpress.com/ >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> --------------------------------------------------------------------- >> >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> >>>> For additional commands, e-mail: dev-h...@maven.apache.org >> >>>> >> >>> >> >>> Thanks, >> >>> >> >>> Jason >> >>> >> >>> ---------------------------------------------------------- >> >>> Jason van Zyl >> >>> Founder, Apache Maven >> >>> http://twitter.com/jvanzyl >> >>> --------------------------------------------------------- >> >>> >> >>> A language that doesn’t affect the way you think about programming is >> not >> >> worth knowing. >> >>> >> >>> -— Alan Perlis >> >>> >> >>> >> >>> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> >> >> >> >> Thanks, >> >> Jason >> >> ---------------------------------------------------------- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> --------------------------------------------------------- >> >> First, the taking in of scattered particulars under one Idea, >> so that everyone understands what is being talked about ... Second, >> the separation of the Idea into parts, by dividing it at the joints, >> as nature directs, not breaking any limb in half as a bad carver might. >> >> -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) >> >> >> >> >
