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