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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]