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 <dant...@gmail.com> 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 <ebenza...@gmail.com> 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" <khmarba...@gmx.de> 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: users-unsubscr...@maven.apache.org
>> > For additional commands, e-mail: users-h...@maven.apache.org
>> >
>> >
>>
>
>
