Yes but the main issue is that nobody will test aether/guice before the release of the beta (and more before a real GA). We can suppose we'll find some others issues like the OOEM I had and thus this beta will be useless (for me it is in the current state => 14M/2488M & 5:23.389s vs 9M/125M & 21.567s). Thus they have to wait again 1 week or two or more to have another beta more stable while they could a have one now with the current trunk.
But I agree we are no more to one or two weeks of delay. beta1 was released several months ago and the latest stable version will have 1 year old in few days. In // others challengers are delivering regular releases and ours users begin to have a look at them because they see no activity in our side. My goal, like you, is to see the 3.0 out ASAP and I hope it will occur. Cheers, On Aug 6, 2010, at 4:53 PM, Jason van Zyl wrote: > > On Aug 6, 2010, at 10:44 AM, Arnaud Héritier wrote: > >> The advantage is to do what I did this morning in few minutes. >> I found a OOME on Aether/Guice branch (reported to benjamin but not in MNG >> because it's not yet integrated) and then I validated it wasn't here in >> current trunk. >> The problem is that I had to rebuild both of them hat users won't do. >> Without the beta2 release, each time you'll have to check if the problem >> reported comes from Guice/Aether or from changes done for now in beta2. >> It is more for you who'll work on it to easily ask a comparison. >> > > I honestly don't want to run, look at, or debug the current trunk. If it's > decided that we're going with the Guice/Aether code then we fix it properly > and release it. If we're not going to make an announcement for beta then just > pull a version from the grid now and we'll merge. This will also give time to > people who want to learn more about the Aether code to help add tests and > help fix the performance problems. Conservatively speaking with Benjamin and > Igor working on fixing the lead/performance in Aether we're looking at a week > starting next Tuesday. If people start helping us with the Aether code 1) > you'll see that it's just as easy to work on the Aether code in Github as > here, and 2) It will significantly speed up the release if we have more > people looking at it. > >> As I said we are also not required to do a big announcement for beta 2. We >> can do it at the same time we do the beta 3 to let users know it is here in >> case of issue. >> >> Now it's you're choice. It's you who are doing. >> >> Cheers >> >> Arnaud >> >> >> >> >> On Aug 6, 2010, at 4:31 PM, Jason van Zyl wrote: >> >>> Then we wait until we fix it. What difference does a week make at this >>> point. Honestly? >>> >>> On Aug 6, 2010, at 10:27 AM, Stephen Connolly wrote: >>> >>>> Given that Arnaud found a bad memory leak in the Aether/Guice version I >>>> think it would be good to get beta-2 out now without Aether/Guice >>>> >>>> Then fix the leak and roll beta-3 as soon as the leak is fixed >>>> >>>> -Stephen >>>> >>>> On 6 August 2010 15:10, Jason van Zyl <ja...@sonatype.com> wrote: >>>> >>>>> >>>>> On Aug 6, 2010, at 10:01 AM, Brian Fox wrote: >>>>> >>>>>> 2010/8/5 Arnaud Héritier <aherit...@gmail.com>: >>>>>>> Ok, >>>>>>> >>>>>>> Thus talking is good but doing is better ( I know I'm talking more than >>>>> I'm doing :-) ) >>>>>>> >>>>>>> Could we have a consensus if we : >>>>>>> - release now the trunk as a beta 2 without Guice and Aether. With that >>>>> we'll have a solid base to compare future changes with. We know it is >>>>> stable >>>>> and it is better than beta 1 (it solves some issues like for the site >>>>> plugin >>>>> and also in // builds). If the vote is called now we can deliver it to >>>>> users >>>>> for Monday. >>>>>>> - just after the beta2 release we merge changes required for Aether and >>>>> Guice and we start the release process for a beta 3 we'll deliver at the >>>>> end >>>>> of next week. >>>>>> >>>>>> mvn:release prepare release:perform takes at most 30 minutes so I >>>>>> don't see any harm in firing them both out there. >>>>>> >>>>> >>>>> Other then it being highly confusing to the general user base. We have >>>>> beta-2 and then three days later trying to message making two drastic >>>>> changes and releasing it again. Also what this entails is that if someone >>>>> does report a problem with the container or artifact resolution it will >>>>> have >>>>> to be addressed in beta-3 anyway. If we're going to release a beta-2 that >>>>> is >>>>> effectively not going to be support I don't see much value in that. Also >>>>> between Stuart, Benjamin, Igor, and myself anything in the container and >>>>> resolution level will get fixed quickly. >>>>> >>>>> Why don't you just try the site plugin with the branch with Aether and >>>>> Guice and make sure it works? I think taking the time to make sure those >>>>> changes work is better then dealing with the WTF responses from users when >>>>> we drop two betas out in the course of three days. The vast majority of >>>>> users are not using 3.0-beta-1 and so I don't think the average user cares >>>>> that a the site plugin doesn't work. I would prefer we delay a single >>>>> decent >>>>> beta of what we are ultimately going to ship. >>>>> >>>>> It's not hard to spin out two releases, but it's just harder to manage >>>>> because when issues come flying in we're dealing with two completely >>>>> different animals. People are unlikely to specify the right version and >>>>> we're just going to have a lot more busy work then necessary. >>>>> >>>>> Let's make one good release wait a week and push out what we actually plan >>>>> to support. >>>>> >>>>> I personally think dropping out two betas that are completely different in >>>>> the span of 3 days is just totally confusing for users and not the tone we >>>>> want to set building up to the release of 3.0. >>>>> >>>>>>> >>>>>>> With that we'll try to receive feedback from users and we'll easily >>>>> validate if problems are related to Guice or Aether by comparing results >>>>> with both versions. >>>>>>> At the end of the month we can push out a new beta with all fixes we'll >>>>> have. It will be always possible to decide to remove Aether if some of you >>>>> have a better solution or aren't satisfied by the change (I would prefer >>>>> to >>>>> have done that in an alpha releases cycle but now we are in beta we cannot >>>>> come back in rear). >>>>>>> >>>>>>> WDYT ? I think it is important to push out new releases to show to our >>>>> community that we are always active and we are going in the good >>>>> direction. >>>>>>> >>>>>>> Arnaud >>>>>>> >>>>>>> >>>>>>> On Aug 5, 2010, at 11:06 PM, Dennis Lundberg wrote: >>>>>>> >>>>>>>> Hi all >>>>>>>> >>>>>>>> Some very important questions have been asked regarding Jason's >>>>>>>> proposal. I usually let my first impressions sink in a bit before I >>>>>>>> reply. That often help to make my comments more about the facts and >>>>> less >>>>>>>> about the feelings, and we've seen a lot of feelings in this thread. >>>>>>>> >>>>>>>> The first thing I would like to happen is that we release 3.0-beta-2 >>>>>>>> *without* merging the proposed code. There are two reasons for this. >>>>>>>> >>>>>>>> 1. The Site Plugin, which most of you know is something that I've >>>>> worked >>>>>>>> quite a lot on, is currently in limbo. On one hand we have the stable >>>>>>>> 2.x trunk of the plugin which works with Maven 2, but not with Maven 3. >>>>>>>> We also have a 3.0-SNAPSHOT branch of the plugin, thanks to Olivier and >>>>>>>> Hervé. But that currently don't work with any released version of Maven >>>>>>>> because of a bug in Maven 3.0-beta-1. In order to gain momentum and >>>>>>>> field testing for Maven Site Plugin 3.0 it needs a stable version of >>>>>>>> Maven to work with. There are too few people working on the Site >>>>> Plugin, >>>>>>>> and if it needs to be rewritten yet again there is a risk that it will >>>>>>>> never be ready. >>>>>>>> >>>>>>>> 2. Release early, release often. Give the users a choice here. They can >>>>>>>> choose to use Maven 3.0-beta-2 which will work much like beta-1 did, >>>>> but >>>>>>>> with lots of bugs fixed. Or a few weeks later they can use 3.0-beta-3 >>>>>>>> the proposed code changes merged in. If the new stuff doesn't work, for >>>>>>>> whatever reason, they can switch back to beta-2 while they wait for a >>>>>>>> bug fixed beta-4. >>>>>>>> >>>>>>>> As for they proposed code bases I am not qualified to make detailed >>>>>>>> comments, so my comments will be very high level. >>>>>>>> >>>>>>>> >>>>>>>> Guice >>>>>>>> >>>>>>>> IIUC this means that we would replace one (external) IOC container with >>>>>>>> another (external) IOC container. If the bar for being allowed to >>>>>>>> participate in the development of Guice is at the same level as it has >>>>>>>> been for Plexus, then I have no problem with this switch. >>>>>>>> >>>>>>>> I am +1 on integrating the Guice code after beta-2 has been released. >>>>>>>> >>>>>>>> >>>>>>>> Aether >>>>>>>> >>>>>>>> One thing that I really think has been successful here at Maven has >>>>> been >>>>>>>> when we have set up proper APIs that abstracts the implementation and >>>>>>>> let the users pick a suitable implementation for their needs. Two >>>>>>>> subprojects come to mind: SCM and Wagon. >>>>>>>> >>>>>>>> If the API part of Aether is anything like that, then that's a good >>>>>>>> thing in my book. I haven't looked at the code, only the high level >>>>>>>> presentation, but I have high confidence in those who have worked on >>>>> it. >>>>>>>> Having the API hosted outside of Apache is fine by me if it means that >>>>>>>> more projects will use it. The more the merrier. >>>>>>>> >>>>>>>> When it comes to the implementation I'm undecided. It does mean that we >>>>>>>> will make an integral part of Maven external, which can lead to >>>>> problems >>>>>>>> with issue tracking etc, as pointed out by others. On the other hand it >>>>>>>> makes sense to use the collective knowledge of the people who is >>>>>>>> responsible for the API, to also work together on implementations. >>>>>>>> Perhaps the Maven repository implementation can be moved back to the >>>>>>>> Maven project, when things have settled down. >>>>>>>> >>>>>>>> I am +0 on integrating Aether after beta-2 has been released. I'll let >>>>>>>> others with more insights decide. >>>>>>>> >>>>>>>> >>>>>>>> On 2010-08-03 20:21, Jason van Zyl wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> We have two major pieces that we, Sonatype, would like to merge into >>>>> Maven 3.x trunk. >>>>>>>>> >>>>>>>>> The first are the Guice changes that we've been talking about for a >>>>> while, and the second is the introduction of Aether which is our second >>>>> attempt at a stand-alone repository API. The PMC is aware of Aether as >>>>> Brian >>>>> reported it in our quarterly report to the Apache Board, but other >>>>> developers who are not on the PMC and the community in general might not >>>>> know much about it. >>>>>>>>> >>>>>>>>> I just posted an entry giving a very high level description: >>>>>>>>> >>>>>>>>> http://www.sonatype.com/people/2010/08/introducing-aether/ >>>>>>>>> >>>>>>>>> There is a resources section at the bottom of the post for those >>>>> interested in the sources, issue tracking, wiki and mailing lists. As part >>>>> of some of the research we are about to embark on with Daniel Le Berre, >>>>> Aether will likely look more like p2 as time passes and as a final resting >>>>> place the Eclipse Foundation is more likely then Apache. I know people >>>>> will >>>>> ask so I'm answering that now. Sonatype is just about to fully move Tycho >>>>> over the Eclipse Foundation and we want to see how that goes. If that >>>>> works, >>>>> then M2Eclipse is next, and then Aether will follow. >>>>>>>>> >>>>>>>>> At any rate we would like to merge these changes in and make plans to >>>>> release 3.0-beta-2. >>>>>>>>> >>>>>>>>> So please let us know if you have any objections. >>>>>>>>> >>>>>>>>> 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) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Dennis Lundberg >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> 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 >>>>>>> >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> 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 >>>>> --------------------------------------------------------- >>>>> >>>>> We all have problems. How we deal with them is a measure of our worth. >>>>> >>>>> -- Unknown >>>>> >>>>> >>>>> >>>>> >>> >>> Thanks, >>> >>> Jason >>> >>> ---------------------------------------------------------- >>> Jason van Zyl >>> Founder, Apache Maven >>> http://twitter.com/jvanzyl >>> --------------------------------------------------------- >>> >>> In short, man creates for himself a new religion of a rational >>> and technical order to justify his work and to be justified in it. >>> >>> -- Jacques Ellul, The Technological Society >>> >>> >>> >> >> >> --------------------------------------------------------------------- >> 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 > --------------------------------------------------------- > > In short, man creates for himself a new religion of a rational > and technical order to justify his work and to be justified in it. > > -- Jacques Ellul, The Technological Society > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
