Quantcast

Continuous Delivery with Maven now possible?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Continuous Delivery with Maven now possible?

Dan Tran
Hi

I have been experimenting with suggestion from Karl [1] with small multi
module maven project.


Is there any one actually bring this to production for large scale project
yet? Love to learn from your experience integration specially with Jenkins,
IDE ( eclipse,  intellij, Netbean)

this allows us to stop using maven-release-plugin

Thanks

-Dan

[1]
http://blog.soebes.de/blog/2017/04/02/maven-pom-files-without-a-version-in-it/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Continuous Delivery with Maven now possible?

Karl Heinz Marbaise-3
Hi Dan,

I'm trying to do something in this direction starting next week...

Apart from that already tested it with Eclipse Neon without any
issue...(at the moment only test projects with 10-15 modules)...

But it works at the moment..

In the meantime I have found one issue which is related to
maven-enforcer-plugin where I already opened an issue for it [1]..

Kind regards
Karl Heinz

[1]: https://issues.apache.org/jira/browse/MENFORCER-268

On 03/05/17 20:39, Dan Tran wrote:

> Hi
>
> I have been experimenting with suggestion from Karl [1] with small multi
> module maven project.
>
>
> Is there any one actually bring this to production for large scale project
> yet? Love to learn from your experience integration specially with Jenkins,
> IDE ( eclipse,  intellij, Netbean)
>
> this allows us to stop using maven-release-plugin
>
> Thanks
>
> -Dan
>
> [1]
> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-without-a-version-in-it/
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Continuous Delivery with Maven now possible?

Eric B
Hi Karl,

Can you provide a little more information how you are doing this? Or do you
have a blog about it somewhere? It's something I desperately need to insert
into my build pipeline but haven't had the time to work on yet.  So far,
the best I've been able to think of is to use a parameter for a build
number, have Jenkins assign a build number, pass it to maven, and have the
version reflect the build number using the external parameter.  But I
really don't like that idea as the version is now dependent on a variable,
which I find is contrary to the whole concept.

The other option is to have Jenkins took the build number in the pom using
the release plugin or the version plugin, commit the new pom, and then
build from a newly checked out code.  My issue there is that I'm having
Jenkins do a lot of scm manipulations which are more subject to failing
(ie: version updates, commit, tag, push, etc).

Finally, I'm trying to think of a good way of rolling all this into Nexus
staging repos and only promoting a build out of a staging repo once it
passes the pre prod environment and is certified for prod.

Any ideas, thoughts, feedback and/or tips would be greatly appreciated.

Thanks,

Eric

On May 3, 2017 2:50 PM, "Karl Heinz Marbaise" <[hidden email]> wrote:

> Hi Dan,
>
> I'm trying to do something in this direction starting next week...
>
> Apart from that already tested it with Eclipse Neon without any
> issue...(at the moment only test projects with 10-15 modules)...
>
> But it works at the moment..
>
> In the meantime I have found one issue which is related to
> maven-enforcer-plugin where I already opened an issue for it [1]..
>
> Kind regards
> Karl Heinz
>
> [1]: https://issues.apache.org/jira/browse/MENFORCER-268
>
> On 03/05/17 20:39, Dan Tran wrote:
>
>> Hi
>>
>> I have been experimenting with suggestion from Karl [1] with small multi
>> module maven project.
>>
>>
>> Is there any one actually bring this to production for large scale project
>> yet? Love to learn from your experience integration specially with
>> Jenkins,
>> IDE ( eclipse,  intellij, Netbean)
>>
>> this allows us to stop using maven-release-plugin
>>
>> Thanks
>>
>> -Dan
>>
>> [1]
>> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
>> t-a-version-in-it/
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Continuous Delivery with Maven now possible?

Dan Tran
I am able to bring it to production with very small project with few
modules. Where I hook up jenkins build number with the version

  <revision>1.0.0-${env.BUILD_NUMBER}</revision>  See Karl's Blog

At the same time,  use buildnumber-m-p to deploy text file with SCM info,
and finally push to staging repo using Artifactory

Once a build is promoted (GAed), I then remove the rest from staging,  and
manually tag the build using the recorded SCM info

My next task is a much bigger project with 300+ modules and lots of
dev/qa.  So it is crucial i dont break their development environments

Thanks

-Dan


On Wed, May 3, 2017 at 5:34 PM, Eric B <[hidden email]> wrote:

> Hi Karl,
>
> Can you provide a little more information how you are doing this? Or do you
> have a blog about it somewhere? It's something I desperately need to insert
> into my build pipeline but haven't had the time to work on yet.  So far,
> the best I've been able to think of is to use a parameter for a build
> number, have Jenkins assign a build number, pass it to maven, and have the
> version reflect the build number using the external parameter.  But I
> really don't like that idea as the version is now dependent on a variable,
> which I find is contrary to the whole concept.
>
> The other option is to have Jenkins took the build number in the pom using
> the release plugin or the version plugin, commit the new pom, and then
> build from a newly checked out code.  My issue there is that I'm having
> Jenkins do a lot of scm manipulations which are more subject to failing
> (ie: version updates, commit, tag, push, etc).
>
> Finally, I'm trying to think of a good way of rolling all this into Nexus
> staging repos and only promoting a build out of a staging repo once it
> passes the pre prod environment and is certified for prod.
>
> Any ideas, thoughts, feedback and/or tips would be greatly appreciated.
>
> Thanks,
>
> Eric
>
> On May 3, 2017 2:50 PM, "Karl Heinz Marbaise" <[hidden email]> wrote:
>
> > Hi Dan,
> >
> > I'm trying to do something in this direction starting next week...
> >
> > Apart from that already tested it with Eclipse Neon without any
> > issue...(at the moment only test projects with 10-15 modules)...
> >
> > But it works at the moment..
> >
> > In the meantime I have found one issue which is related to
> > maven-enforcer-plugin where I already opened an issue for it [1]..
> >
> > Kind regards
> > Karl Heinz
> >
> > [1]: https://issues.apache.org/jira/browse/MENFORCER-268
> >
> > On 03/05/17 20:39, Dan Tran wrote:
> >
> >> Hi
> >>
> >> I have been experimenting with suggestion from Karl [1] with small multi
> >> module maven project.
> >>
> >>
> >> Is there any one actually bring this to production for large scale
> project
> >> yet? Love to learn from your experience integration specially with
> >> Jenkins,
> >> IDE ( eclipse,  intellij, Netbean)
> >>
> >> this allows us to stop using maven-release-plugin
> >>
> >> Thanks
> >>
> >> -Dan
> >>
> >> [1]
> >> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
> >> t-a-version-in-it/
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Continuous Delivery with Maven now possible?

Eric B
Hi Dan,

Can you point me to Karl's blog please? I looked for it, but can't seem to
find it.

Thanks!

Eric

On May 3, 2017 8:56 PM, "Dan Tran" <[hidden email]> wrote:

> I am able to bring it to production with very small project with few
> modules. Where I hook up jenkins build number with the version
>
>   <revision>1.0.0-${env.BUILD_NUMBER}</revision>  See Karl's Blog
>
> At the same time,  use buildnumber-m-p to deploy text file with SCM info,
> and finally push to staging repo using Artifactory
>
> Once a build is promoted (GAed), I then remove the rest from staging,  and
> manually tag the build using the recorded SCM info
>
> My next task is a much bigger project with 300+ modules and lots of
> dev/qa.  So it is crucial i dont break their development environments
>
> Thanks
>
> -Dan
>
>
> On Wed, May 3, 2017 at 5:34 PM, Eric B <[hidden email]> wrote:
>
> > Hi Karl,
> >
> > Can you provide a little more information how you are doing this? Or do
> you
> > have a blog about it somewhere? It's something I desperately need to
> insert
> > into my build pipeline but haven't had the time to work on yet.  So far,
> > the best I've been able to think of is to use a parameter for a build
> > number, have Jenkins assign a build number, pass it to maven, and have
> the
> > version reflect the build number using the external parameter.  But I
> > really don't like that idea as the version is now dependent on a
> variable,
> > which I find is contrary to the whole concept.
> >
> > The other option is to have Jenkins took the build number in the pom
> using
> > the release plugin or the version plugin, commit the new pom, and then
> > build from a newly checked out code.  My issue there is that I'm having
> > Jenkins do a lot of scm manipulations which are more subject to failing
> > (ie: version updates, commit, tag, push, etc).
> >
> > Finally, I'm trying to think of a good way of rolling all this into Nexus
> > staging repos and only promoting a build out of a staging repo once it
> > passes the pre prod environment and is certified for prod.
> >
> > Any ideas, thoughts, feedback and/or tips would be greatly appreciated.
> >
> > Thanks,
> >
> > Eric
> >
> > On May 3, 2017 2:50 PM, "Karl Heinz Marbaise" <[hidden email]> wrote:
> >
> > > Hi Dan,
> > >
> > > I'm trying to do something in this direction starting next week...
> > >
> > > Apart from that already tested it with Eclipse Neon without any
> > > issue...(at the moment only test projects with 10-15 modules)...
> > >
> > > But it works at the moment..
> > >
> > > In the meantime I have found one issue which is related to
> > > maven-enforcer-plugin where I already opened an issue for it [1]..
> > >
> > > Kind regards
> > > Karl Heinz
> > >
> > > [1]: https://issues.apache.org/jira/browse/MENFORCER-268
> > >
> > > On 03/05/17 20:39, Dan Tran wrote:
> > >
> > >> Hi
> > >>
> > >> I have been experimenting with suggestion from Karl [1] with small
> multi
> > >> module maven project.
> > >>
> > >>
> > >> Is there any one actually bring this to production for large scale
> > project
> > >> yet? Love to learn from your experience integration specially with
> > >> Jenkins,
> > >> IDE ( eclipse,  intellij, Netbean)
> > >>
> > >> this allows us to stop using maven-release-plugin
> > >>
> > >> Thanks
> > >>
> > >> -Dan
> > >>
> > >> [1]
> > >> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
> > >> t-a-version-in-it/
> > >>
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Continuous Delivery with Maven now possible?

jieryn
http://blog.soebes.de/blog/2017/04/02/maven-pom-files-without-a-version-in-it/

On Thu, May 4, 2017 at 7:48 AM, Eric B <[hidden email]> wrote:

> Hi Dan,
>
> Can you point me to Karl's blog please? I looked for it, but can't seem to
> find it.
>
> Thanks!
>
> Eric
>
> On May 3, 2017 8:56 PM, "Dan Tran" <[hidden email]> wrote:
>
>> I am able to bring it to production with very small project with few
>> modules. Where I hook up jenkins build number with the version
>>
>>   <revision>1.0.0-${env.BUILD_NUMBER}</revision>  See Karl's Blog
>>
>> At the same time,  use buildnumber-m-p to deploy text file with SCM info,
>> and finally push to staging repo using Artifactory
>>
>> Once a build is promoted (GAed), I then remove the rest from staging,  and
>> manually tag the build using the recorded SCM info
>>
>> My next task is a much bigger project with 300+ modules and lots of
>> dev/qa.  So it is crucial i dont break their development environments
>>
>> Thanks
>>
>> -Dan
>>
>>
>> On Wed, May 3, 2017 at 5:34 PM, Eric B <[hidden email]> wrote:
>>
>> > Hi Karl,
>> >
>> > Can you provide a little more information how you are doing this? Or do
>> you
>> > have a blog about it somewhere? It's something I desperately need to
>> insert
>> > into my build pipeline but haven't had the time to work on yet.  So far,
>> > the best I've been able to think of is to use a parameter for a build
>> > number, have Jenkins assign a build number, pass it to maven, and have
>> the
>> > version reflect the build number using the external parameter.  But I
>> > really don't like that idea as the version is now dependent on a
>> variable,
>> > which I find is contrary to the whole concept.
>> >
>> > The other option is to have Jenkins took the build number in the pom
>> using
>> > the release plugin or the version plugin, commit the new pom, and then
>> > build from a newly checked out code.  My issue there is that I'm having
>> > Jenkins do a lot of scm manipulations which are more subject to failing
>> > (ie: version updates, commit, tag, push, etc).
>> >
>> > Finally, I'm trying to think of a good way of rolling all this into Nexus
>> > staging repos and only promoting a build out of a staging repo once it
>> > passes the pre prod environment and is certified for prod.
>> >
>> > Any ideas, thoughts, feedback and/or tips would be greatly appreciated.
>> >
>> > Thanks,
>> >
>> > Eric
>> >
>> > On May 3, 2017 2:50 PM, "Karl Heinz Marbaise" <[hidden email]> wrote:
>> >
>> > > Hi Dan,
>> > >
>> > > I'm trying to do something in this direction starting next week...
>> > >
>> > > Apart from that already tested it with Eclipse Neon without any
>> > > issue...(at the moment only test projects with 10-15 modules)...
>> > >
>> > > But it works at the moment..
>> > >
>> > > In the meantime I have found one issue which is related to
>> > > maven-enforcer-plugin where I already opened an issue for it [1]..
>> > >
>> > > Kind regards
>> > > Karl Heinz
>> > >
>> > > [1]: https://issues.apache.org/jira/browse/MENFORCER-268
>> > >
>> > > On 03/05/17 20:39, Dan Tran wrote:
>> > >
>> > >> Hi
>> > >>
>> > >> I have been experimenting with suggestion from Karl [1] with small
>> multi
>> > >> module maven project.
>> > >>
>> > >>
>> > >> Is there any one actually bring this to production for large scale
>> > project
>> > >> yet? Love to learn from your experience integration specially with
>> > >> Jenkins,
>> > >> IDE ( eclipse,  intellij, Netbean)
>> > >>
>> > >> this allows us to stop using maven-release-plugin
>> > >>
>> > >> Thanks
>> > >>
>> > >> -Dan
>> > >>
>> > >> [1]
>> > >> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
>> > >> t-a-version-in-it/
>> > >>
>> > >>
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: [hidden email]
>> > > For additional commands, e-mail: [hidden email]
>> > >
>> > >
>> >
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Continuous Delivery with Maven now possible?

Curtis Rueden
In reply to this post by Dan Tran
Hi Dan, Karl & everyone,

> See Karl's Blog

Link, please?

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden


On Wed, May 3, 2017 at 7:54 PM, Dan Tran <[hidden email]> wrote:

> I am able to bring it to production with very small project with few
> modules. Where I hook up jenkins build number with the version
>
>   <revision>1.0.0-${env.BUILD_NUMBER}</revision>  See Karl's Blog
>
> At the same time,  use buildnumber-m-p to deploy text file with SCM info,
> and finally push to staging repo using Artifactory
>
> Once a build is promoted (GAed), I then remove the rest from staging,  and
> manually tag the build using the recorded SCM info
>
> My next task is a much bigger project with 300+ modules and lots of
> dev/qa.  So it is crucial i dont break their development environments
>
> Thanks
>
> -Dan
>
>
> On Wed, May 3, 2017 at 5:34 PM, Eric B <[hidden email]> wrote:
>
> > Hi Karl,
> >
> > Can you provide a little more information how you are doing this? Or do
> you
> > have a blog about it somewhere? It's something I desperately need to
> insert
> > into my build pipeline but haven't had the time to work on yet.  So far,
> > the best I've been able to think of is to use a parameter for a build
> > number, have Jenkins assign a build number, pass it to maven, and have
> the
> > version reflect the build number using the external parameter.  But I
> > really don't like that idea as the version is now dependent on a
> variable,
> > which I find is contrary to the whole concept.
> >
> > The other option is to have Jenkins took the build number in the pom
> using
> > the release plugin or the version plugin, commit the new pom, and then
> > build from a newly checked out code.  My issue there is that I'm having
> > Jenkins do a lot of scm manipulations which are more subject to failing
> > (ie: version updates, commit, tag, push, etc).
> >
> > Finally, I'm trying to think of a good way of rolling all this into Nexus
> > staging repos and only promoting a build out of a staging repo once it
> > passes the pre prod environment and is certified for prod.
> >
> > Any ideas, thoughts, feedback and/or tips would be greatly appreciated.
> >
> > Thanks,
> >
> > Eric
> >
> > On May 3, 2017 2:50 PM, "Karl Heinz Marbaise" <[hidden email]> wrote:
> >
> > > Hi Dan,
> > >
> > > I'm trying to do something in this direction starting next week...
> > >
> > > Apart from that already tested it with Eclipse Neon without any
> > > issue...(at the moment only test projects with 10-15 modules)...
> > >
> > > But it works at the moment..
> > >
> > > In the meantime I have found one issue which is related to
> > > maven-enforcer-plugin where I already opened an issue for it [1]..
> > >
> > > Kind regards
> > > Karl Heinz
> > >
> > > [1]: https://issues.apache.org/jira/browse/MENFORCER-268
> > >
> > > On 03/05/17 20:39, Dan Tran wrote:
> > >
> > >> Hi
> > >>
> > >> I have been experimenting with suggestion from Karl [1] with small
> multi
> > >> module maven project.
> > >>
> > >>
> > >> Is there any one actually bring this to production for large scale
> > project
> > >> yet? Love to learn from your experience integration specially with
> > >> Jenkins,
> > >> IDE ( eclipse,  intellij, Netbean)
> > >>
> > >> this allows us to stop using maven-release-plugin
> > >>
> > >> Thanks
> > >>
> > >> -Dan
> > >>
> > >> [1]
> > >> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
> > >> t-a-version-in-it/
> > >>
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Continuous Delivery with Maven now possible?

Thomas Broyer-2
How about everybody read their mail?
(see below)

On Thu, May 4, 2017 at 6:10 PM Curtis Rueden <[hidden email]> wrote:

> Hi Dan, Karl & everyone,
>
> > See Karl's Blog
>
> Link, please?
>
[…]

> > > > On 03/05/17 20:39, Dan Tran wrote:
> > > >
> > > >> Hi
> > > >>
> > > >> I have been experimenting with suggestion from Karl [1] with small
> > multi
> > > >> module maven project.

[…]

> > > >> [1]
> > > >> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
> > > >> t-a-version-in-it/
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Continuous Delivery with Maven now possible?

Dan Tran
In reply to this post by Dan Tran
a couple corrections:

  * for Jenkins freeslyle, one can create a job parameter  similiar to this
format   revision=x.y.x-${BUILD_NUMBER} to override the default maven
version

  * for Jenkins Pipeline, the revision handling is part of  projec's t
Jenkinsfile

The original blog is here http://blog.soebes.de/blog/
2017/04/02/maven-pom-files-without-a-version-in-it/

-D

On Wed, May 3, 2017 at 5:54 PM, Dan Tran <[hidden email]> wrote:

> I am able to bring it to production with very small project with few
> modules. Where I hook up jenkins build number with the version
>
>   <revision>1.0.0-${env.BUILD_NUMBER}</revision>  See Karl's Blog
>
> At the same time,  use buildnumber-m-p to deploy text file with SCM info,
> and finally push to staging repo using Artifactory
>
> Once a build is promoted (GAed), I then remove the rest from staging,  and
> manually tag the build using the recorded SCM info
>
> My next task is a much bigger project with 300+ modules and lots of
> dev/qa.  So it is crucial i dont break their development environments
>
> Thanks
>
> -Dan
>
>
> On Wed, May 3, 2017 at 5:34 PM, Eric B <[hidden email]> wrote:
>
>> Hi Karl,
>>
>> Can you provide a little more information how you are doing this? Or do
>> you
>> have a blog about it somewhere? It's something I desperately need to
>> insert
>> into my build pipeline but haven't had the time to work on yet.  So far,
>> the best I've been able to think of is to use a parameter for a build
>> number, have Jenkins assign a build number, pass it to maven, and have the
>> version reflect the build number using the external parameter.  But I
>> really don't like that idea as the version is now dependent on a variable,
>> which I find is contrary to the whole concept.
>>
>> The other option is to have Jenkins took the build number in the pom using
>> the release plugin or the version plugin, commit the new pom, and then
>> build from a newly checked out code.  My issue there is that I'm having
>> Jenkins do a lot of scm manipulations which are more subject to failing
>> (ie: version updates, commit, tag, push, etc).
>>
>> Finally, I'm trying to think of a good way of rolling all this into Nexus
>> staging repos and only promoting a build out of a staging repo once it
>> passes the pre prod environment and is certified for prod.
>>
>> Any ideas, thoughts, feedback and/or tips would be greatly appreciated.
>>
>> Thanks,
>>
>> Eric
>>
>> On May 3, 2017 2:50 PM, "Karl Heinz Marbaise" <[hidden email]> wrote:
>>
>> > Hi Dan,
>> >
>> > I'm trying to do something in this direction starting next week...
>> >
>> > Apart from that already tested it with Eclipse Neon without any
>> > issue...(at the moment only test projects with 10-15 modules)...
>> >
>> > But it works at the moment..
>> >
>> > In the meantime I have found one issue which is related to
>> > maven-enforcer-plugin where I already opened an issue for it [1]..
>> >
>> > Kind regards
>> > Karl Heinz
>> >
>> > [1]: https://issues.apache.org/jira/browse/MENFORCER-268
>> >
>> > On 03/05/17 20:39, Dan Tran wrote:
>> >
>> >> Hi
>> >>
>> >> I have been experimenting with suggestion from Karl [1] with small
>> multi
>> >> module maven project.
>> >>
>> >>
>> >> Is there any one actually bring this to production for large scale
>> project
>> >> yet? Love to learn from your experience integration specially with
>> >> Jenkins,
>> >> IDE ( eclipse,  intellij, Netbean)
>> >>
>> >> this allows us to stop using maven-release-plugin
>> >>
>> >> Thanks
>> >>
>> >> -Dan
>> >>
>> >> [1]
>> >> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
>> >> t-a-version-in-it/
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>> >
>>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Continuous Delivery with Maven now possible?

Eric Benzacar
In reply to this post by Thomas Broyer-2
I've read through Karl's blog (http://blog.soebes.de/blog/
2017/04/02/maven-pom-files-without-a-version-in-it/), and while I
understand the approach, there is still one critical issue that bothers
me.  I think this actually reopens an old thread that circulated on this
list a few months ago, but it related to the Idempotence of a pom file.

From my perspective/view a pom file should be idempotent.  That is every
single build of a given NON-SNAPSHOT pom file should finish with the same
build.  But by moving a release number or version number outside of the
pom, it eliminates this need.  Furthermore, from a traceability
perspective, my source control can no longer show me precisely version was
being built/developed at any given time.

By leveraging the mvn.config file, I'm a little further down the path, but
none the less, the value can be overridden at build time with a completely
different value.  Consequently, I can still not be 100% confident that a
pom delivered a particular version.

I'm still not 100% sure of the best approach going forward, but I'm
thinking that something like the version-plugin being able to manipulate a
revision property that can then be committed as part of the pom would be
the best of both approaches.  In that way, my developers can fix the
version number, but my build system can manipulate the revision property.

Does anyone know if there is a plugin that will allow for that?

Thanks,

Eric


On Thu, May 4, 2017 at 12:40 PM, Thomas Broyer <[hidden email]> wrote:

> How about everybody read their mail?
> (see below)
>
> On Thu, May 4, 2017 at 6:10 PM Curtis Rueden <[hidden email]> wrote:
>
> > Hi Dan, Karl & everyone,
> >
> > > See Karl's Blog
> >
> > Link, please?
> >
> […]
>
> > > > > On 03/05/17 20:39, Dan Tran wrote:
> > > > >
> > > > >> Hi
> > > > >>
> > > > >> I have been experimenting with suggestion from Karl [1] with small
> > > multi
> > > > >> module maven project.
>
> […]
>
> > > > >> [1]
> > > > >> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
> > > > >> t-a-version-in-it/
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Continuous Delivery with Maven now possible?

Dan Tran
for trace-ability,  i add this to top level pom

     <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>buildnumber-maven-plugin</artifactId>
        <executions>
          <execution>
            <id>this-has-scm-info-for-tagging-and-tracability-purpose</id>
            <phase>prepare-package</phase>
            <goals>
              <goal>create-metadata</goal>
            </goals>
            <inherited>false</inherited> <!-- only one is needed -->
            <configuration>
              <timestampPropertyName>date</timestampPropertyName>
              <timestampFormat>YYYY.MM.dd</timestampFormat>
              <attach>true</attach>
              <properties>
                <scm>${project.scm.developerConnection}</scm>
              </properties>
            </configuration>
          </execution>
        </executions>
      </plugin>

On Thu, May 4, 2017 at 10:53 AM, Eric Benzacar <[hidden email]> wrote:

> I've read through Karl's blog (http://blog.soebes.de/blog/
> 2017/04/02/maven-pom-files-without-a-version-in-it/), and while I
> understand the approach, there is still one critical issue that bothers
> me.  I think this actually reopens an old thread that circulated on this
> list a few months ago, but it related to the Idempotence of a pom file.
>
> From my perspective/view a pom file should be idempotent.  That is every
> single build of a given NON-SNAPSHOT pom file should finish with the same
> build.  But by moving a release number or version number outside of the
> pom, it eliminates this need.  Furthermore, from a traceability
> perspective, my source control can no longer show me precisely version was
> being built/developed at any given time.
>
> By leveraging the mvn.config file, I'm a little further down the path, but
> none the less, the value can be overridden at build time with a completely
> different value.  Consequently, I can still not be 100% confident that a
> pom delivered a particular version.
>
> I'm still not 100% sure of the best approach going forward, but I'm
> thinking that something like the version-plugin being able to manipulate a
> revision property that can then be committed as part of the pom would be
> the best of both approaches.  In that way, my developers can fix the
> version number, but my build system can manipulate the revision property.
>
> Does anyone know if there is a plugin that will allow for that?
>
> Thanks,
>
> Eric
>
>
> On Thu, May 4, 2017 at 12:40 PM, Thomas Broyer <[hidden email]> wrote:
>
> > How about everybody read their mail?
> > (see below)
> >
> > On Thu, May 4, 2017 at 6:10 PM Curtis Rueden <[hidden email]> wrote:
> >
> > > Hi Dan, Karl & everyone,
> > >
> > > > See Karl's Blog
> > >
> > > Link, please?
> > >
> > […]
> >
> > > > > > On 03/05/17 20:39, Dan Tran wrote:
> > > > > >
> > > > > >> Hi
> > > > > >>
> > > > > >> I have been experimenting with suggestion from Karl [1] with
> small
> > > > multi
> > > > > >> module maven project.
> >
> > […]
> >
> > > > > >> [1]
> > > > > >> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
> > > > > >> t-a-version-in-it/
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Continuous Delivery with Maven now possible?

Robert Patrick
In reply to this post by Eric Benzacar
The problem is that I really want to control the version number for a project from a single place.  Ideally, this would be the <version> element of the project's top-level POM.  The problem is that there is no way to do this because the module POMs have to declare a parent element that can be resolved to find the parent (before they actually find their parent).  Prior to 3.5, you were forced down the rabbit hole with using hard-coded parent version numbers in the module POM and the release plugin was/is the simplest way (that I have found) of handling version number changes across a large project.

With 3.5, you can now use a variable *but* that variable has to be accessible to the POM prior to finding its parent so the only solution is to move the version number outside the POM hierarchy and into a -D defined variable.  While this works, it seems to have some undesirable aspects to it.  In my opinion, it would be better if Maven could find a way to resolve this issue without resorting to -Ds to specify the value of the variable.  I am not sure it is possible but I also worry about moving the version number outside the POM...

Maybe Maven should consider a mechanism by which the project version number can be defined in a separate location that is:

1.) Well-known so that all resolution can happen directly by interacting with this location directly, without the need to traverse the parent hierarchy
2.) It is part of the project structure so that it can be managed in the project's source control system
3.) It cannot be overridden at build time with command-line arguments.
4.) Has a mechanism by which to reference it from all the necessary locations within the POMs

Maybe something like an optional .mvn/project.version file and a variable that cannot be overridden to refer to it?

-----Original Message-----
From: Eric Benzacar [mailto:[hidden email]]
Sent: Thursday, May 04, 2017 12:53 PM
To: Maven Users List
Subject: Re: Continuous Delivery with Maven now possible?

I've read through Karl's blog (https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.soebes.de_blog_&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&m=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4AYSpzB_W99oBqY&s=YS5dQgFEyKUuZzQgF6kuQUcPO2kUvZ3-9aUHcY3Kmmk&e=
2017/04/02/maven-pom-files-without-a-version-in-it/), and while I understand the approach, there is still one critical issue that bothers me.  I think this actually reopens an old thread that circulated on this list a few months ago, but it related to the Idempotence of a pom file.

From my perspective/view a pom file should be idempotent.  That is every single build of a given NON-SNAPSHOT pom file should finish with the same build.  But by moving a release number or version number outside of the pom, it eliminates this need.  Furthermore, from a traceability perspective, my source control can no longer show me precisely version was being built/developed at any given time.

By leveraging the mvn.config file, I'm a little further down the path, but none the less, the value can be overridden at build time with a completely different value.  Consequently, I can still not be 100% confident that a pom delivered a particular version.

I'm still not 100% sure of the best approach going forward, but I'm thinking that something like the version-plugin being able to manipulate a revision property that can then be committed as part of the pom would be the best of both approaches.  In that way, my developers can fix the version number, but my build system can manipulate the revision property.

Does anyone know if there is a plugin that will allow for that?

Thanks,

Eric


On Thu, May 4, 2017 at 12:40 PM, Thomas Broyer <[hidden email]> wrote:

> How about everybody read their mail?
> (see below)
>
> On Thu, May 4, 2017 at 6:10 PM Curtis Rueden <[hidden email]> wrote:
>
> > Hi Dan, Karl & everyone,
> >
> > > See Karl's Blog
> >
> > Link, please?
> >
> […]
>
> > > > > On 03/05/17 20:39, Dan Tran wrote:
> > > > >
> > > > >> Hi
> > > > >>
> > > > >> I have been experimenting with suggestion from Karl [1] with
> > > > >> small
> > > multi
> > > > >> module maven project.
>
> […]
>
> > > > >> [1]
> > > > >> https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.soeb
> > > > >> es.de_blog_2017_04_02_maven-2Dpom-2Dfiles-2Dwithou&d=DwIFaQ&c
> > > > >> =RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0i
> > > > >> ErugdCnFgO-CBGr_pt_OzwdxJosG0&m=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4
> > > > >> AYSpzB_W99oBqY&s=RYXyGU3piqrAe7XDXXTuPvbcQH935sduSNhMeYstT8Y&
> > > > >> e=
> > > > >> t-a-version-in-it/
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Continuous Delivery with Maven now possible?

Karl Heinz Marbaise-3
In reply to this post by Eric Benzacar
Hi,

On 04/05/17 19:53, Eric Benzacar wrote:

> I've read through Karl's blog (http://blog.soebes.de/blog/
> 2017/04/02/maven-pom-files-without-a-version-in-it/), and while I
> understand the approach, there is still one critical issue that bothers
> me.  I think this actually reopens an old thread that circulated on this
> list a few months ago, but it related to the Idempotence of a pom file.
>
>>From my perspective/view a pom file should be idempotent.  That is every
> single build of a given NON-SNAPSHOT pom file should finish with the same
> build.  But by moving a release number or version number outside of the
> pom, it eliminates this need.  Furthermore, from a traceability
> perspective, my source control can no longer show me precisely version was
> being built/developed at any given time.
>
> By leveraging the mvn.config file, I'm a little further down the path, but
> none the less, the value can be overridden at build time with a completely
> different value.  Consequently, I can still not be 100% confident that a
> pom delivered a particular version.
>
> I'm still not 100% sure of the best approach going forward, but I'm
> thinking that something like the version-plugin being able to manipulate a
> revision property that can then be committed as part of the pom would be
> the best of both approaches.  In that way, my developers can fix the
> version number, but my build system can manipulate the revision property.
>
> Does anyone know if there is a plugin that will allow for that?

Ok let me going into your concerns here.

First we are talking about a NON-SNAPSHOT Build or in other words a
release build.

If you are using this you should be aware of some parts:

First if you make a release your release process must create a tag in
your version control with this state of your source code. Furthermore
you should bake informations like the revision number or sha1 of your
version control system into your resulting artifacts (configuration of
maven-jar, maven-war etc.) and a branch name is also helpful which I
always encourage independent of the usage of this here. This makes
traceability more easier...

The problem with this approach is that if you simply set the version
number via properties to a release version and do a simple `mvn deploy`
which in result produces a release version in my repository.

If I have baked in the above information you can track back from the
resulting artifact to the state in your version control....which from
point of view is the real needed part...

This will lack the tag which has been created in the previously
described release setup.

So based on some Continuous Delivery setups in theses days the created
tag is not that essential. It is only essential to create a new artifact
very fast without some run of versions-plugin or bash/script vodoo to
only change the version number in all pom files and produce one, two or
three (release plugin) checkins which only contain information about the
changed versions in pom file nothing more interesting...So if you are
working with branches the version numbers in pom files are always a pain
cause they produce always conflicts....

Furthermore based on the above described scenario the question comes
into my mind: Is the version control the righ tool/location to answer
this question? In the meantime I tend to say no. The artifact repository
(Nexus for example) is the better tool/location to answer this
question...but this a very controversy thing...


So going to the next point:

 > Consequently, I can still not be 100% confident that a
 > pom delivered a particular version.

If you make the release setup as I describe you can...The point is you
need to trust your own setups or implementations for such release
scenario...

Furthermore if you think about this statement in consequence this means
you are not allowed to use any version ranges in none of your pom files
cause this will result in more complicated problems than only not
knowing the version number from your version control...

And finally a thing which is important to know:

The separation between the "build pom" and the "consumer pom" which is
implicitly done by this. This means the "build pom" is checked into
version control but not the resulting "consumer pom" which is only
intended for consumers of your artifacts and only being available in the
destination artifact repository which has been built by a technical
process. This is the same as we compile a Java class cause we only have
as a result the compiled class file in our jar file but not the source
files...


You have the pom which contains the properties with the versions parts
like revision,changelist and sha1 and the resulting pom file which is
installed into the repository (see also flatten-maven-plugin)...or just
define the property(ies) via command line...

This is one of the first very small step into the direction to separate
this explicitly cause If the Maven project will go further this is a
necessary step and to make other changes possible (Changing the pom
model etc.) but this is complete different discussions.

What you mentioned about have the versions-maven-plugin is correct and
it needed to be improved to let the plugin only change the properties
like revision,changelist,sha1 to be changed is something which I already
thougt about which would mean only to change a single pom file (usually
the project parent in a multi module build).....

After thinking about the "Idempotence" part I came to the conclusion
that this is given, cause the process of building the pom file will
result in the same artifact. The only difference I can see is that I
might name it differently which means I just put a different "label"
(Version) on it (or better we interpret that part of the filename as a
version)...


Kind regards
Karl Heinz Marbaise


>
> Thanks,
>
> Eric
>
>
> On Thu, May 4, 2017 at 12:40 PM, Thomas Broyer <[hidden email]> wrote:
>
>> How about everybody read their mail?
>> (see below)
>>
>> On Thu, May 4, 2017 at 6:10 PM Curtis Rueden <[hidden email]> wrote:
>>
>>> Hi Dan, Karl & everyone,
>>>
>>>> See Karl's Blog
>>>
>>> Link, please?
>>>
>> […]
>>
>>>>>> On 03/05/17 20:39, Dan Tran wrote:
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> I have been experimenting with suggestion from Karl [1] with small
>>>> multi
>>>>>>> module maven project.
>>
>> […]
>>
>>>>>>> [1]
>>>>>>> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
>>>>>>> t-a-version-in-it/
>>>
>>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Continuous Delivery with Maven now possible?

Karl Heinz Marbaise-3
In reply to this post by Robert Patrick
Hi Robert,


On 04/05/17 21:55, Robert Patrick wrote:

> With 3.5, you can now use a variable *but* that variable
 > has to be accessible to the POM prior to finding its
 > parent so the only solution is to move the
 >  version number outside the POM hierarchy and into a -D defined
> variable.

Which is not true. You can define the property inside the pom file if
you like and can overwrite the version via command line (-Drevision=...).



 > While this works, it seems to have some undesirable
 > aspects to it.  In my opinion, it would be better if
 > Maven could find a way to resolve this issue
 > without resorting to -Ds to specify the
 > value of the variable.
 > I am not sure it is possible but I also worry
 > about moving the version number outside the POM...

>
> Maybe Maven should consider a mechanism by which the project version number can be defined in a separate location that is:
>
> 1.) Well-known so that all resolution can happen directly by interacting with this location directly, without the need to traverse the parent hierarchy
> 2.) It is part of the project structure so that it can be managed in the project's source control system
> 3.) It cannot be overridden at build time with command-line arguments.
> 4.) Has a mechanism by which to reference it from all the necessary locations within the POMs
>
> Maybe something like an optional .mvn/project.version file and a variable that cannot be overridden to refer to it?
>
> -----Original Message-----
> From: Eric Benzacar [mailto:[hidden email]]
> Sent: Thursday, May 04, 2017 12:53 PM
> To: Maven Users List
> Subject: Re: Continuous Delivery with Maven now possible?
>
> I've read through Karl's blog (https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.soebes.de_blog_&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&m=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4AYSpzB_W99oBqY&s=YS5dQgFEyKUuZzQgF6kuQUcPO2kUvZ3-9aUHcY3Kmmk&e=
> 2017/04/02/maven-pom-files-without-a-version-in-it/), and while I understand the approach, there is still one critical issue that bothers me.  I think this actually reopens an old thread that circulated on this list a few months ago, but it related to the Idempotence of a pom file.
>
>>From my perspective/view a pom file should be idempotent.  That is every single build of a given NON-SNAPSHOT pom file should finish with the same build.  But by moving a release number or version number outside of the pom, it eliminates this need.  Furthermore, from a traceability perspective, my source control can no longer show me precisely version was being built/developed at any given time.
>
> By leveraging the mvn.config file, I'm a little further down the path, but none the less, the value can be overridden at build time with a completely different value.  Consequently, I can still not be 100% confident that a pom delivered a particular version.
>
> I'm still not 100% sure of the best approach going forward, but I'm thinking that something like the version-plugin being able to manipulate a revision property that can then be committed as part of the pom would be the best of both approaches.  In that way, my developers can fix the version number, but my build system can manipulate the revision property.
>
> Does anyone know if there is a plugin that will allow for that?
>
> Thanks,
>
> Eric
>
>
> On Thu, May 4, 2017 at 12:40 PM, Thomas Broyer <[hidden email]> wrote:
>
>> How about everybody read their mail?
>> (see below)
>>
>> On Thu, May 4, 2017 at 6:10 PM Curtis Rueden <[hidden email]> wrote:
>>
>>> Hi Dan, Karl & everyone,
>>>
>>>> See Karl's Blog
>>>
>>> Link, please?
>>>
>> […]
>>
>>>>>> On 03/05/17 20:39, Dan Tran wrote:
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> I have been experimenting with suggestion from Karl [1] with
>>>>>>> small
>>>> multi
>>>>>>> module maven project.
>>
>> […]
>>
>>>>>>> [1]
>>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.soeb
>>>>>>> es.de_blog_2017_04_02_maven-2Dpom-2Dfiles-2Dwithou&d=DwIFaQ&c
>>>>>>> =RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0i
>>>>>>> ErugdCnFgO-CBGr_pt_OzwdxJosG0&m=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4
>>>>>>> AYSpzB_W99oBqY&s=RYXyGU3piqrAe7XDXXTuPvbcQH935sduSNhMeYstT8Y&
>>>>>>> e=
>>>>>>> t-a-version-in-it/
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


Mit freundlichem Gruß
Karl-Heinz Marbaise
--
SoftwareEntwicklung Beratung Schulung    Tel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl-Heinz Marbaise        USt.IdNr: DE191347579
Hauptstrasse 177
52146 Würselen                           http://www.soebes.de

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Continuous Delivery with Maven now possible?

Karl Heinz Marbaise-3
Sorry was to fast with the send button...


On 04/05/17 22:01, Karl Heinz Marbaise wrote:

> Hi Robert,
>
>
> On 04/05/17 21:55, Robert Patrick wrote:
>
>> With 3.5, you can now use a variable *but* that variable
>> has to be accessible to the POM prior to finding its
>> parent so the only solution is to move the
>>  version number outside the POM hierarchy and into a -D defined
>> variable.
>

Which is not true. You can define the property inside the pom file if
you like and can overwrite the version via command line (-Drevision=...).


>
>
>
>> While this works, it seems to have some undesirable
>> aspects to it.  In my opinion, it would be better if
>> Maven could find a way to resolve this issue
>> without resorting to -Ds to specify the
>> value of the variable.
>> I am not sure it is possible but I also worry
>> about moving the version number outside the POM...

>>
>> Maybe Maven should consider a mechanism by which the project version
>> number can be defined in a separate location that is:
>>
>> 1.) Well-known so that all resolution can happen directly by
>> interacting with this location directly, without the need to traverse
>> the parent hierarchy

Can you explain what exactly you mean by this?

>> 2.) It is part of the project structure so that it can be managed in
>> the project's source control system

You can simply use the .mvn/maven.config file for it...


>> 3.) It cannot be overridden at build time with command-line arguments.

Which contradicts the whole idea of making it simple to change the
version...


>> 4.) Has a mechanism by which to reference it from all the necessary
>> locations within the POMs
>>
>> Maybe something like an optional .mvn/project.version file and a
>> variable that cannot be overridden to refer to it?

What is the advantage of having a complete different file here? The
change on the other hand shouldn't be that hard ...


Kind regards
Karl Heinz Marbaise

>>
>> -----Original Message-----
>> From: Eric Benzacar [mailto:[hidden email]]
>> Sent: Thursday, May 04, 2017 12:53 PM
>> To: Maven Users List
>> Subject: Re: Continuous Delivery with Maven now possible?
>>
>> I've read through Karl's blog
>> (https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.soebes.de_blog_&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&m=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4AYSpzB_W99oBqY&s=YS5dQgFEyKUuZzQgF6kuQUcPO2kUvZ3-9aUHcY3Kmmk&e=
>>
>> 2017/04/02/maven-pom-files-without-a-version-in-it/), and while I
>> understand the approach, there is still one critical issue that
>> bothers me.  I think this actually reopens an old thread that
>> circulated on this list a few months ago, but it related to the
>> Idempotence of a pom file.
>>
>>> From my perspective/view a pom file should be idempotent.  That is
>>> every single build of a given NON-SNAPSHOT pom file should finish
>>> with the same build.  But by moving a release number or version
>>> number outside of the pom, it eliminates this need.  Furthermore,
>>> from a traceability perspective, my source control can no longer show
>>> me precisely version was being built/developed at any given time.
>>
>> By leveraging the mvn.config file, I'm a little further down the path,
>> but none the less, the value can be overridden at build time with a
>> completely different value.  Consequently, I can still not be 100%
>> confident that a pom delivered a particular version.
>>
>> I'm still not 100% sure of the best approach going forward, but I'm
>> thinking that something like the version-plugin being able to
>> manipulate a revision property that can then be committed as part of
>> the pom would be the best of both approaches.  In that way, my
>> developers can fix the version number, but my build system can
>> manipulate the revision property.
>>
>> Does anyone know if there is a plugin that will allow for that?
>>
>> Thanks,
>>
>> Eric
>>
>>
>> On Thu, May 4, 2017 at 12:40 PM, Thomas Broyer <[hidden email]>
>> wrote:
>>
>>> How about everybody read their mail?
>>> (see below)
>>>
>>> On Thu, May 4, 2017 at 6:10 PM Curtis Rueden <[hidden email]> wrote:
>>>
>>>> Hi Dan, Karl & everyone,
>>>>
>>>>> See Karl's Blog
>>>>
>>>> Link, please?
>>>>
>>> […]
>>>
>>>>>>> On 03/05/17 20:39, Dan Tran wrote:
>>>>>>>
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> I have been experimenting with suggestion from Karl [1] with
>>>>>>>> small
>>>>> multi
>>>>>>>> module maven project.
>>>
>>> […]
>>>
>>>>>>>> [1]
>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.soeb
>>>>>>>> es.de_blog_2017_04_02_maven-2Dpom-2Dfiles-2Dwithou&d=DwIFaQ&c
>>>>>>>> =RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0i
>>>>>>>> ErugdCnFgO-CBGr_pt_OzwdxJosG0&m=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4
>>>>>>>> AYSpzB_W99oBqY&s=RYXyGU3piqrAe7XDXXTuPvbcQH935sduSNhMeYstT8Y&
>>>>>>>> e=
>>>>>>>> t-a-version-in-it/
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> Mit freundlichem Gruß
> Karl-Heinz Marbaise


Mit freundlichem Gruß
Karl-Heinz Marbaise
--
SoftwareEntwicklung Beratung Schulung    Tel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl-Heinz Marbaise        USt.IdNr: DE191347579
Hauptstrasse 177
52146 Würselen                           http://www.soebes.de

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Continuous Delivery with Maven now possible?

Robert Patrick
In reply to this post by Karl Heinz Marbaise-3
Hi Karl,

If I define the revision property in the top-level POM, I cannot refer to it in the module POMs' <parent> elements *and* still retain the ability to build from the module directory, right?  I tried this and it failed because it was unable to resolve the revision property variable.

C:\rpatrick\work\projects\jcs-las\util>mvn clean install
[INFO] Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[FATAL] Non-resolvable parent POM for oracle.jcs.lifecycle:util:[unknown-version
]: Failure to find oracle.jcs.lifecycle:app-to-cloud:pom:${revision} in http://a
rtifactory-slc.oraclecorp.com/artifactory/repo1 was cached in the local reposito
ry, resolution will not be reattempted until the update interval of repo1 has el
apsed or updates are forced and 'parent.relativePath' points at wrong local POM
@ line 7, column 13
 @
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]
[ERROR]   The project oracle.jcs.lifecycle:util:[unknown-version] (C:\rpatrick\w
ork\projects\jcs-las\util\pom.xml) has 1 error
[ERROR]     Non-resolvable parent POM for oracle.jcs.lifecycle:util:[unknown-ver
sion]: Failure to find oracle.jcs.lifecycle:app-to-cloud:pom:${revision} in http
://artifactory-slc.oraclecorp.com/artifactory/repo1 was cached in the local repo
sitory, resolution will not be reattempted until the update interval of repo1 ha
s elapsed or updates are forced and 'parent.relativePath' points at wrong local
POM @ line 7, column 13 -> [Help 2]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e swit
ch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please rea
d the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildin
gException
[ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableMo
delException


Did I miss something?

Thanks,
Robert

-----Original Message-----
From: Karl Heinz Marbaise [mailto:[hidden email]]
Sent: Thursday, May 04, 2017 3:02 PM
To: Maven Users List
Subject: Re: Continuous Delivery with Maven now possible?

Hi Robert,


On 04/05/17 21:55, Robert Patrick wrote:

> With 3.5, you can now use a variable *but* that variable
 > has to be accessible to the POM prior to finding its  > parent so the only solution is to move the  >  version number outside the POM hierarchy and into a -D defined
> variable.

Which is not true. You can define the property inside the pom file if you like and can overwrite the version via command line (-Drevision=...).



 > While this works, it seems to have some undesirable
 > aspects to it.  In my opinion, it would be better if
 > Maven could find a way to resolve this issue
 > without resorting to -Ds to specify the
 > value of the variable.
 > I am not sure it is possible but I also worry
 > about moving the version number outside the POM...

>
> Maybe Maven should consider a mechanism by which the project version number can be defined in a separate location that is:
>
> 1.) Well-known so that all resolution can happen directly by interacting with this location directly, without the need to traverse the parent hierarchy
> 2.) It is part of the project structure so that it can be managed in the project's source control system
> 3.) It cannot be overridden at build time with command-line arguments.
> 4.) Has a mechanism by which to reference it from all the necessary locations within the POMs
>
> Maybe something like an optional .mvn/project.version file and a variable that cannot be overridden to refer to it?
>
> -----Original Message-----
> From: Eric Benzacar [mailto:[hidden email]]
> Sent: Thursday, May 04, 2017 12:53 PM
> To: Maven Users List
> Subject: Re: Continuous Delivery with Maven now possible?
>
> I've read through Karl's blog (https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.soebes.de_blog_&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&m=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4AYSpzB_W99oBqY&s=YS5dQgFEyKUuZzQgF6kuQUcPO2kUvZ3-9aUHcY3Kmmk&e=
> 2017/04/02/maven-pom-files-without-a-version-in-it/), and while I understand the approach, there is still one critical issue that bothers me.  I think this actually reopens an old thread that circulated on this list a few months ago, but it related to the Idempotence of a pom file.
>
>>From my perspective/view a pom file should be idempotent.  That is every single build of a given NON-SNAPSHOT pom file should finish with the same build.  But by moving a release number or version number outside of the pom, it eliminates this need.  Furthermore, from a traceability perspective, my source control can no longer show me precisely version was being built/developed at any given time.
>
> By leveraging the mvn.config file, I'm a little further down the path, but none the less, the value can be overridden at build time with a completely different value.  Consequently, I can still not be 100% confident that a pom delivered a particular version.
>
> I'm still not 100% sure of the best approach going forward, but I'm thinking that something like the version-plugin being able to manipulate a revision property that can then be committed as part of the pom would be the best of both approaches.  In that way, my developers can fix the version number, but my build system can manipulate the revision property.
>
> Does anyone know if there is a plugin that will allow for that?
>
> Thanks,
>
> Eric
>
>
> On Thu, May 4, 2017 at 12:40 PM, Thomas Broyer <[hidden email]> wrote:
>
>> How about everybody read their mail?
>> (see below)
>>
>> On Thu, May 4, 2017 at 6:10 PM Curtis Rueden <[hidden email]> wrote:
>>
>>> Hi Dan, Karl & everyone,
>>>
>>>> See Karl's Blog
>>>
>>> Link, please?
>>>
>> […]
>>
>>>>>> On 03/05/17 20:39, Dan Tran wrote:
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> I have been experimenting with suggestion from Karl [1] with
>>>>>>> small
>>>> multi
>>>>>>> module maven project.
>>
>> […]
>>
>>>>>>> [1]
>>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.soeb
>>>>>>> es.de_blog_2017_04_02_maven-2Dpom-2Dfiles-2Dwithou&d=DwIFaQ&c
>>>>>>> =RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0i
>>>>>>> ErugdCnFgO-CBGr_pt_OzwdxJosG0&m=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4
>>>>>>> AYSpzB_W99oBqY&s=RYXyGU3piqrAe7XDXXTuPvbcQH935sduSNhMeYstT8Y&
>>>>>>> e=
>>>>>>> t-a-version-in-it/
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


Mit freundlichem Gruß
Karl-Heinz Marbaise
--
SoftwareEntwicklung Beratung Schulung    Tel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl-Heinz Marbaise        USt.IdNr: DE191347579
Hauptstrasse 177
52146 Würselen                           https://urldefense.proofpoint.com/v2/url?u=http-3A__www.soebes.de&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&m=6IAGr4po5BkkfLJYpRCfgqH7OaIePamBF7JGB_W6tbA&s=__Zgpn0s6SLFxUKXhxbaCjPfgjdqUt1eH6CdS582ACI&e= 

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Continuous Delivery with Maven now possible?

Karl Heinz Marbaise-3
Hi Robert,

Ah now I see the issue.

If you have a multi module build you should use

mvn -pl moduleToBuild clean install

but from root location and don't change into the module directory cause
this can't work like this.

Kind regards
Karl Heinz Marbaise

On 04/05/17 22:08, Robert Patrick wrote:

> Hi Karl,
>
> If I define the revision property in the top-level POM, I cannot refer to it in the module POMs' <parent> elements *and* still retain the ability to build from the module directory, right?  I tried this and it failed because it was unable to resolve the revision property variable.
>
> C:\rpatrick\work\projects\jcs-las\util>mvn clean install
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [FATAL] Non-resolvable parent POM for oracle.jcs.lifecycle:util:[unknown-version
> ]: Failure to find oracle.jcs.lifecycle:app-to-cloud:pom:${revision} in http://a
> rtifactory-slc.oraclecorp.com/artifactory/repo1 was cached in the local reposito
> ry, resolution will not be reattempted until the update interval of repo1 has el
> apsed or updates are forced and 'parent.relativePath' points at wrong local POM
> @ line 7, column 13
>  @
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR]   The project oracle.jcs.lifecycle:util:[unknown-version] (C:\rpatrick\w
> ork\projects\jcs-las\util\pom.xml) has 1 error
> [ERROR]     Non-resolvable parent POM for oracle.jcs.lifecycle:util:[unknown-ver
> sion]: Failure to find oracle.jcs.lifecycle:app-to-cloud:pom:${revision} in http
> ://artifactory-slc.oraclecorp.com/artifactory/repo1 was cached in the local repo
> sitory, resolution will not be reattempted until the update interval of repo1 ha
> s elapsed or updates are forced and 'parent.relativePath' points at wrong local
> POM @ line 7, column 13 -> [Help 2]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e swit
> ch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please rea
> d the following articles:
> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildin
> gException
> [ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableMo
> delException
>
>
> Did I miss something?
>
> Thanks,
> Robert
>
> -----Original Message-----
> From: Karl Heinz Marbaise [mailto:[hidden email]]
> Sent: Thursday, May 04, 2017 3:02 PM
> To: Maven Users List
> Subject: Re: Continuous Delivery with Maven now possible?
>
> Hi Robert,
>
>
> On 04/05/17 21:55, Robert Patrick wrote:
>
>> With 3.5, you can now use a variable *but* that variable
>  > has to be accessible to the POM prior to finding its  > parent so the only solution is to move the  >  version number outside the POM hierarchy and into a -D defined
>> variable.
>
> Which is not true. You can define the property inside the pom file if you like and can overwrite the version via command line (-Drevision=...).
>
>
>
>  > While this works, it seems to have some undesirable
>  > aspects to it.  In my opinion, it would be better if
>  > Maven could find a way to resolve this issue
>  > without resorting to -Ds to specify the
>  > value of the variable.
>  > I am not sure it is possible but I also worry
>  > about moving the version number outside the POM...
>>
>> Maybe Maven should consider a mechanism by which the project version number can be defined in a separate location that is:
>>
>> 1.) Well-known so that all resolution can happen directly by interacting with this location directly, without the need to traverse the parent hierarchy
>> 2.) It is part of the project structure so that it can be managed in the project's source control system
>> 3.) It cannot be overridden at build time with command-line arguments.
>> 4.) Has a mechanism by which to reference it from all the necessary locations within the POMs
>>
>> Maybe something like an optional .mvn/project.version file and a variable that cannot be overridden to refer to it?
>>
>> -----Original Message-----
>> From: Eric Benzacar [mailto:[hidden email]]
>> Sent: Thursday, May 04, 2017 12:53 PM
>> To: Maven Users List
>> Subject: Re: Continuous Delivery with Maven now possible?
>>
>> I've read through Karl's blog (https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.soebes.de_blog_&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&m=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4AYSpzB_W99oBqY&s=YS5dQgFEyKUuZzQgF6kuQUcPO2kUvZ3-9aUHcY3Kmmk&e=
>> 2017/04/02/maven-pom-files-without-a-version-in-it/), and while I understand the approach, there is still one critical issue that bothers me.  I think this actually reopens an old thread that circulated on this list a few months ago, but it related to the Idempotence of a pom file.
>>
>> >From my perspective/view a pom file should be idempotent.  That is every single build of a given NON-SNAPSHOT pom file should finish with the same build.  But by moving a release number or version number outside of the pom, it eliminates this need.  Furthermore, from a traceability perspective, my source control can no longer show me precisely version was being built/developed at any given time.
>>
>> By leveraging the mvn.config file, I'm a little further down the path, but none the less, the value can be overridden at build time with a completely different value.  Consequently, I can still not be 100% confident that a pom delivered a particular version.
>>
>> I'm still not 100% sure of the best approach going forward, but I'm thinking that something like the version-plugin being able to manipulate a revision property that can then be committed as part of the pom would be the best of both approaches.  In that way, my developers can fix the version number, but my build system can manipulate the revision property.
>>
>> Does anyone know if there is a plugin that will allow for that?
>>
>> Thanks,
>>
>> Eric
>>
>>
>> On Thu, May 4, 2017 at 12:40 PM, Thomas Broyer <[hidden email]> wrote:
>>
>>> How about everybody read their mail?
>>> (see below)
>>>
>>> On Thu, May 4, 2017 at 6:10 PM Curtis Rueden <[hidden email]> wrote:
>>>
>>>> Hi Dan, Karl & everyone,
>>>>
>>>>> See Karl's Blog
>>>>
>>>> Link, please?
>>>>
>>> […]
>>>
>>>>>>> On 03/05/17 20:39, Dan Tran wrote:
>>>>>>>
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> I have been experimenting with suggestion from Karl [1] with
>>>>>>>> small
>>>>> multi
>>>>>>>> module maven project.
>>>
>>> […]
>>>
>>>>>>>> [1]
>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.soeb
>>>>>>>> es.de_blog_2017_04_02_maven-2Dpom-2Dfiles-2Dwithou&d=DwIFaQ&c
>>>>>>>> =RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0i
>>>>>>>> ErugdCnFgO-CBGr_pt_OzwdxJosG0&m=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4
>>>>>>>> AYSpzB_W99oBqY&s=RYXyGU3piqrAe7XDXXTuPvbcQH935sduSNhMeYstT8Y&
>>>>>>>> e=
>>>>>>>> t-a-version-in-it/
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> Mit freundlichem Gruß
> Karl-Heinz Marbaise
>


Mit freundlichem Gruß
Karl-Heinz Marbaise
--
SoftwareEntwicklung Beratung Schulung    Tel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl-Heinz Marbaise        USt.IdNr: DE191347579
Hauptstrasse 177
52146 Würselen                           http://www.soebes.de

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Continuous Delivery with Maven now possible?

Robert Patrick
Hard to train developers to break old habits but thanks... :-)



-----Original Message-----
From: Karl Heinz Marbaise [mailto:[hidden email]]
Sent: Thursday, May 04, 2017 3:16 PM
To: Robert Patrick; Maven Users List; [hidden email]
Subject: Re: Continuous Delivery with Maven now possible?

Hi Robert,

Ah now I see the issue.

If you have a multi module build you should use

mvn -pl moduleToBuild clean install

but from root location and don't change into the module directory cause this can't work like this.

Kind regards
Karl Heinz Marbaise

On 04/05/17 22:08, Robert Patrick wrote:

> Hi Karl,
>
> If I define the revision property in the top-level POM, I cannot refer to it in the module POMs' <parent> elements *and* still retain the ability to build from the module directory, right?  I tried this and it failed because it was unable to resolve the revision property variable.
>
> C:\rpatrick\work\projects\jcs-las\util>mvn clean install [INFO]
> Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [FATAL] Non-resolvable parent POM for
> oracle.jcs.lifecycle:util:[unknown-version
> ]: Failure to find oracle.jcs.lifecycle:app-to-cloud:pom:${revision}
> in
> https://urldefense.proofpoint.com/v2/url?u=http-3A__a&d=DwIDaQ&c=RoP1Y
> umCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr
> _pt_OzwdxJosG0&m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY&s=by9ucii
> pxSZU0-Wn16t7grG7a5Djk4ZH9440pGIayRE&e=
> rtifactory-slc.oraclecorp.com/artifactory/repo1 was cached in the
> local reposito ry, resolution will not be reattempted until the update
> interval of repo1 has el apsed or updates are forced and
> 'parent.relativePath' points at wrong local POM @ line 7, column 13  @
> [ERROR] The build could not read 1 project -> [Help 1] [ERROR]
> [ERROR]   The project oracle.jcs.lifecycle:util:[unknown-version] (C:\rpatrick\w
> ork\projects\jcs-las\util\pom.xml) has 1 error
> [ERROR]     Non-resolvable parent POM for oracle.jcs.lifecycle:util:[unknown-ver
> sion]: Failure to find
> oracle.jcs.lifecycle:app-to-cloud:pom:${revision} in http
> ://artifactory-slc.oraclecorp.com/artifactory/repo1 was cached in the
> local repo sitory, resolution will not be reattempted until the update
> interval of repo1 ha s elapsed or updates are forced and
> 'parent.relativePath' points at wrong local POM @ line 7, column 13 ->
> [Help 2] [ERROR] [ERROR] To see the full stack trace of the errors,
> re-run Maven with the -e swit ch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions,
> please rea d the following articles:
> [ERROR] [Help 1]
> https://urldefense.proofpoint.com/v2/url?u=http-3A__cwiki.apache.org_c
> onfluence_display_MAVEN_ProjectBuildin&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8
> PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&
> m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY&s=Gpqh8tXn87EJPGvORYVRoH
> s2ncTiyaZSJWc3AEyEsUQ&e=
> gException
> [ERROR] [Help 2]
> https://urldefense.proofpoint.com/v2/url?u=http-3A__cwiki.apache.org_c
> onfluence_display_MAVEN_UnresolvableMo&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8
> PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&
> m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY&s=kjqcy_wD0H5qwfISMGTZrq
> XoHWM-jV5GAbTtEvug-bc&e=
> delException
>
>
> Did I miss something?
>
> Thanks,
> Robert
>
> -----Original Message-----
> From: Karl Heinz Marbaise [mailto:[hidden email]]
> Sent: Thursday, May 04, 2017 3:02 PM
> To: Maven Users List
> Subject: Re: Continuous Delivery with Maven now possible?
>
> Hi Robert,
>
>
> On 04/05/17 21:55, Robert Patrick wrote:
>
>> With 3.5, you can now use a variable *but* that variable
>  > has to be accessible to the POM prior to finding its  > parent so
> the only solution is to move the  >  version number outside the POM
> hierarchy and into a -D defined
>> variable.
>
> Which is not true. You can define the property inside the pom file if you like and can overwrite the version via command line (-Drevision=...).
>
>
>
>  > While this works, it seems to have some undesirable  > aspects to
> it.  In my opinion, it would be better if  > Maven could find a way to
> resolve this issue  > without resorting to -Ds to specify the  > value
> of the variable.
>  > I am not sure it is possible but I also worry  > about moving the
> version number outside the POM...
>>
>> Maybe Maven should consider a mechanism by which the project version number can be defined in a separate location that is:
>>
>> 1.) Well-known so that all resolution can happen directly by
>> interacting with this location directly, without the need to traverse
>> the parent hierarchy
>> 2.) It is part of the project structure so that it can be managed in
>> the project's source control system
>> 3.) It cannot be overridden at build time with command-line arguments.
>> 4.) Has a mechanism by which to reference it from all the necessary
>> locations within the POMs
>>
>> Maybe something like an optional .mvn/project.version file and a variable that cannot be overridden to refer to it?
>>
>> -----Original Message-----
>> From: Eric Benzacar [mailto:[hidden email]]
>> Sent: Thursday, May 04, 2017 12:53 PM
>> To: Maven Users List
>> Subject: Re: Continuous Delivery with Maven now possible?
>>
>> I've read through Karl's blog
>> (https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.soebes.de_b
>> log_&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmb
>> ofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&m=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4A
>> YSpzB_W99oBqY&s=YS5dQgFEyKUuZzQgF6kuQUcPO2kUvZ3-9aUHcY3Kmmk&e=
>> 2017/04/02/maven-pom-files-without-a-version-in-it/), and while I understand the approach, there is still one critical issue that bothers me.  I think this actually reopens an old thread that circulated on this list a few months ago, but it related to the Idempotence of a pom file.
>>
>> >From my perspective/view a pom file should be idempotent.  That is every single build of a given NON-SNAPSHOT pom file should finish with the same build.  But by moving a release number or version number outside of the pom, it eliminates this need.  Furthermore, from a traceability perspective, my source control can no longer show me precisely version was being built/developed at any given time.
>>
>> By leveraging the mvn.config file, I'm a little further down the path, but none the less, the value can be overridden at build time with a completely different value.  Consequently, I can still not be 100% confident that a pom delivered a particular version.
>>
>> I'm still not 100% sure of the best approach going forward, but I'm thinking that something like the version-plugin being able to manipulate a revision property that can then be committed as part of the pom would be the best of both approaches.  In that way, my developers can fix the version number, but my build system can manipulate the revision property.
>>
>> Does anyone know if there is a plugin that will allow for that?
>>
>> Thanks,
>>
>> Eric
>>
>>
>> On Thu, May 4, 2017 at 12:40 PM, Thomas Broyer <[hidden email]> wrote:
>>
>>> How about everybody read their mail?
>>> (see below)
>>>
>>> On Thu, May 4, 2017 at 6:10 PM Curtis Rueden <[hidden email]> wrote:
>>>
>>>> Hi Dan, Karl & everyone,
>>>>
>>>>> See Karl's Blog
>>>>
>>>> Link, please?
>>>>
>>> […]
>>>
>>>>>>> On 03/05/17 20:39, Dan Tran wrote:
>>>>>>>
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> I have been experimenting with suggestion from Karl [1] with
>>>>>>>> small
>>>>> multi
>>>>>>>> module maven project.
>>>
>>> […]
>>>
>>>>>>>> [1]
>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.soeb
>>>>>>>> es.de_blog_2017_04_02_maven-2Dpom-2Dfiles-2Dwithou&d=DwIFaQ&c
>>>>>>>> =RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0i
>>>>>>>> ErugdCnFgO-CBGr_pt_OzwdxJosG0&m=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4
>>>>>>>> AYSpzB_W99oBqY&s=RYXyGU3piqrAe7XDXXTuPvbcQH935sduSNhMeYstT8Y&
>>>>>>>> e=
>>>>>>>> t-a-version-in-it/
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> Mit freundlichem Gruß
> Karl-Heinz Marbaise
>


Mit freundlichem Gruß
Karl-Heinz Marbaise
--
SoftwareEntwicklung Beratung Schulung    Tel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl-Heinz Marbaise        USt.IdNr: DE191347579
Hauptstrasse 177
52146 Würselen                           https://urldefense.proofpoint.com/v2/url?u=http-3A__www.soebes.de&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY&s=N8LOYbqdJesq5BQ2layMkVj3BdKNeoEFvdpv63MBDGc&e= 

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

Justin Georgeson
Also I believe the partial reactor switches don't work for Tycho builds.

-----Original Message-----
From: Robert Patrick [mailto:[hidden email]]
Sent: Thursday, May 4, 2017 3:18 PM
To: Maven Users List <[hidden email]>; [hidden email]
Subject: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

External Sender: Use caution with links/attachments.



Hard to train developers to break old habits but thanks... :-)



-----Original Message-----
From: Karl Heinz Marbaise [mailto:[hidden email]]
Sent: Thursday, May 04, 2017 3:16 PM
To: Robert Patrick; Maven Users List; [hidden email]
Subject: Re: Continuous Delivery with Maven now possible?

Hi Robert,

Ah now I see the issue.

If you have a multi module build you should use

mvn -pl moduleToBuild clean install

but from root location and don't change into the module directory cause this can't work like this.

Kind regards
Karl Heinz Marbaise

On 04/05/17 22:08, Robert Patrick wrote:

> Hi Karl,
>
> If I define the revision property in the top-level POM, I cannot refer to it in the module POMs' <parent> elements *and* still retain the ability to build from the module directory, right?  I tried this and it failed because it was unable to resolve the revision property variable.
>
> C:\rpatrick\work\projects\jcs-las\util>mvn clean install [INFO]
> Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [FATAL] Non-resolvable parent POM for
> oracle.jcs.lifecycle:util:[unknown-version
> ]: Failure to find oracle.jcs.lifecycle:app-to-cloud:pom:${revision}
> in
> https://urldefense.proofpoint.com/v2/url?u=http-3A__a&d=DwIDaQ&c=RoP1Y
> umCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr
> _pt_OzwdxJosG0&m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY&s=by9ucii
> pxSZU0-Wn16t7grG7a5Djk4ZH9440pGIayRE&e=
> https://urldefense.proofpoint.com/v2/url?u=http-3A__rtifactory-2Dslc.o
> raclecorp.com_artifactory_repo1&d=DwIFaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYB
> RbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m=mQrJO
> CEKXlLF5VNECH6aqvyAu4kATrZgYUsiitvnfwY&s=oPO-3-7EEwzSMAr8-re0YxZdReMu1
> 5_A4OMXDtdtFyA&e=  was cached in the local reposito ry, resolution will not be reattempted until the update interval of repo1 has el apsed or updates are forced and 'parent.relativePath' points at wrong local POM @ line 7, column 13  @ [ERROR] The build could not read 1 project -> [Help 1] [ERROR]
> [ERROR]   The project oracle.jcs.lifecycle:util:[unknown-version] (C:\rpatrick\w
> ork\projects\jcs-las\util\pom.xml) has 1 error
> [ERROR]     Non-resolvable parent POM for oracle.jcs.lifecycle:util:[unknown-ver
> sion]: Failure to find
> oracle.jcs.lifecycle:app-to-cloud:pom:${revision} in http
> ://artifactory-slc.oraclecorp.com/artifactory/repo1 was cached in the
> local repo sitory, resolution will not be reattempted until the update
> interval of repo1 ha s elapsed or updates are forced and
> 'parent.relativePath' points at wrong local POM @ line 7, column 13 ->
> [Help 2] [ERROR] [ERROR] To see the full stack trace of the errors,
> re-run Maven with the -e swit ch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions,
> please rea d the following articles:
> [ERROR] [Help 1]
> https://urldefense.proofpoint.com/v2/url?u=http-3A__cwiki.apache.org_c
> onfluence_display_MAVEN_ProjectBuildin&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8
> PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&
> m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY&s=Gpqh8tXn87EJPGvORYVRoH
> s2ncTiyaZSJWc3AEyEsUQ&e=
> gException
> [ERROR] [Help 2]
> https://urldefense.proofpoint.com/v2/url?u=http-3A__cwiki.apache.org_c
> onfluence_display_MAVEN_UnresolvableMo&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8
> PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&
> m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY&s=kjqcy_wD0H5qwfISMGTZrq
> XoHWM-jV5GAbTtEvug-bc&e=
> delException
>
>
> Did I miss something?
>
> Thanks,
> Robert
>
> -----Original Message-----
> From: Karl Heinz Marbaise [mailto:[hidden email]]
> Sent: Thursday, May 04, 2017 3:02 PM
> To: Maven Users List
> Subject: Re: Continuous Delivery with Maven now possible?
>
> Hi Robert,
>
>
> On 04/05/17 21:55, Robert Patrick wrote:
>
>> With 3.5, you can now use a variable *but* that variable
>  > has to be accessible to the POM prior to finding its  > parent so
> the only solution is to move the  >  version number outside the POM
> hierarchy and into a -D defined
>> variable.
>
> Which is not true. You can define the property inside the pom file if you like and can overwrite the version via command line (-Drevision=...).
>
>
>
>  > While this works, it seems to have some undesirable  > aspects to
> it.  In my opinion, it would be better if  > Maven could find a way to
> resolve this issue  > without resorting to -Ds to specify the  > value
> of the variable.
>  > I am not sure it is possible but I also worry  > about moving the
> version number outside the POM...
>>
>> Maybe Maven should consider a mechanism by which the project version number can be defined in a separate location that is:
>>
>> 1.) Well-known so that all resolution can happen directly by
>> interacting with this location directly, without the need to traverse
>> the parent hierarchy
>> 2.) It is part of the project structure so that it can be managed in
>> the project's source control system
>> 3.) It cannot be overridden at build time with command-line arguments.
>> 4.) Has a mechanism by which to reference it from all the necessary
>> locations within the POMs
>>
>> Maybe something like an optional .mvn/project.version file and a variable that cannot be overridden to refer to it?
>>
>> -----Original Message-----
>> From: Eric Benzacar [mailto:[hidden email]]
>> Sent: Thursday, May 04, 2017 12:53 PM
>> To: Maven Users List
>> Subject: Re: Continuous Delivery with Maven now possible?
>>
>> I've read through Karl's blog
>> (https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.soebes.de_b
>> log_&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmb
>> ofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&m=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4A
>> YSpzB_W99oBqY&s=YS5dQgFEyKUuZzQgF6kuQUcPO2kUvZ3-9aUHcY3Kmmk&e=
>> 2017/04/02/maven-pom-files-without-a-version-in-it/), and while I understand the approach, there is still one critical issue that bothers me.  I think this actually reopens an old thread that circulated on this list a few months ago, but it related to the Idempotence of a pom file.
>>
>> >From my perspective/view a pom file should be idempotent.  That is every single build of a given NON-SNAPSHOT pom file should finish with the same build.  But by moving a release number or version number outside of the pom, it eliminates this need.  Furthermore, from a traceability perspective, my source control can no longer show me precisely version was being built/developed at any given time.
>>
>> By leveraging the mvn.config file, I'm a little further down the path, but none the less, the value can be overridden at build time with a completely different value.  Consequently, I can still not be 100% confident that a pom delivered a particular version.
>>
>> I'm still not 100% sure of the best approach going forward, but I'm thinking that something like the version-plugin being able to manipulate a revision property that can then be committed as part of the pom would be the best of both approaches.  In that way, my developers can fix the version number, but my build system can manipulate the revision property.
>>
>> Does anyone know if there is a plugin that will allow for that?
>>
>> Thanks,
>>
>> Eric
>>
>>
>> On Thu, May 4, 2017 at 12:40 PM, Thomas Broyer <https://urldefense.proofpoint.com/v2/url?u=http-3A__t.broyer-40gmail.com&d=DwIFaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m=mQrJOCEKXlLF5VNECH6aqvyAu4kATrZgYUsiitvnfwY&s=0PY7XDt7qFb0WfiWMn1CIgxZ2Q6apBhIlOqIgfU0A3A&e= > wrote:
>>
>>> How about everybody read their mail?
>>> (see below)
>>>
>>> On Thu, May 4, 2017 at 6:10 PM Curtis Rueden <[hidden email]> wrote:
>>>
>>>> Hi Dan, Karl & everyone,
>>>>
>>>>> See Karl's Blog
>>>>
>>>> Link, please?
>>>>
>>> […]
>>>
>>>>>>> On 03/05/17 20:39, Dan Tran wrote:
>>>>>>>
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> I have been experimenting with suggestion from Karl [1] with
>>>>>>>> small
>>>>> multi
>>>>>>>> module maven project.
>>>
>>> […]
>>>
>>>>>>>> [1]
>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.soeb
>>>>>>>> es.de_blog_2017_04_02_maven-2Dpom-2Dfiles-2Dwithou&d=DwIFaQ&c
>>>>>>>> =RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0i
>>>>>>>> ErugdCnFgO-CBGr_pt_OzwdxJosG0&m=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4
>>>>>>>> AYSpzB_W99oBqY&s=RYXyGU3piqrAe7XDXXTuPvbcQH935sduSNhMeYstT8Y&
>>>>>>>> e=
>>>>>>>> t-a-version-in-it/
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> Mit freundlichem Gruß
> Karl-Heinz Marbaise
>


Mit freundlichem Gruß
Karl-Heinz Marbaise
--
SoftwareEntwicklung Beratung Schulung    Tel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl-Heinz Marbaise        USt.IdNr: DE191347579
Hauptstrasse 177
52146 Würselen                           https://urldefense.proofpoint.com/v2/url?u=http-3A__www.soebes.de&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY&s=N8LOYbqdJesq5BQ2layMkVj3BdKNeoEFvdpv63MBDGc&e=

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


----------------------------------------------------------------------
This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient.  Any review, use, distribution, or disclosure by others is strictly prohibited.  If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

Karl Heinz Marbaise-3
Hi,

On 04/05/17 22:52, Justin Georgeson wrote:
> Also I believe the partial reactor switches don't work for Tycho builds.

You mean -pl ..option I suppose?

As far as I know Tycho is handling that at the wrong time of the maven
build and furthermore handles in this relationship some other things
wrong which results in not working things like this..

Kind regards
Karl Heinz Marbaise

>
> -----Original Message-----
> From: Robert Patrick [mailto:[hidden email]]
> Sent: Thursday, May 4, 2017 3:18 PM
> To: Maven Users List <[hidden email]>; [hidden email]
> Subject: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
>
> External Sender: Use caution with links/attachments.
>
>
>
> Hard to train developers to break old habits but thanks... :-)
>
>
>
> -----Original Message-----
> From: Karl Heinz Marbaise [mailto:[hidden email]]
> Sent: Thursday, May 04, 2017 3:16 PM
> To: Robert Patrick; Maven Users List; [hidden email]
> Subject: Re: Continuous Delivery with Maven now possible?
>
> Hi Robert,
>
> Ah now I see the issue.
>
> If you have a multi module build you should use
>
> mvn -pl moduleToBuild clean install
>
> but from root location and don't change into the module directory cause this can't work like this.
>
> Kind regards
> Karl Heinz Marbaise
>
> On 04/05/17 22:08, Robert Patrick wrote:
>> Hi Karl,
>>
>> If I define the revision property in the top-level POM, I cannot refer to it in the module POMs' <parent> elements *and* still retain the ability to build from the module directory, right?  I tried this and it failed because it was unable to resolve the revision property variable.
>>
>> C:\rpatrick\work\projects\jcs-las\util>mvn clean install [INFO]
>> Scanning for projects...
>> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
>> [FATAL] Non-resolvable parent POM for
>> oracle.jcs.lifecycle:util:[unknown-version
>> ]: Failure to find oracle.jcs.lifecycle:app-to-cloud:pom:${revision}
>> in
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__a&d=DwIDaQ&c=RoP1Y
>> umCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr
>> _pt_OzwdxJosG0&m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY&s=by9ucii
>> pxSZU0-Wn16t7grG7a5Djk4ZH9440pGIayRE&e=
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__rtifactory-2Dslc.o
>> raclecorp.com_artifactory_repo1&d=DwIFaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYB
>> RbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m=mQrJO
>> CEKXlLF5VNECH6aqvyAu4kATrZgYUsiitvnfwY&s=oPO-3-7EEwzSMAr8-re0YxZdReMu1
>> 5_A4OMXDtdtFyA&e=  was cached in the local reposito ry, resolution will not be reattempted until the update interval of repo1 has el apsed or updates are forced and 'parent.relativePath' points at wrong local POM @ line 7, column 13  @ [ERROR] The build could not read 1 project -> [Help 1] [ERROR]
>> [ERROR]   The project oracle.jcs.lifecycle:util:[unknown-version] (C:\rpatrick\w
>> ork\projects\jcs-las\util\pom.xml) has 1 error
>> [ERROR]     Non-resolvable parent POM for oracle.jcs.lifecycle:util:[unknown-ver
>> sion]: Failure to find
>> oracle.jcs.lifecycle:app-to-cloud:pom:${revision} in http
>> ://artifactory-slc.oraclecorp.com/artifactory/repo1 was cached in the
>> local repo sitory, resolution will not be reattempted until the update
>> interval of repo1 ha s elapsed or updates are forced and
>> 'parent.relativePath' points at wrong local POM @ line 7, column 13 ->
>> [Help 2] [ERROR] [ERROR] To see the full stack trace of the errors,
>> re-run Maven with the -e swit ch.
>> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>> [ERROR]
>> [ERROR] For more information about the errors and possible solutions,
>> please rea d the following articles:
>> [ERROR] [Help 1]
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__cwiki.apache.org_c
>> onfluence_display_MAVEN_ProjectBuildin&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8
>> PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&
>> m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY&s=Gpqh8tXn87EJPGvORYVRoH
>> s2ncTiyaZSJWc3AEyEsUQ&e=
>> gException
>> [ERROR] [Help 2]
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__cwiki.apache.org_c
>> onfluence_display_MAVEN_UnresolvableMo&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8
>> PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&
>> m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY&s=kjqcy_wD0H5qwfISMGTZrq
>> XoHWM-jV5GAbTtEvug-bc&e=
>> delException
>>
>>
>> Did I miss something?
>>
>> Thanks,
>> Robert
>>
>> -----Original Message-----
>> From: Karl Heinz Marbaise [mailto:[hidden email]]
>> Sent: Thursday, May 04, 2017 3:02 PM
>> To: Maven Users List
>> Subject: Re: Continuous Delivery with Maven now possible?
>>
>> Hi Robert,
>>
>>
>> On 04/05/17 21:55, Robert Patrick wrote:
>>
>>> With 3.5, you can now use a variable *but* that variable
>>  > has to be accessible to the POM prior to finding its  > parent so
>> the only solution is to move the  >  version number outside the POM
>> hierarchy and into a -D defined
>>> variable.
>>
>> Which is not true. You can define the property inside the pom file if you like and can overwrite the version via command line (-Drevision=...).
>>
>>
>>
>>  > While this works, it seems to have some undesirable  > aspects to
>> it.  In my opinion, it would be better if  > Maven could find a way to
>> resolve this issue  > without resorting to -Ds to specify the  > value
>> of the variable.
>>  > I am not sure it is possible but I also worry  > about moving the
>> version number outside the POM...
>>>
>>> Maybe Maven should consider a mechanism by which the project version number can be defined in a separate location that is:
>>>
>>> 1.) Well-known so that all resolution can happen directly by
>>> interacting with this location directly, without the need to traverse
>>> the parent hierarchy
>>> 2.) It is part of the project structure so that it can be managed in
>>> the project's source control system
>>> 3.) It cannot be overridden at build time with command-line arguments.
>>> 4.) Has a mechanism by which to reference it from all the necessary
>>> locations within the POMs
>>>
>>> Maybe something like an optional .mvn/project.version file and a variable that cannot be overridden to refer to it?
>>>
>>> -----Original Message-----
>>> From: Eric Benzacar [mailto:[hidden email]]
>>> Sent: Thursday, May 04, 2017 12:53 PM
>>> To: Maven Users List
>>> Subject: Re: Continuous Delivery with Maven now possible?
>>>
>>> I've read through Karl's blog
>>> (https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.soebes.de_b
>>> log_&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmb
>>> ofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&m=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4A
>>> YSpzB_W99oBqY&s=YS5dQgFEyKUuZzQgF6kuQUcPO2kUvZ3-9aUHcY3Kmmk&e=
>>> 2017/04/02/maven-pom-files-without-a-version-in-it/), and while I understand the approach, there is still one critical issue that bothers me.  I think this actually reopens an old thread that circulated on this list a few months ago, but it related to the Idempotence of a pom file.
>>>
>>> >From my perspective/view a pom file should be idempotent.  That is every single build of a given NON-SNAPSHOT pom file should finish with the same build.  But by moving a release number or version number outside of the pom, it eliminates this need.  Furthermore, from a traceability perspective, my source control can no longer show me precisely version was being built/developed at any given time.
>>>
>>> By leveraging the mvn.config file, I'm a little further down the path, but none the less, the value can be overridden at build time with a completely different value.  Consequently, I can still not be 100% confident that a pom delivered a particular version.
>>>
>>> I'm still not 100% sure of the best approach going forward, but I'm thinking that something like the version-plugin being able to manipulate a revision property that can then be committed as part of the pom would be the best of both approaches.  In that way, my developers can fix the version number, but my build system can manipulate the revision property.
>>>
>>> Does anyone know if there is a plugin that will allow for that?
>>>
>>> Thanks,
>>>
>>> Eric
>>>
>>>
>>> On Thu, May 4, 2017 at 12:40 PM, Thomas Broyer <https://urldefense.proofpoint.com/v2/url?u=http-3A__t.broyer-40gmail.com&d=DwIFaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m=mQrJOCEKXlLF5VNECH6aqvyAu4kATrZgYUsiitvnfwY&s=0PY7XDt7qFb0WfiWMn1CIgxZ2Q6apBhIlOqIgfU0A3A&e= > wrote:
>>>
>>>> How about everybody read their mail?
>>>> (see below)
>>>>
>>>> On Thu, May 4, 2017 at 6:10 PM Curtis Rueden <[hidden email]> wrote:
>>>>
>>>>> Hi Dan, Karl & everyone,
>>>>>
>>>>>> See Karl's Blog
>>>>>
>>>>> Link, please?
>>>>>
>>>> […]
>>>>
>>>>>>>> On 03/05/17 20:39, Dan Tran wrote:
>>>>>>>>
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> I have been experimenting with suggestion from Karl [1] with
>>>>>>>>> small
>>>>>> multi
>>>>>>>>> module maven project.
>>>>
>>>> […]
>>>>
>>>>>>>>> [1]
>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.soeb
>>>>>>>>> es.de_blog_2017_04_02_maven-2Dpom-2Dfiles-2Dwithou&d=DwIFaQ&c
>>>>>>>>> =RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0i
>>>>>>>>> ErugdCnFgO-CBGr_pt_OzwdxJosG0&m=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4
>>>>>>>>> AYSpzB_W99oBqY&s=RYXyGU3piqrAe7XDXXTuPvbcQH935sduSNhMeYstT8Y&
>>>>>>>>> e=
>>>>>>>>> t-a-version-in-it/
>>>>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12
Loading...