maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hervé BOUTEMY <herve.bout...@free.fr>
Subject Re: Using Git tags to cut releases to Maven Central from TravisCI
Date Fri, 02 Aug 2019 06:02:48 GMT
thank you Matthieu for sharing

to me, one key interesting part is:
> An issue with solutions like yours is reproducibility : `git checkout X.Y.Z
> && mvn install`will not build again artifact-X.Y.Z ; but this can be
> considered minor depending on the use cases & needs.

and with jgitver, there is the equivalent reproducibility issue: if a release 
creates a source tarball to be able to download and rebuild independently from 
source control (= something that is mandatory at Apache level, and IMHO a good 
practice), both Ben solution and jgitver fail at rebuilding

I personally find these version changing commits *a key useful feature*: when I 
checkout any point in a projet scm history, whatever the scm (no Git is not 
the only scm in the world), I precisely know what precise version I'm building 
(be it a SNAPSHOT, where by definition the version is fuzzy, or a release where 
the version is strictly defined at a precise state for the whole source tree)


What Maven could do better to me is avoiding modifying every pom.xml file in 
multi-module project: yes, here, modifying only the root pom would be an 
improvement.
I know there is a MNG Jira issue (even if I can't find it right now)


But definitely, trying to remove versions changes at source level seems to me 
not not a good objective because these commits are useful: the codebase is 
really switching from PREV-SNAPSHOT to RELEASE to NEXT-SNAPSHOT
And even the fact that:
- you can't really predict how RELEASE value will really be related to PREV
- you'll have to make a guess at choosing NEXT
proves that these changes at source level are useful.
What we should do is making them easier

Regards,

Hervé

Le jeudi 1 août 2019, 11:23:33 CEST Matthieu BROUILLARD a écrit :
> Hi Ben,
> 
> several years ago I created jgitver <https://jgitver.github.io> to cover
> such a use case and even more.
> 
> It uses git information (tags, branches, commits, metadatas, ...) to
> automatically compute a version based on configurable rules.
> So like you I can simply do: `git tag X.Y.Z && mvn deploy`
> jgitver <https://jgitver.github.io> brings more features & configuration
> capabilities without never modifying the pom files (like `mvn versions
> -dnewVersion` does).
> 
> It is a solution among others but it is worthwhile trying it.
> 
> An issue with solutions like yours is reproducibility : `git checkout X.Y.Z
> && mvn install`will not build again artifact-X.Y.Z ; but this can be
> considered minor depending on the use cases & needs.
> 
> FYI here are the projects I maintain related to the topic:
> 
>    - jgitver library: https://github.com/jgitver/jgitver
>    - jgitver maven extension:
>    https://github.com/jgitver/jgitver-maven-plugin
>    - jgitver gradle plugin: https://github.com/jgitver/gradle-jgitver-plugin
> 
> Regards,
> 
> Matthieu
> 
> On Wed, Jul 31, 2019 at 5:51 PM Ben Podgursky <bpodgursky@gmail.com> wrote:
> > I've been experimenting with setting up Maven Central publishing from a
> > TravisCI build (since it's free for my OSS GitHub project), and I ended up
> > with a pattern that I think is pretty nice to work with (I've struggled
> > with the maven-deploy-plugin in the past).
> > 
> > I've written it up here
> > 
> > https://bpodgursky.com/2019/07/31/using-travisci-to-deploy-to-maven-centra
> > l-via-git-tagging-aka-death-to-commit-clutter/ but
> > tl,dr, the key thing I haven't seen used widely is the use of tags to
> > define release versions, eg:
> > 
> > ```
> > if [ ! -z "$TRAVIS_TAG" ]
> > then
> > 
> >     mvn --settings "${TRAVIS_BUILD_DIR}/.travis/mvn-settings.xml"
> > 
> > org.codehaus.mojo:versions-maven-plugin:2.1:set -DnewVersion=$TRAVIS_TAG
> > 1>/dev/null 2>/dev/null
> > else
> > 
> >     echo "No tags, using snapshot version from pom.xml"
> > 
> > fi
> > 
> > mvn deploy -P publish -DskipTests=true --settings
> > "${TRAVIS_BUILD_DIR}/.travis/mvn-settings.xml"
> > ```
> > 
> > This lets me cut a central release by just pushing a tag:
> > 
> > ```
> > $ git tag 1.23
> > $ git push origin 1.23
> > ```
> > 
> > I've used Maven a fair amount but I wouldn't consider myself perfectly in
> > tune with best practices, so I'm curious what others think of this
> > approach, or if there are other streamlined central deploy setups
> > (especially from CI/Travis) that I missed.
> > 
> > 
> > Thanks,
> > 
> > Ben





---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message