Continuous Delivery with Maven, Jenkins and Nexus
126 views
Skip to first unread message
g.h...@aurenz.de
Apr 20, 2016, 10:14:15 AM4/20/16
to Continuous Delivery
Hello everyone,
we're currently trying to remodel our processes to implement Continuous Integration and Continuous Delivery, but fighting with some basic problems.
As the build is performed by Jenkins it also takes care of the build number which should later be part of the artifact which is later deployed to the artifact repository (in our case Nexus). This will ensure that the name of the artifact (means including the version number) is unique.
But that raises some questions about the dependency management: In other projects depending on this software (let's say it's a library used by other programs and libraries) we also have to change the dependency accordingly.
As we may develop the library in parallel with the programs and other libraries we also have it checked-out into the IDE (Eclipse in our case). The library doesn't contain the build part in the version number. The Eclipse-Maven-Plugin seems to ignore the version number and just uses the current version in your IDE - at least as long as it is in the same workspace. Seems more like a bug, but okay. The problems start if we try to build the program or other libraries depending on it as Maven won't use the version in the IDE. Instead it will use the version in the local repository or the Nexus repository. And if it doesn't find it there it will simply fail.
If we put a version number without the build number into the POM file it will use the version which we currently have in our IDE - means if we have build and deployed it into our local repository. If we haven't done that or if it is a library which we haven't checked-out yet, we have a problem as Maven won't find it and fail.
I asked that question also in the Maven User Group mailing list. It seems that there are some solutions like using version ranges for dependencies (which would break the defined relation), running some programs do alter the version numbers during the build process and checking them into the SCM afterwards (which would trigger the next build), as well as a combination of altering the version numbers locally by some script(s) and having a check-in hook in your SCM which pre-checks these version numbers if they are set correctly.
Somehow this all seems complicated, not very straight-forwarded, partially not automated, error-prone and breaking the principles written in the book "Continuous Delivery".
Is there some easy and clean way to handle artifact versioning?
I mean easy handling on both sides: On side of the build / CI server as well as on the developer / IDE side.
Regards,
Gerrit
we're currently trying to remodel our processes to implement Continuous Integration and Continuous Delivery, but fighting with some basic problems.
As the build is performed by Jenkins it also takes care of the build number which should later be part of the artifact which is later deployed to the artifact repository (in our case Nexus). This will ensure that the name of the artifact (means including the version number) is unique.
But that raises some questions about the dependency management: In other projects depending on this software (let's say it's a library used by other programs and libraries) we also have to change the dependency accordingly.
As we may develop the library in parallel with the programs and other libraries we also have it checked-out into the IDE (Eclipse in our case). The library doesn't contain the build part in the version number. The Eclipse-Maven-Plugin seems to ignore the version number and just uses the current version in your IDE - at least as long as it is in the same workspace. Seems more like a bug, but okay. The problems start if we try to build the program or other libraries depending on it as Maven won't use the version in the IDE. Instead it will use the version in the local repository or the Nexus repository. And if it doesn't find it there it will simply fail.
If we put a version number without the build number into the POM file it will use the version which we currently have in our IDE - means if we have build and deployed it into our local repository. If we haven't done that or if it is a library which we haven't checked-out yet, we have a problem as Maven won't find it and fail.
I asked that question also in the Maven User Group mailing list. It seems that there are some solutions like using version ranges for dependencies (which would break the defined relation), running some programs do alter the version numbers during the build process and checking them into the SCM afterwards (which would trigger the next build), as well as a combination of altering the version numbers locally by some script(s) and having a check-in hook in your SCM which pre-checks these version numbers if they are set correctly.
Somehow this all seems complicated, not very straight-forwarded, partially not automated, error-prone and breaking the principles written in the book "Continuous Delivery".
Is there some easy and clean way to handle artifact versioning?
I mean easy handling on both sides: On side of the build / CI server as well as on the developer / IDE side.
Regards,
Gerrit
g.h...@aurenz.de
Apr 22, 2016, 10:38:21 AM4/22/16
to Continuous Delivery
Hello everyone,
I have to admit that I didn't read the chapter 13 "Managing Components and Dependencies" of the "Continuous Delivery" book before posting the upper message. So I was somehow happy when I read that it deals with "Dependency Hello" and even with "Managing Dependencies with Maven".
Unfortunately the problem with have with Maven and dependency management is not covered by it: How do you handle continuously changing dependency while still having a specified build? And how can you implement that process while still using an IDE also supporting that kind of build?
Would be nice to get some input on this matter.
Regards,
Gerrit
I have to admit that I didn't read the chapter 13 "Managing Components and Dependencies" of the "Continuous Delivery" book before posting the upper message. So I was somehow happy when I read that it deals with "Dependency Hello" and even with "Managing Dependencies with Maven".
Unfortunately the problem with have with Maven and dependency management is not covered by it: How do you handle continuously changing dependency while still having a specified build? And how can you implement that process while still using an IDE also supporting that kind of build?
Would be nice to get some input on this matter.
Regards,
Gerrit
Reply all
Reply to author
Forward
0 new messages