You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Ben Podgursky <bp...@gmail.com> on 2019/07/31 15:50:51 UTC
Using Git tags to cut releases to Maven Central from TravisCI
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-central-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
Re: Using Git tags to cut releases to Maven Central from TravisCI
Posted by Hervé BOUTEMY <he...@free.fr>.
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 <he...@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 <bp...@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
Re: Using Git tags to cut releases to Maven Central from TravisCI
Posted by Matthieu BROUILLARD <ma...@brouillard.fr>.
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 <he...@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 <bp...@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
>
>
Re: Using Git tags to cut releases to Maven Central from TravisCI
Posted by Tibor Digana <ti...@apache.org>.
Ben, you have to delete the remote Tag from Git if you want to repeat the
release of the same version.
It happened many times to me and my colleagues that we had to delete the
tag for whatever reason, e.g. wrong SCM credentials or connectivity
problems.
So it was usual that we deleted the tag, fixed the problem and then we
repeated the process.
This maybe helps. It is the pseudocode of what has been done by our hands:
def ret = sh 'mvn release:prepare -DpushChanges=false'
sh 'git push origin tag yourTag'
if (ret) {
sh 'git tag -d yourTag'
sh 'git push origin :refs/tags/yourTag'
// exit 1
} else {
sh 'git push origin master'
sh 'mvn release:perform -Darguments="-DskipTests'
// ok
}
On Fri, Aug 2, 2019 at 5:19 PM Ben Podgursky <bp...@gmail.com> wrote:
> 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 <he...@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 <bp...@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
> >
> >
>
Re: Using Git tags to cut releases to Maven Central from TravisCI
Posted by Ben Podgursky <bp...@gmail.com>.
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 <he...@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 <bp...@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
>
>
Re: Using Git tags to cut releases to Maven Central from TravisCI
Posted by Hervé BOUTEMY <he...@free.fr>.
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 <bp...@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
Re: Using Git tags to cut releases to Maven Central from TravisCI
Posted by Matthieu BROUILLARD <ma...@brouillard.fr>.
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 <bp...@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-central-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
>