Re: Using Git tags to cut releases to Maven Central from TravisCI

[Hervé BOUTEMY]

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  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  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  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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Maven question - how to pull code from bitbucket repository as dependency

[Jason Young]

On Wed, Jun 12, 2019 at 1:04 AM Anders Hammar  wrote:

> Having a dependency to some other scm repo is not a good approach. If that
> changes your build could fail all of a sudden and you want consistency.
>

This is not true. The "big 3" VCSes each allow you to checkout a specific
tag or revision if you like. If both projects (the dependent and the
dependency) use the same VCS, then, at least in the cases of Git and SVN,
you have a VCS-specific feature, e.g. Git subrepos or SVN externals, to
work with the dependency's repo pretty seamlessly (though admittedly their
use is controversial, but let's not go on a tangent about it :) ).


> Your Maven project should typically be self contained. Any dependency
> should be a Maven artifact (that is immutable).
>

It is certainly preferable to make one Maven project depend on another when
possible, but keep in mind there are by necessity other kinds of
dependencies too: The JDK, system-level libraries not provided by some
JVMs, a SQL database, etc. You _can_ mavenize a lot of dependencies (like a
SQL database project) and gain Maven's dependency management, but that is
not invariably worth the cost of implementing and maintaining that
mavenization.

/Anders
>
> On Wed, Jun 12, 2019 at 7:50 AM Rajesh Deshpande <
> rajesh.deshpa...@gmail.com>
> wrote:
>
> > Hello,
> > I have a maven project that builds Java jar files. I wan to run a python
> > script as one of the goals in the verify phase. I am planning to use the
> > ant run plugin for running the python script. The python script is stored
> > in a separate repository that I would like to copy to my project root
> > folder using maven. Is this possible? What's the best way to approach
> this?
> >
> > Thanks!
> >
>

Re: Using Git tags to cut releases to Maven Central from TravisCI

[Matthieu BROUILLARD]

Hi Ben,

several years ago I created jgitver  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  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  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
>