An alternative, which I never fully explored, is the CI/CD approach. Don't use the release plugin. Use -D, or an extension, to set a unique, non-snapshot, version for each build, and then use version ranges for the dependencies. I built an experimental extension at my last job to automatically set a rev property from the current git commit, but it wasn't entirely satisfactory.
On Wed, Nov 30, 2016 at 1:44 PM, Karl Heinz Marbaise <[email protected]> wrote: > Hi, > > > > On 30/11/16 19:18, Florian Schätz wrote: >>> >>> A library project to be >>> shared between multiple applications each having its own release-cycle >>> should not be part of a multi-module project used to build such an >>> application and should be an independent project with its own >>> release-cycle. >> >> >> While this is of course a good idea, especially when starting to create >> new applications, the library projects will grow with the applications >> and not independently of them. We cannot start by first investing months >> to create the perfect will-work-for-ten-years library and only then >> start coding the application that will, in the first months, only use >> 10% of all these features. So, realistically, during a development >> cycle, both the application and the library will grow... (which doesn't >> mean that we cannot separate them) >> >> Which leads me, for example, to the problem that I still want to >> automate as much as possible. I would like, for example, to click one >> button in my build server, perhaps enter some parameters and get a new >> release candidate of the libraries from the current release branch, >> update the dependency version of the application to this rc version, >> make the application an rc (from the application's release branch), >> install them both into the repository, tag the current status on git and >> deploy the rc application onto the server. >> >> Especially for bigger projects, I want to keep the amount of manual work >> needed as small as possible. As much building should be done >> automatically, if possible. And I would like not having to code a >> jenkins or maven plugin for that purpose (but of course, I would, if >> needed, no problem there). > > > > You can simply use maven-release-plugin (in Maven itself) which you can used > to fully automatically create releases of your project...This will need > only a plugin in Jenkins which handles all those stuff...correctly > configured things like scm entries in your pom file tagging in Git will be > done as well.... > > Sometimes you might need to improve that using the versions-maven-plugin in > combination with some pipeline steps in Jenkins...which prevents some > drawbacks of the maven-release-plugin.... > > > May be you need to think about using the Maven integration in Jenkins or > using freestyle projects or better start using pipelines ...(I often > observed performance drawbacks in relationship with Maven integration in > Jenkins)... > > > https://wiki.jenkins-ci.org/display/JENKINS/M2+Release+Plugin > https://wiki.jenkins-ci.org/display/JENKINS/Release+Plugin > > > Kind regards > Karl Heinz Marbaise > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
