You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Douglas Ferguson <do...@epsiia.com> on 2006/08/30 15:38:12 UTC
Can't release due to SNAPSHOT dependencies
I am using some snapshot plugins so it won�t let me release.
I can understand not wanting to release because of a dependency on code
or library snapshots, but for I don�t have any issues with releasing
something that is dependent on a snapshot of a tool, like cargo.
Is there a way around this?
Re: Can't release due to SNAPSHOT dependencies
Posted by Barrie Treloar <ba...@gmail.com>.
On 8/31/06, Wayne Fay <wa...@gmail.com> wrote:
> Download the code for the plugin(s) from SVN/CVS.
> Increment the version number to a fixed/released number, build,
> install locally and deploy to your corporate repo (if you have one) or
> provide it to your coworkers some other way.
> Update your pom to reflect the new plugin version number.
>
> Generally I would suggest you incorporate a timestamp into the build
> number ie maven-war-plugin 2.1.20060830 just to keep it clear that
> this is not necessarily a real release.
>
> Make sure you understand the artifact version system before picking a
> build number, or else you could easily end up with a situation where
> the "official" plugin releases a new version but your internal plugin
> is still considered "newer" ie if a plugin last released 2.0.5 and is
> currently releasing 2.1-SNAPSHOT, you might want to tag yours as 2.0.6
> or 2.0.5.1 -- if you tag it as 2.1, then you won't get the "real" 2.1
> release when it is final. (Of course, if the plugin release 2.0.6 then
> you'll get a collision there too...)
I wrote this up here
http://docs.codehaus.org/display/MAVENUSER/Patching+Maven+Plugins
It's what I used to release our team's code which needed snaphot
plugins + patches.
The wiki docs assume the next release is going to match the -SNAPSHOT
version being developed and that a younger release won't sneak in for
some critical reason.
Of course, the docs do warn you that when a release is made that you
need to double check it includes any patches that you manually
applied, as you may need to re-apply them.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Can't release due to SNAPSHOT dependencies
Posted by Barrie Treloar <ba...@gmail.com>.
On 8/31/06, Dave Hoffer <DH...@xrite.com> wrote:
> Why does it want to connect to 'people.apache.org'?
If you check the pom files you will find that people.apache.org has
been defined as a repository, probably to get access to the SNAPSHOT
of another plugin.
http://docs.codehaus.org/display/MAVENUSER/Patching+Maven+Plugins will
walk you through the steps.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Can't release due to SNAPSHOT dependencies
Posted by Doug Douglass <do...@gmail.com>.
mvn help:effective-pom should help you get a pom that can be tweaked for
corporate deployment.
Doug
On 8/30/06, Wayne Fay <wa...@gmail.com> wrote:
>
> I would guess that another pom somewhere else (or possibly even not in
> the source code you've got) is introducing this people.apache.org url.
>
> Two choices to chase this down...
> 1. Look in the pom for maven-idea-plugin. Find the parent reference.
> Go to that pom, check its parent. Rinse and repeat until eventually
> you find all the relevant poms and one of them probably has the
> people.apache.org reference.
>
> 2. Grep the Maven source code you've downloaded for
> "people.apache.org". Then grep your Maven install directory and your
> Maven local cache for this same url. I imagine you'll find it.
>
> Sorry I can't be more specific ("oh you need to edit file
> x/y/z/pom.xml"). Perhaps someone else can comment on this specific
> plugin??
>
> Wayne
>
> On 8/30/06, Dave Hoffer <DH...@xrite.com> wrote:
> > Here is a current example of the problem I have with the deploy goal. I
> > am trying to deploy a current build of the maven-idea-plugin.
> >
> > - I have checked out the entire maven source.
> > - At .\plugins\maven-idea-plugin I can install fine (but need to deploy
> > to our repo.
> > - I then edit .\plugins\maven-idea-plugin\pom.xml to be version
> > 2.0.1-beta20060830.
> > - I then search for the pom file that has the distributionManagement
> > repository/snapshotRepository entries. It looks like the only pom that
> > has this is .\pom\asf\pom.xml. I change these to use our local repo.
> >
> > When I run mvn deploy I get:
> >
> >
> > [INFO] [jar:jar]
> > [INFO] Building jar:
> > C:\svn\maven2\plugins\maven-idea-plugin\target\maven-idea-p
> > lugin-2.0.1-beta20060830.jar
> > [INFO] [plugin:addPluginArtifactMetadata]
> > [INFO] [install:install]
> > [INFO] Installing
> > C:\svn\maven2\plugins\maven-idea-plugin\target\maven-idea-plug
> > in-2.0.1-beta20060830.jar to C:\Documents and
> > Settings\DaveHoffer\.m2\repository
> > \org\apache\maven\plugins\maven-idea-plugin\2.0.1-beta20060830\maven-ide
> > a-plugin
> > -2.0.1-beta20060830.jar
> > [INFO] [plugin:updateRegistry]
> > [INFO] [deploy:deploy]
> > The authenticity of host 'people.apache.org' can't be established.
> > DSA key fingerprint is 79:7c:cb:6a:44:47:b2:ef:5c:66:28:d7:40:0d:b1:f9.
> > Are you sure you want to continue connecting? (yes/no): no
> > [INFO]
> > ------------------------------------------------------------------------
> > [ERROR] BUILD ERROR
> > [INFO]
> > ------------------------------------------------------------------------
> > [INFO] Error deploying artifact: Authentication failed: Cannot connect.
> > Reason:
> > reject HostKey: people.apache.org
> >
> >
> > Why does it want to connect to 'people.apache.org'?
> >
> > -dh
> >
> >
> >
> > -----Original Message-----
> > From: Dave Hoffer [mailto:DHoffer@xrite.com]
> > Sent: Wednesday, August 30, 2006 8:49 PM
> > To: Maven Users List
> > Subject: RE: Can't release due to SNAPSHOT dependencies
> >
> > Wayne,
> >
> > ...just to clarify.
> >
> > In order to deploy to my corporate repo I would have to edit the pom
> > files to deploy to my corporate repo instead of the real one. With some
> > large projects, i.e. maven plugins I have had trouble making the
> > necessary pom changes (lots of parent poms) to get the deploy to work.
> >
> > However, if this is the suggested approach I will try it again.
> >
> > -dh
> >
> >
> > -----Original Message-----
> > From: Douglas Ferguson [mailto:douglas.ferguson@epsiia.com]
> > Sent: Wednesday, August 30, 2006 12:21 PM
> > To: users
> > Subject: RE: Can't release due to SNAPSHOT dependencies
> >
> > Thanks.
> >
> > That makes a lot of sense...
> >
> > -----Original Message-----
> > From: Wayne Fay [mailto:waynefay@gmail.com]
> > Sent: Wednesday, August 30, 2006 10:12 AM
> > To: Maven Users List
> > Subject: Re: Can't release due to SNAPSHOT dependencies
> >
> > We've talked about this before on the list, and this is the generally
> > suggested approach...
> >
> > Download the code for the plugin(s) from SVN/CVS.
> > Increment the version number to a fixed/released number, build,
> > install locally and deploy to your corporate repo (if you have one) or
> > provide it to your coworkers some other way.
> > Update your pom to reflect the new plugin version number.
> >
> > Generally I would suggest you incorporate a timestamp into the build
> > number ie maven-war-plugin 2.1.20060830 just to keep it clear that
> > this is not necessarily a real release.
> >
> > Make sure you understand the artifact version system before picking a
> > build number, or else you could easily end up with a situation where
> > the "official" plugin releases a new version but your internal plugin
> > is still considered "newer" ie if a plugin last released 2.0.5 and is
> > currently releasing 2.1-SNAPSHOT, you might want to tag yours as 2.0.6
> > or 2.0.5.1 -- if you tag it as 2.1, then you won't get the "real" 2.1
> > release when it is final. (Of course, if the plugin release 2.0.6 then
> > you'll get a collision there too...)
> >
> > Wayne
> >
> > On 8/30/06, Douglas Ferguson <do...@epsiia.com> wrote:
> > > I am using some snapshot plugins so it won't let me release.
> > >
> > >
> > >
> > > I can understand not wanting to release because of a dependency on
> > code
> > > or library snapshots, but for I don't have any issues with releasing
> > > something that is dependent on a snapshot of a tool, like cargo.
> > >
> > >
> > >
> > > Is there a way around this?
> > >
> > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > 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: Can't release due to SNAPSHOT dependencies
Posted by Wayne Fay <wa...@gmail.com>.
I would guess that another pom somewhere else (or possibly even not in
the source code you've got) is introducing this people.apache.org url.
Two choices to chase this down...
1. Look in the pom for maven-idea-plugin. Find the parent reference.
Go to that pom, check its parent. Rinse and repeat until eventually
you find all the relevant poms and one of them probably has the
people.apache.org reference.
2. Grep the Maven source code you've downloaded for
"people.apache.org". Then grep your Maven install directory and your
Maven local cache for this same url. I imagine you'll find it.
Sorry I can't be more specific ("oh you need to edit file
x/y/z/pom.xml"). Perhaps someone else can comment on this specific
plugin??
Wayne
On 8/30/06, Dave Hoffer <DH...@xrite.com> wrote:
> Here is a current example of the problem I have with the deploy goal. I
> am trying to deploy a current build of the maven-idea-plugin.
>
> - I have checked out the entire maven source.
> - At .\plugins\maven-idea-plugin I can install fine (but need to deploy
> to our repo.
> - I then edit .\plugins\maven-idea-plugin\pom.xml to be version
> 2.0.1-beta20060830.
> - I then search for the pom file that has the distributionManagement
> repository/snapshotRepository entries. It looks like the only pom that
> has this is .\pom\asf\pom.xml. I change these to use our local repo.
>
> When I run mvn deploy I get:
>
>
> [INFO] [jar:jar]
> [INFO] Building jar:
> C:\svn\maven2\plugins\maven-idea-plugin\target\maven-idea-p
> lugin-2.0.1-beta20060830.jar
> [INFO] [plugin:addPluginArtifactMetadata]
> [INFO] [install:install]
> [INFO] Installing
> C:\svn\maven2\plugins\maven-idea-plugin\target\maven-idea-plug
> in-2.0.1-beta20060830.jar to C:\Documents and
> Settings\DaveHoffer\.m2\repository
> \org\apache\maven\plugins\maven-idea-plugin\2.0.1-beta20060830\maven-ide
> a-plugin
> -2.0.1-beta20060830.jar
> [INFO] [plugin:updateRegistry]
> [INFO] [deploy:deploy]
> The authenticity of host 'people.apache.org' can't be established.
> DSA key fingerprint is 79:7c:cb:6a:44:47:b2:ef:5c:66:28:d7:40:0d:b1:f9.
> Are you sure you want to continue connecting? (yes/no): no
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Error deploying artifact: Authentication failed: Cannot connect.
> Reason:
> reject HostKey: people.apache.org
>
>
> Why does it want to connect to 'people.apache.org'?
>
> -dh
>
>
>
> -----Original Message-----
> From: Dave Hoffer [mailto:DHoffer@xrite.com]
> Sent: Wednesday, August 30, 2006 8:49 PM
> To: Maven Users List
> Subject: RE: Can't release due to SNAPSHOT dependencies
>
> Wayne,
>
> ...just to clarify.
>
> In order to deploy to my corporate repo I would have to edit the pom
> files to deploy to my corporate repo instead of the real one. With some
> large projects, i.e. maven plugins I have had trouble making the
> necessary pom changes (lots of parent poms) to get the deploy to work.
>
> However, if this is the suggested approach I will try it again.
>
> -dh
>
>
> -----Original Message-----
> From: Douglas Ferguson [mailto:douglas.ferguson@epsiia.com]
> Sent: Wednesday, August 30, 2006 12:21 PM
> To: users
> Subject: RE: Can't release due to SNAPSHOT dependencies
>
> Thanks.
>
> That makes a lot of sense...
>
> -----Original Message-----
> From: Wayne Fay [mailto:waynefay@gmail.com]
> Sent: Wednesday, August 30, 2006 10:12 AM
> To: Maven Users List
> Subject: Re: Can't release due to SNAPSHOT dependencies
>
> We've talked about this before on the list, and this is the generally
> suggested approach...
>
> Download the code for the plugin(s) from SVN/CVS.
> Increment the version number to a fixed/released number, build,
> install locally and deploy to your corporate repo (if you have one) or
> provide it to your coworkers some other way.
> Update your pom to reflect the new plugin version number.
>
> Generally I would suggest you incorporate a timestamp into the build
> number ie maven-war-plugin 2.1.20060830 just to keep it clear that
> this is not necessarily a real release.
>
> Make sure you understand the artifact version system before picking a
> build number, or else you could easily end up with a situation where
> the "official" plugin releases a new version but your internal plugin
> is still considered "newer" ie if a plugin last released 2.0.5 and is
> currently releasing 2.1-SNAPSHOT, you might want to tag yours as 2.0.6
> or 2.0.5.1 -- if you tag it as 2.1, then you won't get the "real" 2.1
> release when it is final. (Of course, if the plugin release 2.0.6 then
> you'll get a collision there too...)
>
> Wayne
>
> On 8/30/06, Douglas Ferguson <do...@epsiia.com> wrote:
> > I am using some snapshot plugins so it won't let me release.
> >
> >
> >
> > I can understand not wanting to release because of a dependency on
> code
> > or library snapshots, but for I don't have any issues with releasing
> > something that is dependent on a snapshot of a tool, like cargo.
> >
> >
> >
> > Is there a way around this?
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> 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: Can't release due to SNAPSHOT dependencies
Posted by Dave Hoffer <DH...@xrite.com>.
Problem with another option to deploy as well...
I notice that I can use the deploy:deploy-file to deploy an artifact
with an existing pom. I think this would accomplish the same as the
deploy goal below.
Here is the syntax I used: mvn deploy:deploy-file
-DpomFile=<path-to-pom> \
-Dfile=<path-to-file> \
-DrepositoryId=<id-to-map-on-server-section-of-settings.xml> \
-Durl=<url-of-the-repositor-to-deploy>
When I execute this, the jar gets deployed just fine. However the pom
gets deleted from my current directory and I get an error stating that
Error installing metadata: Error rewriting POM
Then it says (The system cannot find the file specified)
Well it deleted the file...how can I fix this?
I have problems with both deploy options....
-dh
P.S. My maven version is 2.0.4. Do I need to be running a snapshot
version that has this fixed? Is it an issue that I am deploying
something newer than I am?
-----Original Message-----
From: Dave Hoffer [mailto:DHoffer@xrite.com]
Sent: Wednesday, August 30, 2006 9:47 PM
To: Maven Users List
Subject: RE: Can't release due to SNAPSHOT dependencies
Here is a current example of the problem I have with the deploy goal. I
am trying to deploy a current build of the maven-idea-plugin.
- I have checked out the entire maven source.
- At .\plugins\maven-idea-plugin I can install fine (but need to deploy
to our repo.
- I then edit .\plugins\maven-idea-plugin\pom.xml to be version
2.0.1-beta20060830.
- I then search for the pom file that has the distributionManagement
repository/snapshotRepository entries. It looks like the only pom that
has this is .\pom\asf\pom.xml. I change these to use our local repo.
When I run mvn deploy I get:
[INFO] [jar:jar]
[INFO] Building jar:
C:\svn\maven2\plugins\maven-idea-plugin\target\maven-idea-p
lugin-2.0.1-beta20060830.jar
[INFO] [plugin:addPluginArtifactMetadata]
[INFO] [install:install]
[INFO] Installing
C:\svn\maven2\plugins\maven-idea-plugin\target\maven-idea-plug
in-2.0.1-beta20060830.jar to C:\Documents and
Settings\DaveHoffer\.m2\repository
\org\apache\maven\plugins\maven-idea-plugin\2.0.1-beta20060830\maven-ide
a-plugin
-2.0.1-beta20060830.jar
[INFO] [plugin:updateRegistry]
[INFO] [deploy:deploy]
The authenticity of host 'people.apache.org' can't be established.
DSA key fingerprint is 79:7c:cb:6a:44:47:b2:ef:5c:66:28:d7:40:0d:b1:f9.
Are you sure you want to continue connecting? (yes/no): no
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] Error deploying artifact: Authentication failed: Cannot connect.
Reason:
reject HostKey: people.apache.org
Why does it want to connect to 'people.apache.org'?
-dh
-----Original Message-----
From: Dave Hoffer [mailto:DHoffer@xrite.com]
Sent: Wednesday, August 30, 2006 8:49 PM
To: Maven Users List
Subject: RE: Can't release due to SNAPSHOT dependencies
Wayne,
...just to clarify.
In order to deploy to my corporate repo I would have to edit the pom
files to deploy to my corporate repo instead of the real one. With some
large projects, i.e. maven plugins I have had trouble making the
necessary pom changes (lots of parent poms) to get the deploy to work.
However, if this is the suggested approach I will try it again.
-dh
-----Original Message-----
From: Douglas Ferguson [mailto:douglas.ferguson@epsiia.com]
Sent: Wednesday, August 30, 2006 12:21 PM
To: users
Subject: RE: Can't release due to SNAPSHOT dependencies
Thanks.
That makes a lot of sense...
-----Original Message-----
From: Wayne Fay [mailto:waynefay@gmail.com]
Sent: Wednesday, August 30, 2006 10:12 AM
To: Maven Users List
Subject: Re: Can't release due to SNAPSHOT dependencies
We've talked about this before on the list, and this is the generally
suggested approach...
Download the code for the plugin(s) from SVN/CVS.
Increment the version number to a fixed/released number, build,
install locally and deploy to your corporate repo (if you have one) or
provide it to your coworkers some other way.
Update your pom to reflect the new plugin version number.
Generally I would suggest you incorporate a timestamp into the build
number ie maven-war-plugin 2.1.20060830 just to keep it clear that
this is not necessarily a real release.
Make sure you understand the artifact version system before picking a
build number, or else you could easily end up with a situation where
the "official" plugin releases a new version but your internal plugin
is still considered "newer" ie if a plugin last released 2.0.5 and is
currently releasing 2.1-SNAPSHOT, you might want to tag yours as 2.0.6
or 2.0.5.1 -- if you tag it as 2.1, then you won't get the "real" 2.1
release when it is final. (Of course, if the plugin release 2.0.6 then
you'll get a collision there too...)
Wayne
On 8/30/06, Douglas Ferguson <do...@epsiia.com> wrote:
> I am using some snapshot plugins so it won't let me release.
>
>
>
> I can understand not wanting to release because of a dependency on
code
> or library snapshots, but for I don't have any issues with releasing
> something that is dependent on a snapshot of a tool, like cargo.
>
>
>
> Is there a way around this?
>
>
>
>
---------------------------------------------------------------------
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: Can't release due to SNAPSHOT dependencies
Posted by Dave Hoffer <DH...@xrite.com>.
Here is a current example of the problem I have with the deploy goal. I
am trying to deploy a current build of the maven-idea-plugin.
- I have checked out the entire maven source.
- At .\plugins\maven-idea-plugin I can install fine (but need to deploy
to our repo.
- I then edit .\plugins\maven-idea-plugin\pom.xml to be version
2.0.1-beta20060830.
- I then search for the pom file that has the distributionManagement
repository/snapshotRepository entries. It looks like the only pom that
has this is .\pom\asf\pom.xml. I change these to use our local repo.
When I run mvn deploy I get:
[INFO] [jar:jar]
[INFO] Building jar:
C:\svn\maven2\plugins\maven-idea-plugin\target\maven-idea-p
lugin-2.0.1-beta20060830.jar
[INFO] [plugin:addPluginArtifactMetadata]
[INFO] [install:install]
[INFO] Installing
C:\svn\maven2\plugins\maven-idea-plugin\target\maven-idea-plug
in-2.0.1-beta20060830.jar to C:\Documents and
Settings\DaveHoffer\.m2\repository
\org\apache\maven\plugins\maven-idea-plugin\2.0.1-beta20060830\maven-ide
a-plugin
-2.0.1-beta20060830.jar
[INFO] [plugin:updateRegistry]
[INFO] [deploy:deploy]
The authenticity of host 'people.apache.org' can't be established.
DSA key fingerprint is 79:7c:cb:6a:44:47:b2:ef:5c:66:28:d7:40:0d:b1:f9.
Are you sure you want to continue connecting? (yes/no): no
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] Error deploying artifact: Authentication failed: Cannot connect.
Reason:
reject HostKey: people.apache.org
Why does it want to connect to 'people.apache.org'?
-dh
-----Original Message-----
From: Dave Hoffer [mailto:DHoffer@xrite.com]
Sent: Wednesday, August 30, 2006 8:49 PM
To: Maven Users List
Subject: RE: Can't release due to SNAPSHOT dependencies
Wayne,
...just to clarify.
In order to deploy to my corporate repo I would have to edit the pom
files to deploy to my corporate repo instead of the real one. With some
large projects, i.e. maven plugins I have had trouble making the
necessary pom changes (lots of parent poms) to get the deploy to work.
However, if this is the suggested approach I will try it again.
-dh
-----Original Message-----
From: Douglas Ferguson [mailto:douglas.ferguson@epsiia.com]
Sent: Wednesday, August 30, 2006 12:21 PM
To: users
Subject: RE: Can't release due to SNAPSHOT dependencies
Thanks.
That makes a lot of sense...
-----Original Message-----
From: Wayne Fay [mailto:waynefay@gmail.com]
Sent: Wednesday, August 30, 2006 10:12 AM
To: Maven Users List
Subject: Re: Can't release due to SNAPSHOT dependencies
We've talked about this before on the list, and this is the generally
suggested approach...
Download the code for the plugin(s) from SVN/CVS.
Increment the version number to a fixed/released number, build,
install locally and deploy to your corporate repo (if you have one) or
provide it to your coworkers some other way.
Update your pom to reflect the new plugin version number.
Generally I would suggest you incorporate a timestamp into the build
number ie maven-war-plugin 2.1.20060830 just to keep it clear that
this is not necessarily a real release.
Make sure you understand the artifact version system before picking a
build number, or else you could easily end up with a situation where
the "official" plugin releases a new version but your internal plugin
is still considered "newer" ie if a plugin last released 2.0.5 and is
currently releasing 2.1-SNAPSHOT, you might want to tag yours as 2.0.6
or 2.0.5.1 -- if you tag it as 2.1, then you won't get the "real" 2.1
release when it is final. (Of course, if the plugin release 2.0.6 then
you'll get a collision there too...)
Wayne
On 8/30/06, Douglas Ferguson <do...@epsiia.com> wrote:
> I am using some snapshot plugins so it won't let me release.
>
>
>
> I can understand not wanting to release because of a dependency on
code
> or library snapshots, but for I don't have any issues with releasing
> something that is dependent on a snapshot of a tool, like cargo.
>
>
>
> Is there a way around this?
>
>
>
>
---------------------------------------------------------------------
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: Can't release due to SNAPSHOT dependencies
Posted by Dave Hoffer <DH...@xrite.com>.
Wayne,
...just to clarify.
In order to deploy to my corporate repo I would have to edit the pom
files to deploy to my corporate repo instead of the real one. With some
large projects, i.e. maven plugins I have had trouble making the
necessary pom changes (lots of parent poms) to get the deploy to work.
However, if this is the suggested approach I will try it again.
-dh
-----Original Message-----
From: Douglas Ferguson [mailto:douglas.ferguson@epsiia.com]
Sent: Wednesday, August 30, 2006 12:21 PM
To: users
Subject: RE: Can't release due to SNAPSHOT dependencies
Thanks.
That makes a lot of sense...
-----Original Message-----
From: Wayne Fay [mailto:waynefay@gmail.com]
Sent: Wednesday, August 30, 2006 10:12 AM
To: Maven Users List
Subject: Re: Can't release due to SNAPSHOT dependencies
We've talked about this before on the list, and this is the generally
suggested approach...
Download the code for the plugin(s) from SVN/CVS.
Increment the version number to a fixed/released number, build,
install locally and deploy to your corporate repo (if you have one) or
provide it to your coworkers some other way.
Update your pom to reflect the new plugin version number.
Generally I would suggest you incorporate a timestamp into the build
number ie maven-war-plugin 2.1.20060830 just to keep it clear that
this is not necessarily a real release.
Make sure you understand the artifact version system before picking a
build number, or else you could easily end up with a situation where
the "official" plugin releases a new version but your internal plugin
is still considered "newer" ie if a plugin last released 2.0.5 and is
currently releasing 2.1-SNAPSHOT, you might want to tag yours as 2.0.6
or 2.0.5.1 -- if you tag it as 2.1, then you won't get the "real" 2.1
release when it is final. (Of course, if the plugin release 2.0.6 then
you'll get a collision there too...)
Wayne
On 8/30/06, Douglas Ferguson <do...@epsiia.com> wrote:
> I am using some snapshot plugins so it won't let me release.
>
>
>
> I can understand not wanting to release because of a dependency on
code
> or library snapshots, but for I don't have any issues with releasing
> something that is dependent on a snapshot of a tool, like cargo.
>
>
>
> Is there a way around this?
>
>
>
>
---------------------------------------------------------------------
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: Can't release due to SNAPSHOT dependencies
Posted by Douglas Ferguson <do...@epsiia.com>.
Thanks.
That makes a lot of sense...
-----Original Message-----
From: Wayne Fay [mailto:waynefay@gmail.com]
Sent: Wednesday, August 30, 2006 10:12 AM
To: Maven Users List
Subject: Re: Can't release due to SNAPSHOT dependencies
We've talked about this before on the list, and this is the generally
suggested approach...
Download the code for the plugin(s) from SVN/CVS.
Increment the version number to a fixed/released number, build,
install locally and deploy to your corporate repo (if you have one) or
provide it to your coworkers some other way.
Update your pom to reflect the new plugin version number.
Generally I would suggest you incorporate a timestamp into the build
number ie maven-war-plugin 2.1.20060830 just to keep it clear that
this is not necessarily a real release.
Make sure you understand the artifact version system before picking a
build number, or else you could easily end up with a situation where
the "official" plugin releases a new version but your internal plugin
is still considered "newer" ie if a plugin last released 2.0.5 and is
currently releasing 2.1-SNAPSHOT, you might want to tag yours as 2.0.6
or 2.0.5.1 -- if you tag it as 2.1, then you won't get the "real" 2.1
release when it is final. (Of course, if the plugin release 2.0.6 then
you'll get a collision there too...)
Wayne
On 8/30/06, Douglas Ferguson <do...@epsiia.com> wrote:
> I am using some snapshot plugins so it won't let me release.
>
>
>
> I can understand not wanting to release because of a dependency on code
> or library snapshots, but for I don't have any issues with releasing
> something that is dependent on a snapshot of a tool, like cargo.
>
>
>
> Is there a way around this?
>
>
>
>
---------------------------------------------------------------------
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: Can't release due to SNAPSHOT dependencies
Posted by Wayne Fay <wa...@gmail.com>.
We've talked about this before on the list, and this is the generally
suggested approach...
Download the code for the plugin(s) from SVN/CVS.
Increment the version number to a fixed/released number, build,
install locally and deploy to your corporate repo (if you have one) or
provide it to your coworkers some other way.
Update your pom to reflect the new plugin version number.
Generally I would suggest you incorporate a timestamp into the build
number ie maven-war-plugin 2.1.20060830 just to keep it clear that
this is not necessarily a real release.
Make sure you understand the artifact version system before picking a
build number, or else you could easily end up with a situation where
the "official" plugin releases a new version but your internal plugin
is still considered "newer" ie if a plugin last released 2.0.5 and is
currently releasing 2.1-SNAPSHOT, you might want to tag yours as 2.0.6
or 2.0.5.1 -- if you tag it as 2.1, then you won't get the "real" 2.1
release when it is final. (Of course, if the plugin release 2.0.6 then
you'll get a collision there too...)
Wayne
On 8/30/06, Douglas Ferguson <do...@epsiia.com> wrote:
> I am using some snapshot plugins so it won't let me release.
>
>
>
> I can understand not wanting to release because of a dependency on code
> or library snapshots, but for I don't have any issues with releasing
> something that is dependent on a snapshot of a tool, like cargo.
>
>
>
> Is there a way around this?
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Can't release due to SNAPSHOT dependencies
Posted by Da...@tdameritrade.com.
The only way around it that we found was to modify the POM for the
snapshot plugin under question and release it into our team repository.
There is a good reason for not releasing code that has a snapshot
dependency on a plugin, though - the behavior of the plugin could change
resulting in the inability to reproduce the exact same build down the
road.
-----Original Message-----
From: Douglas Ferguson [mailto:douglas.ferguson@epsiia.com]
Sent: Wednesday, August 30, 2006 8:38 AM
To: users
Subject: Can't release due to SNAPSHOT dependencies
I am using some snapshot plugins so it won't let me release.
I can understand not wanting to release because of a dependency on code
or library snapshots, but for I don't have any issues with releasing
something that is dependent on a snapshot of a tool, like cargo.
Is there a way around this?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org