Hi Benson Sounds promissing
does it support jenkins env BUILD_NUM? does it push the actual version to maven repo at install/deploy time? Thanks -Dan On Thu, Apr 21, 2016 at 4:00 AM, Benson Margulies <bimargul...@gmail.com> wrote: > https://github.com/basis-technology-corp/auto-version-maven-extension > > On Sat, Apr 16, 2016 at 2:23 PM, Jeff Jensen > <jeffjen...@upstairstechnology.com> wrote: > >> > >> Jason van Zyl also mentioned he was working on CD solution for Maven > last > >> year, not sure what the progress on this front. > > > > > > Yes, I've been curious about the progress too. It's very needed and so > > promising. > > > > > > On Sat, Apr 16, 2016 at 5:49 AM, Dan Tran <dant...@gmail.com> wrote: > > > >> Thanks Stephen. > >> > >> I was excited for a short moment but hitting the reality where I may > have > >> to deal with hundreds of dev and qa over the confusion of the hidden > >> version. Especially, when they have to rebuild a subset of the product. > It > >> just not working > >> > >> Jason van Zyl also mentioned he was working on CD solution for Maven > last > >> year, not sure what the progress on this front. > >> > >> -Dan > >> > >> > >> > >> On Sat, Apr 16, 2016 at 12:51 AM, Stephen Connolly < > >> stephen.alan.conno...@gmail.com> wrote: > >> > >> > I share your concern. We could fix the concern if we created the > >> > transformed pom on disk so that things like GPG signatures were > generated > >> > correctly, but AIUI the issue there was that the pom could not be put > in > >> > target as that would break relative paths. > >> > > >> > I suspect this is also related to the issue of dependency reduced poms > >> for > >> > shade... or any feature where the pom to be used downstream in the > >> reactor > >> > needs to differ from the pom on disk. > >> > > >> > For me, having been burned by not building the effective pom from a > clean > >> > checkout I actually favour the use of the release plugin, typically > for > >> CD > >> > I just have the next development version the same as the current and > if > >> you > >> > tune your preparationGoals then you can just have one compile test > >> cycle... > >> > > >> > But the fight of that blog is a bit like the idiotic quest people > have to > >> > run the tests once only with code coverage as part of the single test > >> > execution... until you have been burned by the code coverage affecting > >> > effective bytecode and preventing the synchronization bug from being > >> caught > >> > by your tests (plus other test invalidating behaviours I have seen) > you > >> > will run around trying to get rid of the second test execution... > >> > > >> > Those who do not understand why we do things will be condemned to > repeat > >> > our mistakes that made us do things that way. > >> > > >> > Having said that, it is a good pressure to have people pushing the > "why > >> do > >> > we need to do it this way" envelope... perhaps it is time that we > need to > >> > ensure that the release plugin has a page outlining our rational for > the > >> > current default behaviour, common ways to tweak it and stressing that > we > >> > have provided a framework for releasing and others are welcome to > reuse > >> the > >> > framework in their own release plugins > >> > > >> > On 16 April 2016 at 06:01, Dan Tran <dant...@gmail.com> wrote: > >> > > >> > > Hi, > >> > > > >> > > Anyone practicing CD according to this blog? > >> > > https://axelfontaine.com/blog/dead-burried.html > >> > > > >> > > I can build locally, but have a huge concern on the pom deployed at > >> maven > >> > > repo since it does NOT have the exact version > >> > > > >> > > If you do, please share your experience. Any hick up when you > introduce > >> > > this new practice? > >> > > > >> > > For our case, we have about 200 modules project and about 100 dev + > qa > >> > > > >> > > Thanks > >> > > > >> > > -Dan > >> > > > >> > > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
