maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Podgursky <bpodgur...@gmail.com>
Subject Re: Using Git tags to cut releases to Maven Central from TravisCI
Date Fri, 02 Aug 2019 15:19:16 GMT
Thanks Hervé and Matthieu.  I'm afraid I am not following this point:

> An issue with solutions like yours is reproducibility : `git checkout
X.Y.Z && mvn install`will not build again artifact-X.Y.Z

I guess I am not stating it explicitly, but once I release version X.Y.Z, I
would never change the tag to point to a different commit, much like I
would not change the Git commit history once it was pushed to master.  In
Git, this would require deleting the tag and recreating it.  Even if I felt
like doing this, it wouldn't do much good, because I cannot re-release the
artifact to central.

> you can't really predict how RELEASE value will really be related to PREV

This is reasonable, although since it's my repository I do know what the
next version will be.  I do feel this could be resolved by wrapping the
commands I listed into a simple script that increments the version (similar
to how the deploy plugin does it, but without the commit).

I appreciate the feedback, thanks for taking the time to read this.



On Thu, Aug 1, 2019 at 11:02 PM Hervé BOUTEMY <herve.boutemy@free.fr> wrote:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message