https://github.com/basis-technology-corp/auto-version-maven-extension
On Sat, Apr 16, 2016 at 2:23 PM, Jeff Jensen <[email protected]> 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 <[email protected]> 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 < >> [email protected]> 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 <[email protected]> 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: [email protected] For additional commands, e-mail: [email protected]
