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) > > > >
