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 Sat, 03 Aug 2019 07:36:41 GMT
I'm torn:
- I find commits for version management useful, then really want them (with 
clear SNAPSHOT during development and no SNAPSHOT at release points)
- but I'd like to have naming in branch, this would be useful (we're lazy, we 
never update pom.xml, and if we did update, this would cause a commit that we 
don't want to merge back to master...)
- and I don't like automatic project version policy: I really think that 
version is a matter of human choice

there is really a question of taste: we'll need to document somewhere the 
different solutions for different tastes in a neutral way and let people choose 
solutions based on their own preferences

one key aspect: in this case, the version in pom.xml in source control is not 
the effective version
In this case, I'd prefer to have a variable reference in the version tag of 
pom.xml to clearly show that the version in not managed in pom.xml

I hope that with future consumer vs build pom, such options will be perfectly 
manageable

Regards,

Hervé

Le vendredi 2 août 2019, 08:37:58 CEST Matthieu BROUILLARD a écrit :
> 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





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


Mime
View raw message