You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason van Zyl <ja...@maven.org> on 2008/07/05 19:56:10 UTC
Developing Maven 2.1
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@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Developing Maven 2.1
Posted by Jason van Zyl <ja...@maven.org>.
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@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> 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
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@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Developing Maven 2.1
Posted by Brett Porter <br...@apache.org>.
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@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Developing Maven 2.1
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
>> 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?
>You got it works with 2.0.9 ?
Yes.
>Just with mvn install ?
Yes.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Developing Maven 2.1
Posted by Jason van Zyl <ja...@maven.org>.
I always bootstrap.
On 10-Jul-08, at 11:12 AM, Henri Gomez wrote:
>> 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?
>
> You got it works with 2.0.9 ?
>
> Just with mvn install ?
>
>> 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.
>
> Indeed but may be my settings is incorrect ?
>
> Just get maven-2.1 from
> http://svn.apache.org/repos/asf/maven/components/trunk on my F:
>
> cd maven-2.1
> mvn install
>
> ---------------------------------------------------------------------
> 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
jason at sonatype dot com
----------------------------------------------------------
To do two things at once is to do neither.
-—Publilius Syrus, Roman slave, first century B.C.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Developing Maven 2.1
Posted by Henri Gomez <he...@gmail.com>.
> 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?
You got it works with 2.0.9 ?
Just with mvn install ?
> 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.
Indeed but may be my settings is incorrect ?
Just get maven-2.1 from
http://svn.apache.org/repos/asf/maven/components/trunk on my F:
cd maven-2.1
mvn install
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Developing Maven 2.1
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
>>
>> 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.
But the jars Maven is executing shouldn't have anything to do with what
is being built. Do you have an example? Because this may be of interest
to projects besides Maven if they happen to use some dependency we don't
allow or interfere with on the classpaths of the project being built.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Developing Maven 2.1
Posted by Jason van Zyl <ja...@maven.org>.
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 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
jason at sonatype dot com
----------------------------------------------------------
Selfish deeds are the shortest path to self destruction.
-- The Seven Samuari, Akira Kirosawa
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Developing Maven 2.1
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
>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@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Developing Maven 2.1
Posted by Jason van Zyl <ja...@maven.org>.
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@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
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@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Developing Maven 2.1
Posted by Henri Gomez <he...@gmail.com>.
Well
I 'll put your maven 2.1 build to our Hudson instance :)
2008/7/10 Jason van Zyl <ja...@maven.org>:
> 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@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot 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: Developing Maven 2.1
Posted by Jason van Zyl <ja...@maven.org>.
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@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Developing Maven 2.1
Posted by Henri Gomez <he...@gmail.com>.
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@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Developing Maven 2.1
Posted by Tom Huybrechts <to...@gmail.com>.
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 <ja...@maven.org> 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 <jd...@commonjava.org> 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@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> 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@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: Developing Maven 2.1
Posted by Jason van Zyl <ja...@maven.org>.
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 <jd...@commonjava.org>
> 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@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
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@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Developing Maven 2.1
Posted by Tom Huybrechts <to...@gmail.com>.
On Mon, Jul 7, 2008 at 5:47 PM, John Casey <jd...@commonjava.org> 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@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Developing Maven 2.1
Posted by Brett Porter <br...@apache.org>.
On 21/07/2008, at 12:20 PM, Jason van Zyl wrote:
>> The important thing is that the release process does not use your
>> credentials for either SVN or SSH when it's not you doing the
>> release.
>>
>
> I don't think that's important at all, but I can easily fix it.
Do I have to SSH into your account or lock you out of SVN to convince
you it is important? :)
Now I trust all the committers on this project not to do that (and
besides, it would be recorded if they did!), but what happens when
someone finds an exploit in Hudson?
> What's important is that the release is is made in a sane way, with
> as much constant as possible. Who does the release would be easily
> recorded. But I can easily collect credentials so a release manager
> can store them for reuse and fully automate the process.
If by collecting you mean storing, then no, that's not a solution to
the problem. I'm certainly not putting my Apache credentials on a
third party CI server that multiple people have access to.
Introducing a clean room for building releases is admirable, but I
believe we need to use our own credentials to do so, and we must
retain full control of them in the process.
Thanks,
Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Developing Maven 2.1
Posted by Jason van Zyl <ja...@maven.org>.
On 20-Jul-08, at 10:13 PM, Brett Porter wrote:
>
> On 18/07/2008, at 11:54 PM, Jason van Zyl wrote:
>
>> I am actually trying to work with a developer who knows Hudson very
>> well to create a better bridge from Maven and Hudson. Basically
>> using Maven SCM (instead of the proliferation of Hudson plugins
>> doing exactly the same thing), creating a Plexus adapter so that I
>> can use all the Plexus components in Hudson, and bridge for Maven
>> plugins into Hudson. This will be my attempt to bridge the two
>> worlds and give Hudson first-class Maven support (some of it is
>> honestly wonky).
>
> Cool - especially if this leads to general improvement of Maven SCM.
>
>> I mean I'm not going to stop you guys from doing whatever with
>> Continuum I just find working with Hudson easier, and the setup
>> here has honestly never been overly stable. Life is short, I used
>> what works for the Maven 2.1 ITs.
>
> Exactly - I think Wendy was just suggesting the right tool for the
> job at hand, not an alternative for the Maven 2.1 ITs or CI in
> general.
>
> Anyway, as Emmanuel said, off-topic :)
>
> The important thing is that the release process does not use your
> credentials for either SVN or SSH when it's not you doing the release.
>
I don't think that's important at all, but I can easily fix it.
What's important is that the release is is made in a sane way, with as
much constant as possible. Who does the release would be easily
recorded. But I can easily collect credentials so a release manager
can store them for reuse and fully automate the process.
> Thanks,
> Brett
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> 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
jason at sonatype dot com
----------------------------------------------------------
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Developing Maven 2.1
Posted by Brett Porter <br...@apache.org>.
On 18/07/2008, at 11:54 PM, Jason van Zyl wrote:
> I am actually trying to work with a developer who knows Hudson very
> well to create a better bridge from Maven and Hudson. Basically
> using Maven SCM (instead of the proliferation of Hudson plugins
> doing exactly the same thing), creating a Plexus adapter so that I
> can use all the Plexus components in Hudson, and bridge for Maven
> plugins into Hudson. This will be my attempt to bridge the two
> worlds and give Hudson first-class Maven support (some of it is
> honestly wonky).
Cool - especially if this leads to general improvement of Maven SCM.
> I mean I'm not going to stop you guys from doing whatever with
> Continuum I just find working with Hudson easier, and the setup here
> has honestly never been overly stable. Life is short, I used what
> works for the Maven 2.1 ITs.
Exactly - I think Wendy was just suggesting the right tool for the job
at hand, not an alternative for the Maven 2.1 ITs or CI in general.
Anyway, as Emmanuel said, off-topic :)
The important thing is that the release process does not use your
credentials for either SVN or SSH when it's not you doing the release.
Thanks,
Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Developing Maven 2.1
Posted by Emmanuel Venisse <em...@gmail.com>.
ok, I prefer when it is explain like that.
It's a good thing to try to reuse existing librairies and plugins
Emmanuel
On Fri, Jul 18, 2008 at 3:54 PM, Jason van Zyl <ja...@maven.org> wrote:
> I'm not saying there is only one developer, the core group just represents
> the group doing the majority of the work in a time period. That graph was
> the last few months in your new location.
>
> It's just the natural evolution of projects.
>
> I am actually trying to work with a developer who knows Hudson very well to
> create a better bridge from Maven and Hudson. Basically using Maven SCM
> (instead of the proliferation of Hudson plugins doing exactly the same
> thing), creating a Plexus adapter so that I can use all the Plexus
> components in Hudson, and bridge for Maven plugins into Hudson. This will be
> my attempt to bridge the two worlds and give Hudson first-class Maven
> support (some of it is honestly wonky).
>
> I mean I'm not going to stop you guys from doing whatever with Continuum I
> just find working with Hudson easier, and the setup here has honestly never
> been overly stable. Life is short, I used what works for the Maven 2.1 ITs.
>
>
> On 18-Jul-08, at 9:35 AM, Emmanuel Venisse wrote:
>
> On Fri, Jul 18, 2008 at 3:00 PM, Jason van Zyl <ja...@maven.org> wrote:
>>
>>
>>> On 17-Jul-08, at 11:12 PM, Wendy Smoak wrote:
>>>
>>> I gather this is the reason that the commits (r677787 to r677789) for
>>>
>>>> the Maven Artifact release that Oleg just called a vote on look like
>>>> they were done by Jason?
>>>>
>>>> I'm really not comfortable with svn credentials being shared like that.
>>>>
>>>>
>>>> They are not being shared. Hudson is running as a sand-boxed user where
>>> I
>>> have setup my credentials, so that the releases can be fully automated
>>> where
>>> the same set of attributes are used across the board. I tested my
>>> credentials, they work. The release plugin is not very graceful when
>>> things
>>> at the SVN bork. I was striving for a QA'd process so I took into account
>>> everything. The machine is secure and the account is secure. So now that
>>> you
>>> know that do you still think it's a problem?
>>>
>>> FWIW, Continuum lets you enter your svn credentials when you do a
>>>
>>>> release, and uses those for the related commits.
>>>>
>>>>
>>>> It's not relevant to me what Continuum can or cannot do at this point.
>>> The
>>> community took a severe hit and Hudson has way more active developers and
>>> it's easier to develop features because it has an extensible API. You can
>>> look at the charts. The core group for Continuum consists of one person:
>>> "olamy". Contrast that with the core group in Hudson which is at least 10
>>> people.
>>>
>>
>>
>> Not totally right because we changed the svn repo. Old values are there :
>> http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fmaven%2Fcontinuum
>>
>> As you can see, Continuum doesn't have only one developer.
>> You are active on continuum like the majority of Hudson developers and the
>> core group in Hudson is one developer too.
>> Just my 2 cents for some values that are totally out of topic!!!
>>
>> Emmanuel
>>
>>
>>
>>> http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fcontinuum
>>>
>>> http://svnsearch.org/svnsearch/repos/HUDSON/search
>>>
>>> So it's nice to say Continuum has this or that, but who's going to fix
>>> it?
>>> Kohsuke and company push out releases super frequently and sometimes even
>>> every week. There's just no comparison in my mind. I have limited time I
>>> simply can't afford to invest anything in Continuum. So for one feature
>>> Continuum might have I think what I have setup with the sandboxed Hudson
>>> user is a reasonable compromise. As a policy we can decide as a PMC
>>> what's
>>> acceptable but the setup I have is secure as far as I'm concerned.
>>>
>>> Also I've had 7 people actually take the Hudson bundle and run the Maven
>>> 2.1 ITs. That's never happened before and it's because Hudson is so easy
>>> to
>>> make a bundle, unpack it with the Maven jobs and boom you have a fully
>>> functional Maven environment.
>>>
>>> --
>>>
>>>> Wendy
>>>>
>>>>
>>>> On Mon, Jul 7, 2008 at 8:47 AM, John Casey <jd...@commonjava.org>
>>>> wrote:
>>>>
>>>> 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 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
>>> jason at sonatype dot com
>>> ----------------------------------------------------------
>>>
>>> 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
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
> jason at sonatype dot com
> ----------------------------------------------------------
>
> 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
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Developing Maven 2.1
Posted by Jason van Zyl <ja...@maven.org>.
I'm not saying there is only one developer, the core group just
represents the group doing the majority of the work in a time period.
That graph was the last few months in your new location.
It's just the natural evolution of projects.
I am actually trying to work with a developer who knows Hudson very
well to create a better bridge from Maven and Hudson. Basically using
Maven SCM (instead of the proliferation of Hudson plugins doing
exactly the same thing), creating a Plexus adapter so that I can use
all the Plexus components in Hudson, and bridge for Maven plugins into
Hudson. This will be my attempt to bridge the two worlds and give
Hudson first-class Maven support (some of it is honestly wonky).
I mean I'm not going to stop you guys from doing whatever with
Continuum I just find working with Hudson easier, and the setup here
has honestly never been overly stable. Life is short, I used what
works for the Maven 2.1 ITs.
On 18-Jul-08, at 9:35 AM, Emmanuel Venisse wrote:
> On Fri, Jul 18, 2008 at 3:00 PM, Jason van Zyl <ja...@maven.org>
> wrote:
>
>>
>> On 17-Jul-08, at 11:12 PM, Wendy Smoak wrote:
>>
>> I gather this is the reason that the commits (r677787 to r677789) for
>>> the Maven Artifact release that Oleg just called a vote on look like
>>> they were done by Jason?
>>>
>>> I'm really not comfortable with svn credentials being shared like
>>> that.
>>>
>>>
>> They are not being shared. Hudson is running as a sand-boxed user
>> where I
>> have setup my credentials, so that the releases can be fully
>> automated where
>> the same set of attributes are used across the board. I tested my
>> credentials, they work. The release plugin is not very graceful
>> when things
>> at the SVN bork. I was striving for a QA'd process so I took into
>> account
>> everything. The machine is secure and the account is secure. So now
>> that you
>> know that do you still think it's a problem?
>>
>> FWIW, Continuum lets you enter your svn credentials when you do a
>>> release, and uses those for the related commits.
>>>
>>>
>> It's not relevant to me what Continuum can or cannot do at this
>> point. The
>> community took a severe hit and Hudson has way more active
>> developers and
>> it's easier to develop features because it has an extensible API.
>> You can
>> look at the charts. The core group for Continuum consists of one
>> person:
>> "olamy". Contrast that with the core group in Hudson which is at
>> least 10
>> people.
>
>
> Not totally right because we changed the svn repo. Old values are
> there :
> http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fmaven%2Fcontinuum
>
> As you can see, Continuum doesn't have only one developer.
> You are active on continuum like the majority of Hudson developers
> and the
> core group in Hudson is one developer too.
> Just my 2 cents for some values that are totally out of topic!!!
>
> Emmanuel
>
>
>>
>> http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fcontinuum
>>
>> http://svnsearch.org/svnsearch/repos/HUDSON/search
>>
>> So it's nice to say Continuum has this or that, but who's going to
>> fix it?
>> Kohsuke and company push out releases super frequently and
>> sometimes even
>> every week. There's just no comparison in my mind. I have limited
>> time I
>> simply can't afford to invest anything in Continuum. So for one
>> feature
>> Continuum might have I think what I have setup with the sandboxed
>> Hudson
>> user is a reasonable compromise. As a policy we can decide as a PMC
>> what's
>> acceptable but the setup I have is secure as far as I'm concerned.
>>
>> Also I've had 7 people actually take the Hudson bundle and run the
>> Maven
>> 2.1 ITs. That's never happened before and it's because Hudson is so
>> easy to
>> make a bundle, unpack it with the Maven jobs and boom you have a
>> fully
>> functional Maven environment.
>>
>> --
>>> Wendy
>>>
>>>
>>> On Mon, Jul 7, 2008 at 8:47 AM, John Casey <jd...@commonjava.org>
>>> wrote:
>>>
>>>> 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 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
>> jason at sonatype dot com
>> ----------------------------------------------------------
>>
>> 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
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
jason at sonatype dot com
----------------------------------------------------------
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Developing Maven 2.1
Posted by Emmanuel Venisse <em...@gmail.com>.
On Fri, Jul 18, 2008 at 3:00 PM, Jason van Zyl <ja...@maven.org> wrote:
>
> On 17-Jul-08, at 11:12 PM, Wendy Smoak wrote:
>
> I gather this is the reason that the commits (r677787 to r677789) for
>> the Maven Artifact release that Oleg just called a vote on look like
>> they were done by Jason?
>>
>> I'm really not comfortable with svn credentials being shared like that.
>>
>>
> They are not being shared. Hudson is running as a sand-boxed user where I
> have setup my credentials, so that the releases can be fully automated where
> the same set of attributes are used across the board. I tested my
> credentials, they work. The release plugin is not very graceful when things
> at the SVN bork. I was striving for a QA'd process so I took into account
> everything. The machine is secure and the account is secure. So now that you
> know that do you still think it's a problem?
>
> FWIW, Continuum lets you enter your svn credentials when you do a
>> release, and uses those for the related commits.
>>
>>
> It's not relevant to me what Continuum can or cannot do at this point. The
> community took a severe hit and Hudson has way more active developers and
> it's easier to develop features because it has an extensible API. You can
> look at the charts. The core group for Continuum consists of one person:
> "olamy". Contrast that with the core group in Hudson which is at least 10
> people.
Not totally right because we changed the svn repo. Old values are there :
http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fmaven%2Fcontinuum
As you can see, Continuum doesn't have only one developer.
You are active on continuum like the majority of Hudson developers and the
core group in Hudson is one developer too.
Just my 2 cents for some values that are totally out of topic!!!
Emmanuel
>
> http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fcontinuum
>
> http://svnsearch.org/svnsearch/repos/HUDSON/search
>
> So it's nice to say Continuum has this or that, but who's going to fix it?
> Kohsuke and company push out releases super frequently and sometimes even
> every week. There's just no comparison in my mind. I have limited time I
> simply can't afford to invest anything in Continuum. So for one feature
> Continuum might have I think what I have setup with the sandboxed Hudson
> user is a reasonable compromise. As a policy we can decide as a PMC what's
> acceptable but the setup I have is secure as far as I'm concerned.
>
> Also I've had 7 people actually take the Hudson bundle and run the Maven
> 2.1 ITs. That's never happened before and it's because Hudson is so easy to
> make a bundle, unpack it with the Maven jobs and boom you have a fully
> functional Maven environment.
>
> --
>> Wendy
>>
>>
>> On Mon, Jul 7, 2008 at 8:47 AM, John Casey <jd...@commonjava.org>
>> wrote:
>>
>>> 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 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
> jason at sonatype dot com
> ----------------------------------------------------------
>
> 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
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Developing Maven 2.1
Posted by Wendy Smoak <ws...@gmail.com>.
On Sun, Jul 20, 2008 at 7:12 PM, Jason van Zyl <ja...@maven.org> wrote:
> On 20-Jul-08, at 9:42 PM, Wendy Smoak wrote:
>
>> Yes. The svn commits need to show the person who actually made the
>> change to svn.
>
> I can fix that, is that the only problem?
No, but I think Brett has it covered. :)
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Developing Maven 2.1
Posted by Jason van Zyl <ja...@maven.org>.
On 20-Jul-08, at 9:42 PM, Wendy Smoak wrote:
> On Fri, Jul 18, 2008 at 6:00 AM, Jason van Zyl <ja...@maven.org>
> wrote:
>
>> They are not being shared. Hudson is running as a sand-boxed user
>> where I
>> have setup my credentials, so that the releases can be fully
>> automated where
>> the same set of attributes are used across the board. I tested my
>> credentials, they work. The release plugin is not very graceful
>> when things
>> at the SVN bork. I was striving for a QA'd process so I took into
>> account
>> everything. The machine is secure and the account is secure. So now
>> that you
>> know that do you still think it's a problem?
>
> Yes. The svn commits need to show the person who actually made the
> change to svn.
I can fix that, is that the only problem?
>
>
> --
> Wendy
>
> ---------------------------------------------------------------------
> 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
jason at sonatype dot com
----------------------------------------------------------
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Developing Maven 2.1
Posted by Wendy Smoak <ws...@gmail.com>.
On Fri, Jul 18, 2008 at 6:00 AM, Jason van Zyl <ja...@maven.org> wrote:
> They are not being shared. Hudson is running as a sand-boxed user where I
> have setup my credentials, so that the releases can be fully automated where
> the same set of attributes are used across the board. I tested my
> credentials, they work. The release plugin is not very graceful when things
> at the SVN bork. I was striving for a QA'd process so I took into account
> everything. The machine is secure and the account is secure. So now that you
> know that do you still think it's a problem?
Yes. The svn commits need to show the person who actually made the
change to svn.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Developing Maven 2.1
Posted by Jason van Zyl <ja...@maven.org>.
On 17-Jul-08, at 11:12 PM, Wendy Smoak wrote:
> I gather this is the reason that the commits (r677787 to r677789) for
> the Maven Artifact release that Oleg just called a vote on look like
> they were done by Jason?
>
> I'm really not comfortable with svn credentials being shared like
> that.
>
They are not being shared. Hudson is running as a sand-boxed user
where I have setup my credentials, so that the releases can be fully
automated where the same set of attributes are used across the board.
I tested my credentials, they work. The release plugin is not very
graceful when things at the SVN bork. I was striving for a QA'd
process so I took into account everything. The machine is secure and
the account is secure. So now that you know that do you still think
it's a problem?
> FWIW, Continuum lets you enter your svn credentials when you do a
> release, and uses those for the related commits.
>
It's not relevant to me what Continuum can or cannot do at this point.
The community took a severe hit and Hudson has way more active
developers and it's easier to develop features because it has an
extensible API. You can look at the charts. The core group for
Continuum consists of one person: "olamy". Contrast that with the core
group in Hudson which is at least 10 people.
http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fcontinuum
http://svnsearch.org/svnsearch/repos/HUDSON/search
So it's nice to say Continuum has this or that, but who's going to fix
it? Kohsuke and company push out releases super frequently and
sometimes even every week. There's just no comparison in my mind. I
have limited time I simply can't afford to invest anything in
Continuum. So for one feature Continuum might have I think what I have
setup with the sandboxed Hudson user is a reasonable compromise. As a
policy we can decide as a PMC what's acceptable but the setup I have
is secure as far as I'm concerned.
Also I've had 7 people actually take the Hudson bundle and run the
Maven 2.1 ITs. That's never happened before and it's because Hudson is
so easy to make a bundle, unpack it with the Maven jobs and boom you
have a fully functional Maven environment.
> --
> Wendy
>
>
> On Mon, Jul 7, 2008 at 8:47 AM, John Casey <jd...@commonjava.org>
> wrote:
>> 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 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
jason at sonatype dot com
----------------------------------------------------------
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Developing Maven 2.1
Posted by Wendy Smoak <ws...@gmail.com>.
I gather this is the reason that the commits (r677787 to r677789) for
the Maven Artifact release that Oleg just called a vote on look like
they were done by Jason?
I'm really not comfortable with svn credentials being shared like that.
FWIW, Continuum lets you enter your svn credentials when you do a
release, and uses those for the related commits.
--
Wendy
On Mon, Jul 7, 2008 at 8:47 AM, John Casey <jd...@commonjava.org> wrote:
> 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 unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Developing Maven 2.1
Posted by Jason van Zyl <ja...@maven.org>.
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@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> 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
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@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Developing Maven 2.1
Posted by Brett Porter <br...@apache.org>.
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@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Developing Maven 2.1
Posted by John Casey <jd...@commonjava.org>.
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@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org