maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthieu BROUILLARD <matth...@brouillard.fr>
Subject Re: Using Git tags to cut releases to Maven Central from TravisCI
Date Fri, 02 Aug 2019 06:37:58 GMT
Hi Herve,

you're right for the source tarball, if it is a need for you or your
project then your need a not so clever solution.
everything depends on the needs. If a project needs an offline build then
maven will probably fail also.

The thing is that part of maven users would like the build process to be
smarter than it is today and even if you tomorrow you modify only the root
pom then you'll have two commits.
jgitver, like other core extension, tries to bring some new capabilities
which bring value to the users who want those features:
- no commit for version management
- naming in branch
- shared & enforced automatic project policy to compute project version
- ...

We're probably no so aligned in this area of having the version changes in
the source control but that's also good to me ; it reflects different needs
in the community.
And the fact that people try to find workarounds to the 'standard' way of
doing things prove that there is some place for additional workflows/tools
like jgitver.

Regards,

Matthieu

On Fri, Aug 2, 2019 at 8:03 AM 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