Although I am not a committer at Maven, I also share the sentiment that Maven 3's external development hinders community development at Apache. It's difficult to know where things are going -- and usually I feel the direction is wholly controlled by Sonatype. I have no problems with commercial endeavors and making money off your own sweat (Jason, congrats on building that company!), but I say the the divided allegiances is a turn off. If I wanted to contribute to Maven's core, I want to do so without worrying what other designs are brewing in external communities/organizations.
Paul On Wed, Aug 4, 2010 at 7:31 AM, Stephen Connolly < [email protected]> 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 <[email protected]> wrote: > > > > > On Aug 4, 2010, at 4:00 AM, Stephen Connolly wrote: > > > > > On 4 August 2010 08:06, Ralph Goers <[email protected]> > 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 > > >>>> [email protected] > > >>>> http://brettporter.wordpress.com/ > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > --------------------------------------------------------------------- > > >>>> To unsubscribe, e-mail: [email protected] > > >>>> For additional commands, e-mail: [email protected] > > >>>> > > >>> > > >>> 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: [email protected] > > >> For additional commands, e-mail: [email protected] > > >> > > >> > > > > 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) > > > > > > > > >
