On 4 August 2010 13:55, Jason van Zyl <ja...@sonatype.com> wrote: > > On Aug 4, 2010, at 8:37 AM, Stephen Connolly wrote: > > > 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. > > > > It's not going to be any different then with Guice, and it was easy to get > commit access to Plexus. >
OK, I'll try making this clear. I'm fine with the Guice stuff. > > > 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... > > No one is getting automatic commit access to Aether. Make contributions and > you'll get access. This is how it's worked with all our projects at Github Github... fair enough... at least with git I can fork and allow others to pull my changes. > and that's worked fine. For example, as soon as some fellow came along with > Clojure support for Polyglot Maven we gave him access. There will be no > blanket commit privs for people who may, or may not, contribute anything. You're running off of Git. AFAIK there is no such thing as commit rights for Git, only "official" Git sources and people having permission to push to those sources... and ok, so there will be nexus permissions for deployment, but at least I can work in my local repo and get everything done before fighting to get my changes pushed to the official Git source and into the next release. > Sorry, but that makes no sense to me as a practical way to run a project. > > > 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) > >>> > >>> > >>> > >>> > >> > > 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 > > > >
