Merging in our Aether and Guice changes to Maven 3.x

[Jason van Zyl <ja...@sonatype.com>]

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)

Re: Merging in our Aether and Guice changes to Maven 3.x

[Brian Fox <br...@infinity.nu>]

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

Lets stage them both, I don't see any harm in having them back to
back, it certainly could help isolate any regressions.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Emmanuel Venisse <em...@gmail.com>]

+1

Emmanuel

2010/8/6 Arnaud Héritier <ah...@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.
>
>  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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Olivier Lamy <ol...@apache.org>]

Hi,
I have fixed it locally.

You can have a look at the patch for site plugin attached here :
https://issues.sonatype.org/browse/SPICE-33.

But you must have a look too at SPICE-33 and use last SNAPSHOT of
guice/plexus stuff.




2010/8/6 Hervé BOUTEMY <he...@free.fr>:
> Le vendredi 06 août 2010, Jason van Zyl a écrit :
>> Why don't you just try the site plugin with the branch with Aether and
>> Guice and make sure it works?
>
> I built Benjamin's branch for myself and tried "mvn -Prun-its install" on
> maven-site-plugin 3.0-beta-1-SNAPSHOT branch and got failure for evey ITs:
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.0-
> beta-1-SNAPSHOT:site (default-cli) on project no-version: Execution default-
> cli of goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-1-
> SNAPSHOT:site failed: An API incompatibility was encountered while executing
> org.apache.maven.plugins:maven-site-plugin:3.0-beta-1-SNAPSHOT:site:
> java.lang.NoSuchMethodError:
> org.apache.maven.plugin.MavenPluginManager.getPluginDescriptor(Lorg/apache/maven/model/Plugin;Lorg/apache/maven/artifact/repository/RepositoryRequest;)Lorg/apache/maven/plugin/descriptor/PluginDescriptor;
>
>
>
> Any hint?
>
> Regards,
>
> Hervé
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>



-- 
Olivier
http://twitter.com/olamy
http://fr.linkedin.com/in/olamy
http://www.viadeo.com/fr/profile/olivier.lamy7

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Benjamin Bentmann <be...@udo.edu>]

Hervé BOUTEMY wrote:

> java.lang.NoSuchMethodError:
> org.apache.maven.plugin.MavenPluginManager.getPluginDescriptor(Lorg/apache/maven/model/Plugin;Lorg/apache/maven/artifact/repository/RepositoryRequest;)Lorg/apache/maven/plugin/descriptor/PluginDescriptor;

I adjusted the 3.x API, so just sync up with Olivier, he already dealt 
with it (see his patch at https://issues.sonatype.org/browse/SPICE-33).


Benjamin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Hervé BOUTEMY <he...@free.fr>]

Le vendredi 06 août 2010, Jason van Zyl a écrit :
> Why don't you just try the site plugin with the branch with Aether and
> Guice and make sure it works?

I built Benjamin's branch for myself and tried "mvn -Prun-its install" on 
maven-site-plugin 3.0-beta-1-SNAPSHOT branch and got failure for evey ITs:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.0-
beta-1-SNAPSHOT:site (default-cli) on project no-version: Execution default-
cli of goal org.apache.maven.plugins:maven-site-plugin:3.0-beta-1-
SNAPSHOT:site failed: An API incompatibility was encountered while executing 
org.apache.maven.plugins:maven-site-plugin:3.0-beta-1-SNAPSHOT:site: 
java.lang.NoSuchMethodError: 
org.apache.maven.plugin.MavenPluginManager.getPluginDescriptor(Lorg/apache/maven/model/Plugin;Lorg/apache/maven/artifact/repository/RepositoryRequest;)Lorg/apache/maven/plugin/descriptor/PluginDescriptor;



Any hint?

Regards,

Hervé

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: guice & memory usage was: (3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x)

[Hervé BOUTEMY <he...@free.fr>]

Le jeudi 19 août 2010, Jochen Wiedmann a écrit :
> On Wed, Aug 18, 2010 at 11:18 PM, Hervé BOUTEMY <he...@free.fr> 
wrote:
> > I have only one concern with current maven-3 code in GitHub: it's not
> > compatible with maven-site-plugin 3.0-beta-1
> 
> I think, that's a blocker for a new beta release, but not for a merge,
> isn't it?
it's not a blocker neither for a merge nor a new beta release

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: guice & memory usage was: (3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x)

[Hervé BOUTEMY <he...@free.fr>]

Le mercredi 18 août 2010, Olivier Lamy a écrit :
> 2010/8/18 Benjamin Bentmann <be...@udo.edu>:
> > Olivier Lamy wrote:
> >> So maybe having a compatibility even if we are in a beta release
> >> process (benjamin ?)
> > 
> > I don't feel motivated to maintain yet another layer of compat/bridge
> > code for the sake of single beta plugin.
> 
> ok np for me.
ok for me, since this is really a layer and not only a few deprecated methods
:/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: guice & memory usage was: (3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x)

[Olivier Lamy <ol...@apache.org>]

2010/8/18 Benjamin Bentmann <be...@udo.edu>:
> Olivier Lamy wrote:
>
>> So maybe having a compatibility even if we are in a beta release
>> process (benjamin ?)
>
> I don't feel motivated to maintain yet another layer of compat/bridge code
> for the sake of single beta plugin.

ok np for me.

>
>
> Benjamin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>



-- 
Olivier
http://twitter.com/olamy
http://fr.linkedin.com/in/olamy
http://www.viadeo.com/fr/profile/olivier.lamy7

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: guice & memory usage was: (3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x)

[Benjamin Bentmann <be...@udo.edu>]

Olivier Lamy wrote:

> So maybe having a compatibility even if we are in a beta release
> process (benjamin ?)

I don't feel motivated to maintain yet another layer of compat/bridge 
code for the sake of single beta plugin.


Benjamin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: guice & memory usage was: (3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x)

[Olivier Lamy <ol...@apache.org>]

2010/8/18 Hervé BOUTEMY <he...@free.fr>:
> Le mercredi 18 août 2010, Olivier Lamy a écrit :
>> Herve : regarding site plugin there is a patch here (
>> https://issues.sonatype.org/secure/attachment/23615/site-plugin-guice-eathe
>> r.patch ).
> yes, I know the patch (I studied it since our last discussion), but that
> doesn't make the future maven 3.0-beta-3 with maven-site-plugin 3.0-beta-1:
> we'll have to release maven-site-plugin 3.0-beta-2, and every pom.xml using
> site plugin will have to be modified.
Sure (btw we need a new release of site plugin for issue with webdav
deployment).
So maybe having a compatibility even if we are in a beta release
process (benjamin ?)
> That's why I am annoyed.
> But you're right, with this patch, this isn't a blocker
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>



-- 
Olivier
http://twitter.com/olamy
http://fr.linkedin.com/in/olamy
http://www.viadeo.com/fr/profile/olivier.lamy7

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: guice & memory usage was: (3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x)

[Hervé BOUTEMY <he...@free.fr>]

Le mercredi 18 août 2010, Olivier Lamy a écrit :
> Herve : regarding site plugin there is a patch here (
> https://issues.sonatype.org/secure/attachment/23615/site-plugin-guice-eathe
> r.patch ).
yes, I know the patch (I studied it since our last discussion), but that 
doesn't make the future maven 3.0-beta-3 with maven-site-plugin 3.0-beta-1: 
we'll have to release maven-site-plugin 3.0-beta-2, and every pom.xml using 
site plugin will have to be modified.
That's why I am annoyed.
But you're right, with this patch, this isn't a blocker

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: guice & memory usage was: (3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x)

[Manfred Moser <ma...@mosabuam.com>]

Well.. can we get that patch applied and a new release of the maven 3 site
plugin as well then.

manfred

PS: beta 2 works on all my projects..

> Hi,
> Let's go for merge ! (with last spice version 1.3.3-SNAPSHOT or
> released version to have a fix for SPICE-34).
>
> Herve : regarding site plugin there is a patch here (
> https://issues.sonatype.org/secure/attachment/23615/site-plugin-guice-eather.patch
> ).
>
>
> 2010/8/18 Hervé BOUTEMY <he...@free.fr>:
>> Le mercredi 18 août 2010, Jason van Zyl a écrit :
>>> On Aug 18, 2010, at 1:43 PM, Arnaud Héritier wrote:
>>> > Hi,
>>> >
>>> >  I just rebuilt aether and maven3 and I have now : 14M/125M
>>> >  We are really near of 9M/125M we have in beta2
>>> >  Perfect !!!
>>> >
>>> >  Let's go for a merge in trunk ??
>>>
>>> Yup, let's merge it all in and move forward.
>>
>> I have only one concern with current maven-3 code in GitHub: it's not
>> compatible with maven-site-plugin 3.0-beta-1
>> I'm trying to find a way to make it compatible, without success for the
>> moment
>> :(
>> I know it's only betas, used only by people who know what they are
>> doing, but
>> it is annoying...
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
>
> --
> Olivier
> http://twitter.com/olamy
> http://fr.linkedin.com/in/olamy
> http://www.viadeo.com/fr/profile/olivier.lamy7
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: guice & memory usage was: (3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x)

[Olivier Lamy <ol...@apache.org>]

Hi,
Let's go for merge ! (with last spice version 1.3.3-SNAPSHOT or
released version to have a fix for SPICE-34).

Herve : regarding site plugin there is a patch here (
https://issues.sonatype.org/secure/attachment/23615/site-plugin-guice-eather.patch
).


2010/8/18 Hervé BOUTEMY <he...@free.fr>:
> Le mercredi 18 août 2010, Jason van Zyl a écrit :
>> On Aug 18, 2010, at 1:43 PM, Arnaud Héritier wrote:
>> > Hi,
>> >
>> >  I just rebuilt aether and maven3 and I have now : 14M/125M
>> >  We are really near of 9M/125M we have in beta2
>> >  Perfect !!!
>> >
>> >  Let's go for a merge in trunk ??
>>
>> Yup, let's merge it all in and move forward.
>
> I have only one concern with current maven-3 code in GitHub: it's not
> compatible with maven-site-plugin 3.0-beta-1
> I'm trying to find a way to make it compatible, without success for the moment
> :(
> I know it's only betas, used only by people who know what they are doing, but
> it is annoying...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>



-- 
Olivier
http://twitter.com/olamy
http://fr.linkedin.com/in/olamy
http://www.viadeo.com/fr/profile/olivier.lamy7

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: guice & memory usage was: (3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x)

[Jochen Wiedmann <jo...@gmail.com>]

On Wed, Aug 18, 2010 at 11:18 PM, Hervé BOUTEMY <he...@free.fr> wrote:

> I have only one concern with current maven-3 code in GitHub: it's not
> compatible with maven-site-plugin 3.0-beta-1

I think, that's a blocker for a new beta release, but not for a merge, isn't it?

Jochen

-- 
I Am What I Am And That's All What I Yam (Popeye)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: guice & memory usage was: (3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x)

[Hervé BOUTEMY <he...@free.fr>]

Le mercredi 18 août 2010, Jason van Zyl a écrit :
> On Aug 18, 2010, at 1:43 PM, Arnaud Héritier wrote:
> > Hi,
> > 
> >  I just rebuilt aether and maven3 and I have now : 14M/125M
> >  We are really near of 9M/125M we have in beta2
> >  Perfect !!!
> >  
> >  Let's go for a merge in trunk ??
> 
> Yup, let's merge it all in and move forward.

I have only one concern with current maven-3 code in GitHub: it's not 
compatible with maven-site-plugin 3.0-beta-1
I'm trying to find a way to make it compatible, without success for the moment 
:(
I know it's only betas, used only by people who know what they are doing, but 
it is annoying...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: guice & memory usage was: (3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x)

[Stephen Connolly <st...@gmail.com>]

+10000

On 18 August 2010 22:02, Jason van Zyl <ja...@sonatype.com> wrote:
>
> On Aug 18, 2010, at 1:43 PM, Arnaud Héritier wrote:
>
>> Hi,
>>
>>  I just rebuilt aether and maven3 and I have now : 14M/125M
>>  We are really near of 9M/125M we have in beta2
>>  Perfect !!!
>>
>>  Let's go for a merge in trunk ??
>>
>
> Yup, let's merge it all in and move forward.
>
>> Arnaud
>>
>> On Aug 7, 2010, at 2:37 PM, Arnaud Héritier wrote:
>>
>>> Results I had yesterday were :
>>>
>>> 3.0-benjamin (built yesterday) : 14M/2488M in 5:23.389s (It probably swapped a lot)
>>> 3.0-beta-2 (downloaded few minutes ago) : 9M/125M built in 23.723s
>>> 2.2.1 : 67M/136M built in 30s
>>>
>>> I only built one module : http://svn.exoplatform.org/projects/ecms/trunk/packaging/wcm/ear
>>> Its dependencies tree is horrible !
>>>
>>> I used : MAVEN_OPTS = -Xshare:auto -Xms128M -Xmx4G -XX:MaxPermSize=256M
>>> (In theory Xmx = 1G but I increased it to 4G to fix the OOME)
>>>
>>> To build it and reproduce the issue you need this repo : http://repository.exoplatform.org/public/ (releases & snapshots)
>>>
>>> I will try to open the debugger this WE if I find few minutes.
>>>
>>> On Aug 7, 2010, at 1:26 PM, Brett Porter wrote:
>>>
>>>>
>>>> On 07/08/2010, at 12: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 ran this over one of my builds out of curiosity. Not sure if this is helpful, but maybe some datapoints.
>>>>
>>>> 3.0-benjamin => 73m / 252m
>>>> 3.0-beta-1 => 63m / 159m
>>>> 2.2.1 => 129m / 252m
>>>>
>>>> Then I checked just the following:
>>>> 3.0-beta-2-SNAPSHOT + guice patch => 70m/218m
>>>> 3.0-beta-2-SNAPSHOT => 74m/252m
>>>>
>>>> The numbers are quite consistent, so it looks like the problem might have been on trunk here, not the guice++ branch. Arnaud, is that also what you see with trunk?
>>>>
>>>> I quickly ran the first two with Yourkit and saw that in Benjamin's branch, the memory grows faster at a consistent rate, but is still released at the end. The retained memory is only the classrealms and JDK ZIP cache, which basically is the same for beta-1. So more usage, but not a leak. No OOME, but perhaps the project is not big enough to exhibit it.
>>>>
>>>> Nothing to particularly note on the garbage collection front. The non-heap memory looks to be identical. Basically the same results running with a clean repository to do more artifact operations. Scanning the allocations, there's quite deep trees of allocations for Guice & the shim - but given the results for the other snapshots I'm not sure that's an issue itself.
>>>>
>>>> That's all I had time for, but I'll hold onto the snapshots in case they help.
>>>>
>>>> - Brett
>>>>
>>>> --
>>>> Brett Porter
>>>> brett@apache.org
>>>> http://brettporter.wordpress.com/
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> Selfish deeds are the shortest path to self destruction.
>
>  -- The Seven Samuari, Akira Kurosawa
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: guice & memory usage was: (3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x)

[Jason van Zyl <ja...@sonatype.com>]

On Aug 18, 2010, at 1:43 PM, Arnaud Héritier wrote:

> Hi,
> 
>  I just rebuilt aether and maven3 and I have now : 14M/125M
>  We are really near of 9M/125M we have in beta2
>  Perfect !!!
> 
>  Let's go for a merge in trunk ??
> 

Yup, let's merge it all in and move forward.

> Arnaud
> 
> On Aug 7, 2010, at 2:37 PM, Arnaud Héritier wrote:
> 
>> Results I had yesterday were :
>> 
>> 3.0-benjamin (built yesterday) : 14M/2488M in 5:23.389s (It probably swapped a lot)
>> 3.0-beta-2 (downloaded few minutes ago) : 9M/125M built in 23.723s
>> 2.2.1 : 67M/136M built in 30s
>> 
>> I only built one module : http://svn.exoplatform.org/projects/ecms/trunk/packaging/wcm/ear
>> Its dependencies tree is horrible !
>> 
>> I used : MAVEN_OPTS = -Xshare:auto -Xms128M -Xmx4G -XX:MaxPermSize=256M
>> (In theory Xmx = 1G but I increased it to 4G to fix the OOME)
>> 
>> To build it and reproduce the issue you need this repo : http://repository.exoplatform.org/public/ (releases & snapshots)
>> 
>> I will try to open the debugger this WE if I find few minutes.
>> 
>> On Aug 7, 2010, at 1:26 PM, Brett Porter wrote:
>> 
>>> 
>>> On 07/08/2010, at 12: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 ran this over one of my builds out of curiosity. Not sure if this is helpful, but maybe some datapoints.
>>> 
>>> 3.0-benjamin => 73m / 252m
>>> 3.0-beta-1 => 63m / 159m
>>> 2.2.1 => 129m / 252m
>>> 
>>> Then I checked just the following:
>>> 3.0-beta-2-SNAPSHOT + guice patch => 70m/218m
>>> 3.0-beta-2-SNAPSHOT => 74m/252m
>>> 
>>> The numbers are quite consistent, so it looks like the problem might have been on trunk here, not the guice++ branch. Arnaud, is that also what you see with trunk?
>>> 
>>> I quickly ran the first two with Yourkit and saw that in Benjamin's branch, the memory grows faster at a consistent rate, but is still released at the end. The retained memory is only the classrealms and JDK ZIP cache, which basically is the same for beta-1. So more usage, but not a leak. No OOME, but perhaps the project is not big enough to exhibit it. 
>>> 
>>> Nothing to particularly note on the garbage collection front. The non-heap memory looks to be identical. Basically the same results running with a clean repository to do more artifact operations. Scanning the allocations, there's quite deep trees of allocations for Guice & the shim - but given the results for the other snapshots I'm not sure that's an issue itself.
>>> 
>>> That's all I had time for, but I'll hold onto the snapshots in case they help.
>>> 
>>> - Brett
>>> 
>>> --
>>> Brett Porter
>>> brett@apache.org
>>> http://brettporter.wordpress.com/
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>> 
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

Selfish deeds are the shortest path to self destruction.

 -- The Seven Samuari, Akira Kurosawa

Re: guice & memory usage was: (3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x)

[Jason van Zyl <ja...@sonatype.com>]

So the plan is that we're going to do a release of spice-inject as fast as we can and then do the merge. So that will likely happen early next week. Until then folks can pick things up from Benjamin's branch:

http://github.com/bentmann/maven-3

On Aug 19, 2010, at 4:20 AM, Tamás Cservenák wrote:

> Cool!
> 
> +1 for merges!
> 
> 
> Thanks,
> ~t~
> 
> 2010/8/18 Arnaud Héritier <ah...@gmail.com>
> 
>> Hi,
>> 
>> I just rebuilt aether and maven3 and I have now : 14M/125M
>> We are really near of 9M/125M we have in beta2
>> Perfect !!!
>> 
>> Let's go for a merge in trunk ??
>> 
>> Arnaud
>> 
>> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

the course of true love never did run smooth ...

 -- Shakespeare

Re: guice & memory usage was: (3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x)

[Tamás Cservenák <ta...@cservenak.net>]

Cool!

+1 for merges!


Thanks,
~t~

2010/8/18 Arnaud Héritier <ah...@gmail.com>

> Hi,
>
>  I just rebuilt aether and maven3 and I have now : 14M/125M
>  We are really near of 9M/125M we have in beta2
>  Perfect !!!
>
>  Let's go for a merge in trunk ??
>
> Arnaud
>
>

Re: guice & memory usage was: (3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x)

[Arnaud Héritier <ah...@gmail.com>]

Hi,

  I just rebuilt aether and maven3 and I have now : 14M/125M
  We are really near of 9M/125M we have in beta2
  Perfect !!!

  Let's go for a merge in trunk ??

Arnaud

On Aug 7, 2010, at 2:37 PM, Arnaud Héritier wrote:

> Results I had yesterday were :
> 
> 3.0-benjamin (built yesterday) : 14M/2488M in 5:23.389s (It probably swapped a lot)
> 3.0-beta-2 (downloaded few minutes ago) : 9M/125M built in 23.723s
> 2.2.1 : 67M/136M built in 30s
> 
> I only built one module : http://svn.exoplatform.org/projects/ecms/trunk/packaging/wcm/ear
> Its dependencies tree is horrible !
> 
> I used : MAVEN_OPTS = -Xshare:auto -Xms128M -Xmx4G -XX:MaxPermSize=256M
> (In theory Xmx = 1G but I increased it to 4G to fix the OOME)
> 
> To build it and reproduce the issue you need this repo : http://repository.exoplatform.org/public/ (releases & snapshots)
> 
> I will try to open the debugger this WE if I find few minutes.
> 
> On Aug 7, 2010, at 1:26 PM, Brett Porter wrote:
> 
>> 
>> On 07/08/2010, at 12: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 ran this over one of my builds out of curiosity. Not sure if this is helpful, but maybe some datapoints.
>> 
>> 3.0-benjamin => 73m / 252m
>> 3.0-beta-1 => 63m / 159m
>> 2.2.1 => 129m / 252m
>> 
>> Then I checked just the following:
>> 3.0-beta-2-SNAPSHOT + guice patch => 70m/218m
>> 3.0-beta-2-SNAPSHOT => 74m/252m
>> 
>> The numbers are quite consistent, so it looks like the problem might have been on trunk here, not the guice++ branch. Arnaud, is that also what you see with trunk?
>> 
>> I quickly ran the first two with Yourkit and saw that in Benjamin's branch, the memory grows faster at a consistent rate, but is still released at the end. The retained memory is only the classrealms and JDK ZIP cache, which basically is the same for beta-1. So more usage, but not a leak. No OOME, but perhaps the project is not big enough to exhibit it. 
>> 
>> Nothing to particularly note on the garbage collection front. The non-heap memory looks to be identical. Basically the same results running with a clean repository to do more artifact operations. Scanning the allocations, there's quite deep trees of allocations for Guice & the shim - but given the results for the other snapshots I'm not sure that's an issue itself.
>> 
>> That's all I had time for, but I'll hold onto the snapshots in case they help.
>> 
>> - Brett
>> 
>> --
>> Brett Porter
>> brett@apache.org
>> http://brettporter.wordpress.com/
>> 
>> 
>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

RE: guice & memory usage was: (3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x)

["Nord, James" <JN...@nds.com>]

>>
>> There's been little to no feedback on beta-2 so I honestly don't think it
>> matters.
> feedback from Maven developers was good: since people complain only when it
> does not work, I suppose no feedback = it works as good as for Maven
> developers.
>

I agree, I consider also the no feedback as good feedback because when it doesn't work we quickly have bad feedbacks.


[JN] An alternate reason is most people are on holiday in the northern hemisphere (at least it is a quiet time in Europe!)



**************************************************************************************
This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmaster@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.

NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00
**************************************************************************************

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: guice & memory usage was: (3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x)

[Arnaud Héritier <ah...@gmail.com>]

On Aug 18, 2010, at 10:47 PM, Hervé BOUTEMY wrote:

> Le mercredi 18 août 2010, Jason van Zyl a écrit :
>> On Aug 18, 2010, at 12:59 PM, Hervé BOUTEMY wrote:
>>> Le mercredi 18 août 2010, Arnaud Héritier a écrit :
>>>> It's always in GitHub or the merge started in trunk ?
>>> 
>>> BTW, we have 3.0-beta-2 released without Guice nor Aether and GitHub with
>>> both Guice and Aether.
>>> What about merging Guice in svn trunk, so we can test the 3 major steps:
>>> 3.0- beta-2, +Guice, +Aether?
>> 
>> There's been little to no feedback on beta-2 so I honestly don't think it
>> matters.
> feedback from Maven developers was good: since people complain only when it 
> does not work, I suppose no feedback = it works as good as for Maven 
> developers.
> 

I agree, I consider also the no feedback as good feedback because when it doesn't work we quickly have bad feedbacks.

>> Put everything in that we plan ship and release it. If you want
>> an incremental build that is separate that's probably fine to make
>> comparisons easier,
> yes, that's the idea.
> 
>> but the world at large doesn't care.
> it's august, a lot of people are on vacation.
> I suppose there will can be more feedback in september.

I'm now enough confident in benjamin's branch to merge 2 patchs quickly in trunk and push out a beta 3

> 
>> 
>> Let's merge it all in, try and get 3.0 out the door.
> we're all impatient

YEAHHHH

> 
> Regards,
> 
> Hervé
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: guice & memory usage was: (3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x)

[Hervé BOUTEMY <he...@free.fr>]

Le mercredi 18 août 2010, Jason van Zyl a écrit :
> On Aug 18, 2010, at 12:59 PM, Hervé BOUTEMY wrote:
> > Le mercredi 18 août 2010, Arnaud Héritier a écrit :
> >> It's always in GitHub or the merge started in trunk ?
> > 
> > BTW, we have 3.0-beta-2 released without Guice nor Aether and GitHub with
> > both Guice and Aether.
> > What about merging Guice in svn trunk, so we can test the 3 major steps:
> > 3.0- beta-2, +Guice, +Aether?
> 
> There's been little to no feedback on beta-2 so I honestly don't think it
> matters.
feedback from Maven developers was good: since people complain only when it 
does not work, I suppose no feedback = it works as good as for Maven 
developers.

> Put everything in that we plan ship and release it. If you want
> an incremental build that is separate that's probably fine to make
> comparisons easier,
yes, that's the idea.

> but the world at large doesn't care.
it's august, a lot of people are on vacation.
I suppose there will can be more feedback in september.

> 
> Let's merge it all in, try and get 3.0 out the door.
we're all impatient

Regards,

Hervé

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: guice & memory usage was: (3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x)

[Jochen Wiedmann <jo...@gmail.com>]

On Wed, Aug 18, 2010 at 10:10 PM, Jason van Zyl <ja...@sonatype.com> wrote:

> There's been little to no feedback on beta-2 so I honestly don't think it matters.

That's good news, isn't it? :-)



-- 
I Am What I Am And That's All What I Yam (Popeye)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: guice & memory usage was: (3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x)

[Mark Derricutt <ma...@talios.com>]

I'd love to offer more feedback on beta-2, but since it totally breaks our
builds it's a non-starter.  Without reworking our entire build setup ( which
we're going to do anyway when we move to git ) M3 is effectively unusable
for my main $work project.

Which is a shame as all the new things look great.

-- 
Pull me down under...



On Thu, Aug 19, 2010 at 8:10 AM, Jason van Zyl <ja...@sonatype.com> wrote:

> There's been little to no feedback on beta-2 so I honestly don't think it
> matters. Put everything in that we plan ship and release it. If you want an
> incremental build that is separate that's probably fine to make comparisons
> easier, but the world at large doesn't care.

Re: guice & memory usage was: (3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x)

[Jason van Zyl <ja...@sonatype.com>]

On Aug 18, 2010, at 12:59 PM, Hervé BOUTEMY wrote:

> Le mercredi 18 août 2010, Arnaud Héritier a écrit :
>> It's always in GitHub or the merge started in trunk ?
> BTW, we have 3.0-beta-2 released without Guice nor Aether and GitHub with both 
> Guice and Aether.
> What about merging Guice in svn trunk, so we can test the 3 major steps: 3.0-
> beta-2, +Guice, +Aether?
> 

There's been little to no feedback on beta-2 so I honestly don't think it matters. Put everything in that we plan ship and release it. If you want an incremental build that is separate that's probably fine to make comparisons easier, but the world at large doesn't care.

Let's merge it all in, try and get 3.0 out the door.

> Regards,
> 
> Hervé
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

People develop abstractions by generalizing from concrete examples.
Every attempt to determine the correct abstraction on paper without
actually developing a running system is doomed to failure. No one
is that smart. A framework is a resuable design, so you develop it by
looking at the things it is supposed to be a design of. The more examples
you look at, the more general your framework will be.

  -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks 

Re: guice & memory usage was: (3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x)

[Hervé BOUTEMY <he...@free.fr>]

Le mercredi 18 août 2010, Arnaud Héritier a écrit :
> It's always in GitHub or the merge started in trunk ?
BTW, we have 3.0-beta-2 released without Guice nor Aether and GitHub with both 
Guice and Aether.
What about merging Guice in svn trunk, so we can test the 3 major steps: 3.0-
beta-2, +Guice, +Aether?

Regards,

Hervé

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: guice & memory usage was: (3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x)

[Benjamin Bentmann <be...@udo.edu>]

Arnaud Héritier wrote:

> It's always in GitHub or the merge started in trunk ?

It's still in github.

> I'll try to build and test it this evening.

Cool, thanks!


Benjamin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: guice & memory usage was: (3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x)

[Arnaud Héritier <ah...@gmail.com>]

It's always in GitHub or the merge started in trunk ?
I'll try to build and test it this evening.
Thx


On Aug 18, 2010, at 1:59 PM, Benjamin Bentmann wrote:

> Arnaud Héritier wrote:
> 
>> 3.0-benjamin (built yesterday) : 14M/2488M in 5:23.389s (It probably swapped a lot)
> 
> Should be fixed now, would be cool if you could double-check when time allows.
> 
> 
> Benjamin
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: guice & memory usage was: (3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x)

[Benjamin Bentmann <be...@udo.edu>]

Arnaud Héritier wrote:

> 3.0-benjamin (built yesterday) : 14M/2488M in 5:23.389s (It probably swapped a lot)

Should be fixed now, would be cool if you could double-check when time 
allows.


Benjamin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: guice & memory usage was: (3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x)

[Arnaud Héritier <ah...@gmail.com>]

Results I had yesterday were :

3.0-benjamin (built yesterday) : 14M/2488M in 5:23.389s (It probably swapped a lot)
3.0-beta-2 (downloaded few minutes ago) : 9M/125M built in 23.723s
2.2.1 : 67M/136M built in 30s

I only built one module : http://svn.exoplatform.org/projects/ecms/trunk/packaging/wcm/ear
Its dependencies tree is horrible !

I used : MAVEN_OPTS = -Xshare:auto -Xms128M -Xmx4G -XX:MaxPermSize=256M
(In theory Xmx = 1G but I increased it to 4G to fix the OOME)

To build it and reproduce the issue you need this repo : http://repository.exoplatform.org/public/ (releases & snapshots)

I will try to open the debugger this WE if I find few minutes.

On Aug 7, 2010, at 1:26 PM, Brett Porter wrote:

> 
> On 07/08/2010, at 12: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 ran this over one of my builds out of curiosity. Not sure if this is helpful, but maybe some datapoints.
> 
> 3.0-benjamin => 73m / 252m
> 3.0-beta-1 => 63m / 159m
> 2.2.1 => 129m / 252m
> 
> Then I checked just the following:
> 3.0-beta-2-SNAPSHOT + guice patch => 70m/218m
> 3.0-beta-2-SNAPSHOT => 74m/252m
> 
> The numbers are quite consistent, so it looks like the problem might have been on trunk here, not the guice++ branch. Arnaud, is that also what you see with trunk?
> 
> I quickly ran the first two with Yourkit and saw that in Benjamin's branch, the memory grows faster at a consistent rate, but is still released at the end. The retained memory is only the classrealms and JDK ZIP cache, which basically is the same for beta-1. So more usage, but not a leak. No OOME, but perhaps the project is not big enough to exhibit it. 
> 
> Nothing to particularly note on the garbage collection front. The non-heap memory looks to be identical. Basically the same results running with a clean repository to do more artifact operations. Scanning the allocations, there's quite deep trees of allocations for Guice & the shim - but given the results for the other snapshots I'm not sure that's an issue itself.
> 
> That's all I had time for, but I'll hold onto the snapshots in case they help.
> 
> - Brett
> 
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: guice & memory usage was: (3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x)

[Jason van Zyl <ja...@sonatype.com>]

On Aug 7, 2010, at 7:26 AM, Brett Porter wrote:

> 
> On 07/08/2010, at 12: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 ran this over one of my builds out of curiosity. Not sure if this is helpful, but maybe some datapoints.
> 
> 3.0-benjamin => 73m / 252m
> 3.0-beta-1 => 63m / 159m
> 2.2.1 => 129m / 252m
> 
> Then I checked just the following:
> 3.0-beta-2-SNAPSHOT + guice patch => 70m/218m
> 3.0-beta-2-SNAPSHOT => 74m/252m
> 
> The numbers are quite consistent, so it looks like the problem might have been on trunk here, not the guice++ branch. Arnaud, is that also what you see with trunk?
> 
> I quickly ran the first two with Yourkit and saw that in Benjamin's branch, the memory grows faster at a consistent rate, but is still released at the end. The retained memory is only the classrealms and JDK ZIP cache, which basically is the same for beta-1. So more usage, but not a leak. No OOME, but perhaps the project is not big enough to exhibit it. 
> 
> Nothing to particularly note on the garbage collection front. The non-heap memory looks to be identical. Basically the same results running with a clean repository to do more artifact operations. Scanning the allocations, there's quite deep trees of allocations for Guice & the shim - but given the results for the other snapshots I'm not sure that's an issue itself.
> 

Yes, we believe there are no GC or leakage issues with the Aether it is the dirty tree which is memory intensive and it's that structure we are trying to compact. The performance framework found the intense memory use instantly. It was reduced and now we're thinking of trying to use a graph structure for the dirty tree. We're not sure if this will work or not yet.

> That's all I had time for, but I'll hold onto the snapshots in case they help.
> 
> - Brett
> 
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

Three people can keep a secret provided two of them are dead.

 -- Unknown

Re: guice & memory usage was: (3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x)

[Brett Porter <br...@apache.org>]

On 07/08/2010, at 12: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 ran this over one of my builds out of curiosity. Not sure if this is helpful, but maybe some datapoints.

3.0-benjamin => 73m / 252m
3.0-beta-1 => 63m / 159m
2.2.1 => 129m / 252m

Then I checked just the following:
3.0-beta-2-SNAPSHOT + guice patch => 70m/218m
3.0-beta-2-SNAPSHOT => 74m/252m

The numbers are quite consistent, so it looks like the problem might have been on trunk here, not the guice++ branch. Arnaud, is that also what you see with trunk?

I quickly ran the first two with Yourkit and saw that in Benjamin's branch, the memory grows faster at a consistent rate, but is still released at the end. The retained memory is only the classrealms and JDK ZIP cache, which basically is the same for beta-1. So more usage, but not a leak. No OOME, but perhaps the project is not big enough to exhibit it. 

Nothing to particularly note on the garbage collection front. The non-heap memory looks to be identical. Basically the same results running with a clean repository to do more artifact operations. Scanning the allocations, there's quite deep trees of allocations for Guice & the shim - but given the results for the other snapshots I'm not sure that's an issue itself.

That's all I had time for, but I'll hold onto the snapshots in case they help.

- Brett

--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Christian Edward Gruber <ch...@gmail.com>]

I think user issues can be addressed with some naming magic.  Instead  
of 3.0-beta2 and 3.0-beta3, go with 3.0-beta2, and 3.0-beta2a

It's still "forward", and it implies that they're similar or related  
versions, and the notes/announce on it can be clear, but it won't  
carry the implication that beta3 is the new hotness and expected bug- 
fixes on the road to release, but it's something else.  Even if that  
just spurs questions, it's the right questions.

Or something else, but not naming them with the same normal sequential  
jump is a slightly more meaningful signal.

I'm +1 on the plan of two releases, though, as it does make end-users  
who are testing the releases have a lower burden to validate error.

Christian.


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.
>
> 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 <ah...@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-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Paul Benedict <pb...@apache.org>]

You could also cut beta-2 today and just not release it. Move on to beta-3
immediately to merge. If the merge turns out to be a disaster, at least you
have a branch and an artifact to deploy as a backup plan. Regardless, I
don't expect anything to go tragically wrong.

>From my perspective of a Release Manager, milestones should have defined
boundaries. Throwing in Guice/Aether at the end of the beta smells to me.
There is always risk involved when importing a huge chunk of code no matter
how much testing it has.

I believe this discussion is merely about risk assessment. It looks like the
committers prefer a more conservative approach.

Paul

On Fri, Aug 6, 2010 at 9:53 AM, Jason van Zyl <ja...@sonatype.com> 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 <ah...@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-unsubscribe@maven.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@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
>
>
>
>

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Henri Gomez <he...@gmail.com>]

Point of vue of a Maven user :

We need to have a new beta release, ie beta-2 since the beta-1 is now
3/4 months old and Maven 2.2.1 is one year old.

This will help us show our co-workers and may be more important, our
IT managers, that Maven 3.0 progress.
They didn't follow maven-dev list and only knowns about Maven release
(including beta).

And as a bonus, it will allow more time and testing for the beta-3
with Aether and Guice.

Regards

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Paul Benedict <pb...@apache.org>]

I think it would be helpful if two JIRA tickets were created for the
separate integrations. This way, people can track and report back on any
issues they find -- plus know what release it planned for. I, being a
bystander who watches the development, I did not know these two things were
planned.

Paul

On Fri, Aug 6, 2010 at 11:05 AM, Jason van Zyl <ja...@sonatype.com> wrote:

>
> On Aug 6, 2010, at 11:54 AM, Brett Porter wrote:
>
> >
> > On 07/08/2010, at 1:22 AM, Brian Fox wrote:
> >
> >> I'm not so concerned about confusing users with a beta2 and then a
> >> beta3, that can be mitigated easily in the announcement. More releases
> >> won't hurt anyone.
> >>
> >> Let those working on it decide what to do and when presented with a
> >> vote, I'll test, verify and vote accordingly, regardless of if it's
> >> beta2 with or without Aether/Guice.  I would just rather see one
> >> sooner rather then later. We too often have a tendency of waiting for
> >> everything to be perfect. They are betas, pick one and stage it I say.
> >
> > +1 to that
> >
> > Not to extend the thread too much further, but I'd still like to see
> someone answer my questions about the impact of changing the project's scope
> by moving the artifact implementation to Aether before that lands anyway.
> We've had a lot more time to ponder Guice.
> >
> > 1) is there any alternative that would keep what we have today - the
> Maven implementation and API for Maven plugin developers - within the Maven
> project, while still allowing Jason's desire to involve more people in an
> expanded effort?
> >
>
> The current Plugin API is not changed at all. We didn't change any of the
> plugin code. No impact on plugin developers. A new API is a different story
> and that will be far more powerful with JSR330 and Aether.
>
> No one is going to work on the Maven implementation, that is clear from the
> sheer lack of neglect over the last 3 years. No one is magically going to
> start working on this. That much is clear.
>
> > 2) either way, what API are we expecting plugin developers to use for
> artifact resolution in Maven 3?
>
> They can use what exists now. We didn't alter any plugins. I imagine we
> will have to support the old API forever.
>
> > If it is Aether, what is the impact to plugin developers if the
> interfaces change after 3.0
>
> Pretty much zero, plugins that exist today run without change. There are a
> couple gotchas but nothing major.
>
> > , or if it moves to Eclipse (or even back to Apache) and changes
> packaging again?
> >
>
> Aether is the library, and what should happen to prevent API leakage is
> that if a new Plugin API is developed that it prevent leakage this time and
> nothing will be couched in terms of Aether directly. That was a mistake with
> the current code and with Wagon. What is used now in terms of API we've
> tried to support to the best of our ability and there's no reason it can't
> remain indefinitely. Any new JSR330-based API for plugins should attempt to
> prevent API leakage.
>
> > I'm still having trouble understanding the dichotomy between an project
> intended to evolve rapidly, and wanting to include that in a project
> (hopefully) nearing release which will be used for years.
> >
>
> You do it by maintaining APIs which we have attempted to do.
>
> > Thanks,
> > Brett
> >
> > --
> > Brett Porter
> > brett@apache.org
> > http://brettporter.wordpress.com/
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> We know what we are, but know not what we may be.
>
>  -- Shakespeare
>
>
>
>

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Jason van Zyl <ja...@sonatype.com>]

On Aug 8, 2010, at 9:17 PM, Brett Porter wrote:

> 
> On 09/08/2010, at 10:55 AM, Jason van Zyl wrote:
> 
>>>> 
>>>> So I refute this with an act by Kristian today which was to sign the Sonatype CLA, sign up for the mailing list, asked for access to the wiki, already has access and has been working with Benjamin. You'll also notice he hasn't participated in this discussion at all he's just doing. So I completely disagree there is any real pain, just a general unwillingness to attempt anything different. So you can spend 15 minutes telling me how hard it is to get involved or spend 15 minutes getting involved like Kristian just did. 
>>> 
>>> You mean like spending 15 minutes seeing if I could replicate Arnaud's results? I'm one of the few who has invested the time to try and track any artifact work over the last few years, and I don't really appreciate my commitment being called into question.
>>> 
>> 
>> That's not what I meant at all. I'm not sure how you're coming up with that interpretation. I'm saying it's not hard for people to participate. Kristian demonstrated. I thought you were talking about people contributing in general not yourself. I wasn't talking about you specifically.
> 
> "So you can spend 15 minutes telling me how hard it is to get involved or spend 15 minutes getting involved" was what I interpreted as that.
> 

I meant you as in any person, I know you don't have a problem finding issue tracking systems.

>> 
>>> As for signing the Sonatype CLA:
>>> "Sonatype requires that you assign the intellectual property rights in your contribution to Sonatype (with a license back to you to use it in any way you please)."
>>> 
>>> No thanks.
>>> 
>> 
>> If we want to move anything to Eclipse, then we need to be able to give them everything. We've already set a precedent by doing this with Tycho. We just turned around and assigned everything to them.
> 
> I know why you need to, but I don't like the other options it also gives you. Not sure where that leaves anyone that has an assignment agreement with their employer.
> 

In practice for a product or project at Sonatype if you don't want to sign it we won't risk taking anyone's code. We tried to make one agreement, the onus is on the contributor. When code we know will move on to Eclipse the Foundation insists on individual and employer agreements or more generally I let Eclipse deal with it. 

> Anyway, that's getting out of scope for this list.
> 
> - Brett
> 
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people. 

 -- Paul Graham

Re: copyright assignment (off-topic)

[Jason van Zyl <ja...@sonatype.com>]

On Aug 9, 2010, at 9:56 AM, Brett Porter wrote:

> An interesting read just popped up on twitter as I got this mail: http://www.h-online.com/open/features/Copyright-assignment-Once-bitten-twice-shy-1049631.html (points both for and against, including "I want to spend my spare time coding, not doing paperwork" :)
> 
> On 09/08/2010, at 9:53 PM, Jason van Zyl wrote:
> 
>> It's a nice gesture but in practical terms what are you really going to do with your portion of the copyrighted code?
> 
> In the context of that article, the answer was to not allow $BIGCO to use the work in a way that wasn't intended (eg. non-free).
> 

I honestly don't see how that changes anything because it's the license that is going to prevent that. Doesn't have anything to do with copyright. There's no real practical way $BIGCO could get copyright assignment to change the license in order to subvert the existing license.

> - Brett
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

believe nothing, no matter where you read it,
or who has said it,
not even if i have said it,
unless it agrees with your own reason
and your own common sense.

 -- Buddha

Re: copyright assignment (off-topic)

[Brett Porter <br...@apache.org>]

An interesting read just popped up on twitter as I got this mail: http://www.h-online.com/open/features/Copyright-assignment-Once-bitten-twice-shy-1049631.html (points both for and against, including "I want to spend my spare time coding, not doing paperwork" :)

On 09/08/2010, at 9:53 PM, Jason van Zyl wrote:

> It's a nice gesture but in practical terms what are you really going to do with your portion of the copyrighted code?

In the context of that article, the answer was to not allow $BIGCO to use the work in a way that wasn't intended (eg. non-free).

- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Jason van Zyl <ja...@sonatype.com>]

On Aug 8, 2010, at 11:34 PM, Brett Porter wrote:

> 
> On 09/08/2010, at 12:39 PM, Mark Derricutt wrote:
> 
>> Wouldn't this have the same problem with Apache based code?  Doesn't the
>> Apache Contributor agreements say you assigned copyright over to Apache?
> 
> No, it doesn't.
> 

It is a grant not assignment, clause 2 of the CLA[1]. So the ASF owns the copyright over the whole body of code by each individual contributor granting copyright, but the individual still retains copyright of their own submissions. It's a nice gesture but in practical terms what are you really going to do with your portion of the copyrighted code?

At Eclipse there is no grant or assignment of copyright. The effect is that once the code is EPL, done by the initial submission of the code to the Eclipse Foundation, it is in practical terms impossible to relicense. The code could be forked or extended but it's going to be very hard to relicense it. Unless you wanted to track down every contributor to get an grant/assignment of copyright which would be required to perform said relicensing.

At Apache the contributor and the ASF are owners of the submission. At Eclipse the contributor retains ownership[2]. At Sonatype we honestly take a defensive posture and ask for everything. If it's for a product like Nexus we don't want there to be any question and we're not going to take any changes without full assignment. If you don't like it you don't have to contribute. If it's for something like Tycho, of M2E, or Aether that we incubate at Sonatype for a year we don't want to have to go track down everyone for a copyright assignment in order to relicense the code. This would also be the case if for something like Nexus we wanted to go from the GPL to EPL which is something we are considering.

[1]: http://www.apache.org/licenses/icla.txt
[2]: http://www.eclipse.org/legal/eplfaq.php#USEINANOTHER

> - Brett
> 
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

A party which is not afraid of letting culture,
business, and welfare go to ruin completely can
be omnipotent for a while.

  -- Jakob Burckhardt

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Brett Porter <br...@apache.org>]

On 09/08/2010, at 12:39 PM, Mark Derricutt wrote:

> Wouldn't this have the same problem with Apache based code?  Doesn't the
> Apache Contributor agreements say you assigned copyright over to Apache?

No, it doesn't.

- Brett

--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Mark Derricutt <ma...@talios.com>]

Wouldn't this have the same problem with Apache based code?  Doesn't the
Apache Contributor agreements say you assigned copyright over to Apache?

As you say - out of scope for the list.  I'll take my answer off-list (mmm,
sounds like a talk back radio caller!).

-- 
Pull me down under...

On Mon, Aug 9, 2010 at 1:17 PM, Brett Porter <br...@apache.org> wrote:

> I know why you need to, but I don't like the other options it also gives
> you. Not sure where that leaves anyone that has an assignment agreement with
> their employer.

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Brett Porter <br...@apache.org>]

On 09/08/2010, at 10:55 AM, Jason van Zyl wrote:

>>> 
>>> So I refute this with an act by Kristian today which was to sign the Sonatype CLA, sign up for the mailing list, asked for access to the wiki, already has access and has been working with Benjamin. You'll also notice he hasn't participated in this discussion at all he's just doing. So I completely disagree there is any real pain, just a general unwillingness to attempt anything different. So you can spend 15 minutes telling me how hard it is to get involved or spend 15 minutes getting involved like Kristian just did. 
>> 
>> You mean like spending 15 minutes seeing if I could replicate Arnaud's results? I'm one of the few who has invested the time to try and track any artifact work over the last few years, and I don't really appreciate my commitment being called into question.
>> 
> 
> That's not what I meant at all. I'm not sure how you're coming up with that interpretation. I'm saying it's not hard for people to participate. Kristian demonstrated. I thought you were talking about people contributing in general not yourself. I wasn't talking about you specifically.

"So you can spend 15 minutes telling me how hard it is to get involved or spend 15 minutes getting involved" was what I interpreted as that.

> 
>> As for signing the Sonatype CLA:
>> "Sonatype requires that you assign the intellectual property rights in your contribution to Sonatype (with a license back to you to use it in any way you please)."
>> 
>> No thanks.
>> 
> 
> If we want to move anything to Eclipse, then we need to be able to give them everything. We've already set a precedent by doing this with Tycho. We just turned around and assigned everything to them.

I know why you need to, but I don't like the other options it also gives you. Not sure where that leaves anyone that has an assignment agreement with their employer.

Anyway, that's getting out of scope for this list.

- Brett

--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Jason van Zyl <ja...@sonatype.com>]

On Aug 8, 2010, at 8:18 PM, Brett Porter wrote:

> 
> On 07/08/2010, at 9:47 PM, Jason van Zyl wrote:
> 
>> 
>> On Aug 7, 2010, at 1:44 AM, Brett Porter wrote:
>> 
>>> 
>>>> 
>>>> Unavoidable. We're not going to bring in everyone other dependency and any developer worth their salt can figure out how to pull in sources for dependent projects. Aether is all JIRA and Confluence it's not a big leap for anyone here. The barrier is not and never will be the infrastructure, it's people's time and willingness to contribute.
>>>> 
>>> 
>>> I continue to disagree. Time/willingess is #1, but the pain of tracking two of everything takes away from the time and willingness one has. We've seen it too many times before.
>>> 
>>> 
>> 
>> So I refute this with an act by Kristian today which was to sign the Sonatype CLA, sign up for the mailing list, asked for access to the wiki, already has access and has been working with Benjamin. You'll also notice he hasn't participated in this discussion at all he's just doing. So I completely disagree there is any real pain, just a general unwillingness to attempt anything different. So you can spend 15 minutes telling me how hard it is to get involved or spend 15 minutes getting involved like Kristian just did. 
> 
> You mean like spending 15 minutes seeing if I could replicate Arnaud's results? I'm one of the few who has invested the time to try and track any artifact work over the last few years, and I don't really appreciate my commitment being called into question.
> 

That's not what I meant at all. I'm not sure how you're coming up with that interpretation. I'm saying it's not hard for people to participate. Kristian demonstrated. I thought you were talking about people contributing in general not yourself. I wasn't talking about you specifically.

> As for signing the Sonatype CLA:
> "Sonatype requires that you assign the intellectual property rights in your contribution to Sonatype (with a license back to you to use it in any way you please)."
> 
> No thanks.
> 

If we want to move anything to Eclipse, then we need to be able to give them everything. We've already set a precedent by doing this with Tycho. We just turned around and assigned everything to them.

> In all of the above, if it had been here, Kristian could have saved himself the 15 minutes. But it's the ongoing cost I'm concerned about - stuff like tracking issues and dealing with external snapshots. I've already said all I can on it.
> 
> I'm not unwilling to attempt something different. I'd be happy to explore ways we could make development at Apache more open to external contributions. I would be in favour of a low barrier to entry to people committing on things where we know we need help, particularly when we already know of some existing merit in the area.
> 
> - Brett
> 
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

People develop abstractions by generalizing from concrete examples.
Every attempt to determine the correct abstraction on paper without
actually developing a running system is doomed to failure. No one
is that smart. A framework is a resuable design, so you develop it by
looking at the things it is supposed to be a design of. The more examples
you look at, the more general your framework will be.

  -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks 

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Brett Porter <br...@apache.org>]

On 07/08/2010, at 9:47 PM, Jason van Zyl wrote:

> 
> On Aug 7, 2010, at 1:44 AM, Brett Porter wrote:
> 
>> 
>>> 
>>> Unavoidable. We're not going to bring in everyone other dependency and any developer worth their salt can figure out how to pull in sources for dependent projects. Aether is all JIRA and Confluence it's not a big leap for anyone here. The barrier is not and never will be the infrastructure, it's people's time and willingness to contribute.
>>> 
>> 
>> I continue to disagree. Time/willingess is #1, but the pain of tracking two of everything takes away from the time and willingness one has. We've seen it too many times before.
>> 
>> 
> 
> So I refute this with an act by Kristian today which was to sign the Sonatype CLA, sign up for the mailing list, asked for access to the wiki, already has access and has been working with Benjamin. You'll also notice he hasn't participated in this discussion at all he's just doing. So I completely disagree there is any real pain, just a general unwillingness to attempt anything different. So you can spend 15 minutes telling me how hard it is to get involved or spend 15 minutes getting involved like Kristian just did. 

You mean like spending 15 minutes seeing if I could replicate Arnaud's results? I'm one of the few who has invested the time to try and track any artifact work over the last few years, and I don't really appreciate my commitment being called into question.

As for signing the Sonatype CLA:
"Sonatype requires that you assign the intellectual property rights in your contribution to Sonatype (with a license back to you to use it in any way you please)."

No thanks.

In all of the above, if it had been here, Kristian could have saved himself the 15 minutes. But it's the ongoing cost I'm concerned about - stuff like tracking issues and dealing with external snapshots. I've already said all I can on it.

I'm not unwilling to attempt something different. I'd be happy to explore ways we could make development at Apache more open to external contributions. I would be in favour of a low barrier to entry to people committing on things where we know we need help, particularly when we already know of some existing merit in the area.

- Brett

--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Jason van Zyl <ja...@sonatype.com>]

On Aug 7, 2010, at 1:44 AM, Brett Porter wrote:

> 
>> 
>> Unavoidable. We're not going to bring in everyone other dependency and any developer worth their salt can figure out how to pull in sources for dependent projects. Aether is all JIRA and Confluence it's not a big leap for anyone here. The barrier is not and never will be the infrastructure, it's people's time and willingness to contribute.
>> 
> 
> I continue to disagree. Time/willingess is #1, but the pain of tracking two of everything takes away from the time and willingness one has. We've seen it too many times before.
> 
> 

So I refute this with an act by Kristian today which was to sign the Sonatype CLA, sign up for the mailing list, asked for access to the wiki, already has access and has been working with Benjamin. You'll also notice he hasn't participated in this discussion at all he's just doing. So I completely disagree there is any real pain, just a general unwillingness to attempt anything different. So you can spend 15 minutes telling me how hard it is to get involved or spend 15 minutes getting involved like Kristian just did. 

> Thanks,
> Brett
> 
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

We know what we are, but know not what we may be.

  -- Shakespeare

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Jason van Zyl <ja...@sonatype.com>]

On Aug 7, 2010, at 1:44 AM, Brett Porter wrote:

> 
> 
> And doesn't that show that you could have done the same thing with Aether? :)
> 

Could happen with anything, it's only dependent on what people do. 

>>> It is not an easily reversible step, and I want to ensure that anyone that wants to get an improvement into Maven doesn't have to navigate the different controls and infrastructure of another project.
>> 
>> Unavoidable. We're not going to bring in everyone other dependency and any developer worth their salt can figure out how to pull in sources for dependent projects. Aether is all JIRA and Confluence it's not a big leap for anyone here. The barrier is not and never will be the infrastructure, it's people's time and willingness to contribute.
>> 
> 
> I continue to disagree. Time/willingess is #1, but the pain of tracking two of everything takes away from the time and willingness one has. We've seen it too many times before.

Then we can agree to disagree. It's not going to stop anyone who starts with doing and not talking and it's pretty much all avoided by spending 5 minutes talking to someone on IRC. It's not a big deal. I will always stand by the reasoning that good tooling is the only true solution to breaking down the barriers. Any contributor should be guided to do the right thing.

> 
>>> I lived through the worst of it in Maven 2.0/Plexus/Modello/etc. and it drove me crazy.
>> 
>> It's no different now. We still have Modello and now Guice which none of you have any control over. We are very fortunate to have Stuart working with us at Sonatype who is a committer but by your measure this is worse. Totally different infrastructure and no access.
> 
> Guice is an improvement because it reduces our exposure. Guice itself is a fairly known quantity, so we may only have to deal with issues in the shim or the rare one in Guice, not having to maintain all of plexus. I went through exactly the same thing with the plexus-spring bridge in Archiva, and it made things much easier (and I hope we might consider using the guice bridge there too). I expect us to work at improving the Maven APIs to use Guice directly, but other than that the hard work has been done (thanks!). There's no reason for Maven to need to make significant enhancements to the underlying stuff in the future.
> 
> Aether would be a completely different story. Any time an MNG issue could be filed that means I need to file an AETHER issue, I consider that a problem. Apart from the next few weeks, I think that'll be rare for the shim. It's probably 1/3rd of open MNG issues for Aether though.
> 

I think this is the nature of the old code, and Aether will be more like Guice. Aether and it will just fade into the background like anything else. Anyone can find an excuse not to do something. If there are 5 people contributing to Aether by the end of the year I'll be ecstatic. I don't think issue tracking systems are the barrier, it's just hard code to write.

> Moving on, it seems you've answered my technical concerns from a Maven3 PoV, so I'm not objecting to this landing on trunk as is.
> 
> I'll repeat that I remain reluctant to see an important part of the project's scope heading out of its governance. I can't force it to happen, but I'd again strongly urge you to reconsider hosting the core part as a subproject here (and by all means bring Alin on board as the other main contributor to it so far). I would gladly help with that. Continue to use github and whatever else forked from that repo to work on improvements that aren't important to Maven with others. If in the future it starts to shape like something that is quite stable from Maven's point of view, and the scope outgrowing it, then graduate to a TLP, Eclipse, or wherever seems appropriate.
> 
> I know the tone of this thread in parts hasn't been particularly helpful and maybe isn't conducive to wanting to do that. A lot of that is knee-jerk stuff that should die down moving forward as people get on with it. I could be wrong, but I still think that if you ran a poll of committers who have a stake in Maven3 development, you'd find a preference for hosting it here. If I'm right, I think that's worth taking into consideration.

If it does not flourish outside of Apache, then I honestly won't have a preference. But I believe it will and just because some of you don't like it doesn't mean I should have to kill the experiment. One of the reasons I don't want it here is pure lack of involvement and I do not think that can all be dropped at my feet and what Sonatype has or hasn't done. If after six months it's all people from Maven contributing and no one else I will admit I thought wrong and happily push it back here. Hervé is already participating on the Aether dev list and I encourage others to do the same.

> 
> Thanks,
> Brett
> 
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

You are never dedicated to something you have complete confidence in.
No one is fanatically shouting that the sun is going to rise tomorrow.
They know it is going to rise tomorrow. When people are fanatically
dedicated to political or religious faiths or any other kind of 
dogmas or goals, it's always because these dogmas or
goals are in doubt.

  -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Brett Porter <br...@apache.org>]

On 07/08/2010, at 1:23 PM, Jason van Zyl wrote:

> 
> Ideally there should be no API leakage from Aether. As part of the plugin API we should provide access to whatever resolution functionality we feel is necessary to expose and hide Aether. Initially a few attempts are likely needed and I might try using the Aether API directly. I honestly don't think using Aether APIs directly would be a great idea and really I think we exposed way too much previously. It boils down to answering the question: what do plugin developers actually need? Walk the dirty tree, walk the resolved graph, filter, I don't know yet. Maybe I'm wrong and this might just end up being the complete replication of the Aether API at which point I don't know if it makes sense to try and hide it. This is why we preserved the use of the old API because this stuff just takes a while to figure out. Even us working full-tilt it's taken a while. I would like to limit drastically what's in the plugin API for dealing with artifact resolution.

Ok, that's making more sense. So it's still hidden behind the old resolver APIs. In future versions, we offer a Maven API to expose whatever is used internally that is more capable of some of its features. If a plugin developer is not satisfied that might code against aether directly, and that would be completely decoupled from the Maven version, reresolve, etc.

That's my main concern from a 3.0 PoV.

> 
>> Other new features have been stalled waiting for a 2.1/3.0 release so that we can change the POM to properly utilise them. Any attempt to fix bugs would have been fruitless because there was always another thing out there that was going to replace the current code - in fact I've been trying to get you to open up your declared plans on artifact handling since we met at JavaOne in 2007. I can think of a handful of committers here that had a crack at Mercury and ultimately had their time wasted on a moving target.
> 
> Sorry, but I think that's nonsense. Oleg was not locked in a vault. If someone actually worked faster then us and implemented something we stated we were going to do I would have been fine with it.

It should never be a race to a concurrent working implementation. Circumstances and frustration were at play in that, but I felt like I did what I could to get involved in Mercury. But anyway that's history, I just wanted to illustrate why a lack of activity here is not always that clear-cut.

> But I don't think anyone actually understands how much work it is. I don't know how exactly things are going to look ultimately but in the case of Aether we just went nuts for 8 weeks. The sequence of events was probably required. I didn't know how hard it would be and it proved to be hard. I honestly don't think design by committee works for this stuff.

I don't disagree at all.

> Much like parallel builds, it just drops out from a couple people doing a lot of work and then there's something to look at. Dan dropped in the first implementation and he just did it. No one much batted an eyelash. Kristian then picked it up. After looking at Aether I think people will agree it's the best starting place we've had. Nothing is perfect, but I think it's a good place to start.

And doesn't that show that you could have done the same thing with Aether? :)

>> It is not an easily reversible step, and I want to ensure that anyone that wants to get an improvement into Maven doesn't have to navigate the different controls and infrastructure of another project.
> 
> Unavoidable. We're not going to bring in everyone other dependency and any developer worth their salt can figure out how to pull in sources for dependent projects. Aether is all JIRA and Confluence it's not a big leap for anyone here. The barrier is not and never will be the infrastructure, it's people's time and willingness to contribute.
> 

I continue to disagree. Time/willingess is #1, but the pain of tracking two of everything takes away from the time and willingness one has. We've seen it too many times before.

>> I lived through the worst of it in Maven 2.0/Plexus/Modello/etc. and it drove me crazy.
> 
> It's no different now. We still have Modello and now Guice which none of you have any control over. We are very fortunate to have Stuart working with us at Sonatype who is a committer but by your measure this is worse. Totally different infrastructure and no access.

Guice is an improvement because it reduces our exposure. Guice itself is a fairly known quantity, so we may only have to deal with issues in the shim or the rare one in Guice, not having to maintain all of plexus. I went through exactly the same thing with the plexus-spring bridge in Archiva, and it made things much easier (and I hope we might consider using the guice bridge there too). I expect us to work at improving the Maven APIs to use Guice directly, but other than that the hard work has been done (thanks!). There's no reason for Maven to need to make significant enhancements to the underlying stuff in the future.

Aether would be a completely different story. Any time an MNG issue could be filed that means I need to file an AETHER issue, I consider that a problem. Apart from the next few weeks, I think that'll be rare for the shim. It's probably 1/3rd of open MNG issues for Aether though.

Moving on, it seems you've answered my technical concerns from a Maven3 PoV, so I'm not objecting to this landing on trunk as is.

I'll repeat that I remain reluctant to see an important part of the project's scope heading out of its governance. I can't force it to happen, but I'd again strongly urge you to reconsider hosting the core part as a subproject here (and by all means bring Alin on board as the other main contributor to it so far). I would gladly help with that. Continue to use github and whatever else forked from that repo to work on improvements that aren't important to Maven with others. If in the future it starts to shape like something that is quite stable from Maven's point of view, and the scope outgrowing it, then graduate to a TLP, Eclipse, or wherever seems appropriate.

I know the tone of this thread in parts hasn't been particularly helpful and maybe isn't conducive to wanting to do that. A lot of that is knee-jerk stuff that should die down moving forward as people get on with it. I could be wrong, but I still think that if you ran a poll of committers who have a stake in Maven3 development, you'd find a preference for hosting it here. If I'm right, I think that's worth taking into consideration.

Thanks,
Brett

--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Jason van Zyl <ja...@sonatype.com>]

On Aug 6, 2010, at 10:08 PM, Brett Porter wrote:

> 
> On 07/08/2010, at 2:05 AM, Jason van Zyl wrote:
> 
>> 
>> On Aug 6, 2010, at 11:54 AM, Brett Porter wrote:
>> 
>>> 
>>> On 07/08/2010, at 1:22 AM, Brian Fox wrote:
>>> 
>>>> I'm not so concerned about confusing users with a beta2 and then a
>>>> beta3, that can be mitigated easily in the announcement. More releases
>>>> won't hurt anyone.
>>>> 
>>>> Let those working on it decide what to do and when presented with a
>>>> vote, I'll test, verify and vote accordingly, regardless of if it's
>>>> beta2 with or without Aether/Guice.  I would just rather see one
>>>> sooner rather then later. We too often have a tendency of waiting for
>>>> everything to be perfect. They are betas, pick one and stage it I say.
>>> 
>>> +1 to that
>>> 
>>> Not to extend the thread too much further, but I'd still like to see someone answer my questions about the impact of changing the project's scope by moving the artifact implementation to Aether before that lands anyway. We've had a lot more time to ponder Guice.
>>> 
>>> 1) is there any alternative that would keep what we have today - the Maven implementation and API for Maven plugin developers - within the Maven project, while still allowing Jason's desire to involve more people in an expanded effort?
>>> 
>> 
>> The current Plugin API is not changed at all. We didn't change any of the plugin code. No impact on plugin developers. A new API is a different story and that will be far more powerful with JSR330 and Aether.
> 
> Sorry, I wasn't clear. When I say "plugin developers", let's say someone was writing the Dependency plugin anew against Maven 3. What artifact resolution APIs would they use? I didn't spot any examples of this in Benjamin's fork of Maven. Essentially the same question as https://issues.sonatype.org/browse/AETHER-5.
> 

Ideally there should be no API leakage from Aether. As part of the plugin API we should provide access to whatever resolution functionality we feel is necessary to expose and hide Aether. Initially a few attempts are likely needed and I might try using the Aether API directly. I honestly don't think using Aether APIs directly would be a great idea and really I think we exposed way too much previously. It boils down to answering the question: what do plugin developers actually need? Walk the dirty tree, walk the resolved graph, filter, I don't know yet. Maybe I'm wrong and this might just end up being the complete replication of the Aether API at which point I don't know if it makes sense to try and hide it. This is why we preserved the use of the old API because this stuff just takes a while to figure out. Even us working full-tilt it's taken a while. I would like to limit drastically what's in the plugin API for dealing with artifact resolution.

>> 
>> No one is going to work on the Maven implementation, that is clear from the sheer lack of neglect over the last 3 years. No one is magically going to start working on this. That much is clear.
> 
> I want to be clear that I'm not talking about continuing to work on the existing code - I'm talking about working on the new code that covers the existing scope of Maven. I thought this was the point of the repository system in trunk up until now - compatibility but more flexible and extensible so that improvements can happen both here and things built on top of it elsewhere.
> 
> As for lack of activity over recent years, well it's carts and horses as John said before. I had a working PGP implementation that was shot down because Mercury had already "solved" it, even though it wasn't integrated to trunk.

That bit of Mercury actually works. We use it in Nexus and we'll likely backport that bit to Aether.

> Other new features have been stalled waiting for a 2.1/3.0 release so that we can change the POM to properly utilise them. Any attempt to fix bugs would have been fruitless because there was always another thing out there that was going to replace the current code - in fact I've been trying to get you to open up your declared plans on artifact handling since we met at JavaOne in 2007. I can think of a handful of committers here that had a crack at Mercury and ultimately had their time wasted on a moving target.

Sorry, but I think that's nonsense. Oleg was not locked in a vault. If someone actually worked faster then us and implemented something we stated we were going to do I would have been fine with it. But I don't think anyone actually understands how much work it is. I don't know how exactly things are going to look ultimately but in the case of Aether we just went nuts for 8 weeks. The sequence of events was probably required. I didn't know how hard it would be and it proved to be hard. I honestly don't think design by committee works for this stuff. Much like parallel builds, it just drops out from a couple people doing a lot of work and then there's something to look at. Dan dropped in the first implementation and he just did it. No one much batted an eyelash. Kristian then picked it up. After looking at Aether I think people will agree it's the best starting place we've had. Nothing is perfect, but I think it's a good place to start.

> I had to promise myself not to get involved until 3.0 was out because I had burned so much time on dead ends. I thought in December last year we were getting there (http://markmail.org/message/4w46ioimp4vrssx3), but apparently "I think we're done" was a bit more of your endless optimism :) 

Someone has to be an optimist.

> 
> My endless optimism is that if Maven 3.0 comes out, or even looks like coming out, you'll see activity here lift to meet the challenge.

I hope you're right.

> I certainly empathise with your point about folks making demands and then not following through with the help. I would much rather be helping on making this happen than getting bogged down in these discussions. I agree it's best to ensure the changes to the architecture get into Maven 3.0 so that we're not shifting the target significantly again in the near future. But based on what I've seen so far, and my experience in the past, I remain reluctant to see development of Maven repository APIs move outside of this project.

They are not, all the bits that are Maven specific are in Benjamin's branch. Aether has absolutely no dependency on Maven and knows nothing about Maven. The ArtifactDescriptorReader for POMs everyone will have access to.

> It is not an easily reversible step, and I want to ensure that anyone that wants to get an improvement into Maven doesn't have to navigate the different controls and infrastructure of another project.

Unavoidable. We're not going to bring in everyone other dependency and any developer worth their salt can figure out how to pull in sources for dependent projects. Aether is all JIRA and Confluence it's not a big leap for anyone here. The barrier is not and never will be the infrastructure, it's people's time and willingness to contribute.

> I lived through the worst of it in Maven 2.0/Plexus/Modello/etc. and it drove me crazy.

It's no different now. We still have Modello and now Guice which none of you have any control over. We are very fortunate to have Stuart working with us at Sonatype who is a committer but by your measure this is worse. Totally different infrastructure and no access.

> But most of all, I want to see the shortest (but still correct) path to a 3.0 release - we need the unification it would bring. I may learn different from your answer to the above, but at this point it still seems like an evolving Aether poses a risk to that.

Aside from the memory issue that needs to be resolved Aether is the only viable way forward with respect to artifact resolution. Kristian has looked at it here, Brian and I are familiar with it and internally at Sonatype Tamas done an initial pass at integrating it into Nexus and Alin has it working in our p2-based runtime assembler (part of Proviso) so we already have some very skilled people who have it working in other systems. I have no doubt it will be picked up by some of the other build tools as well.

> 
> I'll still do what limited things I can to help see Maven 3.0 ship, if we can get some agreement here about what that really means.
> 
> Thanks,
> Brett
> 
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@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

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Brett Porter <br...@apache.org>]

On 07/08/2010, at 2:05 AM, Jason van Zyl wrote:

> 
> On Aug 6, 2010, at 11:54 AM, Brett Porter wrote:
> 
>> 
>> On 07/08/2010, at 1:22 AM, Brian Fox wrote:
>> 
>>> I'm not so concerned about confusing users with a beta2 and then a
>>> beta3, that can be mitigated easily in the announcement. More releases
>>> won't hurt anyone.
>>> 
>>> Let those working on it decide what to do and when presented with a
>>> vote, I'll test, verify and vote accordingly, regardless of if it's
>>> beta2 with or without Aether/Guice.  I would just rather see one
>>> sooner rather then later. We too often have a tendency of waiting for
>>> everything to be perfect. They are betas, pick one and stage it I say.
>> 
>> +1 to that
>> 
>> Not to extend the thread too much further, but I'd still like to see someone answer my questions about the impact of changing the project's scope by moving the artifact implementation to Aether before that lands anyway. We've had a lot more time to ponder Guice.
>> 
>> 1) is there any alternative that would keep what we have today - the Maven implementation and API for Maven plugin developers - within the Maven project, while still allowing Jason's desire to involve more people in an expanded effort?
>> 
> 
> The current Plugin API is not changed at all. We didn't change any of the plugin code. No impact on plugin developers. A new API is a different story and that will be far more powerful with JSR330 and Aether.

Sorry, I wasn't clear. When I say "plugin developers", let's say someone was writing the Dependency plugin anew against Maven 3. What artifact resolution APIs would they use? I didn't spot any examples of this in Benjamin's fork of Maven. Essentially the same question as https://issues.sonatype.org/browse/AETHER-5.

> 
> No one is going to work on the Maven implementation, that is clear from the sheer lack of neglect over the last 3 years. No one is magically going to start working on this. That much is clear.

I want to be clear that I'm not talking about continuing to work on the existing code - I'm talking about working on the new code that covers the existing scope of Maven. I thought this was the point of the repository system in trunk up until now - compatibility but more flexible and extensible so that improvements can happen both here and things built on top of it elsewhere.

As for lack of activity over recent years, well it's carts and horses as John said before. I had a working PGP implementation that was shot down because Mercury had already "solved" it, even though it wasn't integrated to trunk. Other new features have been stalled waiting for a 2.1/3.0 release so that we can change the POM to properly utilise them. Any attempt to fix bugs would have been fruitless because there was always another thing out there that was going to replace the current code - in fact I've been trying to get you to open up your declared plans on artifact handling since we met at JavaOne in 2007. I can think of a handful of committers here that had a crack at Mercury and ultimately had their time wasted on a moving target. I had to promise myself not to get involved until 3.0 was out because I had burned so much time on dead ends. I thought in December last year we were getting there (http://markmail.org/message/4w46ioimp4vrssx3), but apparently "I think we're done" was a bit more of your endless optimism :) 

My endless optimism is that if Maven 3.0 comes out, or even looks like coming out, you'll see activity here lift to meet the challenge. I certainly empathise with your point about folks making demands and then not following through with the help. I would much rather be helping on making this happen than getting bogged down in these discussions. I agree it's best to ensure the changes to the architecture get into Maven 3.0 so that we're not shifting the target significantly again in the near future. But based on what I've seen so far, and my experience in the past, I remain reluctant to see development of Maven repository APIs move outside of this project. It is not an easily reversible step, and I want to ensure that anyone that wants to get an improvement into Maven doesn't have to navigate the different controls and infrastructure of another project. I lived through the worst of it in Maven 2.0/Plexus/Modello/etc. and it drove me crazy. But most of all, I want to see the shortest (but still correct) path to a 3.0 release - we need the unification it would bring. I may learn different from your answer to the above, but at this point it still seems like an evolving Aether poses a risk to that.

I'll still do what limited things I can to help see Maven 3.0 ship, if we can get some agreement here about what that really means.

Thanks,
Brett

--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Jason van Zyl <ja...@sonatype.com>]

On Aug 6, 2010, at 11:54 AM, Brett Porter wrote:

> 
> On 07/08/2010, at 1:22 AM, Brian Fox wrote:
> 
>> I'm not so concerned about confusing users with a beta2 and then a
>> beta3, that can be mitigated easily in the announcement. More releases
>> won't hurt anyone.
>> 
>> Let those working on it decide what to do and when presented with a
>> vote, I'll test, verify and vote accordingly, regardless of if it's
>> beta2 with or without Aether/Guice.  I would just rather see one
>> sooner rather then later. We too often have a tendency of waiting for
>> everything to be perfect. They are betas, pick one and stage it I say.
> 
> +1 to that
> 
> Not to extend the thread too much further, but I'd still like to see someone answer my questions about the impact of changing the project's scope by moving the artifact implementation to Aether before that lands anyway. We've had a lot more time to ponder Guice.
> 
> 1) is there any alternative that would keep what we have today - the Maven implementation and API for Maven plugin developers - within the Maven project, while still allowing Jason's desire to involve more people in an expanded effort?
> 

The current Plugin API is not changed at all. We didn't change any of the plugin code. No impact on plugin developers. A new API is a different story and that will be far more powerful with JSR330 and Aether.

No one is going to work on the Maven implementation, that is clear from the sheer lack of neglect over the last 3 years. No one is magically going to start working on this. That much is clear.

> 2) either way, what API are we expecting plugin developers to use for artifact resolution in Maven 3?

They can use what exists now. We didn't alter any plugins. I imagine we will have to support the old API forever. 

> If it is Aether, what is the impact to plugin developers if the interfaces change after 3.0

Pretty much zero, plugins that exist today run without change. There are a couple gotchas but nothing major.

> , or if it moves to Eclipse (or even back to Apache) and changes packaging again?
> 

Aether is the library, and what should happen to prevent API leakage is that if a new Plugin API is developed that it prevent leakage this time and nothing will be couched in terms of Aether directly. That was a mistake with the current code and with Wagon. What is used now in terms of API we've tried to support to the best of our ability and there's no reason it can't remain indefinitely. Any new JSR330-based API for plugins should attempt to prevent API leakage.

> I'm still having trouble understanding the dichotomy between an project intended to evolve rapidly, and wanting to include that in a project (hopefully) nearing release which will be used for years.
> 

You do it by maintaining APIs which we have attempted to do.

> Thanks,
> Brett
> 
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

We know what we are, but know not what we may be.

  -- Shakespeare

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Brett Porter <br...@apache.org>]

On 07/08/2010, at 1:22 AM, Brian Fox wrote:

> I'm not so concerned about confusing users with a beta2 and then a
> beta3, that can be mitigated easily in the announcement. More releases
> won't hurt anyone.
> 
> Let those working on it decide what to do and when presented with a
> vote, I'll test, verify and vote accordingly, regardless of if it's
> beta2 with or without Aether/Guice.  I would just rather see one
> sooner rather then later. We too often have a tendency of waiting for
> everything to be perfect. They are betas, pick one and stage it I say.

+1 to that

Not to extend the thread too much further, but I'd still like to see someone answer my questions about the impact of changing the project's scope by moving the artifact implementation to Aether before that lands anyway. We've had a lot more time to ponder Guice.

1) is there any alternative that would keep what we have today - the Maven implementation and API for Maven plugin developers - within the Maven project, while still allowing Jason's desire to involve more people in an expanded effort?

2) either way, what API are we expecting plugin developers to use for artifact resolution in Maven 3? If it is Aether, what is the impact to plugin developers if the interfaces change after 3.0, or if it moves to Eclipse (or even back to Apache) and changes packaging again?

I'm still having trouble understanding the dichotomy between an project intended to evolve rapidly, and wanting to include that in a project (hopefully) nearing release which will be used for years.

Thanks,
Brett

--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Jason van Zyl <ja...@sonatype.com>]

On Aug 6, 2010, at 11:22 AM, Brian Fox wrote:

> I'm not so concerned about confusing users with a beta2 and then a
> beta3, that can be mitigated easily in the announcement. More releases
> won't hurt anyone.
> 

If we were deciding to leave Guice/Aether to Maven 3.1 then my opinion would be let it rip, the more the merrier.

For me crux is are we deciding to put this new code into 3.0? If so, we have more betas with the old code then new doesn't make any sense to me. By releasing the trunk now as beta-2 it seems to satisfy the wants of some of the people voting here but ultimately people who adopt these betas in the Maven user base is going to be miniscule. So this beta satisfies the wants of very few people in real terms.

It's also a focal point as I see for for people always complaining that Sonatype dominates. If you believe the Guice/Aether code should go into 3.0 then you fully back that plan as a committer and help fix the problems before we release it. In practical terms if no one else helps, it really makes no difference to us to debug the Guice/Aether code. The only thing that might potentially help for Benjamin is if people used the old/new versions to do diffs on behaviour. No normal user is going to do this, any one adept enough to have done this already can do it with a build out of Hudson.

I also frankly want to prevent someone from saying after we release the beta-2 that "Oh maybe we should just wait to integrate Guice/Aether until 3.1" at which point we're either stuck holding the bag to maintain a codebase in parallel or we quickly release a 3.1 which would be even more confusing then a beta2/beta3 now. If you support the direction, then let's work together and really if 5 people pull out the debuggers and profilers to help track down the problems we'll likely find them. At the very least it gives committers here the opportunity to learn the code that is the basis of future of Maven. If that happens it might only take into early next week to fix the problems and then we release what we plan to go forward with for the life of Maven 3.

If really what people are saying is the we want what we want now, and then just sit back and let us fix all the problems with the Guice/Aether code I'll frankly be disappointed. Really after all the work that has been done thus far what is another week or two? 

> Let those working on it decide what to do and when presented with a
> vote, I'll test, verify and vote accordingly, regardless of if it's
> beta2 with or without Aether/Guice.  I would just rather see one
> sooner rather then later. We too often have a tendency of waiting for
> everything to be perfect. They are betas, pick one and stage it I say.

I can't block a vote, but i honestly don't think it's a matter of trying to be perfect and more a matter of getting a level of commitment from the developers. And I think it's far too easy to under estimate the confusion it will cause users dropping betas out so closely no matter how much messaging you do in announcements.

> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

Our achievements speak for themselves. What we have to keep track
of are our failures, discouragements and doubts. We tend to forget
the past difficulties, the many false starts, and the painful
groping. We see our past achievements as the end result of a
clean forward thrust, and our present difficulties as
signs of decline and decay.

 -- Eric Hoffer, Reflections on the Human Condition

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Brian Fox <br...@infinity.nu>]

I'm not so concerned about confusing users with a beta2 and then a
beta3, that can be mitigated easily in the announcement. More releases
won't hurt anyone.

 Let those working on it decide what to do and when presented with a
vote, I'll test, verify and vote accordingly, regardless of if it's
beta2 with or without Aether/Guice.  I would just rather see one
sooner rather then later. We too often have a tendency of waiting for
everything to be perfect. They are betas, pick one and stage it I say.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Arnaud Héritier <ah...@gmail.com>]

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 <ah...@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-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Jason van Zyl <ja...@sonatype.com>]

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 <ah...@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-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>> 
>>>>>> 
>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@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

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Arnaud Héritier <ah...@gmail.com>]

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 <ah...@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-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>> 
>>>>> 
>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>> 
>>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Jason van Zyl <ja...@sonatype.com>]

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 <ah...@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-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>> 
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>> 
>>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@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

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Stephen Connolly <st...@gmail.com>]

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 <ah...@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-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@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
>
>
>
>

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Jason van Zyl <ja...@sonatype.com>]

On Aug 6, 2010, at 10:14 AM, John Casey wrote:

> There is one huge advantage to two releases, however:
> 
> You know that if the bug exists in both places, you don't have to dig through this huge pile of code that is the new container. That's a large set of assumptions you don't have to check.
> 

The end result will be that it needs to be fixed in the new codebase if it's present in both. If we weren't so intimately close with the code and I didn't think we could find it almost instantly and fix it I would agree with you. That the preference would be to have something without so much churn, but we can fix this stuff extremely quickly.

There are 612 ITs and that was the purpose in investing in them. So that we can make changes like this and be prepared.

> On 8/6/10 10:10 AM, Jason van Zyl wrote:
>> 
>> On Aug 6, 2010, at 10:01 AM, Brian Fox wrote:
>> 
>>> 2010/8/5 Arnaud Héritier<ah...@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-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>> 
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>> 
>>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@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
>> 
>> 
>> 
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

A man enjoys his work when he understands the whole and when he
is responsible for the quality of the whole

 -- Christopher Alexander, A Pattern Language

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Stephane Nicoll <st...@gmail.com>]

+1 and if you're so concerned about the official beta2/beta3 thing you can
just build an official internal release that can be provided on demand to
reproduce the problem. I don't see what the problem could be if we explain
to the community what we're trying to achieve. It is in their best interest
anyway.

S.

---
[image: Linkedin] <http://www.linkedin.com/in/snicoll>[image:
Twitter]<http://twitter.com/snicoll>


On Fri, Aug 6, 2010 at 4:14 PM, John Casey <jd...@commonjava.org> wrote:

> There is one huge advantage to two releases, however:
>
> You know that if the bug exists in both places, you don't have to dig
> through this huge pile of code that is the new container. That's a large set
> of assumptions you don't have to check.
>
>
> On 8/6/10 10:10 AM, Jason van Zyl wrote:
>
>>
>> On Aug 6, 2010, at 10:01 AM, Brian Fox wrote:
>>
>>  2010/8/5 Arnaud Héritier<ah...@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-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@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
>>
>>
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[John Casey <jd...@commonjava.org>]

There is one huge advantage to two releases, however:

You know that if the bug exists in both places, you don't have to dig 
through this huge pile of code that is the new container. That's a large 
set of assumptions you don't have to check.

On 8/6/10 10:10 AM, Jason van Zyl wrote:
>
> On Aug 6, 2010, at 10:01 AM, Brian Fox wrote:
>
>> 2010/8/5 Arnaud Héritier<ah...@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@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
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Jason van Zyl <ja...@sonatype.com>]

On Aug 6, 2010, at 10:01 AM, Brian Fox wrote:

> 2010/8/5 Arnaud Héritier <ah...@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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>> 
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@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

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Brian Fox <br...@infinity.nu>]

2010/8/5 Arnaud Héritier <ah...@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.

>
>  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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Arnaud Héritier <ah...@gmail.com>]

yes the goal will be to do more communications on beta-3 than beta-2 to let a maximum number of users trying it.
If they have any issues due to Ather or Guice we'll be able to ask them to come back to beta 2 the time we fix issues and deploy the beta-4

On Aug 6, 2010, at 2:09 AM, Mark Derricutt wrote:

> +1 on releasing beta-2 followed -very quickly- with beta-3 inc guice/aether
> (like days apart).  Tho I wonder if it might confuse people - but then, if
> you're playing with beta's you're probably following these threads anyway ).
> 
> Mark
> 
> -- 
> Pull me down under...
> 
> 
> 
> 2010/8/6 Arnaud Héritier <ah...@gmail.com>
> 
>> 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.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Mark Derricutt <ma...@talios.com>]

+1 on releasing beta-2 followed -very quickly- with beta-3 inc guice/aether
(like days apart).  Tho I wonder if it might confuse people - but then, if
you're playing with beta's you're probably following these threads anyway ).

Mark

-- 
Pull me down under...



2010/8/6 Arnaud Héritier <ah...@gmail.com>

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

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Stephane Nicoll <st...@gmail.com>]

+1

S.

---
[image: Linkedin] <http://www.linkedin.com/in/snicoll>[image:
Twitter]<http://twitter.com/snicoll>


2010/8/6 Arnaud Héritier <ah...@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.
>
>  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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Vincent Siveton <vi...@gmail.com>]

+1

Vincent

Le 2010-08-05 à 20:04, Arnaud Héritier <ah...@gmail.com> a  
écrit :

> 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.
>
>  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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Paul Benedict <pb...@apache.org>]

Arnaud,

I think your plan is sensible. I agree with what you and Dennis have said.
It allows the Maven community to move forward but also doesn't stop
development of the integration.

Paul

2010/8/5 Arnaud Héritier <ah...@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.
>
>  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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Stephen Connolly <st...@gmail.com>]

+1

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Barrie Treloar <ba...@gmail.com>]

+1

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[John Casey <jd...@commonjava.org>]

+1

On 8/5/10 8:04 PM, Arnaud Héritier wrote:
> 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.
>
>    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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Hervé BOUTEMY <he...@free.fr>]

+1

Regards,

Hervé

Le vendredi 06 août 2010, Arnaud Héritier a écrit :
> 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.
> 
>   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)
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x

[Arnaud Héritier <ah...@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.

  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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Merging in our Aether and Guice changes to Maven 3.x

[Dennis Lundberg <de...@apache.org>]

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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Merging in our Aether and Guice changes to Maven 3.x

[Brian Fox <br...@infinity.nu>]

>
>
> Our ITs say the codebases behave in an equivalent fashion, but it's the Aether/Guice changes that will be with us for the long >haul. I would rather wait to integrate those in order to suss out problems that may be a result of that integration.

I think you meant you would rather _not_ wait.

I agree, these are the big hitters that need the most attention.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Merging in our Aether and Guice changes to Maven 3.x

[Jason van Zyl <ja...@sonatype.com>]

On Aug 3, 2010, at 6:18 PM, Paul Benedict wrote:

> Jason, I think it would be more appropriate to get out beta-2 in its current
> state. The new Guice/Aether contributions would be a significant enhancement
> and are better suited for beta-3, as far as I see it. Waiting allows you to
> continue getting feedback from regressions introduced in beta-2 while
> working through any integration issues with your new code.
> 

Our ITs say the codebases behave in an equivalent fashion, but it's the Aether/Guice changes that will be with us for the long haul. I would rather wait to integrate those in order to suss out problems that may be a result of that integration. We found issues with Nexus on the Guice side once in production and I'm sure we're going to find similar issues with Maven. The sooner these changes make it into the hands of users the better IMO. Our testing is extensive so at this point we really do need some real world testing to find the edge cases.

> Paul
> 
> On Tue, Aug 3, 2010 at 1:21 PM, Jason van Zyl <ja...@sonatype.com> 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)
>> 
>> 
>> 
>> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

A man enjoys his work when he understands the whole and when he
is responsible for the quality of the whole

 -- Christopher Alexander, A Pattern Language

Re: Merging in our Aether and Guice changes to Maven 3.x

[Paul Benedict <pb...@apache.org>]

Jason, I think it would be more appropriate to get out beta-2 in its current
state. The new Guice/Aether contributions would be a significant enhancement
and are better suited for beta-3, as far as I see it. Waiting allows you to
continue getting feedback from regressions introduced in beta-2 while
working through any integration issues with your new code.

Paul

On Tue, Aug 3, 2010 at 1:21 PM, Jason van Zyl <ja...@sonatype.com> 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)
>
>
>
>

Re: Merging in our Aether and Guice changes to Maven 3.x

[Arnaud Héritier <ah...@gmail.com>]

A thing I forgot to add yesterday : 

For me Maven is a success because of its fundamentals (rules/guidelines) which allowed to created a large large variety of services with plugins.

The value of Maven is many many more in its plugins than in its core (I don't want to reduce the work done on it which is really important but in term of end user they are using before everything the large set of plugins).

To ensure a good future for the project I consider, that we have to do all the necessary to better develop plugins.

For me even if I would like to have the time to work on core stuffs which are really interesting, I prefer to try to work on plugins and to animate our community of contributors around them. We don't need 100 developers for core. But for plugins ....

It is already a big big challenge to maintain and keep them alive. You can have a look at the list of "official" maven plugins to see the list of latest releases. Even if a big effort where done, there a re always many bugs opened and some plugins weren't released for more than one year.

That's also why I'm ready to let Jason/Sonatype drive the core and I'll focus on plugins for the good of the community.

Cheers.


On Aug 4, 2010, at 11:26 PM, Arnaud Héritier wrote:

> Hi,
> 
>  Here is my position about these proposals.
> 
>  Guice : I understand it will replace the IOC part of plexus. More important changes in Maven will be done in Maven (>3.0) to fully use the JSR and Guice itself. For now it is just a technical switch between IOC containers and we need more real life tests to validate it. Thus +1 for it ASAP. 
> 
>  Aether : Like others I would prefer to have seen a development done by our community to replace our current stack which is unstable and complex. That's not the case (for many reasons) and you (Jason/Sonatype) proposes a new library you developed and you'll lead in the future. As it was said it will be a library like any other and we have to choice to take it or not inside Maven. PRO is its potential quality compared to the existing one (I didn't yet checked that's why I don't confirm), and CONs is the fact we delegate a part of our code outside with all problems it could creates (lifecycles not coherent with maven needs, ..). The fact this one is driven by the same set of people who are maintaining actively the core is for me a positive point. And myself I have nothing better to propose. Like many others I have less and less time to give to Maven (Since 1 year I more focused on the community than on its development) thus I see this proposal as the better choice we have for now. Thus let's go for it. My +1.
> 
> Arnaud
> 
> 
> On Aug 3, 2010, at 8:21 PM, 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)
>> 
>> 
>> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Merging in our Aether and Guice changes to Maven 3.x

[Stephen Connolly <st...@gmail.com>]

OK, I am going to round off my view on the topic.

Guice integration: +1

Aether integration: +0.999999 _for now_... let's suck it and see... if it
works well and the interaction between the two code bases works well, then
all is good.

There is a generic issue when we have volunteers and paid for effort working
on the same code base.

* volunteers will necessarily have a lower velocity that paid for effort.

* paid for effort will generate more volatility from the point of view of
the volunteers and their velocity.

* too much volatility makes contribution harder

There are a couple of points that I see arising from the above:

* paid for effort bemoaning the lack of volunteer effort (which is a
side-effect of the increased volatility from the paid for effort) is not
really a constructive moan... it will more likely result in a decrease in
volunteer contribution.

* elimination of paid for effort will kill a mature project as volunteers
just don't advance things as fast as this new world needs things advanced.
Volunteers typically don't like to revisit the tricky problems as their time
is limited.

I don't see paid for effort going away, and it's a good thing too... but I
do think that the paid for effort needs to acknowledge the side-effects of
its velocity.

BTW, I see the above as being generic issues, not specific to Maven or
Sonatype.

-Stephen

Re: Merging in our Aether and Guice changes to Maven 3.x

[Tamás Cservenák <ta...@cservenak.net>]

Hi there,

As for Guice, I think that what JVZ said does stands: a very few people does
understand how big and complex that work was (and is, since it is ongoing).
Stuart did a real magic, with just a "drop in" replacement for
Plexus-components backed by Guice. But don't stop there. With his
foundation, it is very easy and straight-forward to create any "IoC lingo",
just as Plexus "shim" is implemented. What I really loved about it, is the
fact, that "reimplementing" Nexus Plugin API (and it's internals) using
spice-inject boiled down to few very simple modules. Before, it was a pile
of asm+deep-plexus-trickery+classworlds heavy lifting and complex, error
prone code. Now it is a beautiful and simple. The previous was written by
me, but I felt no sorry for ditching it, not a teardrop at all. A big +1 for
it.

As for Aether, only few comments from Apache newbie. I did lurk a lot of
time around Apache project, especially Maven. Was present on lists, was
following the project even if I was not a "committer", had no merits
(neither have now) and was not a member for a long time (today I am). But
due to my private OSS project, I present with my Proximity Maven Proxy
implementation a little bit, and was participating mostly on these lists.
So, I am kinda aware of "The Apache Way", did seen it "in action".

IMO, the decision here is more about "The Apache Way" and something else. I
think everyone spent some time on Github, and I am always amazed how quickly
things get picked up, changed, modded and thrown back at you there, The
"speed" (in it's broadest sense) over there is awesome, like there is no
mass, hence no inertia force is applicable there. Here, you have a limited
(small) set of people with committer rights, with direct or indirect infra
access, and even if someone is at full throttle, the project itself is
doomed with this bottleneck, people cannot gain momentum unless they are
"in" this circle. We saw a lot of "insiders" saying they can't do it now,
they have other (like for example work related) obligations, family, etc.
There, you have literally open set (kinda unlimited) of potential
collaborators, and the "work" does not stop. In any moment, everybody being
active are actually at the top of their momentum. But if someone does
"retire" for a week or month, still leaves his work free and at disposal to
others. But I have to agree with Brett, centralized issue tracking is a
bliss.

Over "here", I see a lot of bureaucracy, different dams that just makes
things swim slower. And this is not the "git vs svn" story at all, this is
more about flow. Code and idea flow. The juice. Just like Stephen Connolly
told, here you hit "walls" and usually loose the momentum. When your JIRA
with patch get's absorbed, you will usually have the "wtf?" moment at first
when the JIRA mail lands in your mailbox. But there are lot of nice pros
over here too not to be lost: things like backing organization, tied
community, togetherness and all those other nice things Apache is known for.
Maybe we need to merry these two?

This "Apache Way" was maybe superior back then when it all started. But
today, as everything is speeding up, I kinda feel this "way" just makes
people... well, loose the momentum. And this applies to projects too.

Aether is ASLv2, I see no problem here taking it under Apache umbrella if
it's backing company shuts down.

Aether as external project is really something as Plexus was (still is but I
see positive opinionated people regarding ditching it). It was/is essential
part of Maven, but even then it was external. I personally think, that
trowing Aether into some whirling creek (like github, codehaus or even
eclipse) is a very good option. Not just it will be more easily adopted by
3rd parties, but also it will be a general commissar for Maven out there in
the wild.

This is a problem of "merits" too. I do understand people dislike the idea
to ditch some code with they were involved with for a long time, and was
probably increasing/representing their "merits". We all were there at least
once. But I cannot agree more with JVZ, that "merits" should melt and
vaporize, should be considered somewhat temporal. The "single amount of
work" made today should "count more" than "single amount of work" made a
year ago and so on. At least wrt decisions made today. When it's about beer
and fun, naturally the one having most "absolute" merits (without the time
factor that makes it melt) should pay the beer and margaritas, beyond
question, and we, without merits, should just enjoy the beer in great
companionship ;)

Any Maven emeritus anywhere around central Europe in near future? :D

In general, and aside all this "philosophy" above, I agree very much with
Arnaud. I think he nailed it.


Thanks,
~t~

Disclaimer: I am involved with Sonatype. This mail does not represent any
"internally approved" or Sonatype opinion, it is strictly my private
opinion.

Re: Merging in our Aether and Guice changes to Maven 3.x

[Arnaud Héritier <ah...@gmail.com>]

Hi,

  Here is my position about these proposals.

  Guice : I understand it will replace the IOC part of plexus. More important changes in Maven will be done in Maven (>3.0) to fully use the JSR and Guice itself. For now it is just a technical switch between IOC containers and we need more real life tests to validate it. Thus +1 for it ASAP. 

  Aether : Like others I would prefer to have seen a development done by our community to replace our current stack which is unstable and complex. That's not the case (for many reasons) and you (Jason/Sonatype) proposes a new library you developed and you'll lead in the future. As it was said it will be a library like any other and we have to choice to take it or not inside Maven. PRO is its potential quality compared to the existing one (I didn't yet checked that's why I don't confirm), and CONs is the fact we delegate a part of our code outside with all problems it could creates (lifecycles not coherent with maven needs, ..). The fact this one is driven by the same set of people who are maintaining actively the core is for me a positive point. And myself I have nothing better to propose. Like many others I have less and less time to give to Maven (Since 1 year I more focused on the community than on its development) thus I see this proposal as the better choice we have for now. Thus let's go for it. My +1.

Arnaud


On Aug 3, 2010, at 8:21 PM, 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)
> 
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Merging in our Aether and Guice changes to Maven 3.x

[nicolas de loof <ni...@gmail.com>]

Could it be supported by a JSR ?

Not a lightweight process, even considering JSR-330 was out after 6 month,
but the most agnostic way to group community efforts. Aether could then be
proposed as RI

2010/8/4 John Casey <jd...@commonjava.org>

> On 8/4/10 10:39 AM, nicolas de loof wrote:
>
>> Ivy Guys could be interested in such a "neutral" repository API, as they
>> also support both m2 and proprietary repo format.
>>
>
> Is Ivy even active still?
>
> I see Eclipse p2 as a better target for interoperability, but that's beside
> the point.
>
> We're talking about mediating the way artifacts are shared in software
> builds and deployments. Gradle, Ant, Ivy, Maven, Eclipse are all projects
> interested in this space. Users of this sharing mechanism may come to it via
> a wide variety of applications.
>
> Surely we can agree that establishing a standard and having everyone on the
> same page contributing to a fully interoperable design would be a good
> thing? We have two fairly mature designs out there, so this wouldn't be
> whole-cloth design by committee. It's more of a standards board, or steering
> committee, or whatever.
>
> Personally, I'm sick of coding against implementations without some stable
> API specification I can depend on. It breeds bugs.
>
>
>
>> 2010/8/4 John Casey<jd...@commonjava.org>
>>
>>  On 8/3/10 2:21 PM, 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.
>>>>
>>>>
>>>
>>> There's too much in this thread that I this is a tad distracting from the
>>> important points, so I'm replying to the top post.
>>>
>>> I _really_ appreciate all the work done in getting M3 into a usable form,
>>> and in general I like the way Aether looks (I haven't had time to look
>>> into
>>> the guice shim yet). I realize there are newer thoughts on repository
>>> design
>>> since Maven took its swing at things, and we need to find a way to
>>> transition forward..."transition" because we have a large legacy of
>>> artifacts already under the Maven repository format. HOWEVER, there are a
>>> couple things here I'm pretty deeply concerned about.
>>>
>>>
>>> 1. The repository format is a Maven concept. I'd argue that it's one of
>>> Maven's two great contributions to the world of software (the other being
>>> a
>>> decent build tool). As such, the Maven community should have some role in
>>> guiding the future of that format.
>>>
>>> If Maven relinquishes all ownership of the API and implementation for the
>>> piece that resolves artifacts, then we have no say in the future design
>>> of
>>> the repository Maven uses as its lifeblood. Many people who aren't
>>> Sonatype
>>> people have spent time working on that de facto specification, and
>>> they've
>>> shown the merit to earn a voice in guiding this API...at least, if it's
>>> going to be billed as a Maven-compatible Repository API.
>>>
>>>
>>> 2. Jason, you mentioned sponsoring a Sat4j developer to work with
>>> Sonatype
>>> in the future to improve Aether. What effect is this likely to have on
>>> the
>>> aether-api module? My concern here is that we're talking about releasing
>>> Maven 3.0-beta-2 with a completely rewritten API / implementation for one
>>> of
>>> the most pivotal parts of Maven. It's not that I don't trust Benjamin and
>>> Kristian to produce high-quality code.
>>>
>>> What I'm actually worried about having Aether API drift AFTER we adopt it
>>> in Maven. This will hamper anyone wishing to integrate with the Maven 3
>>> core, whether that's Maven plugin development or Maven embedding.
>>>
>>>
>>> What I'd actually prefer to see is the Aether API published in some
>>> neutral
>>> location where we have an iron-clad guarantee that we won't be locked out
>>> of
>>> its design. Then, put the implementations wherever you think is best. IMO
>>> the key moving forward is to establish a standard API for resolving
>>> artifacts. IMO, this is our great failure with Plexus, that we depended
>>> directly on a container implementation, not on a container API.
>>>
>>> Having a stable set of specifications define their interaction with Maven
>>> would make plugin development and embedding MUCH better. In fact, I think
>>> establishing this practice might be the single best contribution we can
>>> make
>>> to Maven in the near term.
>>>
>>> Thanks,
>>>
>>> -john
>>>
>>>
>>>
>>>
>>>  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)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: Merging in our Aether and Guice changes to Maven 3.x

[John Casey <jd...@commonjava.org>]

On 8/4/10 10:39 AM, nicolas de loof wrote:
> Ivy Guys could be interested in such a "neutral" repository API, as they
> also support both m2 and proprietary repo format.

Is Ivy even active still?

I see Eclipse p2 as a better target for interoperability, but that's 
beside the point.

We're talking about mediating the way artifacts are shared in software 
builds and deployments. Gradle, Ant, Ivy, Maven, Eclipse are all 
projects interested in this space. Users of this sharing mechanism may 
come to it via a wide variety of applications.

Surely we can agree that establishing a standard and having everyone on 
the same page contributing to a fully interoperable design would be a 
good thing? We have two fairly mature designs out there, so this 
wouldn't be whole-cloth design by committee. It's more of a standards 
board, or steering committee, or whatever.

Personally, I'm sick of coding against implementations without some 
stable API specification I can depend on. It breeds bugs.

>
> 2010/8/4 John Casey<jd...@commonjava.org>
>
>> On 8/3/10 2:21 PM, 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.
>>>
>>
>>
>> There's too much in this thread that I this is a tad distracting from the
>> important points, so I'm replying to the top post.
>>
>> I _really_ appreciate all the work done in getting M3 into a usable form,
>> and in general I like the way Aether looks (I haven't had time to look into
>> the guice shim yet). I realize there are newer thoughts on repository design
>> since Maven took its swing at things, and we need to find a way to
>> transition forward..."transition" because we have a large legacy of
>> artifacts already under the Maven repository format. HOWEVER, there are a
>> couple things here I'm pretty deeply concerned about.
>>
>>
>> 1. The repository format is a Maven concept. I'd argue that it's one of
>> Maven's two great contributions to the world of software (the other being a
>> decent build tool). As such, the Maven community should have some role in
>> guiding the future of that format.
>>
>> If Maven relinquishes all ownership of the API and implementation for the
>> piece that resolves artifacts, then we have no say in the future design of
>> the repository Maven uses as its lifeblood. Many people who aren't Sonatype
>> people have spent time working on that de facto specification, and they've
>> shown the merit to earn a voice in guiding this API...at least, if it's
>> going to be billed as a Maven-compatible Repository API.
>>
>>
>> 2. Jason, you mentioned sponsoring a Sat4j developer to work with Sonatype
>> in the future to improve Aether. What effect is this likely to have on the
>> aether-api module? My concern here is that we're talking about releasing
>> Maven 3.0-beta-2 with a completely rewritten API / implementation for one of
>> the most pivotal parts of Maven. It's not that I don't trust Benjamin and
>> Kristian to produce high-quality code.
>>
>> What I'm actually worried about having Aether API drift AFTER we adopt it
>> in Maven. This will hamper anyone wishing to integrate with the Maven 3
>> core, whether that's Maven plugin development or Maven embedding.
>>
>>
>> What I'd actually prefer to see is the Aether API published in some neutral
>> location where we have an iron-clad guarantee that we won't be locked out of
>> its design. Then, put the implementations wherever you think is best. IMO
>> the key moving forward is to establish a standard API for resolving
>> artifacts. IMO, this is our great failure with Plexus, that we depended
>> directly on a container implementation, not on a container API.
>>
>> Having a stable set of specifications define their interaction with Maven
>> would make plugin development and embedding MUCH better. In fact, I think
>> establishing this practice might be the single best contribution we can make
>> to Maven in the near term.
>>
>> Thanks,
>>
>> -john
>>
>>
>>
>>
>>> 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)
>>>
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Merging in our Aether and Guice changes to Maven 3.x

[nicolas de loof <ni...@gmail.com>]

Ivy Guys could be interested in such a "neutral" repository API, as they
also support both m2 and proprietary repo format.

2010/8/4 John Casey <jd...@commonjava.org>

> On 8/3/10 2:21 PM, 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.
>>
>
>
> There's too much in this thread that I this is a tad distracting from the
> important points, so I'm replying to the top post.
>
> I _really_ appreciate all the work done in getting M3 into a usable form,
> and in general I like the way Aether looks (I haven't had time to look into
> the guice shim yet). I realize there are newer thoughts on repository design
> since Maven took its swing at things, and we need to find a way to
> transition forward..."transition" because we have a large legacy of
> artifacts already under the Maven repository format. HOWEVER, there are a
> couple things here I'm pretty deeply concerned about.
>
>
> 1. The repository format is a Maven concept. I'd argue that it's one of
> Maven's two great contributions to the world of software (the other being a
> decent build tool). As such, the Maven community should have some role in
> guiding the future of that format.
>
> If Maven relinquishes all ownership of the API and implementation for the
> piece that resolves artifacts, then we have no say in the future design of
> the repository Maven uses as its lifeblood. Many people who aren't Sonatype
> people have spent time working on that de facto specification, and they've
> shown the merit to earn a voice in guiding this API...at least, if it's
> going to be billed as a Maven-compatible Repository API.
>
>
> 2. Jason, you mentioned sponsoring a Sat4j developer to work with Sonatype
> in the future to improve Aether. What effect is this likely to have on the
> aether-api module? My concern here is that we're talking about releasing
> Maven 3.0-beta-2 with a completely rewritten API / implementation for one of
> the most pivotal parts of Maven. It's not that I don't trust Benjamin and
> Kristian to produce high-quality code.
>
> What I'm actually worried about having Aether API drift AFTER we adopt it
> in Maven. This will hamper anyone wishing to integrate with the Maven 3
> core, whether that's Maven plugin development or Maven embedding.
>
>
> What I'd actually prefer to see is the Aether API published in some neutral
> location where we have an iron-clad guarantee that we won't be locked out of
> its design. Then, put the implementations wherever you think is best. IMO
> the key moving forward is to establish a standard API for resolving
> artifacts. IMO, this is our great failure with Plexus, that we depended
> directly on a container implementation, not on a container API.
>
> Having a stable set of specifications define their interaction with Maven
> would make plugin development and embedding MUCH better. In fact, I think
> establishing this practice might be the single best contribution we can make
> to Maven in the near term.
>
> Thanks,
>
> -john
>
>
>
>
>> 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)
>>
>>
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: Merging in our Aether and Guice changes to Maven 3.x

[John Casey <jd...@commonjava.org>]

Having worked with Aether yesterday in some test code, and after 
sleeping on it last night, I'll withdraw my objections for now.

This looks like a good way forward in terms of code. I'm still concerned 
about volatility in terms of writing plugins that need to resolve X or Y 
artifact at runtime, but I agree that we need something better than we 
currently have.

I say go ahead and integrate it, and let's see what happens.

As for the Guice stuff, I never had much objection to that.

On 8/4/10 2:36 PM, John Casey wrote:
> I want it to be clear that the _only_ thing I asked for was that the
> Aether API/SPI _specification_ be hosted in a neutral location where
> Maven committers can contribute to the design.
>
> Let me emphasize that: API/SPI only, and in a neutral location. The
> Maven project is not what I'd call "neutral" here.
>
> If, as you claim, the API is set, then we're only talking about the
> future here. We're talking about having open discussions where people
> can have a real vote on new features in the API/SPI.
>
>
>
> I believe I'm sufficiently grateful to Benjamin, Kristian, and the
> others for implementing this. From what I can see, it looks like a
> really good way to go, and I have no doubt the code is excellent. And,
> the implementation can live in Timbuktu as far as I'm concerned. I have
> no doubt that you'll publish it so others can use it...as you say,
> that's the whole point.
>
> The _only_ thing I want for my vote to integrate is that we can make
> this API/SPI a standard set of interfaces by making it its own project
> somewhere that Maven committers can get automatic access...and then
> leaving it there. If that's not ASF, I have no problem with that. But I
> think Maven committers should have the automatic ability to participate
> in shaping the Maven's contract with the repository into the future.
>
> This is a critical piece to Maven, and TBH _not_ having this access may
> be part of why projects like Ivy won't use the Maven repository
> code...they aren't represented in the decision-making process.
>
> On 8/4/10 12:57 PM, Jason van Zyl wrote:
>>
>> On Aug 4, 2010, at 11:54 AM, John Casey wrote:
>>
>>>>>
>>>>>
>>>>> Having a stable set of specifications define their interaction with
>>>>> Maven would make plugin development and embedding MUCH better. In
>>>>> fact, I think establishing this practice might be the single best
>>>>> contribution we can make to Maven in the near term.
>>>>>
>>>
>>> All due respect, but that dodges the question of separating and
>>> standardizing the API from the implementation. It also dodges the
>>> discussion about who sets the design of the repository format and the
>>> API spec used to access it.
>>>
>>
>> To me that's sounds like a bunch of busy work without much value. It
>> works, and it's going to evolve by having people use it. The ultimate
>> API will never be arrived at without lots of integrators. That's how
>> everything evolves.
>>
>>> You're asking the Maven community to give up one of its greatest
>>> creations - the repository format that has become a de facto standard
>>> - and become completely dependent on a project whose future may be
>>> uncertain. It's easy to talk about companies as these fixtures in the
>>> market, but the fact is we're talking about giving complete control
>>> over the Maven repository API / format to a start-up.
>>
>> I can't make you, or anyone else, do anything you don't want to do.
>> Vote against it, implement your own library, I'm not putting a gun to
>> your head. I've done what I feel is best, I've laid out what I think
>> is best. You can disagree and take action accordingly.
>>
>>> Start-ups are not known for their stability. Then, the company in
>>> control _may_ decide (unilaterally) to move the whole shebang to
>>> Eclipse. There's absolutely no role for Maven developers in this
>>> model, unless they go out and re-establish their merit on a new project.
>>>
>>
>> First, the code is ASL so if we rolled over tomorrow then take it.
>> That's really not a problem. Second, yes we created it so if we want
>> to take it to Eclipse we can do that. People who do the work get to
>> make choices like that. Eclipse is solid place to do OSS work.
>>
>> I'm tired of the endless debates about infrastructure, release
>> process, using git, and I honestly think Aether not being here is the
>> best thing for getting others involved.
>>
>>> I'm not talking about the merit to contribute implementation details
>>> - though the ASF concept of non-expiring merit argues strongly
>>> against losing access to that. What I'm talking about is the right to
>>> contribute to the design of the repository format, API, and SPI (now
>>> that I notice that's separate from the API). The language we use to
>>> share artifacts and metadata should not be under the sole control of
>>> a private entity.
>>
>> That honestly has nothing to do with where the code is. If we shut
>> everyone out, we'd just be shooting ourselves in the face and ruin any
>> reputation we have of being meaningful contributors to the Maven
>> ecosystem. That doesn't do Sonatype any good. The argument that the
>> only place that can be done is simply not true.
>>
>>>
>>> Sure, there haven't been too many contributors to Maven 3. But how
>>> much of that has to do with the velocity of work done and paid for by
>>> Sonatype,
>>
>> It has a great deal to do with that. No one can keep up with full-time
>> people but that doesn't mean contributions should fall off to zero
>> which is what's pretty much happened. Kristian and Olivier being the
>> exceptions.
>>
>>> the dramatic and repeated shift in direction by those paid
>>> contributions (mercury for example),
>>
>> That was not a dramatic shift at all. We attempted to make an artifact
>> resolution API and the first attempt failed. No shift, a second more
>> successful attempt.
>>
>>> the need to chase code from SVN to GitHub, to still other GitHub
>>> repositories, and the lack of discussion of the design of any of it?
>>
>> It was not developed here, you do not have to accept it. I posit we
>> would have been in endless debate, no one would have contributed and
>> we'd be in the same boat. My conjecture possibly, but no different
>> then your view which is also conjecture. The fact is right now we have
>> a working library and a way forward. Anyone here who feels I'm limited
>> their choice can blame themselves for not participating previously.
>> Yes, I felt it would be more expedient to just do it because this
>> project needs to get on the rails again and I believe this is one of
>> the critical steps. Aether was implemented in a very short period of
>> time. There's code there, it works and now people can provide
>> feedback. I honestly feel that works better. Yes I told some people
>> about it and not others and that was purely a judgement I made based
>> on what people have been contributing lately. That's why I didn't
>> develop here because that mode of operation is looked dimly upon here
>> so I didn't do it here. And I want
> the velocity to continue, and that just is not going to happen here
> based on my cumulative experience of over 10 years here. I wanted to try
> something different and this is the result. You may not like it, you
> don't have to agree, but you can't make me do what you feel is right.
>>
>>>
>>> It makes me uneasy to see how much this has become a skunkworks type
>>> of project, where much of the development takes place behind closed
>>> doors and then gets dumped on the Maven community.
>>
>> You're entitled to your point of view. I'm interested at this point in
>> the efficacy of execution and the survival of the project. Not whether
>> everyone has the warm fuzzies. Apart from the Maven 1.x to Maven 2.x
>> I've tried not to fuck users and doing so now wouldn't serve my
>> commercial or non-commercial efforts.
>>
>>>
>>> Maven contributors established the foundational concepts (and code,
>>> from what I can tell) for Aether; Aether is a refactoring of that
>>> essential design and format. If you expect Maven to use Aether, then
>>> the Maven community deserves some say in the future of the format and
>>> API. That's my opinion.
>>>
>>
>> Just because the code base is not here does not stop you from
>> participating. I think that's just something you're going to have to
>> reconcile yourself to. I believe the code needs a chance to live
>> outside these walls. And Aether is a very different design, sure it
>> borrows things from all over the place including here but it's
>> definitely not a refactoring.
>>
>> There isn't just the Apache Way and nothing else. As I've stated
>> before Maven 3.0 is an effort at backward compatibility with a way
>> forward. We have not gone and secretly and radically changed Maven and
>> dropped Maven 4 in your laps. We made a library, yes an important one,
>> but it's a library nonetheless. I've said that all new features
>> developed in the core and that's not going to change. And guess what?
>> There are no new features and we've basically be doing the shit work
>> of writing tests for 2 years that no one has helped with. We made
>> Aether and made it compatible, turfed Plexus to be more sensitive to
>> users being confronted with my one-off IoC and made it work with all
>> existing code. I don't think anyone understands how much work that
>> was. The project would never move forward and it would be in a "good
>> enough" state which would leave it to be trampled by the competition.
>> I'm just not going to let that happen. Some work like what we've done
>> is just never going to happen h
> ere, and it's definitely not going to happen without millions of dollars
> of concerted effort. Which is where Sonatype is at this point. I love
> that I've been fortunate enough to provide the work that's been done. It
> was the exact same thing with Maven 2.x. If I hadn't start Mergere do
> you think Maven 2.x would exist? I honestly doubt it. I try to balance
> what I think is necessary, and what I can reasonably do at Apache and
> when what I think needs to be done falls outside of those parameters I
> opt out instead of trying to force my opinions on everyone here.
>>
>> There are things I believe work best here, like when we start
>> discussion outward facing features for Maven 3.1. I don't think that
>> can happen any place but here with a lot of discussion as painful as I
>> think that's going to be this is the right place to do that. For the
>> bits that are really, really hard require dedicated people, talking on
>> the phone 5 times a day and pretty much every other violation of what
>> would be considered the Apache Way. Every commercial company involved
>> here probably does lots of things like we do but they don't attempt to
>> contribute it back. I don't want a disparity in my working life where
>> the OSS stuff I work on is good enough and then I have to build around
>> it to make something great on the commercial side. I want Maven to be
>> great and this is how I approach it.
>>
>> I'm doing what I think is best for Maven users. If you disagree I'm
>> not going to fault you, and I encourage you to do what you think is
>> right. I wouldn't ask anything less of anyone involved here.
>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>>
>> happiness is like a butterfly: the more you chase it, the more it will
>> elude you, but if you turn your attention to other things, it will come
>> and sit softly on your shoulder ...
>>
>> -- Thoreau
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Merging in our Aether and Guice changes to Maven 3.x

[John Casey <jd...@commonjava.org>]

I want it to be clear that the _only_ thing I asked for was that the 
Aether API/SPI _specification_ be hosted in a neutral location where 
Maven committers can contribute to the design.

Let me emphasize that: API/SPI only, and in a neutral location. The 
Maven project is not what I'd call "neutral" here.

If, as you claim, the API is set, then we're only talking about the 
future here. We're talking about having open discussions where people 
can have a real vote on new features in the API/SPI.



I believe I'm sufficiently grateful to Benjamin, Kristian, and the 
others for implementing this. From what I can see, it looks like a 
really good way to go, and I have no doubt the code is excellent. And, 
the implementation can live in Timbuktu as far as I'm concerned. I have 
no doubt that you'll publish it so others can use it...as you say, 
that's the whole point.

The _only_ thing I want for my vote to integrate is that we can make 
this API/SPI a standard set of interfaces by making it its own project 
somewhere that Maven committers can get automatic access...and then 
leaving it there. If that's not ASF, I have no problem with that. But I 
think Maven committers should have the automatic ability to participate 
in shaping the Maven's contract with the repository into the future.

This is a critical piece to Maven, and TBH _not_ having this access may 
be part of why projects like Ivy won't use the Maven repository 
code...they aren't represented in the decision-making process.

On 8/4/10 12:57 PM, Jason van Zyl wrote:
>
> On Aug 4, 2010, at 11:54 AM, John Casey wrote:
>
>>>>
>>>>
>>>> Having a stable set of specifications define their interaction with Maven would make plugin development and embedding MUCH better. In fact, I think establishing this practice might be the single best contribution we can make to Maven in the near term.
>>>>
>>
>> All due respect, but that dodges the question of separating and standardizing the API from the implementation. It also dodges the discussion about who sets the design of the repository format and the API spec used to access it.
>>
>
> To me that's sounds like a bunch of busy work without much value. It works, and it's going to evolve by having people use it. The ultimate API will never be arrived at without lots of integrators. That's how everything evolves.
>
>> You're asking the Maven community to give up one of its greatest creations - the repository format that has become a de facto standard - and become completely dependent on a project whose future may be uncertain. It's easy to talk about companies as these fixtures in the market, but the fact is we're talking about giving complete control over the Maven repository API / format to a start-up.
>
> I can't make you, or anyone else, do anything you don't want to do. Vote against it, implement your own library, I'm not putting a gun to your head. I've done what I feel is best, I've laid out what I think is best. You can disagree and take action accordingly.
>
>> Start-ups are not known for their stability. Then, the company in control _may_ decide (unilaterally) to move the whole shebang to Eclipse. There's absolutely no role for Maven developers in this model, unless they go out and re-establish their merit on a new project.
>>
>
> First, the code is ASL so if we rolled over tomorrow then take it. That's really not a problem. Second, yes we created it so if we want to take it to Eclipse we can do that. People who do the work get to make choices like that. Eclipse is solid place to do OSS work.
>
> I'm tired of the endless debates about infrastructure, release process, using git, and I honestly think Aether not being here is the best thing for getting others involved.
>
>> I'm not talking about the merit to contribute implementation details - though the ASF concept of non-expiring merit argues strongly against losing access to that. What I'm talking about is the right to contribute to the design of the repository format, API, and SPI (now that I notice that's separate from the API). The language we use to share artifacts and metadata should not be under the sole control of a private entity.
>
> That honestly has nothing to do with where the code is. If we shut everyone out, we'd just be shooting ourselves in the face and ruin any reputation we have of being meaningful contributors to the Maven ecosystem. That doesn't do Sonatype any good. The argument that the only place that can be done is simply not true.
>
>>
>> Sure, there haven't been too many contributors to Maven 3. But how much of that has to do with the velocity of work done and paid for by Sonatype,
>
> It has a great deal to do with that. No one can keep up with full-time people but that doesn't mean contributions should fall off to zero which is what's pretty much happened. Kristian and Olivier being the exceptions.
>
>> the dramatic and repeated shift in direction by those paid contributions (mercury for example),
>
> That was not a dramatic shift at all. We attempted to make an artifact resolution API and the first attempt failed. No shift, a second more successful attempt.
>
>> the need to chase code from SVN to GitHub, to still other GitHub repositories, and the lack of discussion of the design of any of it?
>
> It was not developed here, you do not have to accept it. I posit we would have been in endless debate, no one would have contributed and we'd be in the same boat. My conjecture possibly, but no different then your view which is also conjecture. The fact is right now we have a working library and a way forward. Anyone here who feels I'm limited their choice can blame themselves for not participating previously. Yes, I felt it would be more expedient to just do it because this project needs to get on the rails again and I believe this is one of the critical steps. Aether was implemented in a very short period of time. There's code there, it works and now people can provide feedback. I honestly feel that works better. Yes I told some people about it and not others and that was purely a judgement I made based on what people have been contributing lately. That's why I didn't develop here because that mode of operation is looked dimly upon here so I didn't do it here. And I want 
the velocity to continue, and that just is not going to happen here based on my cumulative experience of over 10 years here. I wanted to try something different and this is the result. You may not like it, you don't have to agree, but you can't make me do what you feel is right.
>
>>
>> It makes me uneasy to see how much this has become a skunkworks type of project, where much of the development takes place behind closed doors and then gets dumped on the Maven community.
>
> You're entitled to your point of view. I'm interested at this point in the efficacy of execution and the survival of the project. Not whether everyone has the warm fuzzies. Apart from the Maven 1.x to Maven 2.x I've tried not to fuck users and doing so now wouldn't serve my commercial or non-commercial efforts.
>
>>
>> Maven contributors established the foundational concepts (and code, from what I can tell) for Aether; Aether is a refactoring of that essential design and format. If you expect Maven to use Aether, then the Maven community deserves some say in the future of the format and API. That's my opinion.
>>
>
> Just because the code base is not here does not stop you from participating. I think that's just something you're going to have to reconcile yourself to. I believe the code needs a chance to live outside these walls. And Aether is a very different design, sure it borrows things from all over the place including here but it's definitely not a refactoring.
>
> There isn't just the Apache Way and nothing else. As I've stated before Maven 3.0 is an effort at backward compatibility with a way forward. We have not gone and secretly and radically changed Maven and dropped Maven 4 in your laps. We made a library, yes an important one, but it's a library nonetheless. I've said that all new features developed in the core and that's not going to change. And guess what? There are no new features and we've basically be doing the shit work of writing tests for 2 years that no one has helped with. We made Aether and made it compatible, turfed Plexus to be more sensitive to users being confronted with my one-off IoC and made it work with all existing code. I don't think anyone understands how much work that was. The project would never move forward and it would be in a "good enough" state which would leave it to be trampled by the competition. I'm just not going to let that happen. Some work like what we've done is just never going to happen h
ere, and it's definitely not going to happen without millions of dollars of concerted effort. Which is where Sonatype is at this point. I love that I've been fortunate enough to provide the work that's been done. It was the exact same thing with Maven 2.x. If I hadn't start Mergere do you think Maven 2.x would exist? I honestly doubt it. I try to balance what I think is necessary, and what I can reasonably do at Apache and when what I think needs to be done falls outside of those parameters I opt out instead of trying to force my opinions on everyone here.
>
> There are things I believe work best here, like when we start discussion outward facing features for Maven 3.1. I don't think that can happen any place but here with a lot of discussion as painful as I think that's going to be this is the right place to do that. For the bits that are really, really hard require dedicated people,  talking on the phone 5 times a day and pretty much every other violation of what would be considered the Apache Way. Every commercial company involved here probably does lots of things like we do but they don't attempt to contribute it back. I don't want a disparity in my working life where the OSS stuff I work on is good enough and then I have to build around it to make something great on the commercial side. I want Maven to be great and this is how I approach it.
>
> I'm doing what I think is best for Maven users. If you disagree I'm not going to fault you, and I encourage you to do what you think is right. I wouldn't ask anything less of anyone involved here.
>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> happiness is like a butterfly: the more you chase it, the more it will
> elude you, but if you turn your attention to other things, it will come
> and sit softly on your shoulder ...
>
>   -- Thoreau
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Merging in our Aether and Guice changes to Maven 3.x

[Jason van Zyl <ja...@sonatype.com>]

On Aug 4, 2010, at 11:54 AM, John Casey wrote:

>>> 
>>> 
>>> Having a stable set of specifications define their interaction with Maven would make plugin development and embedding MUCH better. In fact, I think establishing this practice might be the single best contribution we can make to Maven in the near term.
>>> 
> 
> All due respect, but that dodges the question of separating and standardizing the API from the implementation. It also dodges the discussion about who sets the design of the repository format and the API spec used to access it.
> 

To me that's sounds like a bunch of busy work without much value. It works, and it's going to evolve by having people use it. The ultimate API will never be arrived at without lots of integrators. That's how everything evolves.

> You're asking the Maven community to give up one of its greatest creations - the repository format that has become a de facto standard - and become completely dependent on a project whose future may be uncertain. It's easy to talk about companies as these fixtures in the market, but the fact is we're talking about giving complete control over the Maven repository API / format to a start-up.

I can't make you, or anyone else, do anything you don't want to do. Vote against it, implement your own library, I'm not putting a gun to your head. I've done what I feel is best, I've laid out what I think is best. You can disagree and take action accordingly.

> Start-ups are not known for their stability. Then, the company in control _may_ decide (unilaterally) to move the whole shebang to Eclipse. There's absolutely no role for Maven developers in this model, unless they go out and re-establish their merit on a new project.
> 

First, the code is ASL so if we rolled over tomorrow then take it. That's really not a problem. Second, yes we created it so if we want to take it to Eclipse we can do that. People who do the work get to make choices like that. Eclipse is solid place to do OSS work.

I'm tired of the endless debates about infrastructure, release process, using git, and I honestly think Aether not being here is the best thing for getting others involved. 

> I'm not talking about the merit to contribute implementation details - though the ASF concept of non-expiring merit argues strongly against losing access to that. What I'm talking about is the right to contribute to the design of the repository format, API, and SPI (now that I notice that's separate from the API). The language we use to share artifacts and metadata should not be under the sole control of a private entity.

That honestly has nothing to do with where the code is. If we shut everyone out, we'd just be shooting ourselves in the face and ruin any reputation we have of being meaningful contributors to the Maven ecosystem. That doesn't do Sonatype any good. The argument that the only place that can be done is simply not true.

> 
> Sure, there haven't been too many contributors to Maven 3. But how much of that has to do with the velocity of work done and paid for by Sonatype,

It has a great deal to do with that. No one can keep up with full-time people but that doesn't mean contributions should fall off to zero which is what's pretty much happened. Kristian and Olivier being the exceptions.

> the dramatic and repeated shift in direction by those paid contributions (mercury for example),

That was not a dramatic shift at all. We attempted to make an artifact resolution API and the first attempt failed. No shift, a second more successful attempt.

> the need to chase code from SVN to GitHub, to still other GitHub repositories, and the lack of discussion of the design of any of it?

It was not developed here, you do not have to accept it. I posit we would have been in endless debate, no one would have contributed and we'd be in the same boat. My conjecture possibly, but no different then your view which is also conjecture. The fact is right now we have a working library and a way forward. Anyone here who feels I'm limited their choice can blame themselves for not participating previously. Yes, I felt it would be more expedient to just do it because this project needs to get on the rails again and I believe this is one of the critical steps. Aether was implemented in a very short period of time. There's code there, it works and now people can provide feedback. I honestly feel that works better. Yes I told some people about it and not others and that was purely a judgement I made based on what people have been contributing lately. That's why I didn't develop here because that mode of operation is looked dimly upon here so I didn't do it here. And I want the velocity to continue, and that just is not going to happen here based on my cumulative experience of over 10 years here. I wanted to try something different and this is the result. You may not like it, you don't have to agree, but you can't make me do what you feel is right.

> 
> It makes me uneasy to see how much this has become a skunkworks type of project, where much of the development takes place behind closed doors and then gets dumped on the Maven community.

You're entitled to your point of view. I'm interested at this point in the efficacy of execution and the survival of the project. Not whether everyone has the warm fuzzies. Apart from the Maven 1.x to Maven 2.x I've tried not to fuck users and doing so now wouldn't serve my commercial or non-commercial efforts.

> 
> Maven contributors established the foundational concepts (and code, from what I can tell) for Aether; Aether is a refactoring of that essential design and format. If you expect Maven to use Aether, then the Maven community deserves some say in the future of the format and API. That's my opinion.
> 

Just because the code base is not here does not stop you from participating. I think that's just something you're going to have to reconcile yourself to. I believe the code needs a chance to live outside these walls. And Aether is a very different design, sure it borrows things from all over the place including here but it's definitely not a refactoring.

There isn't just the Apache Way and nothing else. As I've stated before Maven 3.0 is an effort at backward compatibility with a way forward. We have not gone and secretly and radically changed Maven and dropped Maven 4 in your laps. We made a library, yes an important one, but it's a library nonetheless. I've said that all new features developed in the core and that's not going to change. And guess what? There are no new features and we've basically be doing the shit work of writing tests for 2 years that no one has helped with. We made Aether and made it compatible, turfed Plexus to be more sensitive to users being confronted with my one-off IoC and made it work with all existing code. I don't think anyone understands how much work that was. The project would never move forward and it would be in a "good enough" state which would leave it to be trampled by the competition. I'm just not going to let that happen. Some work like what we've done is just never going to happen here, and it's definitely not going to happen without millions of dollars of concerted effort. Which is where Sonatype is at this point. I love that I've been fortunate enough to provide the work that's been done. It was the exact same thing with Maven 2.x. If I hadn't start Mergere do you think Maven 2.x would exist? I honestly doubt it. I try to balance what I think is necessary, and what I can reasonably do at Apache and when what I think needs to be done falls outside of those parameters I opt out instead of trying to force my opinions on everyone here. 

There are things I believe work best here, like when we start discussion outward facing features for Maven 3.1. I don't think that can happen any place but here with a lot of discussion as painful as I think that's going to be this is the right place to do that. For the bits that are really, really hard require dedicated people,  talking on the phone 5 times a day and pretty much every other violation of what would be considered the Apache Way. Every commercial company involved here probably does lots of things like we do but they don't attempt to contribute it back. I don't want a disparity in my working life where the OSS stuff I work on is good enough and then I have to build around it to make something great on the commercial side. I want Maven to be great and this is how I approach it.

I'm doing what I think is best for Maven users. If you disagree I'm not going to fault you, and I encourage you to do what you think is right. I wouldn't ask anything less of anyone involved here.

> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...

 -- Thoreau 

Re: Merging in our Aether and Guice changes to Maven 3.x

[Jason van Zyl <ja...@sonatype.com>]

On Aug 6, 2010, at 2:23 PM, Ralph Goers wrote:

> So even though I'm on vacation this week I took the time to get the code from git and read the wiki. Now I am even more concerned, even though I have read everyone's responses. 
> 
> Aether is NOT a replacement for the Wagon, from what I can tell it replaces all the artifact resolution handling. This is handled through methods like RepositorySystem.resolveDependencies. This relegates Maven to the status of  pretty much just a plugin processor.  I would be much less concerned if aether-api was hosted somewhere outside of Apache or was even javax.repository or somesuch thing. But aether-impl, etc belong in Maven, IMO.
> 
> Brian and I spoke at the last ApacheCon about the need to enhance the pom and the only way we could see to do that was to have a new project descriptor in addition to the pom. The ability to do this - and is something I have been planning on working on once 3.0 is stable - would now be out of the control of this project. 
> 

Aether is a general library purpose and incomplete without processing for the particular target system. Whether that be properties files or POMs. The interface that needs to have an implementation is http://github.com/sonatype/sonatype-aether/blob/master/aether-impl/src/main/java/org/sonatype/aether/impl/ArtifactDescriptorReader.java

The implementation that is required for making Aether work for Maven is http://github.com/bentmann/maven-3/blob/repo/maven-artifact-descriptor/src/main/java/org/apache/maven/repository/internal/DefaultArtifactDescriptorReader.java

You'll see that it's clear on the Maven side of the fence, and that someone could use Aether without a single dependency on anything in Maven.

I think you people need to dig a little deeper instead of making these knee jerk reactions. As such what the fuck, we'll release beta-2 as it is in trunk and let people catch up.

> Although I like the structure of the code very much I am inclined to do one of two things:
> 1. Vote -1 for inclusion.
> 2. Take the code as it is under the Apache license and check it in to Maven's SVN. The only thing preventing this would be the -1 vote I would expect from Sonatype employees. An alternative approach to this would be to check it into a new incubator project. This would only require a majority vote of the incubator PMC and would be allowable under the license. However, I don't consider this a viable option as it would be too disruptive to the incubator unless Sonatype supported this, which it is clear they do not.  
> 
> I believe in "The Apache Way" - Community over Code. I am not in favor of adopting a direction that relegates the Maven project to almost the point of irrelevance. However, I also believe that the community should not be blocked by a single individual so if I am the only one who feels that gutting the Maven project is a bad thing then I will simply abstain from voting. But frankly, the arguments in favor of hosting Aether outside of the ASF has left me wondering why the proposal wasn't to move the whole project out of the ASF.
> 
> And for what it is worth, I have appreciated when those of you who are employed by Sonatype have explicitly included that in your replies on this topic.
> 
> Ralph
> 
> 
> On Aug 4, 2010, at 8:54 AM, John Casey wrote:
> 
>> 
>> All due respect, but that dodges the question of separating and standardizing the API from the implementation. It also dodges the discussion about who sets the design of the repository format and the API spec used to access it.
>> 
>> You're asking the Maven community to give up one of its greatest creations - the repository format that has become a de facto standard - and become completely dependent on a project whose future may be uncertain. It's easy to talk about companies as these fixtures in the market, but the fact is we're talking about giving complete control over the Maven repository API / format to a start-up. Start-ups are not known for their stability. Then, the company in control _may_ decide (unilaterally) to move the whole shebang to Eclipse. There's absolutely no role for Maven developers in this model, unless they go out and re-establish their merit on a new project.
>> 
>> I'm not talking about the merit to contribute implementation details - though the ASF concept of non-expiring merit argues strongly against losing access to that. What I'm talking about is the right to contribute to the design of the repository format, API, and SPI (now that I notice that's separate from the API). The language we use to share artifacts and metadata should not be under the sole control of a private entity.
>> 
>> Sure, there haven't been too many contributors to Maven 3. But how much of that has to do with the velocity of work done and paid for by Sonatype, the dramatic and repeated shift in direction by those paid contributions (mercury for example), the need to chase code from SVN to GitHub, to still other GitHub repositories, and the lack of discussion of the design of any of it?
>> 
>> It makes me uneasy to see how much this has become a skunkworks type of project, where much of the development takes place behind closed doors and then gets dumped on the Maven community.
>> 
>> Maven contributors established the foundational concepts (and code, from what I can tell) for Aether; Aether is a refactoring of that essential design and format. If you expect Maven to use Aether, then the Maven community deserves some say in the future of the format and API. That's my opinion.
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

A man enjoys his work when he understands the whole and when he
is responsible for the quality of the whole

 -- Christopher Alexander, A Pattern Language

Re: Merging in our Aether and Guice changes to Maven 3.x

[Ralph Goers <ra...@dslextreme.com>]

So even though I'm on vacation this week I took the time to get the code from git and read the wiki. Now I am even more concerned, even though I have read everyone's responses. 

Aether is NOT a replacement for the Wagon, from what I can tell it replaces all the artifact resolution handling. This is handled through methods like RepositorySystem.resolveDependencies. This relegates Maven to the status of  pretty much just a plugin processor.  I would be much less concerned if aether-api was hosted somewhere outside of Apache or was even javax.repository or somesuch thing. But aether-impl, etc belong in Maven, IMO.

Brian and I spoke at the last ApacheCon about the need to enhance the pom and the only way we could see to do that was to have a new project descriptor in addition to the pom. The ability to do this - and is something I have been planning on working on once 3.0 is stable - would now be out of the control of this project. 

Although I like the structure of the code very much I am inclined to do one of two things:
1. Vote -1 for inclusion.
2. Take the code as it is under the Apache license and check it in to Maven's SVN. The only thing preventing this would be the -1 vote I would expect from Sonatype employees. An alternative approach to this would be to check it into a new incubator project. This would only require a majority vote of the incubator PMC and would be allowable under the license. However, I don't consider this a viable option as it would be too disruptive to the incubator unless Sonatype supported this, which it is clear they do not.  

I believe in "The Apache Way" - Community over Code. I am not in favor of adopting a direction that relegates the Maven project to almost the point of irrelevance. However, I also believe that the community should not be blocked by a single individual so if I am the only one who feels that gutting the Maven project is a bad thing then I will simply abstain from voting. But frankly, the arguments in favor of hosting Aether outside of the ASF has left me wondering why the proposal wasn't to move the whole project out of the ASF.

And for what it is worth, I have appreciated when those of you who are employed by Sonatype have explicitly included that in your replies on this topic.

Ralph


On Aug 4, 2010, at 8:54 AM, John Casey wrote:

> 
> All due respect, but that dodges the question of separating and standardizing the API from the implementation. It also dodges the discussion about who sets the design of the repository format and the API spec used to access it.
> 
> You're asking the Maven community to give up one of its greatest creations - the repository format that has become a de facto standard - and become completely dependent on a project whose future may be uncertain. It's easy to talk about companies as these fixtures in the market, but the fact is we're talking about giving complete control over the Maven repository API / format to a start-up. Start-ups are not known for their stability. Then, the company in control _may_ decide (unilaterally) to move the whole shebang to Eclipse. There's absolutely no role for Maven developers in this model, unless they go out and re-establish their merit on a new project.
> 
> I'm not talking about the merit to contribute implementation details - though the ASF concept of non-expiring merit argues strongly against losing access to that. What I'm talking about is the right to contribute to the design of the repository format, API, and SPI (now that I notice that's separate from the API). The language we use to share artifacts and metadata should not be under the sole control of a private entity.
> 
> Sure, there haven't been too many contributors to Maven 3. But how much of that has to do with the velocity of work done and paid for by Sonatype, the dramatic and repeated shift in direction by those paid contributions (mercury for example), the need to chase code from SVN to GitHub, to still other GitHub repositories, and the lack of discussion of the design of any of it?
> 
> It makes me uneasy to see how much this has become a skunkworks type of project, where much of the development takes place behind closed doors and then gets dumped on the Maven community.
> 
> Maven contributors established the foundational concepts (and code, from what I can tell) for Aether; Aether is a refactoring of that essential design and format. If you expect Maven to use Aether, then the Maven community deserves some say in the future of the format and API. That's my opinion.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Merging in our Aether and Guice changes to Maven 3.x

[John Casey <jd...@commonjava.org>]

On 8/4/10 11:03 AM, Jason van Zyl wrote:
>
> On Aug 4, 2010, at 10:35 AM, John Casey wrote:
>
>> On 8/3/10 2:21 PM, 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.
>>
>>
>> There's too much in this thread that I this is a tad distracting from the important points, so I'm replying to the top post.
>>
>> I _really_ appreciate all the work done in getting M3 into a usable form, and in general I like the way Aether looks (I haven't had time to look into the guice shim yet). I realize there are newer thoughts on repository design since Maven took its swing at things, and we need to find a way to transition forward..."transition" because we have a large legacy of artifacts already under the Maven repository format. HOWEVER, there are a couple things here I'm pretty deeply concerned about.
>>
>>
>> 1. The repository format is a Maven concept. I'd argue that it's one of Maven's two great contributions to the world of software (the other being a decent build tool). As such, the Maven community should have some role in guiding the future of that format.
>>
>> If Maven relinquishes all ownership of the API and implementation for the piece that resolves artifacts, then we have no say in the future design of the repository Maven uses as its lifeblood. Many people who aren't Sonatype people have spent time working on that de facto specification, and they've shown the merit to earn a voice in guiding this API...at least, if it's going to be billed as a Maven-compatible Repository API.
>>
>>
>> 2. Jason, you mentioned sponsoring a Sat4j developer to work with Sonatype in the future to improve Aether. What effect is this likely to have on the aether-api module? My concern here is that we're talking about releasing Maven 3.0-beta-2 with a completely rewritten API / implementation for one of the most pivotal parts of Maven. It's not that I don't trust Benjamin and Kristian to produce high-quality code.
>>
>
> Once the API is set for Aether it will be supported forever. Essentially the Eclipse way of supporting APIs. Just like we're supporting the old Artifact APIs now with Aether being the backing implementation. We're sensitive to external consumes.
>
>> What I'm actually worried about having Aether API drift AFTER we adopt it in Maven. This will hamper anyone wishing to integrate with the Maven 3 core, whether that's Maven plugin development or Maven embedding.
>>
>
> It can't drift. Whatever is in place needs to be supported, all the plugins that use the artifact resolution APIs as they stand here now still work with.
>
>>
>> What I'd actually prefer to see is the Aether API published in some neutral location where we have an iron-clad guarantee that we won't be locked out of its design. Then, put the implementations wherever you think is best. IMO the key moving forward is to establish a standard API for resolving artifacts. IMO, this is our great failure with Plexus, that we depended directly on a container implementation, not on a container API.
>>
>> Having a stable set of specifications define their interaction with Maven would make plugin development and embedding MUCH better. In fact, I think establishing this practice might be the single best contribution we can make to Maven in the near term.
>>

All due respect, but that dodges the question of separating and 
standardizing the API from the implementation. It also dodges the 
discussion about who sets the design of the repository format and the 
API spec used to access it.

You're asking the Maven community to give up one of its greatest 
creations - the repository format that has become a de facto standard - 
and become completely dependent on a project whose future may be 
uncertain. It's easy to talk about companies as these fixtures in the 
market, but the fact is we're talking about giving complete control over 
the Maven repository API / format to a start-up. Start-ups are not known 
for their stability. Then, the company in control _may_ decide 
(unilaterally) to move the whole shebang to Eclipse. There's absolutely 
no role for Maven developers in this model, unless they go out and 
re-establish their merit on a new project.

I'm not talking about the merit to contribute implementation details - 
though the ASF concept of non-expiring merit argues strongly against 
losing access to that. What I'm talking about is the right to contribute 
to the design of the repository format, API, and SPI (now that I notice 
that's separate from the API). The language we use to share artifacts 
and metadata should not be under the sole control of a private entity.

Sure, there haven't been too many contributors to Maven 3. But how much 
of that has to do with the velocity of work done and paid for by 
Sonatype, the dramatic and repeated shift in direction by those paid 
contributions (mercury for example), the need to chase code from SVN to 
GitHub, to still other GitHub repositories, and the lack of discussion 
of the design of any of it?

It makes me uneasy to see how much this has become a skunkworks type of 
project, where much of the development takes place behind closed doors 
and then gets dumped on the Maven community.

Maven contributors established the foundational concepts (and code, from 
what I can tell) for Aether; Aether is a refactoring of that essential 
design and format. If you expect Maven to use Aether, then the Maven 
community deserves some say in the future of the format and API. That's 
my opinion.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Merging in our Aether and Guice changes to Maven 3.x

[Jason van Zyl <ja...@sonatype.com>]

On Aug 4, 2010, at 10:35 AM, John Casey wrote:

> On 8/3/10 2:21 PM, 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.
> 
> 
> There's too much in this thread that I this is a tad distracting from the important points, so I'm replying to the top post.
> 
> I _really_ appreciate all the work done in getting M3 into a usable form, and in general I like the way Aether looks (I haven't had time to look into the guice shim yet). I realize there are newer thoughts on repository design since Maven took its swing at things, and we need to find a way to transition forward..."transition" because we have a large legacy of artifacts already under the Maven repository format. HOWEVER, there are a couple things here I'm pretty deeply concerned about.
> 
> 
> 1. The repository format is a Maven concept. I'd argue that it's one of Maven's two great contributions to the world of software (the other being a decent build tool). As such, the Maven community should have some role in guiding the future of that format.
> 
> If Maven relinquishes all ownership of the API and implementation for the piece that resolves artifacts, then we have no say in the future design of the repository Maven uses as its lifeblood. Many people who aren't Sonatype people have spent time working on that de facto specification, and they've shown the merit to earn a voice in guiding this API...at least, if it's going to be billed as a Maven-compatible Repository API.
> 
> 
> 2. Jason, you mentioned sponsoring a Sat4j developer to work with Sonatype in the future to improve Aether. What effect is this likely to have on the aether-api module? My concern here is that we're talking about releasing Maven 3.0-beta-2 with a completely rewritten API / implementation for one of the most pivotal parts of Maven. It's not that I don't trust Benjamin and Kristian to produce high-quality code.
> 

Once the API is set for Aether it will be supported forever. Essentially the Eclipse way of supporting APIs. Just like we're supporting the old Artifact APIs now with Aether being the backing implementation. We're sensitive to external consumes.

> What I'm actually worried about having Aether API drift AFTER we adopt it in Maven. This will hamper anyone wishing to integrate with the Maven 3 core, whether that's Maven plugin development or Maven embedding.
> 

It can't drift. Whatever is in place needs to be supported, all the plugins that use the artifact resolution APIs as they stand here now still work with.

> 
> What I'd actually prefer to see is the Aether API published in some neutral location where we have an iron-clad guarantee that we won't be locked out of its design. Then, put the implementations wherever you think is best. IMO the key moving forward is to establish a standard API for resolving artifacts. IMO, this is our great failure with Plexus, that we depended directly on a container implementation, not on a container API.
> 
> Having a stable set of specifications define their interaction with Maven would make plugin development and embedding MUCH better. In fact, I think establishing this practice might be the single best contribution we can make to Maven in the near term.
> 
> Thanks,
> 
> -john
> 
> 
>> 
>> 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)
>> 
>> 
>> 
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people. 

 -- Paul Graham

Re: Merging in our Aether and Guice changes to Maven 3.x

[John Casey <jd...@commonjava.org>]

On 8/3/10 2:21 PM, 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.


There's too much in this thread that I this is a tad distracting from 
the important points, so I'm replying to the top post.

I _really_ appreciate all the work done in getting M3 into a usable 
form, and in general I like the way Aether looks (I haven't had time to 
look into the guice shim yet). I realize there are newer thoughts on 
repository design since Maven took its swing at things, and we need to 
find a way to transition forward..."transition" because we have a large 
legacy of artifacts already under the Maven repository format. HOWEVER, 
there are a couple things here I'm pretty deeply concerned about.


1. The repository format is a Maven concept. I'd argue that it's one of 
Maven's two great contributions to the world of software (the other 
being a decent build tool). As such, the Maven community should have 
some role in guiding the future of that format.

If Maven relinquishes all ownership of the API and implementation for 
the piece that resolves artifacts, then we have no say in the future 
design of the repository Maven uses as its lifeblood. Many people who 
aren't Sonatype people have spent time working on that de facto 
specification, and they've shown the merit to earn a voice in guiding 
this API...at least, if it's going to be billed as a Maven-compatible 
Repository API.


2. Jason, you mentioned sponsoring a Sat4j developer to work with 
Sonatype in the future to improve Aether. What effect is this likely to 
have on the aether-api module? My concern here is that we're talking 
about releasing Maven 3.0-beta-2 with a completely rewritten API / 
implementation for one of the most pivotal parts of Maven. It's not that 
I don't trust Benjamin and Kristian to produce high-quality code.

What I'm actually worried about having Aether API drift AFTER we adopt 
it in Maven. This will hamper anyone wishing to integrate with the Maven 
3 core, whether that's Maven plugin development or Maven embedding.


What I'd actually prefer to see is the Aether API published in some 
neutral location where we have an iron-clad guarantee that we won't be 
locked out of its design. Then, put the implementations wherever you 
think is best. IMO the key moving forward is to establish a standard API 
for resolving artifacts. IMO, this is our great failure with Plexus, 
that we depended directly on a container implementation, not on a 
container API.

Having a stable set of specifications define their interaction with 
Maven would make plugin development and embedding MUCH better. In fact, 
I think establishing this practice might be the single best contribution 
we can make to Maven in the near term.

Thanks,

-john


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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Merging in our Aether and Guice changes to Maven 3.x

[Benjamin Bentmann <be...@udo.edu>]

Mark Derricutt wrote:

> Can the guice stuff be merged in cleanly independent of aether?

Yes, see patch at http://jira.codehaus.org/browse/MNG-4749.

There are no interdependencies between Aether and the 
Plexus-Guice-Bridge. The Git branch I mentioned earlier aggregates them 
for the sole purpose of providing me the Maven distro I use for daily 
work/testing.


Benjamin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Merging in our Aether and Guice changes to Maven 3.x

[Paul Benedict <pb...@apache.org>]

To my point earlier, perhaps beta-2 could be tagged/cut/released before the
merges take place. Once the merges take place, you could spin beta-3 with
these new additions rather quickly. I would consider that to be good plan --
at one time, Jason did posted that wanted betas to be released every 2
weeks.

On Wed, Aug 4, 2010 at 10:28 PM, Mark Derricutt <ma...@talios.com> wrote:

> Out of curiository - are the guice/aether changes available in separate
> branches at all?
>
> Can the guice stuff be merged in cleanly independent of aether?  If so -
> I'd
> like to see the guice code merged in, and deal with aether as a separate
> thing.
>
>
> --
> Pull me down under...
>
>
>
> On Wed, Aug 4, 2010 at 6:21 AM, Jason van Zyl <ja...@sonatype.com> wrote:
>
> > So please let us know if you have any objections.
>

Re: Merging in our Aether and Guice changes to Maven 3.x

[Mark Derricutt <ma...@talios.com>]

Out of curiository - are the guice/aether changes available in separate
branches at all?

Can the guice stuff be merged in cleanly independent of aether?  If so - I'd
like to see the guice code merged in, and deal with aether as a separate
thing.


-- 
Pull me down under...



On Wed, Aug 4, 2010 at 6:21 AM, Jason van Zyl <ja...@sonatype.com> wrote:

> So please let us know if you have any objections.

Re: Merging in our Aether and Guice changes to Maven 3.x

[Ralph Goers <ra...@dslextreme.com>]

On Aug 4, 2010, at 7:04 AM, Brian Fox wrote:

>> 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.
>> 
> 
> Knowing you in person, I'll take the above with a grain of salt that
> maybe it's not exactly what you meant. However my first reading of
> this was alarming.

There is no good way to explain exactly what I meant, but I'll try.  I realize Jason started this project but:
1. "The Maven Company" thing has bugged me for a long time. It is in clear violation of an ASF trademark but Jason says tough shit. We on the PMC let it go because in the whole scheme of things it isn't that big of a deal.
2. Periodically I am in meeetings with folks at my company with people who start a sentence with "Jason said"... and then go on to say something that has never been discussed on these lists. That ticks me off because they believe he is the BDFL of Maven when Apache doesn't allow for such a title.
3. I see posts like the one I responded to on a regular basis that imply the decision has already been made and the rest of the community doesn't have a voice. My response would not have included the above had the email started with something like "I think hosting Aether at Eclipse is a great choice and would like consensus for that" vs "Aether will be at Eclipse. Let me know if you have any objections".  The first is about team building while the second is the BDFL model.

I realize the above is not going to sit well with Jason. Individually none of the above are a big deal, but when added up they make me very concerned about this project.


> 
> People have a right to produce and publish code anywhere they choose.
> What we have purview over as a Maven project is only the code that
> comes in here. So you could choose to say you don't like Maven
> depending upon this external dependency, but that should be
> rationalized with the fact that the current resolution logic is flawed
> and unmaintainable. No one in the years I've been around has
> significantly stepped up to try and fix it (I may be the last one
> besides Benjamin that really dove in and fixed bugs and that was years
> ago). Continuing to think the current resolution code will magically
> improve while externally people are inventing and reinventing the same
> pieces of code is not a good idea.

I don't work for Sonatype. I don't work on Maven full time. I've started to look at new code previously only to have it pulled out making my effort a waste of time.  You know very well what problems I want to address - I've mentioned them several times and attempted to fix one of them, ending with you and me reviewing the code. Since then I've been told on this list that those issues cannot be addressed until after 3.0. Who knew that 3.0 was still going to be in development years later.

> 
> 
>> I'm going to have to give serious consideration as to whether I could accept this dependency without the code also residing at Apache.
>> 
> The key question here is why is this different than ANY other
> dependency we choose to use that's not at Apache?

The difference is in how critical the component is to the overall project. Maven and the repository go hand in hand. Maven cannot run without it. From an external point of view when people think of Maven they think of poms and the repository. 
 
> 
> Maven is a consumer of this api, which is separate than the fact that
> Maven specific bits are the things Aether is attempting to make
> generic at the moment. It's a grey line sure about what is core to
> maven and what is needed by all consumers of this api. I'm sure Ivy,
> Gradle etc have written code to read Maven specific bits. Should that
> code also be located here? Are you upset that they didn't? These are
> obviously facetious question because I know you don't actually think
> that, but asking them illustrates the distinctions a bit.
> 
> I for one would love if anyone consuming and producing artifacts for
> Maven repos could use the same code easily. Having all these
> permutations makes a mess of the repos when files and metadata aren't
> updated correctly.
> 
> It's obvious that projects other than Maven won't use the code in
> Maven to do it, evidenced by the fact that they don't today. Having
> this api code in a neutral location makes that hurdle, even if it's a
> mental one, non-existent. Projects that "compete" won't use each
> other's code, but everyone uses the same external dependencies
> already. (think about logging...everyone uses log4j, slf4j etc. If we
> made log4m and dropped it in maven's scm, would Gradle, Ivy, Buildr
> use it? Doubtful... at the same time, would the Maven project start
> depending upon the code in gradle for resolution? Also doubtful.)

I agree with all of the above except:
a. No one uses the code in Maven because it wasn't designed to do it. Providing Aether as a separate jar solves that problem no matter where it resides.
b. Saying Ivy or Gradle won't use code produced by Maven because we compete is sheer conjecture. 
c. I haven't seen anyone say that the code has to be bundled as part of Maven. As a Maven subproject or an independent ASF project it can be packaged separately.

So really, I just don't buy the argument that moving this to a separate foundation is required so that other projects will use it.  I do buy into the argument that this code needs to be completely separate and even have its own build lifecycle.


Ralph


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Merging in our Aether and Guice changes to Maven 3.x

[Brett Porter <br...@apache.org>]

I'll try and sum up some things I expressed on IRC, in response to Brian's message.

I'll be clear upfront that we have no right to tell Sonatype where they host code they wrote, so let's focus on the impact for Maven itself. Equally so, no matter how generous they are with a donation: solutions that move project scope or code, or tie the project to a single company or individual - are close to a non-starter IMO.

On 05/08/2010, at 12:04 AM, Brian Fox wrote:

> The key question here is why is this different than ANY other
> dependency we choose to use that's not at Apache?

It's different because it's changing the scope of the current Maven project, and because of the increased likelihood in having to chase code across projects to develop Maven. The problem will always exist, but we can do what we can to narrow our exposure.

It would make my occasional stint as Chief JIRA Monkey even more annoying :)

> 
> I for one would love if anyone consuming and producing artifacts for
> Maven repos could use the same code easily. Having all these
> permutations makes a mess of the repos when files and metadata aren't
> updated correctly.

+1, and I don't think anyone is arguing that.

> 
> It's obvious that projects other than Maven won't use the code in
> Maven to do it, evidenced by the fact that they don't today.

How much of that is crap API, poor documentation, etc. vs. the other factors though?

> Having
> this api code in a neutral location makes that hurdle, even if it's a
> mental one, non-existent. Projects that "compete" won't use each
> other's code, but everyone uses the same external dependencies
> already. (think about logging...everyone uses log4j, slf4j etc. If we
> made log4m and dropped it in maven's scm, would Gradle, Ivy, Buildr
> use it? Doubtful... at the same time, would the Maven project start
> depending upon the code in gradle for resolution? Also doubtful.)

What you touch on also goes in the other direction. The reason they'd not do that, assuming it was well coded and accessible, is lack of control. That could be a problem here.

I'm not arguing against the value of being separate to increase the scope of the library. I can see where that is a potential growth area for it outside of Maven, and while I don't entirely agree with some points raised, I recognise the concerns about being able to collaborate on all that inside Maven.

But what I most want resolved is the concern of losing control over the bits Maven has today. I would ideally like to see the API Maven uses, and expects plugins to use, here. I would like to see the Maven implementation for a local repository and a Maven-format remote repository here. The rest matters far less to me.

Is there any scope for a trimmed down API here, that is pretty much final now, and a wider-scoped Aether (that depends on the Maven API and legacy implementation as a basis) elsewhere? Or are there other alternatives that could be suggested?

There are a number of reasons that I don't like about how we got here, but we've no choice but to put them behind us and figure out the implementation details. We all agree so far that refactoring the API is a good thing that needs to be available in Maven 3.0. I think we're a bit short on details of what that really means for Maven developers, and for Maven plugin authors after 3.0, though.

Thanks,
Brett

--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Merging in our Aether and Guice changes to Maven 3.x

[Brian Fox <br...@infinity.nu>]

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

Knowing you in person, I'll take the above with a grain of salt that
maybe it's not exactly what you meant. However my first reading of
this was alarming.

People have a right to produce and publish code anywhere they choose.
What we have purview over as a Maven project is only the code that
comes in here. So you could choose to say you don't like Maven
depending upon this external dependency, but that should be
rationalized with the fact that the current resolution logic is flawed
and unmaintainable. No one in the years I've been around has
significantly stepped up to try and fix it (I may be the last one
besides Benjamin that really dove in and fixed bugs and that was years
ago). Continuing to think the current resolution code will magically
improve while externally people are inventing and reinventing the same
pieces of code is not a good idea.


> I'm going to have to give serious consideration as to whether I could accept this dependency without the code also residing at Apache.
>
The key question here is why is this different than ANY other
dependency we choose to use that's not at Apache?

Maven is a consumer of this api, which is separate than the fact that
Maven specific bits are the things Aether is attempting to make
generic at the moment. It's a grey line sure about what is core to
maven and what is needed by all consumers of this api. I'm sure Ivy,
Gradle etc have written code to read Maven specific bits. Should that
code also be located here? Are you upset that they didn't? These are
obviously facetious question because I know you don't actually think
that, but asking them illustrates the distinctions a bit.

I for one would love if anyone consuming and producing artifacts for
Maven repos could use the same code easily. Having all these
permutations makes a mess of the repos when files and metadata aren't
updated correctly.

It's obvious that projects other than Maven won't use the code in
Maven to do it, evidenced by the fact that they don't today. Having
this api code in a neutral location makes that hurdle, even if it's a
mental one, non-existent. Projects that "compete" won't use each
other's code, but everyone uses the same external dependencies
already. (think about logging...everyone uses log4j, slf4j etc. If we
made log4m and dropped it in maven's scm, would Gradle, Ivy, Buildr
use it? Doubtful... at the same time, would the Maven project start
depending upon the code in gradle for resolution? Also doubtful.)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Merging in our Aether and Guice changes to Maven 3.x

[nicolas de loof <ni...@gmail.com>]

>
>
> > 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
>
> +1
>
> Guice allready as its own large community of users and maintainers.
> It's a general 'purpose' API.
>
> Aether is new, Maven related and need to create its own community.
> Why not moving it to ASF as a Maven subproject ?
>
>
+1 for Guice

As discussed here [1], Guice would help a lot integrating nicelly Maven3
into Hudson. It also has a larger user base and doc than Plexus, and has
been proposed for a while on this ML as a replacement. The Git branch is
also avialable for testing for a while

+0 for Aether.
It looks technicaly nice according to the code sample [2]. I just share the
concern about a major component beeing outside Maven SCM.

[1]
http://maven.40175.n5.nabble.com/Maven3-with-guice-was-Re-Maven-3-tests-td219507.html#a219507

[2]
http://github.com/sonatype/sonatype-aether/blob/master/aether-demo/src/main/java/demo/RepoSys.java

Nicolas

Re: Merging in our Aether and Guice changes to Maven 3.x

[Henri Gomez <he...@gmail.com>]

2010/8/4 Stephen Connolly <st...@gmail.com>:

> 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

+1

Guice allready as its own large community of users and maintainers.
It's a general 'purpose' API.

Aether is new, Maven related and need to create its own community.
Why not moving it to ASF as a Maven subproject ?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Merging in our Aether and Guice changes to Maven 3.x

[Stephen Connolly <st...@gmail.com>]

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.connolly@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 <ra...@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
> >>>>>>> brett@apache.org
> >>>>>>> http://brettporter.wordpress.com/
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: dev-help@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
>
>
>
>

Re: Merging in our Aether and Guice changes to Maven 3.x

[Jason van Zyl <ja...@sonatype.com>]

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.

> 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 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. 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 <st...@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 <ra...@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
>>>>>>> brett@apache.org
>>>>>>> http://brettporter.wordpress.com/
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@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

Re: Merging in our Aether and Guice changes to Maven 3.x

[Henri Gomez <he...@gmail.com>]

2010/8/4 Stephen Connolly <st...@gmail.com>:

> Alternatively, host the Aether API in one place (hey why not codehaus), the
> Maven Repo impl in Apache and the p2 repo impl in Eclipse ;-)

Very good idea

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Merging in our Aether and Guice changes to Maven 3.x

[Stephen Connolly <st...@gmail.com>]

On 4 August 2010 13:42, Henri Gomez <he...@gmail.com> wrote:

> 2010/8/4 Stephen Connolly <st...@gmail.com>:
>
> > 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...
> 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.
>
> Aether and p2 make me think this project should be best suited for the
> Eclipse Foundation, as subproject.
>

Eclipse Foundation's bar for commit access seems quite high.  I'd prefer a
lower bar if we are 1st/2nd adopter of a project and we are considering
where the project is hosted.

Alternatively, host the Aether API in one place (hey why not codehaus), the
Maven Repo impl in Apache and the p2 repo impl in Eclipse ;-)

-Stephen


>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: Merging in our Aether and Guice changes to Maven 3.x

[Henri Gomez <he...@gmail.com>]

2010/8/4 Stephen Connolly <st...@gmail.com>:

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

Aether and p2 make me think this project should be best suited for the
Eclipse Foundation, as subproject.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Merging in our Aether and Guice changes to Maven 3.x

[Stephen Connolly <st...@gmail.com>]

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.

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... 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 <st...@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 <ra...@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
>> >>>> brett@apache.org
>> >>>> http://brettporter.wordpress.com/
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@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)
>>
>>
>>
>>
>

Re: Merging in our Aether and Guice changes to Maven 3.x

[Paul Benedict <pb...@apache.org>]

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 <
stephen.alan.connolly@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 <ra...@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
> > >>>> brett@apache.org
> > >>>> http://brettporter.wordpress.com/
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> ---------------------------------------------------------------------
> > >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> > >> For additional commands, e-mail: dev-help@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)
> >
> >
> >
> >
>

Re: Merging in our Aether and Guice changes to Maven 3.x

[Stephen Connolly <st...@gmail.com>]

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 <ra...@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
> >>>> brett@apache.org
> >>>> http://brettporter.wordpress.com/
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@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)
>
>
>
>

Re: Merging in our Aether and Guice changes to Maven 3.x

[Jason van Zyl <ja...@sonatype.com>]

We can also all pop into IRC if you want a more productive, real-time discussion. Also happy to host a call. Might as well get everything aired out sooner rather then later.

On Aug 4, 2010, at 7:35 AM, Jason van Zyl wrote:

> 
> On Aug 4, 2010, at 4:00 AM, Stephen Connolly wrote:
> 
>> On 4 August 2010 08:06, Ralph Goers <ra...@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
>>>>> brett@apache.org
>>>>> http://brettporter.wordpress.com/
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@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
---------------------------------------------------------

You are never dedicated to something you have complete confidence in.
No one is fanatically shouting that the sun is going to rise tomorrow.
They know it is going to rise tomorrow. When people are fanatically
dedicated to political or religious faiths or any other kind of 
dogmas or goals, it's always because these dogmas or
goals are in doubt.

  -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance

Re: Merging in our Aether and Guice changes to Maven 3.x

[Jason van Zyl <ja...@sonatype.com>]

On Aug 4, 2010, at 4:00 AM, Stephen Connolly wrote:

> On 4 August 2010 08:06, Ralph Goers <ra...@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
>>>> brett@apache.org
>>>> http://brettporter.wordpress.com/
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@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)

Re: Merging in our Aether and Guice changes to Maven 3.x

[Stephen Connolly <st...@gmail.com>]

On 4 August 2010 08:06, Ralph Goers <ra...@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

-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
> >> brett@apache.org
> >> http://brettporter.wordpress.com/
> >>
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: Merging in our Aether and Guice changes to Maven 3.x

[Jesse McConnell <je...@gmail.com>]

If the future of the repository is to be akin to p2 then I think
living at eclipse is the best place for it.

If it lives at eclipse then it has all IP concerned managed out of the
gates and companies are very comfortable with eclipse IP practices.
Living at eclipse it will likely be osgified out of the gate which is
great and since tycho is going to be an initial consumer of it I think
that also plays with with it being at eclipse.  If its as good as I
suspect it is then it will be a commodity component in no time flat
and maven will be just one user (albeit an important one) among many.
Having it exist under maven as a subproject would probably hamper its
uptake more then anything in the long run as the concept of consuming
stuff out of a repository has moved on quite a bit since maven2 really
starting making people aware of it.

Viewing it outside of the scope of just maven, I think living at
eclipse is a good home for the technology, or it would have to be
another top lvl project at apache with all the overhead that would
require (not that eclipse doesn't have overhead..sheesh)

my thoughts,
jesse

--
jesse mcconnell
jesse.mcconnell@gmail.com



On Wed, Aug 4, 2010 at 07:56, Olivier Lamy <ol...@apache.org> wrote:
> I don't see any veto here.
> Perso, I like this change (at least/especially the plexus-guice stuff).
> Concerning the other part, I didn't work enough and don't have enough
> time to work on this part of the project to have a clear idea.
>
> As I haven't seen vote here , I push my +1.
>
> And IMHO, earlier thoses changes will be here and released better it will be
>
> And btw, your position regarding eather codebase place can be review later.
> If the issue is only long release process etc.., you can change when
> the codebase will have reach a good stability...
>
> 2010/8/4 Jason van Zyl <ja...@sonatype.com>:
>> If anyone wants to -1 then you are free to do so.
>>
>> I've given my reasoning for Aether not being here, I won't go on ad nauseum.
>>
>> I'll leave it to the objectors to come up with a timeline for deciding. There's no rush.
>>
>> On Aug 4, 2010, at 5:03 AM, Olivier Lamy wrote:
>>
>>> +1 : agree on having aether in asf too.
>>>
>>> 2010/8/4 Ralph Goers <ra...@dslextreme.com>:
>>>> 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.
>>>>
>>>> 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
>>>>>> brett@apache.org
>>>>>> http://brettporter.wordpress.com/
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Olivier
>>> http://twitter.com/olamy
>>> http://fr.linkedin.com/in/olamy
>>> http://www.viadeo.com/fr/profile/olivier.lamy7
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@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
>>
>>
>>
>>
>
>
>
> --
> Olivier
> http://twitter.com/olamy
> http://fr.linkedin.com/in/olamy
> http://www.viadeo.com/fr/profile/olivier.lamy7
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Merging in our Aether and Guice changes to Maven 3.x

[Olivier Lamy <ol...@apache.org>]

I don't see any veto here.
Perso, I like this change (at least/especially the plexus-guice stuff).
Concerning the other part, I didn't work enough and don't have enough
time to work on this part of the project to have a clear idea.

As I haven't seen vote here , I push my +1.

And IMHO, earlier thoses changes will be here and released better it will be

And btw, your position regarding eather codebase place can be review later.
If the issue is only long release process etc.., you can change when
the codebase will have reach a good stability...

2010/8/4 Jason van Zyl <ja...@sonatype.com>:
> If anyone wants to -1 then you are free to do so.
>
> I've given my reasoning for Aether not being here, I won't go on ad nauseum.
>
> I'll leave it to the objectors to come up with a timeline for deciding. There's no rush.
>
> On Aug 4, 2010, at 5:03 AM, Olivier Lamy wrote:
>
>> +1 : agree on having aether in asf too.
>>
>> 2010/8/4 Ralph Goers <ra...@dslextreme.com>:
>>> 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.
>>>
>>> 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
>>>>> brett@apache.org
>>>>> http://brettporter.wordpress.com/
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Olivier
>> http://twitter.com/olamy
>> http://fr.linkedin.com/in/olamy
>> http://www.viadeo.com/fr/profile/olivier.lamy7
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@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
>
>
>
>



-- 
Olivier
http://twitter.com/olamy
http://fr.linkedin.com/in/olamy
http://www.viadeo.com/fr/profile/olivier.lamy7

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Merging in our Aether and Guice changes to Maven 3.x

[Jason van Zyl <ja...@sonatype.com>]

If anyone wants to -1 then you are free to do so. 

I've given my reasoning for Aether not being here, I won't go on ad nauseum.

I'll leave it to the objectors to come up with a timeline for deciding. There's no rush.

On Aug 4, 2010, at 5:03 AM, Olivier Lamy wrote:

> +1 : agree on having aether in asf too.
> 
> 2010/8/4 Ralph Goers <ra...@dslextreme.com>:
>> 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.
>> 
>> 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
>>>> brett@apache.org
>>>> http://brettporter.wordpress.com/
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>> 
>> 
> 
> 
> 
> -- 
> Olivier
> http://twitter.com/olamy
> http://fr.linkedin.com/in/olamy
> http://www.viadeo.com/fr/profile/olivier.lamy7
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@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

Re: Merging in our Aether and Guice changes to Maven 3.x

[Olivier Lamy <ol...@apache.org>]

+1 : agree on having aether in asf too.

2010/8/4 Ralph Goers <ra...@dslextreme.com>:
> 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.
>
> 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
>>> brett@apache.org
>>> http://brettporter.wordpress.com/
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>



-- 
Olivier
http://twitter.com/olamy
http://fr.linkedin.com/in/olamy
http://www.viadeo.com/fr/profile/olivier.lamy7

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Merging in our Aether and Guice changes to Maven 3.x

[Ralph Goers <ra...@dslextreme.com>]

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. 

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
>> brett@apache.org
>> http://brettporter.wordpress.com/
>> 
>> 
>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Merging in our Aether and Guice changes to Maven 3.x

[Jason van Zyl <ja...@sonatype.com>]

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
> brett@apache.org
> http://brettporter.wordpress.com/
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@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

Re: Merging in our Aether and Guice changes to Maven 3.x

[Brett Porter <br...@apache.org>]

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

Actually it wasn't. I think the only reason I know about it is because you told me directly and because I follow your twitter feed. I hope it's clear that world -> PMC -> developers is not an optimal direction for getting folks here involved.

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

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.

I'm torn on this. For starters, there's clearly a need for something better. One of the first tasks I created on Maven 2 (over 5 years ago now - http://jira.codehaus.org/browse/MNG-140), was to re-do maven-artifact. In the end, I never got to that task and instead built a lot on top of it before we decided to ship Maven 2, and we suffered for not revisiting it. So, bear in mind I have a fair emotional investment in the code that just got wiped away :)

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.

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.

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?

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

Thanks,
Brett

--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Merging in our Aether and Guice changes to Maven 3.x

[Benjamin Bentmann <be...@udo.edu>]

Hervé BOUTEMY wrote:

> I had a look at the branch, and don't understand how the new maven-artifact-
> descriptor module is used to extend Aether in Maven 3.

It enables Aether to extract dependency information out of POMs, similar 
in purpose to the MavenMetadataSource in 2.x

> - RepositorySystem interface: resolveDependencies methods are about transitive
> dependencies, while other methods are about reading artifacts from or putting
> artifacts into repository. [...] Is it possible to have transitive dependency methods and classes
> into a different package?

It was a design goal to present API clients a single entry point to the 
repo system and not have them hunt for all the various components the 
impl can be split into as we have now.

> Is there something available about P2 integration?

No that I know of.


Benjamin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Merging in our Aether and Guice changes to Maven 3.x

[Hervé BOUTEMY <he...@free.fr>]

Le mardi 03 août 2010, Benjamin Bentmann a écrit :
> Jason van Zyl wrote:
> > At any rate we would like to merge these changes in and make plans to
> > release 3.0-beta-2.
> 
> Just in case, those changes currently live at
> http://github.com/bentmann/maven-3/

I had a look at the branch, and don't understand how the new maven-artifact-
descriptor module is used to extend Aether in Maven 3.

The question of relations between Aether And Maven specifics is not clear to 
me for the moment: I'm digging deeper into the code.

I have 3 questions:

- aether-api: shouldn't it have its own release cycle, different from other 
modules? I worked on retro-documenting how reporting-api and doxia-api evolved 
over time, which releases where exactly the same code, and which ones added a 
little evolution, I think that having the same version for aether API and 
implementation will lead to same issues

- RepositorySystem interface: resolveDependencies methods are about transitive 
dependencies, while other methods are about reading artifacts from or putting 
artifacts into repository. Transitive dependencies need to interpret pom 
content, while getting or putting an artifact doesn't require to understand 
pom format. Is it possible to have transitive dependency methods and classes 
into a different package? I think this is the part that can be extended, with 
lots of different options for algorithms, formats, and so on.


- Aether seems really an interesting piece of software. But I still don't see 
how Maven and P2 will integrate their specific parts into Aether's umbrella. 
Is there something available about P2 integration?


Regards,

Hervé


> 
> 
> Benjamin
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Merging in our Aether and Guice changes to Maven 3.x

[Jason van Zyl <ja...@sonatype.com>]

On Aug 3, 2010, at 3:20 PM, Olivier Lamy wrote:

> Hi,
> No particular objections.
> The site plugin branch for maven 3 now fail. (I haven't time to debug it more).
> After the merge, how long will we have to add some "hack" to make it work ?
> 

I don't think there's any particular rush. If you want to spend a couple days to try and sort it out then go for it. We can help you as well.

> 2010/8/3 Benjamin Bentmann <be...@udo.edu>:
>> Jason van Zyl wrote:
>> 
>>> At any rate we would like to merge these changes in and make plans to
>>> release 3.0-beta-2.
>> 
>> Just in case, those changes currently live at
>> http://github.com/bentmann/maven-3/
>> 
>> 
>> Benjamin
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>> 
>> 
> 
> 
> 
> -- 
> Olivier
> http://twitter.com/olamy
> http://fr.linkedin.com/in/olamy
> http://www.viadeo.com/fr/profile/olivier.lamy7
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@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)

Re: Merging in our Aether and Guice changes to Maven 3.x

[Olivier Lamy <ol...@apache.org>]

Hi,
No particular objections.
The site plugin branch for maven 3 now fail. (I haven't time to debug it more).
After the merge, how long will we have to add some "hack" to make it work ?

2010/8/3 Benjamin Bentmann <be...@udo.edu>:
> Jason van Zyl wrote:
>
>> At any rate we would like to merge these changes in and make plans to
>> release 3.0-beta-2.
>
> Just in case, those changes currently live at
> http://github.com/bentmann/maven-3/
>
>
> Benjamin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>



-- 
Olivier
http://twitter.com/olamy
http://fr.linkedin.com/in/olamy
http://www.viadeo.com/fr/profile/olivier.lamy7

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Merging in our Aether and Guice changes to Maven 3.x

[Benjamin Bentmann <be...@udo.edu>]

Jason van Zyl wrote:

> At any rate we would like to merge these changes in and make plans to release 3.0-beta-2.

Just in case, those changes currently live at
http://github.com/bentmann/maven-3/


Benjamin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org