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
>