You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Todd Thiessen <th...@nortel.com> on 2008/12/03 22:49:26 UTC
Limitation of the release plugin?
I have been looking at the release plugin a fair bit lately and noticed
something that concerned me.
The first modification of the pom changes the version to remove the
"-SNAPSHOT" and also changes the SCM values to point to the tag location
instead of the trunk location. Once done, it then commits this change
to trunk.
So what happens if another user checks out the project during this
window? I just tried testing it myself by interrupting a
release:prepare right after the first commit. I then checkout the
project to a another directory and lo and behold, the version looked
like a released version and the SCM information referenced the tag not
the trunk.
Can anyone else confirm this? This seems pretty dangerous.
---
Todd Thiessen
RE: Limitation of the release plugin?
Posted by Todd Thiessen <th...@nortel.com>.
By doing an svn copy of the working copy with uncommited changes. The
release plugin does not do a revision copy to the tags folder. It does
a copy of your working folder.
---
Todd Thiessen
> -----Original Message-----
> From: Barrie Treloar [mailto:baerrach@gmail.com]
> Sent: Thursday, December 04, 2008 2:56 PM
> To: Maven Users List
> Subject: Re: Limitation of the release plugin?
>
> On Fri, Dec 5, 2008 at 2:15 AM, Todd Thiessen
> <th...@nortel.com> wrote:
> > My suggestion though is to not commit at all. Just do a
> working copy.
> > So no commit to tags would be required.
>
> Err, if you dont commit, then how can you tag?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Limitation of the release plugin?
Posted by Barrie Treloar <ba...@gmail.com>.
On Fri, Dec 5, 2008 at 2:15 AM, Todd Thiessen <th...@nortel.com> wrote:
> My suggestion though is to not commit at all. Just do a working copy.
> So no commit to tags would be required.
Err, if you dont commit, then how can you tag?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Limitation of the release plugin?
Posted by Todd Thiessen <th...@nortel.com>.
Am I? I didn't think I was.
Doing a copy of the working directory though is a corner stone of how
maven release plugin works. If an SCM doesn't support it, then the
plugin would be flakey at best or not work outright at worst.
---
Todd Thiessen
> -----Original Message-----
> From: Brian E. Fox [mailto:brianf@reply.infinity.nu]
> Sent: Thursday, December 04, 2008 10:53 AM
> To: Maven Users List
> Subject: RE: Limitation of the release plugin?
>
> Yeah but it sounds like you're thinking in svn terms only.
> This might not work for all scms.
>
> -----Original Message-----
> From: Todd Thiessen [mailto:thiessen@nortel.com]
> Sent: Thursday, December 04, 2008 7:45 AM
> To: Maven Users List
> Subject: RE: Limitation of the release plugin?
>
> My suggestion though is to not commit at all. Just do a working copy.
> So no commit to tags would be required.
>
> ---
> Todd Thiessen
>
>
> > -----Original Message-----
> > From: Brian E. Fox [mailto:brianf@reply.infinity.nu]
> > Sent: Thursday, December 04, 2008 10:42 AM
> > To: Maven Users List
> > Subject: RE: Limitation of the release plugin?
> >
> > Many scm's don't let you commit changes to tags, which is why it
> > commits to trunk first and then tags.
> >
> > -----Original Message-----
> > From: Todd Thiessen [mailto:thiessen@nortel.com]
> > Sent: Thursday, December 04, 2008 6:18 AM
> > To: Maven Users List
> > Subject: RE: Limitation of the release plugin?
> >
> > Have anyone considered changing the release plugin such
> that it does
> > not commit the changes to the POM which removes SNAPSHOT from the
> > version?
> > The only negative I can see is that you don't see a history of this
> > change in your trunk. But this shouldn't matter since you
> have a copy
> > of this POM in your tags. In fact, this makes more sense to me
> > anyway.
> > I don't like seeing a released version of my POM in my
> trunk history.
> >
> > So to be clear, the steps would be changed to this (roughly):
> >
> > 1. Make changes to the POM in your working copy to remove "SNAPSHOT"
> > from the version and make changes to your SCM entries to
> point to your
> > tags instead of your trunk. (Same) 2. DO NOT commit this
> change back
> > to trunk. (Different).
> > 3. Do an svn copy of your working directory to your tags,
> just as it
> > does today. (Same) 4. ... continue as normal
> >
> > Are there any negatives to this that I have overlooked?
> >
> > ---
> > Todd Thiessen
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Limitation of the release plugin?
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
Yeah but it sounds like you're thinking in svn terms only. This might
not work for all scms.
-----Original Message-----
From: Todd Thiessen [mailto:thiessen@nortel.com]
Sent: Thursday, December 04, 2008 7:45 AM
To: Maven Users List
Subject: RE: Limitation of the release plugin?
My suggestion though is to not commit at all. Just do a working copy.
So no commit to tags would be required.
---
Todd Thiessen
> -----Original Message-----
> From: Brian E. Fox [mailto:brianf@reply.infinity.nu]
> Sent: Thursday, December 04, 2008 10:42 AM
> To: Maven Users List
> Subject: RE: Limitation of the release plugin?
>
> Many scm's don't let you commit changes to tags, which is why
> it commits to trunk first and then tags.
>
> -----Original Message-----
> From: Todd Thiessen [mailto:thiessen@nortel.com]
> Sent: Thursday, December 04, 2008 6:18 AM
> To: Maven Users List
> Subject: RE: Limitation of the release plugin?
>
> Have anyone considered changing the release plugin such that
> it does not commit the changes to the POM which removes
> SNAPSHOT from the version?
> The only negative I can see is that you don't see a history
> of this change in your trunk. But this shouldn't matter
> since you have a copy of this POM in your tags. In fact,
> this makes more sense to me anyway.
> I don't like seeing a released version of my POM in my trunk history.
>
> So to be clear, the steps would be changed to this (roughly):
>
> 1. Make changes to the POM in your working copy to remove "SNAPSHOT"
> from the version and make changes to your SCM entries to
> point to your tags instead of your trunk. (Same) 2. DO NOT
> commit this change back to trunk. (Different).
> 3. Do an svn copy of your working directory to your tags,
> just as it does today. (Same) 4. ... continue as normal
>
> Are there any negatives to this that I have overlooked?
>
> ---
> Todd Thiessen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Limitation of the release plugin?
Posted by Todd Thiessen <th...@nortel.com>.
My suggestion though is to not commit at all. Just do a working copy.
So no commit to tags would be required.
---
Todd Thiessen
> -----Original Message-----
> From: Brian E. Fox [mailto:brianf@reply.infinity.nu]
> Sent: Thursday, December 04, 2008 10:42 AM
> To: Maven Users List
> Subject: RE: Limitation of the release plugin?
>
> Many scm's don't let you commit changes to tags, which is why
> it commits to trunk first and then tags.
>
> -----Original Message-----
> From: Todd Thiessen [mailto:thiessen@nortel.com]
> Sent: Thursday, December 04, 2008 6:18 AM
> To: Maven Users List
> Subject: RE: Limitation of the release plugin?
>
> Have anyone considered changing the release plugin such that
> it does not commit the changes to the POM which removes
> SNAPSHOT from the version?
> The only negative I can see is that you don't see a history
> of this change in your trunk. But this shouldn't matter
> since you have a copy of this POM in your tags. In fact,
> this makes more sense to me anyway.
> I don't like seeing a released version of my POM in my trunk history.
>
> So to be clear, the steps would be changed to this (roughly):
>
> 1. Make changes to the POM in your working copy to remove "SNAPSHOT"
> from the version and make changes to your SCM entries to
> point to your tags instead of your trunk. (Same) 2. DO NOT
> commit this change back to trunk. (Different).
> 3. Do an svn copy of your working directory to your tags,
> just as it does today. (Same) 4. ... continue as normal
>
> Are there any negatives to this that I have overlooked?
>
> ---
> Todd Thiessen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Limitation of the release plugin?
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
Many scm's don't let you commit changes to tags, which is why it commits
to trunk first and then tags.
-----Original Message-----
From: Todd Thiessen [mailto:thiessen@nortel.com]
Sent: Thursday, December 04, 2008 6:18 AM
To: Maven Users List
Subject: RE: Limitation of the release plugin?
Have anyone considered changing the release plugin such that it does not
commit the changes to the POM which removes SNAPSHOT from the version?
The only negative I can see is that you don't see a history of this
change in your trunk. But this shouldn't matter since you have a copy
of this POM in your tags. In fact, this makes more sense to me anyway.
I don't like seeing a released version of my POM in my trunk history.
So to be clear, the steps would be changed to this (roughly):
1. Make changes to the POM in your working copy to remove "SNAPSHOT"
from the version and make changes to your SCM entries to point to your
tags instead of your trunk. (Same)
2. DO NOT commit this change back to trunk. (Different).
3. Do an svn copy of your working directory to your tags, just as it
does today. (Same)
4. ... continue as normal
Are there any negatives to this that I have overlooked?
---
Todd Thiessen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Limitation of the release plugin?
Posted by Todd Thiessen <th...@nortel.com>.
Have anyone considered changing the release plugin such that it does not
commit the changes to the POM which removes SNAPSHOT from the version?
The only negative I can see is that you don't see a history of this
change in your trunk. But this shouldn't matter since you have a copy
of this POM in your tags. In fact, this makes more sense to me anyway.
I don't like seeing a released version of my POM in my trunk history.
So to be clear, the steps would be changed to this (roughly):
1. Make changes to the POM in your working copy to remove "SNAPSHOT"
from the version and make changes to your SCM entries to point to your
tags instead of your trunk. (Same)
2. DO NOT commit this change back to trunk. (Different).
3. Do an svn copy of your working directory to your tags, just as it
does today. (Same)
4. ... continue as normal
Are there any negatives to this that I have overlooked?
---
Todd Thiessen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Limitation of the release plugin?
Posted by "Nord, James" <JN...@nds.com>.
> > Todd Thiessen wrote:
> >> The first modification of the pom changes the version to
> remove the
> >> "-SNAPSHOT" and also changes the SCM values to point to the tag
> >> location instead of the trunk location. Once done, it
> then commits
> >> this change to trunk.
>
> To some extent I think there's a reason for this, which is so
> that the files will not appear to have been modified on the
> tag, and the tag is a straight copy of some actual SVN
> revision, rather than being created out of thin air from a
> working copy. (Of course, if you branch from a tag and have
> it increment the branch version numbers, it straight-up
> modifies the tag and then modifies it back, which bugs me.)
>
> Something similar is done when branching - version numbers
> are updated beforehand, then branched, so that the set of
> revisions on the branch doesn't include the version number
> change. I guess this is so when you merge over all changes on
> the branch to the turnk, you don't get a bunch of spurious
> version number changes that you'd have to ignore.
>
> >> Can anyone else confirm this? This seems pretty dangerous.
>
> Certainly confirmable. I guess the main danger is really if
> someone updates and does a 'mvn deploy' and it blows away
> your release version. Keeping your release deployment
> credentials close is good practice, so this would be pretty
> uncommon in the wild. But it's an issue that maybe bears
> rethinking nonetheless.
Yes, unfortunaltley it interferes with any(most?) CI systems - as the CI
System has the potential to see the release (on the trunk) and build it.
All my snapshots are built and deployed by the CI system, the only way I
have found to stop this is to disable the project in the CI server
before the release happens - which is a bit labour intensive but better
than changing all the versions and scm location by hand.
/James
*********************************************************************************************************
This e-mail is confidential, the property of NDS Ltd and intended for the addressee only. Any dissemination, copying or distribution of this message or any attachments by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please immediately notify the postmaster@nds.com and destroy the original message. Messages sent to and from NDS may be monitored. NDS cannot guarantee any message delivery method is secure or error-free. Information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. We do not accept responsibility for any errors or omissions in this message and/or attachment that arise as a result of transmission. You should carry out your own virus checks before opening any attachment. Any views or opinions presented are solely those of the author and do not necessarily represent those of NDS.
To protect the environment please do not print this e-mail unless necessary.
NDS Limited Registered office: One Heathrow Boulevard, 286 Bath Road, West Drayton, Middlesex, UB7 0DQ, United Kingdom. A company registered in England and Wales Registered no. 3080780 VAT no. GB 603 8808 40-00
**********************************************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Limitation of the release plugin?
Posted by Todd Thiessen <th...@nortel.com>.
If you did a revision copy, you would have to do commit to capture the
changes to the POM. You couldn't do a straight revision copy. So the
situation now become more complicated.
If you checkout revision x, someone may commit before you release
incrementing the revision to x+1. You then run your prepare,
incrementing the revision to x+2 to change the version of your pom to a
released version. So you now have to copy revision x+2 of your pom to
your tags folder but use revision x for everything else.
The best solution I see is to not commit the changes to the POM which
changes the version to a released version and continue to do a working
copy as the plugin does now.
Thoughts?
---
Todd Thiessen
> -----Original Message-----
> From: Nick Stolwijk [mailto:nick.stolwijk@gmail.com]
> Sent: Thursday, December 04, 2008 9:22 AM
> To: Maven Users List
> Subject: Re: Limitation of the release plugin?
>
> > Doing a copy from your working directory, however, is important. If
> > you did a copy from an SVN revision you could potentially release
> > something you didn't intend if someone commits to that
> revision after
> > the you checked out your working copy from that revion, but
> before you
> > performed the release.
>
> If the release plugin did a copy of the revision there would
> be no problem. The problem is that you cannot make a copy of
> the HEAD revision. You cannot commit anymore to any revision
> (It would make a new revision)
>
> Hth,
>
> Nick Stolwijk
> ~Java Developer~
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Limitation of the release plugin?
Posted by Nick Stolwijk <ni...@gmail.com>.
> Doing a copy from your working directory, however, is important. If you
> did a copy from an SVN revision you could potentially release something
> you didn't intend if someone commits to that revision after the you
> checked out your working copy from that revion, but before you performed
> the release.
If the release plugin did a copy of the revision there would be no
problem. The problem is that you cannot make a copy of the HEAD
revision. You cannot commit anymore to any revision (It would make a
new revision)
Hth,
Nick Stolwijk
~Java Developer~
Iprofs BV.
Claus Sluterweg 125
2012 WS Haarlem
www.iprofs.nl
On Thu, Dec 4, 2008 at 3:16 PM, Todd Thiessen <th...@nortel.com> wrote:
>
>> -----Original Message-----
>> From: sirlyric@gmail.com [mailto:sirlyric@gmail.com] On
>> Behalf Of John Stoneham
>>
>> To some extent I think there's a reason for this, which is so
>> that the files will not appear to have been modified on the
>> tag, and the tag is a straight copy of some actual SVN
>> revision, rather than being created out of thin air from a
>> working copy.
>
> I believe Maven intentially does an svn working dopy, not a copy from an
> SVN revision. If you look closely at the output from a prepare, you
> will see a line something like this:
>
> [INFO] Executing: svn --non-interactive copy --file
> D:\yourtempdir\maven-scm-791753447.commit .
> https://yoursvnserver/project/tags/project-1.0.0
>
> Notice that it copies from "." (BTW. There seems to be a bug with SVN
> working copies. You can read about that here [1]).
>
> Doing a copy from your working directory, however, is important. If you
> did a copy from an SVN revision you could potentially release something
> you didn't intend if someone commits to that revision after the you
> checked out your working copy from that revion, but before you performed
> the release.
>
> [1] http://jira.codehaus.org/browse/SCM-406
>
> ---
> Todd Thiessen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Limitation of the release plugin?
Posted by Todd Thiessen <th...@nortel.com>.
> -----Original Message-----
> From: sirlyric@gmail.com [mailto:sirlyric@gmail.com] On
> Behalf Of John Stoneham
>
> To some extent I think there's a reason for this, which is so
> that the files will not appear to have been modified on the
> tag, and the tag is a straight copy of some actual SVN
> revision, rather than being created out of thin air from a
> working copy.
I believe Maven intentially does an svn working dopy, not a copy from an
SVN revision. If you look closely at the output from a prepare, you
will see a line something like this:
[INFO] Executing: svn --non-interactive copy --file
D:\yourtempdir\maven-scm-791753447.commit .
https://yoursvnserver/project/tags/project-1.0.0
Notice that it copies from "." (BTW. There seems to be a bug with SVN
working copies. You can read about that here [1]).
Doing a copy from your working directory, however, is important. If you
did a copy from an SVN revision you could potentially release something
you didn't intend if someone commits to that revision after the you
checked out your working copy from that revion, but before you performed
the release.
[1] http://jira.codehaus.org/browse/SCM-406
---
Todd Thiessen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Limitation of the release plugin?
Posted by John Stoneham <ly...@lyrically.net>.
> Todd Thiessen wrote:
>> The first modification of the pom changes the version to remove the
>> "-SNAPSHOT" and also changes the SCM values to point to the tag location
>> instead of the trunk location. Once done, it then commits this change
>> to trunk.
To some extent I think there's a reason for this, which is so that the
files will not appear to have been modified on the tag, and the tag is
a straight copy of some actual SVN revision, rather than being created
out of thin air from a working copy. (Of course, if you branch from a
tag and have it increment the branch version numbers, it straight-up
modifies the tag and then modifies it back, which bugs me.)
Something similar is done when branching - version numbers are updated
beforehand, then branched, so that the set of revisions on the branch
doesn't include the version number change. I guess this is so when you
merge over all changes on the branch to the turnk, you don't get a
bunch of spurious version number changes that you'd have to ignore.
>> Can anyone else confirm this? This seems pretty dangerous.
Certainly confirmable. I guess the main danger is really if someone
updates and does a 'mvn deploy' and it blows away your release
version. Keeping your release deployment credentials close is good
practice, so this would be pretty uncommon in the wild. But it's an
issue that maybe bears rethinking nonetheless.
- John Stoneham
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Limitation of the release plugin?
Posted by John Stoneham <ly...@lyrically.net>.
On Wed, Dec 3, 2008 at 5:39 PM, Barrie Treloar <ba...@gmail.com> wrote:
> The alternative is to BRANCH first.
This is very true and we ended up doing this as well. It allows you to
lock down your code changes and then do any Maven fix-ups that you
need to do before release, without having to do them on the trunk
until you're sure they're OK. release:prepare/release:rollback to your
heart's content, then once you're really ready to pull the trigger,
release:perform and your branch transforms itself into a maintenance
branch.
Is there a wiki or something for best practices like this? I wish
someone had told me about all this before we made all the mistakes
that led us to rediscover this best practice on our own. The release
plugin is picky enough that it's become another piece of the You Must
Follow The Maven Way Or You Will Regret It dogma, but it's not nearly
so well documented.
- John Stoneham
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Limitation of the release plugin?
Posted by Barrie Treloar <ba...@gmail.com>.
On Thu, Dec 4, 2008 at 8:31 AM, David C. Hicks <dh...@i-hicks.org> wrote:
> Never noticed or thought about it. On my team, we call a "cease fire" when
> a build is being done to avoid any such problems. We were doing that before
> using Maven, too, so it's a bit of a hold-over. I can see your point,
> though.
The alternative is to BRANCH first.
We create a branch "<PROJECT_NAME>_RB_X_Y_Z"
And we release from that branch.
Only the release manager is using that branch so there are no issues.
After the release the release branch is merged back to head.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Limitation of the release plugin?
Posted by "David C. Hicks" <dh...@i-hicks.org>.
Never noticed or thought about it. On my team, we call a "cease fire"
when a build is being done to avoid any such problems. We were doing
that before using Maven, too, so it's a bit of a hold-over. I can see
your point, though.
Todd Thiessen wrote:
> I have been looking at the release plugin a fair bit lately and noticed
> something that concerned me.
>
> The first modification of the pom changes the version to remove the
> "-SNAPSHOT" and also changes the SCM values to point to the tag location
> instead of the trunk location. Once done, it then commits this change
> to trunk.
>
> So what happens if another user checks out the project during this
> window? I just tried testing it myself by interrupting a
> release:prepare right after the first commit. I then checkout the
> project to a another directory and lo and behold, the version looked
> like a released version and the SCM information referenced the tag not
> the trunk.
>
> Can anyone else confirm this? This seems pretty dangerous.
>
> ---
> Todd Thiessen
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org