Then you run into issues of cross timezone deployments.... (assuming you wanted to force the timestamp to match your last scm update timestamp)....or what if someone deployed since you last update?
On 8/13/08 8:34 AM, "nicolas de loof" <[EMAIL PROTECTED]> wrote: > Another option could be to have a parameter in the deploy mojo to set the > timestamp to be used, so that we can rebuild a previous snapshot by getting > it's sources from SCM at the timestamp date. > > > > 2008/8/13 Stephen Connolly <[EMAIL PROTECTED]> > >> Smarty-pants! >> >> That only works for internal projects. But what about if you are working on >> a public project and need the fix... If you deploy to your own repo we have >> a repo fight between my repo and repo1 >> >> ;-) >> >> On Wed, Aug 13, 2008 at 1:25 PM, Nick Stolwijk <[EMAIL PROTECTED] >>> wrote: >> >>> 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. >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
