Developing Maven 2.1

[Jason van Zyl-2]

I have put together a visual of the system, some information on using  
m2eclipse to debug the entire platform, and the use of Hudson for  
testing the resulting system.

http://docs.codehaus.org/display/MAVEN/Developing+Maven+2.1

The guide included there (put together by Igor) should allow anyone to  
debug the entire toolchain (Plexus, XBR, Classworlds, Maven ...) from  
within Eclipse which will make developing and debugging easier. You  
can actually execute Maven plugins from within the workspace (i.e you  
don't have to install it) using m2e.

I will start collapsing all the cruft that's built up around 2.1 and  
flesh out that landing page as I start automating more in Hudson, and  
building out the Hudson nodes that will support other standard  
platforms.

If you want to surf around Hudson you can look at it here:

http://ci.sonatype.org/

There are groups there for Maven 2.1, Plexus, Maven IDE (really  
embedder consumers), and I will also limit the plugins to the default  
lifecycles of the commonly used packagings like JAR, and WAR. John has  
also started creating automated ways to release to stage, and  
subsequent promotion upon success. So for any component in the tool  
chain there will be a way to do a consistent release from a canonical  
machine.

I am also working with the Apache Infrastructure team to integrate the  
Contegix folks who are the ones who currently host all the hardware  
we're using. Maven's central repository, our Hudson instance, and our  
Nexus instance. So, in short order, the Contegix hardware will be  
official Apache hardware.

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
----------------------------------------------------------

A language that doesn’t affect the way you think about programming is  
not worth knowing.

  -— Alan Perlis


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

[brettporter]

On 06/07/2008, at 3:56 AM, Jason van Zyl wrote:

> I am also working with the Apache Infrastructure team to integrate  
> the Contegix folks who are the ones who currently host all the  
> hardware we're using. Maven's central repository, our Hudson  
> instance, and our Nexus instance. So, in short order, the Contegix  
> hardware will be official Apache hardware.

Can you be a bit more specific about how you are proposing this could  
be structured in your mind? When the board approved my request to fund  
this in February, it was only to host the central repository. I find  
it surprising infra would be looking to support another CI setup now -  
so are you saying the new set up will be 100% ASF/Maven dedicated like  
the repo box, or just continue to use the shared/volunteer setup and  
that Contegix and Infra will work more closely together through the  
other?

Thanks,
Brett

>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
> A language that doesn’t affect the way you think about programming  
> is not worth knowing.
>
> -— Alan Perlis
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

--
Brett Porter
brett@...
http://blogs.exist.com/bporter/


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

[Jason van Zyl-2]

On 6-Jul-08, at 10:08 AM, Brett Porter wrote:

>
> On 06/07/2008, at 3:56 AM, Jason van Zyl wrote:
>
>> I am also working with the Apache Infrastructure team to integrate  
>> the Contegix folks who are the ones who currently host all the  
>> hardware we're using. Maven's central repository, our Hudson  
>> instance, and our Nexus instance. So, in short order, the Contegix  
>> hardware will be official Apache hardware.
>
> Can you be a bit more specific about how you are proposing this  
> could be structured in your mind? When the board approved my request  
> to fund this in February, it was only to host the central  
> repository. I find it surprising infra would be looking to support  
> another CI setup now - so are you saying the new set up will be 100%  
> ASF/Maven dedicated like the repo box, or just continue to use the  
> shared/volunteer setup and that Contegix and Infra will work more  
> closely together through the other?

We are still chatting about what's actually going to happen (myself,  
Joe/Justin/Paul/Matthew Porter). But the general idea is that Contegix  
would become part of the infrastructure. First thing we're talking  
about is the repository, the CI setup Sonatype is paying for and how  
that gets integrated, if it does, hasn't been discussed. It would be  
something that Contegix supports irrespective. But as of today we have  
no reliable CI infrastructure so I'm using Sonatype machines.  
Hopefully it just becomes a cooperative setup and if we have things  
running at Contegix the Apache infra people will have access if they  
want to do anything.

>
>
> Thanks,
> Brett
>
>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder,  Apache Maven
>> jason at sonatype dot com
>> ----------------------------------------------------------
>>
>> A language that doesn’t affect the way you think about programming  
>> is not worth knowing.
>>
>> -— Alan Perlis
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>
> --
> Brett Porter
> brett@...
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
----------------------------------------------------------

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


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

[John Casey-5]

Jason van Zyl wrote:
>
> There are groups there for Maven 2.1, Plexus, Maven IDE (really
> embedder consumers), and I will also limit the plugins to the default
> lifecycles of the commonly used packagings like JAR, and WAR. John has
> also started creating automated ways to release to stage, and
> subsequent promotion upon success. So for any component in the tool
> chain there will be a way to do a consistent release from a canonical
> machine.
Just for posterity (if we're going to be using this as an official
release vector for the entire project):

Jason's referring to a ruby script I wrote to lookup the version string
for a particular staged project, for use in the stage:copy mojo. This
allows us to setup generic promotion scripts in a CI environment like
Hudson. I've committed this script to:
https://svn.apache.org/repos/asf/maven/sandbox/trunk/scripts.

The rest of this release infrastructure has simply been configuration of
hudson and nexus - nexus, to provide a staging ground for releases - to
configure release jobs that deploy to this staging location instead of
the real release repository...just generalizing on configuration that we
all have in our personal settings.xml files by now. Jason's credentials
are used for SVN and SSH where necessary, and I've created a new GPG key
for use in this CI system, then signed it with my own key.  That key ID
is: 84B54612.

To echo Jason, the goal here is to create an environment that - if not
perfectly flawless - is at least a known quantity. Just as we've moved
in the direction of pointing to our CI servers as the definitive point
of reference for our unit and integration tests (though we're not quite
there yet), we need to be releasing Maven artifacts from a similarly
definitive environment. In principle, the configuration and script I've
written (above) should enable any team to enable a similar release
infrastructure for their own projects.

-john

>
> I am also working with the Apache Infrastructure team to integrate the
> Contegix folks who are the ones who currently host all the hardware
> we're using. Maven's central repository, our Hudson instance, and our
> Nexus instance. So, in short order, the Contegix hardware will be
> official Apache hardware.
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
> A language that doesn’t affect the way you think about programming is
> not worth knowing.
>
>  -— Alan Perlis
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/


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

[brettporter]

On 08/07/2008, at 1:47 AM, John Casey wrote:

> Jason's referring to a ruby script I wrote to lookup the version  
> string for a particular staged project, for use in the stage:copy  
> mojo. This allows us to setup generic promotion scripts in a CI  
> environment like Hudson. I've committed this script to: https://svn.apache.org/repos/asf/maven/sandbox/trunk/scripts 
> .

So basically it's a simple way to do http to http repository copies  
instead of http to scp?

>
>
> The rest of this release infrastructure has simply been  
> configuration of hudson and nexus - nexus, to provide a staging  
> ground for releases - to configure release jobs that deploy to this  
> staging location instead of the real release repository...just  
> generalizing on configuration that we all have in our personal  
> settings.xml files by now. Jason's credentials are used for SVN and  
> SSH where necessary, and I've created a new GPG key for use in this  
> CI system, then signed it with my own key.  That key ID is: 84B54612.

Sorry, but I'm not at all comfortable with this.

Firstly, it rules out both of our current Hudson instances, since it  
gives access to people outside the project to be able to read our  
private release key. I'm not even sure about the wisdom of using a  
shared key vs. an individual one and would want to ask someone with  
more experience.

Secondly, it gives others access to Jason's account on  
people.apache.org that are not Jason, as well as losing the  
information of who deployed it.

There are other ways to handle the second part if we do have a  
canonical release repository on a different machine to the present one  
(namely, a user initiated pull from people which is easy enough).

But the question of how you sign something there is something that  
would need to be addressed. These challenges are the reason I haven't  
suggested using Continuum's built-in release mechanism for our  
releases over all the time it has been available.

Maybe we could run whatever the final proposal is past the ASF  
security and infrastructure teams?

> To echo Jason, the goal here is to create an environment that - if  
> not perfectly flawless - is at least a known quantity. Just as we've  
> moved in the direction of pointing to our CI servers as the  
> definitive point of reference for our unit and integration tests  
> (though we're not quite there yet), we need to be releasing Maven  
> artifacts from a similarly definitive environment. In principle, the  
> configuration and script I've written (above) should enable any team  
> to enable a similar release infrastructure for their own projects.

I certainly understand the drive to it - it's the first thing I set up  
in most environments (way back to when I got burned by this in the m1  
days).

But on the other hand, like you said, we're not even there with CI  
yet. I do hope that with an increased push towards determinism in the  
artifact resolution this becomes less of an issue.

Right now, I feel like our efforts would be better spent in tooling to  
validate releases wherever they come from.

Cheers,
Brett

--
Brett Porter
brett@...
http://blogs.exist.com/bporter/


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

[Jason van Zyl-2]

On 8-Jul-08, at 12:19 AM, Brett Porter wrote:

>
> On 08/07/2008, at 1:47 AM, John Casey wrote:
>
>> Jason's referring to a ruby script I wrote to lookup the version  
>> string for a particular staged project, for use in the stage:copy  
>> mojo. This allows us to setup generic promotion scripts in a CI  
>> environment like Hudson. I've committed this script to: https://svn.apache.org/repos/asf/maven/sandbox/trunk/scripts 
>> .
>
> So basically it's a simple way to do http to http repository copies  
> instead of http to scp?
>
>>
>>
>> The rest of this release infrastructure has simply been  
>> configuration of hudson and nexus - nexus, to provide a staging  
>> ground for releases - to configure release jobs that deploy to this  
>> staging location instead of the real release repository...just  
>> generalizing on configuration that we all have in our personal  
>> settings.xml files by now. Jason's credentials are used for SVN and  
>> SSH where necessary, and I've created a new GPG key for use in this  
>> CI system, then signed it with my own key.  That key ID is: 84B54612.
>
> Sorry, but I'm not at all comfortable with this.
>
> Firstly, it rules out both of our current Hudson instances, since it  
> gives access to people outside the project to be able to read our  
> private release key. I'm not even sure about the wisdom of using a  
> shared key vs. an individual one and would want to ask someone with  
> more experience.
>

The driving idea is that you generate sub-keys so that if the primary  
is compromised you don't have the revoke the primary key around the  
world and breaking everything using the primary key, or breaking  
everything where a sub-key was generated with the primary key. Fairly  
standard stuff.

> Secondly, it gives others access to Jason's account on  
> people.apache.org that are not Jason, as well as losing the  
> information of who deployed it.
>

Not in Hudson, the person who initiated a job can be tracked. It's not  
in the UI but that's easy to capture.

> There are other ways to handle the second part if we do have a  
> canonical release repository on a different machine to the present  
> one (namely, a user initiated pull from people which is easy enough).

As long as the movement is auditable and secure it doesn't much  
matter. Let's say what we want first.

>
> Maybe we could run whatever the final proposal is past the ASF  
> security and infrastructure teams?
>

I think the Contegix and Infra teams would have valuable input. It's  
really more at the security level where they would play a part. But  
the goal is full automation with a reliable tool like Hudson.

> Cheers,
> Brett
>
> --
> Brett Porter
> brett@...
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
----------------------------------------------------------

A language that doesn’t affect the way you think about programming is  
not worth knowing.

  -— Alan Perlis


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

[TomHuybrechts]

On Mon, Jul 7, 2008 at 5:47 PM, John Casey <jdcasey@...> wrote:

>
>
> Jason van Zyl wrote:
>>
>> There are groups there for Maven 2.1, Plexus, Maven IDE (really embedder
>> consumers), and I will also limit the plugins to the default lifecycles of
>> the commonly used packagings like JAR, and WAR. John has also started
>> creating automated ways to release to stage, and subsequent promotion upon
>> success. So for any component in the tool chain there will be a way to do a
>> consistent release from a canonical machine.
>
> Just for posterity (if we're going to be using this as an official release
> vector for the entire project):
>
> Jason's referring to a ruby script I wrote to lookup the version string for
> a particular staged project, for use in the stage:copy mojo. This allows us
> to setup generic promotion scripts in a CI environment like Hudson. I've
> committed this script to:
> https://svn.apache.org/repos/asf/maven/sandbox/trunk/scripts.
>
> The rest of this release infrastructure has simply been configuration of
> hudson and nexus - nexus, to provide a staging ground for releases - to
> configure release jobs that deploy to this staging location instead of the
> real release repository...just generalizing on configuration that we all
> have in our personal settings.xml files by now. Jason's credentials are used
> for SVN and SSH where necessary, and I've created a new GPG key for use in
> this CI system, then signed it with my own key.  That key ID is: 84B54612.
>
> To echo Jason, the goal here is to create an environment that - if not
> perfectly flawless - is at least a known quantity. Just as we've moved in
> the direction of pointing to our CI servers as the definitive point of
> reference for our unit and integration tests (though we're not quite there
> yet), we need to be releasing Maven artifacts from a similarly definitive
> environment. In principle, the configuration and script I've written (above)
> should enable any team to enable a similar release infrastructure for their
> own projects.
>
> -john
>>

I tried to automate part of the Maven release process (including
staging a release and voting on it) as a demo of Hudson-JBPM
integration.
This is a work in progress, but if you're interested, you can find
more info at http://hudson.gotdns.com/wiki/display/HUDSON/JBPM+Plugin

Tom

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

[Jason van Zyl-2]

Is the code anywhere?

I'm interested in the process, but have gone down the Drools workflow  
way, and I'm trying to work on the promotion from Nexus. But I'll  
definitely take a look at code.

On 8-Jul-08, at 3:40 PM, Tom Huybrechts wrote:

> On Mon, Jul 7, 2008 at 5:47 PM, John Casey <jdcasey@...>  
> wrote:
>>
>>
>> Jason van Zyl wrote:
>>>
>>> There are groups there for Maven 2.1, Plexus, Maven IDE (really  
>>> embedder
>>> consumers), and I will also limit the plugins to the default  
>>> lifecycles of
>>> the commonly used packagings like JAR, and WAR. John has also  
>>> started
>>> creating automated ways to release to stage, and subsequent  
>>> promotion upon
>>> success. So for any component in the tool chain there will be a  
>>> way to do a
>>> consistent release from a canonical machine.
>>
>> Just for posterity (if we're going to be using this as an official  
>> release
>> vector for the entire project):
>>
>> Jason's referring to a ruby script I wrote to lookup the version  
>> string for
>> a particular staged project, for use in the stage:copy mojo. This  
>> allows us
>> to setup generic promotion scripts in a CI environment like Hudson.  
>> I've
>> committed this script to:
>> https://svn.apache.org/repos/asf/maven/sandbox/trunk/scripts.
>>
>> The rest of this release infrastructure has simply been  
>> configuration of
>> hudson and nexus - nexus, to provide a staging ground for releases  
>> - to
>> configure release jobs that deploy to this staging location instead  
>> of the
>> real release repository...just generalizing on configuration that  
>> we all
>> have in our personal settings.xml files by now. Jason's credentials  
>> are used
>> for SVN and SSH where necessary, and I've created a new GPG key for  
>> use in
>> this CI system, then signed it with my own key.  That key ID is:  
>> 84B54612.
>>
>> To echo Jason, the goal here is to create an environment that - if  
>> not
>> perfectly flawless - is at least a known quantity. Just as we've  
>> moved in
>> the direction of pointing to our CI servers as the definitive point  
>> of
>> reference for our unit and integration tests (though we're not  
>> quite there
>> yet), we need to be releasing Maven artifacts from a similarly  
>> definitive
>> environment. In principle, the configuration and script I've  
>> written (above)
>> should enable any team to enable a similar release infrastructure  
>> for their
>> own projects.
>>
>> -john
>>>
>
> I tried to automate part of the Maven release process (including
> staging a release and voting on it) as a demo of Hudson-JBPM
> integration.
> This is a work in progress, but if you're interested, you can find
> more info at http://hudson.gotdns.com/wiki/display/HUDSON/JBPM+Plugin
>
> Tom
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
----------------------------------------------------------

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

  -- Unknown


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

[TomHuybrechts]

There's a setup section on the wiki page which has the necessary info
on setting up Hudson.
The staging plugin is part of the 'tom' branch which is linked to from the page.

On Tue, Jul 8, 2008 at 9:59 PM, Jason van Zyl <jason@...> wrote:

> Is the code anywhere?
>
> I'm interested in the process, but have gone down the Drools workflow way,
> and I'm trying to work on the promotion from Nexus. But I'll definitely take
> a look at code.
>
> On 8-Jul-08, at 3:40 PM, Tom Huybrechts wrote:
>
>> On Mon, Jul 7, 2008 at 5:47 PM, John Casey <jdcasey@...> wrote:
>>>
>>>
>>> Jason van Zyl wrote:
>>>>
>>>> There are groups there for Maven 2.1, Plexus, Maven IDE (really embedder
>>>> consumers), and I will also limit the plugins to the default lifecycles
>>>> of
>>>> the commonly used packagings like JAR, and WAR. John has also started
>>>> creating automated ways to release to stage, and subsequent promotion
>>>> upon
>>>> success. So for any component in the tool chain there will be a way to
>>>> do a
>>>> consistent release from a canonical machine.
>>>
>>> Just for posterity (if we're going to be using this as an official
>>> release
>>> vector for the entire project):
>>>
>>> Jason's referring to a ruby script I wrote to lookup the version string
>>> for
>>> a particular staged project, for use in the stage:copy mojo. This allows
>>> us
>>> to setup generic promotion scripts in a CI environment like Hudson. I've
>>> committed this script to:
>>> https://svn.apache.org/repos/asf/maven/sandbox/trunk/scripts.
>>>
>>> The rest of this release infrastructure has simply been configuration of
>>> hudson and nexus - nexus, to provide a staging ground for releases - to
>>> configure release jobs that deploy to this staging location instead of
>>> the
>>> real release repository...just generalizing on configuration that we all
>>> have in our personal settings.xml files by now. Jason's credentials are
>>> used
>>> for SVN and SSH where necessary, and I've created a new GPG key for use
>>> in
>>> this CI system, then signed it with my own key.  That key ID is:
>>> 84B54612.
>>>
>>> To echo Jason, the goal here is to create an environment that - if not
>>> perfectly flawless - is at least a known quantity. Just as we've moved in
>>> the direction of pointing to our CI servers as the definitive point of
>>> reference for our unit and integration tests (though we're not quite
>>> there
>>> yet), we need to be releasing Maven artifacts from a similarly definitive
>>> environment. In principle, the configuration and script I've written
>>> (above)
>>> should enable any team to enable a similar release infrastructure for
>>> their
>>> own projects.
>>>
>>> -john
>>>>
>>
>> I tried to automate part of the Maven release process (including
>> staging a release and voting on it) as a demo of Hudson-JBPM
>> integration.
>> This is a work in progress, but if you're interested, you can find
>> more info at http://hudson.gotdns.com/wiki/display/HUDSON/JBPM+Plugin
>>
>> Tom
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
> Three people can keep a secret provided two of them are dead.
>
>  -- Unknown
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

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

[hgomez]

I tried to build the latest maven 2.1 from trunk with mvn install but
it still failed in tests.

What should be done to get a build of maven 2.1 ?

I need it to track a classloader issue with jaxws-maven-plugin even if
it seems to be a general problem with the system scope.

Regards and thanks for your help

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

[Jason van Zyl-2]

It's working fine:

http://ci.sonatype.org/view/Maven%202.1x/

You can take the build produced in the workspace of the bootstrap  
build in that group.

If you have 2.0.x installed you need to bootstrap.

On 10-Jul-08, at 10:02 AM, Henri Gomez wrote:

> I tried to build the latest maven 2.1 from trunk with mvn install but
> it still failed in tests.
>
> What should be done to get a build of maven 2.1 ?
>
> I need it to track a classloader issue with jaxws-maven-plugin even if
> it seems to be a general problem with the system scope.
>
> Regards and thanks for your help
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
----------------------------------------------------------

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

[Jason van Zyl-2]

Henri,

Here's the most recent build:

http://ci.sonatype.org/view/Maven%202.1x/job/maven-2.1.x-bootstrap/ws/trunk/maven-distribution/target/

On 10-Jul-08, at 10:02 AM, Henri Gomez wrote:

> I tried to build the latest maven 2.1 from trunk with mvn install but
> it still failed in tests.
>
> What should be done to get a build of maven 2.1 ?
>
> I need it to track a classloader issue with jaxws-maven-plugin even if
> it seems to be a general problem with the system scope.
>
> Regards and thanks for your help
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
----------------------------------------------------------



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

[hgomez]

Well

I 'll put your maven 2.1 build to our Hudson instance :)

2008/7/10 Jason van Zyl <jason@...>:

> Henri,
>
> Here's the most recent build:
>
> http://ci.sonatype.org/view/Maven%202.1x/job/maven-2.1.x-bootstrap/ws/trunk/maven-distribution/target/
>
> On 10-Jul-08, at 10:02 AM, Henri Gomez wrote:
>
>> I tried to build the latest maven 2.1 from trunk with mvn install but
>> it still failed in tests.
>>
>> What should be done to get a build of maven 2.1 ?
>>
>> I need it to track a classloader issue with jaxws-maven-plugin even if
>> it seems to be a general problem with the system scope.
>>
>> Regards and thanks for your help
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

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

[Brian E Fox]

>If you have 2.0.x installed you need to bootstrap.

It builds fine for me now with 2.0.9, we've never needed to bootstrap to
build 2.1 before, so what's different now?

If we can't trust Maven to build our own applications here, then we have
a serious problem IMO that needs to be fixed. Maven 2.1 is just another
application being built, there shouldn't be any concerns of cross over
between the application building and the application being built.

--Brian

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

[Jason van Zyl-2]

On 10-Jul-08, at 11:01 AM, Brian E. Fox wrote:

>> If you have 2.0.x installed you need to bootstrap.
>
> It builds fine for me now with 2.0.9, we've never needed to  
> bootstrap to
> build 2.1 before, so what's different now?

If you ever change APIs where the JARs in the distribution come first  
on the classpath you need to start from scratch. Most of the time we  
don't do that so it never matters.

>
>
> If we can't trust Maven to build our own applications here, then we  
> have
> a serious problem IMO that needs to be fixed. Maven 2.1 is just  
> another
> application being built, there shouldn't be any concerns of cross over
> between the application building and the application being built.

The bootstrap is Maven building Maven. It uses Ant for the first phase  
to build a small Maven distro and then uses itself to build itself.

>
>
> --Brian
>
> ---------------------------------------------------------------------
> To