On 4 Jul 07, at 5:32 PM 4 Jul 07, Barrie Treloar wrote:
Is there a preferred way of testing a staged release?
Yes, the way that we had originally talked about for a staged release
was providing a profile.xml that could be used in the project using
the staged version of an artifact. So that's how you can use the new
version without affecting your current POMs.
The only way to prevent pollution of your existing repo would be to
do something like:
mvn -Dmaven.repo.local=/tmp/test-repo mvn install
But depending on the project this may take a long time.
We should really generate a profiles.xml file.
Do I test both the staged plugin jar and the tagged code?
How do I avoid polluting my local repo with these staging plugins?
What do other committers do?
(I have the additional problem of being behind an NTLM proxy)
I can write up the response on the wiki for future reference.
I asked this question on the eclipse:2.4 release thread:
Barrie Treloar wrote:
Apologies for the noob question, but how do I test the stage release?
(I had a quick look at
http://docs.codehaus.org/display/MAVEN/Development+Process and
http://docs.codehaus.org/display/MAVEN/Development+Procedures but
couldn't find it).
Is it just a matter of defining
http://people.apache.org/~brianf/staging-repository/ as a repo in
settings.xml as:
<profile>
<id>staging</id>
<repositories>
<pluginRepositories>
<pluginRepository>
<id>staging</id>
<name>Maven Plugin Staging Repository</name>
<url>http://people.apache.org/~brianf/staging-repository/
</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</pluginRepository>
</pluginRepositories>
</profile>
That would work fine to allow trialling the plugin against various
projects on the command line.
The other part of testing would be to check out the svn tag and verify
that it builds.
What happens when the real thing is released? Will my local repo be
polluted with the staging details and I need to clean it up?
If you don't build it yourself, and the staged version is released
unchanged, then that's mostly not a problem - though there'd be some
metadata xml files left over in the local repo.
If you do build it yourself, then you'd *hope* you'd have an exact
workalike to the release, but it won't be bytewise identical, so you
probably ought to call that pollution, and clean it up.
And of course, there's the possibility that this staging iteration
doesn't succeed, in which case, it's *definitely* pollution in the
local
repo that needs to be cleaned up.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
