I admit, it is not a really good way of doing this. We used this with internal projects, with our own repository. Mostly when we bumped into a solved issue, which was not already released. I checked out the trunk, changed the version numbers to something like <current-trunk-version>-<company-name>-<revisionnumber>, added the distributionManagement for our own repository and ran a mvn deploy.
I would prefer more, quicker releases also, but this is a workable work around. With regards, Nick Stolwijk ~Java Developer~ Iprofs BV. Claus Sluterweg 125 2012 WS Haarlem www.iprofs.nl On Wed, Aug 13, 2008 at 2:31 PM, nicolas de loof <[EMAIL PROTECTED]> wrote: > Maybe I'm wrong, but this requires me to commit (to use the release plugin) > the original POM ! > > 2008/8/13 Nick Stolwijk <[EMAIL PROTECTED]> > > > The other option would be to create a release of the plugin in your own > > repository, with an own version number. > > > > Hth, > > > > Nick Stolwijk > > ~Java Developer~ > > > > Iprofs BV. > > Claus Sluterweg 125 > > 2012 WS Haarlem > > www.iprofs.nl > > > > > > On Wed, Aug 13, 2008 at 2:20 PM, nicolas de loof <[EMAIL PROTECTED]> > > wrote: > > > > > The option is to allow timestamp for SNAPSHOT dependencies, considering > > the > > > timestamp jar will not be updated as a SNAPSHOT would, and so the build > > > get's reproductible ... until the snapshot repo gets cleaned ! > > > > > > The idea is interesting as we hardly get plugin releases, and have no > > > roadmap for them, so a project that requires a bug fix has no other > > option > > > > > > > > > 2008/8/13 Stephen Connolly <[EMAIL PROTECTED]> > > > > > > > Oooooh! there's an option to allow snapshot dependencies in release? > > > Cool! > > > > I did not know that... Now I can go cause me a heap load of trouble! > > > > > > > > On Wed, Aug 13, 2008 at 1:14 PM, nicolas de loof <[EMAIL PROTECTED] > > > > > > wrote: > > > > > > > > > Would you DEPLOY a snapshot without first testing and commiting ? > > > > > > > > > > You're right that this is not a 100% safe way to fix this issue, > just > > > an > > > > > attempt to make things (a little bit) more stable. > > > > > A full fix would be to never use SNAPSHOTs, and to deprecate > > > > > release/enforcer option to accept them ;-) > > > > > > > > > > 2008/8/13 Stephen Connolly <[EMAIL PROTECTED]> > > > > > > > > > > > Of course the problem with that is what if there were local > changes > > > > when > > > > > > the > > > > > > build was made? Now the SCM revision is meaningless > > > > > > > > > > > > On Wed, Aug 13, 2008 at 1:03 PM, nicolas de loof < > > [EMAIL PROTECTED] > > > > > > > > > > wrote: > > > > > > > > > > > > > Recent snapshot repository purge introduced issues for those of > > us > > > > that > > > > > > > depend on a specific timestamp SNAPSHOT. This is supposed to be > a > > > > valid > > > > > > > usecase as supported by the release and enforcer plugins. > > > > > > > > > > > > > > There is no way to rebuild such jars, as we can get the sources > > > from > > > > > SCM > > > > > > > according to date, but cannot build and deploy the jar with the > > > > > expected > > > > > > > name (manual renaming is required). > > > > > > > > > > > > > > Could we consider for future the option to use the SCM revision > ( > > > for > > > > > SCM > > > > > > > that support this option, but most of us use SVN ;-) ) in > > > replacement > > > > > to > > > > > > a > > > > > > > timestamp, so that a specific timestamp can easily be rebuilded > > at > > > > > > anytime > > > > > > > ? > > > > > > > The version format could be "X.Y.Z-revision-ABCDE". > > > > > > > > > > > > > > Nicolas. > > > > > > > > > > > > > > > > > > > > > > > > > > > >
