On Thu, Apr 21, 2016 at 2:52 PM, Dan Tran <dant...@gmail.com> wrote: > Hi Benson > > Sounds promissing > > does it support jenkins env BUILD_NUM?
I doubt it. I dislike Jenkins and avoid having anything to do with it. Feel free to make a PR. > does it push the actual version to maven repo at install/deploy time? if you run mvn deploy, your artifacts will be deployed. > > 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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
