Re: Maven & Continuous Delivery

[Benson Margulies]

On Thu, Apr 21, 2016 at 10:20 PM, Dan Tran  wrote:
> does it upload the pom with its version fully translated?

All it does is arrange to trigger the 'version with a property'
functionality that was added quite some time ago. If that
functionality uploaded resolved poms, it uploads resolved poms. If
not, I guess, not.


>
> Thanks
>
> -D
>
> On Thu, Apr 21, 2016 at 6:40 PM, Benson Margulies 
> wrote:
>
>> On Thu, Apr 21, 2016 at 2:52 PM, Dan Tran  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 > >
>> > wrote:
>> >
>> >> https://github.com/basis-technology-corp/auto-version-maven-extension
>> >>
>> >> On Sat, Apr 16, 2016 at 2:23 PM, Jeff Jensen
>> >>  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  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  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, 

Re: Maven & Continuous Delivery

[Dan Tran]

does it upload the pom with its version fully translated?

Thanks

-D

On Thu, Apr 21, 2016 at 6:40 PM, Benson Margulies 
wrote:

> On Thu, Apr 21, 2016 at 2:52 PM, Dan Tran  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  >
> > wrote:
> >
> >> https://github.com/basis-technology-corp/auto-version-maven-extension
> >>
> >> On Sat, Apr 16, 2016 at 2:23 PM, Jeff Jensen
> >>  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  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  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
> >>
> >>
>
> 

Re: Maven & Continuous Delivery

[Benson Margulies]

On Thu, Apr 21, 2016 at 2:52 PM, Dan Tran  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 
> wrote:
>
>> https://github.com/basis-technology-corp/auto-version-maven-extension
>>
>> On Sat, Apr 16, 2016 at 2:23 PM, Jeff Jensen
>>  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  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  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

Re: Maven & Continuous Delivery

[Dan Tran]

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 
wrote:

> https://github.com/basis-technology-corp/auto-version-maven-extension
>
> On Sat, Apr 16, 2016 at 2:23 PM, Jeff Jensen
>  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  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  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
>
>

Re: Maven & Continuous Delivery

[Benson Margulies]

https://github.com/basis-technology-corp/auto-version-maven-extension

On Sat, Apr 16, 2016 at 2:23 PM, Jeff Jensen
 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  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  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

Re: Maven & Continuous Delivery

[Jeff Jensen]

>
> 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  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  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
> > >
> >
>

Re: Maven & Continuous Delivery

[Dan Tran]

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  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
> >
>

Re: Maven & Continuous Delivery

[Stephen Connolly]

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  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
>