Giter Club home page Giter Club logo

jgitver-maven-plugin's Introduction

jgitver-maven-plugin

Maven Central Sponsor Build Status Open Hub project report for jgitver-maven-plugin Discuss

This plugin allows to define the pom version of your project using the information from your git history. It calculates the version, a little bit like git describe would do but in a more efficient way for maven projects:

  • new commits have upper version than previous commit (in the way maven/semver interpret versions)
  • version calculation is based on git tags & branches
  • git lightweight tags allow for intermediate version controlling between releases
    • allow to define what is the next version pattern to use
  • minimal setup via maven extension

Here is an illustration of the capabilities of the plugin

Example

Usage

Activation by maven core extension

Since version 0.3.0 jgitver-maven-plugin needs to be run as a maven core extension.
The installation scripts below will use the latest version available ; if you are updating find the latest version here or there.

via curl

from the root directory of your project, run:

sh -c "$(curl -fsSL https://raw.githubusercontent.com/jgitver/jgitver-maven-plugin/master/src/doc/scripts/install.sh)"

via wget

from the root directory of your project, run:

sh -c "$(wget https://raw.githubusercontent.com/jgitver/jgitver-maven-plugin/master/src/doc/scripts/install.sh -O -)"

manually

  1. Create a directory .mvn under the root directory of your project.

  2. Create file .mvn/extensions.xml

  3. Put the following content to .mvn/extensions.xml (adapt to latest version).

    <extensions xmlns="http://maven.apache.org/EXTENSIONS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://maven.apache.org/EXTENSIONS/1.0.0 http://maven.apache.org/xsd/core-extensions-1.0.0.xsd">
      <extension>
        <groupId>fr.brouillard.oss</groupId>
        <artifactId>jgitver-maven-plugin</artifactId>
        <version>1.8.0</version>
      </extension>
    </extensions>

Configuration

In order to control jgitver-maven-plugin behavior, you can provide a configuration file under $rootProjectDir/.mvn/jgitver.config.xml. The configuration file must be compliant with the latest jgitver-configuration-v1_1_0.xsd xml schema.

Here is an example configuration file:

<configuration xmlns="http://jgitver.github.io/maven/configuration/1.1.0"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://jgitver.github.io/maven/configuration/1.1.0 https://jgitver.github.io/maven/configuration/jgitver-configuration-v1_1_0.xsd">
    <mavenLike>true/false</mavenLike>   <!-- deprecated, use 'strategy' instead -->
    <strategy>MAVEN|CONFIGURABLE|PATTERN</strategy>
    <policy>MAX|LATEST|NEAREST</policy>    <!-- LookupPolicy to select the base tag/commit for the version computation -->
    <autoIncrementPatch>true/false</autoIncrementPatch>
    <useCommitDistance>true/false</useCommitDistance>
    <useDirty>true/false</useDirty>
    <useGitCommitId>true/false</useGitCommitId>
    <useSnapshot>true/false</useSnapshot> <!-- use -SNAPSHOT in CONFIGURABLE strategy -->
    <gitCommitIdLength>integer</gitCommitIdLength>  <!-- between [8,40] -->
    <maxSearchDepth>integer</maxSearchDepth>  <!-- upper or equal to 1, ommited otherwise, default to infinite -->
    <nonQualifierBranches>master</nonQualifierBranches> <!-- comma separated, example "master,integration" -->
    <regexVersionTag>r([0-9]+)</regexVersionTag>  <!-- a java regular expression with a capture group matching only 
                                                       tags of the form r0, r1, ..., r34-->
    <exclusions>    <!-- Optional list of directory path -->
      <exclusion>relative directory path</exclusion>    <!-- relative path from project root directory -->
    </exclusions>
    <useDefaultBranchingPolicy>true/false</useDefaultBranchingPolicy>   <!-- uses jgitver#BranchingPolicy#DEFAULT_FALLBACK as fallback branch policy-->
    <branchPolicies>
        <branchPolicy>
            <pattern>pattern</pattern>                  <!-- regex pattern -->
            <!-- list of transformations to apply, if empty, defaults to REPLACE_UNEXPECTED_CHARS_UNDERSCORE, LOWERCASE_EN -->
            <transformations>                           
                <transformation>NAME</transformation> <!-- transformation name, one of jgitver#fr.brouillard.oss.jgitver.BranchingPolicy#BranchNameTransformations -->
                ...
            </transformations>
        </branchPolicy>
        ...
    </branchPolicies>
</configuration>

Please consult jgitver documentation to fully understand what the parameters do.

Old xml schemas are kept for reference.

Command line arguments

  • -Djgitver.skip=true : skips totally jgitver usage
  • -Djgitver.config=FILE : overrides default config file and uses FILE instead
  • -Djgitver.use-version=VERSION : execute jgitver but finally uses VERSION as the project version
  • -Djgitver.resolve-project-version=true : replaces the ${project.version} also in properties, dependencies, dependencyManagement, plugins and pluginManagement sections
  • -Djgitver.export-properties-path=FILE : exports output properties into the given file

Working on a detached HEAD

When working on a detached HEAD, no branch information exists anymore from git.
Since 1.3.0 it now possible to provide externally the branch information via a system property or an envrionement variable.

  • -Djgitver.branch=SOME_BRANCH_NAME
  • JGITVER_BRANCH=SOME_BRANCH_NAME && mvn validate for bash like shells
  • SET JGITVER_BRANCH=SOME_BRANCH_NAME
    mvn validate
    for windows CMD (I don't know a one liner solution)

Available output properties

The plugin exposes git calculated properties available during the maven build. Those are available under the following properties name: "jgitver.meta" where meta is one of Metadatas name in lowercase in addition to jgitver.used_version which represents the version ultimately applied (in case it was overriden on the command line using -Djgitver.use-version=VERSION).

You can then use them as standard maven properties in your build:

<plugin>
    <artifactId>maven-antrun-plugin</artifactId>
    <executions>
        <execution>
            <phase>validate</phase>
            <goals>
                <goal>run</goal>
            </goals>
            <configuration>
                <tasks>
                    <echo>used version: ${jgitver.used_version}</echo>
                    <echo>version calculated: ${jgitver.calculated_version}</echo>
                    <echo>dirty: ${jgitver.dirty}</echo>
                    <echo>head_committer_name: ${jgitver.head_committer_name}</echo>
                    <echo>head_commiter_email: ${jgitver.head_commiter_email}</echo>
                    <echo>head_commit_datetime: ${jgitver.head_commit_datetime}</echo>
                    <echo>git_sha1_full: ${jgitver.git_sha1_full}</echo>
                    <echo>git_sha1_8: ${jgitver.git_sha1_8}</echo>
                    <echo>branch_name: ${jgitver.branch_name}</echo>
                    <echo>head_tags: ${jgitver.head_tags}</echo>
                    <echo>head_annotated_tags: ${jgitver.head_annotated_tags}</echo>
                    <echo>head_lightweight_tags: ${jgitver.head_lightweight_tags}</echo>
                    <echo>base_tag: ${jgitver.base_tag}</echo>
                    <echo>all_tags: ${jgitver.all_tags}</echo>
                    <echo>all_annotated_tags: ${jgitver.all_annotated_tags}</echo>
                    <echo>all_lightweight_tags: ${jgitver.all_lightweight_tags}</echo>
                    <echo>all_version_tags: ${jgitver.all_version_tags}</echo>
                    <echo>all_version_annotated_tags: ${jgitver.all_version_annotated_tags}</echo>
                    <echo>all_version_lightweight_tags: ${jgitver.all_version_lightweight_tags}</echo>
                </tasks>
            </configuration>
        </execution>
    </executions>
</plugin>

resulted in my case

[INFO] Executing tasks
     [echo] used version: 0.2.0-SNAPSHOT
     [echo] version calculated: 0.2.0-SNAPSHOT
     [echo] dirty: true
     [echo] head_committer_name: Matthieu Brouillard
     [echo] head_commiter_email: [email protected]
     [echo] head_commit_datetime: Thu Jun 30 14:06:14 2016 +0200
     [echo] git_sha1_full: fadd88e04b25c794cea876b03d8234df5bf4e37b
     [echo] git_sha1_8: fadd88e0
     [echo] branch_name: master
     [echo] head_tags:
     [echo] head_annotated_tags:
     [echo] head_lightweight_tags:
     [echo] base_tag: v0.2.0
     [echo] all_tags: v0.2.0,0.1.1,0.1.0,0.0.3,0.0.2,0.0.1
     [echo] all_annotated_tags: 0.1.1,0.1.0,0.0.3,0.0.2,0.0.1
     [echo] all_lightweight_tags: v0.2.0
     [echo] all_version_tags: v0.2.0,0.1.1,0.1.0,0.0.3,0.0.2,0.0.1
     [echo] all_version_annotated_tags: 0.1.1,0.1.0,0.0.3,0.0.2,0.0.1
     [echo] all_version_lightweight_tags: v0.2.0
[INFO] Executed tasks

You can also output the properties into a file so that they can be picked up by the next steps in your build pipeline. This is accomplished by setting the jgitver.export-properties-path system property, e.g. from the command line:

    mvn ... -Djgitver.export-properties-path=./jgitver-output.properties

The produced file follows the Java Properties standard.

Example

If you want to give it a try you can use the following script that will setup a demo project under /tmp/jgitver-tester

# let's create a fake maven project under /tmp
cd /tmp
mvn archetype:generate -B -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-quickstart \
  -DarchetypeVersion=1.1 -DgroupId=com.company -DartifactId=jgitver-tester -Dversion=0 -Dpackage=com.company.project
cd jgitver-tester

# init the created project with jgitver-maven-plugin
sh -c "$(wget https://raw.githubusercontent.com/jgitver/jgitver-maven-plugin/master/src/doc/scripts/install.sh -O -)"

# let's do some modifications/commits/tags
echo A > content
git init
git add .
git commit -m "initial commit"
echo B > content && git add -u && git commit -m "added B data"
git tag 1.0 -m "release 1.0"
echo C > content && git add -u && git commit -m "added C data"
git checkout -b cool-feature
echo D > content && git add -u && git commit -m "added D data"
git checkout master
echo E > content && git add -u && git commit -m "added E data"
mvn validate

Then play around with it doing:

  • mvn validate
  • mvn install
  • git checkout 1.0
  • mvn validate
  • git checkout cool-feature
  • mvn validate

Requirements

Maven requirements

jgitver-maven-plugin requires at least maven-3.3.2 to work correctly.

Think to modify your IDE settings regarding maven version ; if required do not use the embedded maven version of your IDE but an external one that fulfill the maven minimal requirements.

Supported IDEs

  • Eclipse: tested with Eclipse Mars.2 Release 4.5.2
  • Netbeans: tested with NetBeans IDE 8.1 Build 201510222201
  • Intellij IDEA: tested with 2016.1.3

Build & release

see also the Contributing guide.

Github Markdown rendering

Before pushing try to always verify that the modifications pushed in MD files will be correctly rendered by Github.
For that purpose you can use grip.

Normal build

  • mvn -Prun-its clean install

or using docker

  • Linux: docker run --rm -v $(pwd):/root/sources -w /root/sources maven:3.6.3-openjdk-11 mvn -Prun-its clean install
  • Windows: docker run --rm -v %CD%:/root/sources -w /root/sources maven:3.6.3-openjdk-11 mvn -Prun-its clean install
  • Old linux command: docker run --rm -v $(pwd):/root/sources -w /root/sources maven:3.6.3-openjdk-11 ./src/ci/build-with-external-it-fallback.sh

build and filter some IT tests

  • mvn -Prun-its clean install "-Dinvoker.test=issues/issue-36*"

If needed, one can also add in above docker command a volume sharing with the maven local repository by adding something like -v MLR_LOCATION:/root/.m2/repository for example -v D:\dev\mlr:/root/.m2/repository.

Release

  • mvn -Poss clean install: this will simulate a full build for oss delivery (javadoc, source attachement, GPG signature, ...)
  • git tag -a -s -m "release X.Y.Z, additionnal reason" X.Y.Z: tag the current HEAD with the given tag name. The tag is signed by the author of the release. Adapt with gpg key of maintainer.
    • Matthieu Brouillard command: git tag -a -s -u 2AB5F258 -m "release X.Y.Z, additionnal reason" X.Y.Z
    • Matthieu Brouillard public key
  • mvn -Poss,release -DskipTests clean deploy
  • git push --follow-tags origin master

Issues

I want to temporary disable the plugin execution

Since 1.0.0, it is possible to totally skip the plugin execution by launching maven with the user property jgtiver.skip set to true, example:

  • mvn clean install -Djgitver.skip=true

maven reports my project version to be 0 (or the one set in the pom.xml)

If your version is not calculated correctly by maven/jgitver, there are good chances that the plugin is not active.
Please verify that you are using maven >= 3.3.2.

build fail because all project plugins & dependencies resolve to the same version

if during a build all the plugins & dependencies are resolved to the exacts same version then chances are high that you have the local maven repository as a subdirectory of your jgitver handled project.

To overcome this problem you have 2 possibilities:

  • separate correctly your project from the MLR and make sure the MLR is not a subdirectory of your jgitver managed project
  • configure jgitver (using .mvn/jgitver.config.xml) to ignore your subdirectory MLR, see the configuration paragraph
    <configuration>
        <exclusions>
            <exclusion>path_to_your_mlr</exclusion>    <!-- can be .m2, .repository or something else -->
        </exclusions>
    </configuration>

see also #90 && #91 for discussions on this topic.

the invoker tests of my maven plugin project do not work anymore

If you develop a maven plugin project, you normally run maven-invoker-plugin to test your plugin.
Using default configuration, maven-invoker-plugin will use a temporary local repository under target/local-repo and the IT tests will be executed from target/it/XYZ. In this context, when executing tests, maven will try to activate extensions starting from the target/it/XYZ directory ; and it will find your extensions definition in the root directory of the project. This will lead in the activation of jgitver-maven-plugin for all your IT projects AND for the poms inside the temporary local repository under target/local-repository.

To avoid such behavior, you need to tell jgitver-maven-plugin to ignore some directories. If you do not have already a jgitver configuration file, create one under .mvn/jgitver.config.xml and declare some exclusions (see configuration):

<configuration>
    <exclusions>
        <exclusion>target/local-repo</exclusion>
        <exclusion>target/it/**</exclusion>
    </exclusions>
</configuration>

You can have a look at the configuration of jgitver-maven-plugin itself.

License

jgitver-maven-plugin is delivered under the Apache Licence, Version 2

jgitver-maven-plugin's People

Contributors

cchantep avatar drekbour avatar driseley avatar hbvit7 avatar jeremy-im avatar jschneider avatar lbruun avatar marcobjorge avatar mcfoggy avatar michael-wirth avatar skapral avatar xeagle2 avatar zomzog avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

jgitver-maven-plugin's Issues

jgitver-maven-plugin does not correctly report groupId & version for multi modules

New implementation uses directly maven model object.
When the pom does not redefine the groupId & version from parent, those values are null in the model

[INFO] Scanning for projects...
[INFO] jgitver-maven-plugin is about to change project(s) version(s)
[INFO]     null::multi-pure-extension-it-module::null -> 2.0.0-SNAPSHOT
[INFO]     fr.brouillard.oss.it.multi::multi-pure-extension-it::0 -> 2.0.0-SNAPSHOT

Allow regex for autoIncrementPatch

Here's what I'm trying to accomplish, maybe there's a way to do it currently

on a brand new project (calculated version is 0.0.0), i make two commits against the master branch, at which point the version is 0.0.0-2
I then create an annotated tag to release 0.0.0
with autoIncrementPatch=true when I continue committing against master, i get the results i want, the next commit causes calculated version to be 0.0.1-1

Now we find that there's a bug in the release 0.0.0 so we create a hotfix branch hotfix/0.0.0 from that tag.
What I want is for commits to this branch to not increment the patch, but keep in the 0.0.0-x family

However, since I set autoIncrementPatch=true to get the desired behaviour in master, it's giving me undesirable behaviour in my hotfix branch, as in this branch, after i commit, the version will be
0.0.1-1-hotfix_0.0.0 (I'd like it to be 0.0.0-3-hotfix_0.0.0)

If it's not possible to get the desired behaviour with current features, then I'd like to propose that the autoIncrementPatch takes a comma separated list of regex values, to indicate which branches should have autoIncrementPatch enabled

Version-Number modified problem with nexus-staging-maven-plugin

Using version 0.3.0-alpha2.

Building as free style project in Jenkins fails with this message:

The project com.cedarsoft:open:75.1.1-SNAPSHOT (/var/lib/jenkins/jobs/com.cedarsoft.open/workspace/pom.xml) has 1 error
[ERROR] Unresolveable build extension: Plugin org.sonatype.plugins:nexus-staging-maven-plugin:1.6.7 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.sonatype.plugins:nexus-staging-maven-plugin:jar:1.6.7: Could not find artifact org.sonatype.nexus.maven:nexus-staging:pom:75.1.1-SNAPSHOT in sonatype-nexus-snapshots (https://oss.sonatype.org/content/repositories/snapshots/) -> [Help 2]
org.apache.maven.plugin.PluginManagerException: Plugin org.sonatype.plugins:nexus-staging-maven-plugin:1.6.7 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.sonatype.plugins:nexus-staging-maven-plugin:jar:1.6.7

It seems to be a bit strange. But obviously the version number for the parent of an other extension is set to a invalid value.

This problem does not happen when executed as stand alone. So probably it is a Jenkins bug... Buy maybe you have an idea?

Multi-module project and ${project.version}

I have a multi-module project, where inter-module dependencies are specified like this:

eg. in module website-core I depend on website-domain:

        <dependency>
            <groupId>com.business.website</groupId>
            <artifactId>website-domain</artifactId>
            <version>${project.version}</version>
        </dependency>

When building the parent of this, maven still sees this as version 0, and fails with error:

[ERROR] Failed to execute goal on project website-core: 
Could not resolve dependencies for project com.business.website:website-core:jar:2.5.0-1: 
The following artifacts could not be resolved: com.business.website:website-domain:jar:tests:0,
 com.business.website:website-integration:0: 
Failure to find com.business.website:website-domain:jar:tests:0 in 
http://nexus:8081/nexus/content/groups/public was cached in the local repository, resolution will not be 
reattempted until the update interval of nexus has elapsed or updates are forced -> [Help 1]

Should this work, or is my maven structure goofed?

It would be helpful to have .xsd for jgitver.config.xml

In most cases it's easy to make the mistakes while specifying the configuration in jgitver.config.xml.

It would be helpful to have at least .xsd to help others configure the plugin properly from IDEs and it would be a good step ahead to validate configuration while it's loaded by plugin.

Would be nice to have this feature.

Thank you,

Using the Maven Plugin makes IntelliJ Maven support useless

By enabling the Maven Plugin, IntelliJ Multi-Module Projects completely fail to resolve their depencencies within the IDE. I had to put the Plugin in a Profile and just use the Project-Version 0.0.0-SNAPSHOT for every module to make it working. On my build system i have enabled the Maven Profile which then uses the jgitver mechanism to determine the correct version.

document a 'quick start' guide

As a maven user landing of the jgitver-maven-plugin site/root page, I want to see a mini start guide that I can follow:

  • to start using jgitver-maven-plugin when starting from scratch (ie blank new project)
  • to start using jgitver-maven-plugin from an existing project:
    • document how to introduce jgitver-maven-plugin
    • document how to set lightweight tags to be fully version compatible with latest project version
    • ...

Multi module project: Can not resolve versions for test-jar deps

I have a multi module project. Building it from the main directory works.

I have two problems:

  • I have defined a dependency to another module with version "${project.version}". This works usually. But if the type is "test-jar", Maven tries to download the version "0".

Sample:
Multi-Module pom.xml:

<groupId>my.group</groupId>
<artifactId>parent</artifactId>

<dependencyManagement>
<dependencies>
      <dependency>
        <groupId>my.group</groupId>
        <artifactId>domain</artifactId>
        <version>${project.version}</version>
        <type>test-jar</type>
        <scope>test</scope>
      </dependency>

Child pom.xml:

<groupId>my.group</groupId>
<artifactId>ui</artifactId>

<dependencies>
<dependency>
      <groupId>my.group</groupId>
      <artifactId>domain</artifactId>
      <type>test-jar</type>
    </dependency>

provide git metadata as maven properties

as the plugin already loads some git information, would be great to expose that as maven properties for later reuse in the builds.
This way the usage of external additional plugins could be removed:

  • maven-jgit-buildnumber-plugin
  • maven-buildnumber-plugin

Plugin is incompatible with Artifactory Jenkins Plugin

Issue

First off: Nice plugin, good idea and clean approach to automatically generate version numbers based on the git history. Unfortunately it seems that the plugin is not compatible with the Artifactory Plugin of Jenkins inside our CI environment. I will describe the details below.

version: 0.4.0

usage context:

Problem description:

I'm currently working on a new internally used set of libraries composed as multi module project using maven. I've added the plugin as described (.mvn/extension.xml). Locally it's working totally fine using intelliJ. But inside Jenkins the plugin breaks the Artifactory Plugin to publish the generated artifacts to a artifactory server instance.

I'm using a JenkinsFile to build the artifacts - snip

checkout(...)
def server = Artifactory.server 'maven'
def buildInfo = Artifactory.newBuildInfo()
buildInfo.env.capture = true
def rtMaven = Artifactory.newMavenBuild()
rtMaven.tool = 'MavenLatest'
rtMaven.deployer releaseRepo:'java-releases', snapshotRepo:'java-snapshots', server: server
rtMaven.deployer.artifactDeploymentPatterns.addInclude('....)
rtMaven.run pom: 'pom.xml', goals: 'clean package', buildInfo: buildInfo
server.publishBuildInfo buildInfo}

The Artifactory Plugin is calling maven internally, which is working fine and the jgtiver plugin is also invoked with no issues:

java -classpath /opt/maven/apache-maven-3.3.9/boot/plexus-classworlds-2.5.2.jar -Dmaven.home=/opt/maven/apache-maven-3.3.9 -DbuildInfoConfig.propertiesFile=/tmp/buildInfo5131567399890492507.properties -Dclassworlds.conf=/tmp/classworlds9114561323625377013conf -Dmaven.multiModuleProjectDirectory=/var/lib/jenkins/path-to-project -org.codehaus.plexus.classworlds.launcher.Launcher -f pom.xml clean package

Output (I've omitted some names for privacy reasons):

[main] INFO org.apache.maven.cli.event.ExecutionEventLogger - Scanning for projects... [main] INFO fr.brouillard.oss.jgitver.JGitverModelProcessor - jgitver-maven-plugin is about to change project(s) version(s) [main] INFO fr.brouillard.oss.jgitver.JGitverExtension - XXX::XXX-YYY:1.0.0-SNAPSHOT -> 1.0.0-SNAPSHOT .... [main] INFO org.jfrog.build.extractor.maven.BuildInfoRecorder - Initializing Artifactory Build-Info Recording [main] INFO org.apache.maven.cli.event.ExecutionEventLogger - ------------------------------------------------------------------------ [main] INFO org.apache.maven.cli.event.ExecutionEventLogger - Reactor Build Order: [main] INFO org.apache.maven.cli.event.ExecutionEventLogger - [main] INFO org.apache.maven.cli.event.ExecutionEventLogger - XXX-YYY ... [main] INFO org.apache.maven.cli.event.ExecutionEventLogger - [main] INFO org.apache.maven.cli.event.ExecutionEventLogger - ------------------------------------------------------------------------ [main] INFO org.apache.maven.cli.event.ExecutionEventLogger - Building XXX-YYY 1.0.0-SNAPSHOT [main] INFO org.apache.maven.cli.event.ExecutionEventLogger - ---------------------------------------------------------

But then the Artifactory Plugin kicks in and hangs:

[main] ERROR org.jfrog.build.extractor.maven.resolver.ArtifactoryEclipseRepositoryListener - Failed while enforcing Artifactory artifact resolver org.codehaus.plexus.component.repository.exception.ComponentLookupException: java.util.NoSuchElementException role: org.jfrog.build.extractor.maven.resolver.ArtifactoryEclipseArtifactResolver roleHint: at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:267) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:243) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:237) at

I saw that your plugin is using plexus as well - Is it possible, that the plugin overrides the plexus context and therefore the Artifactory Plugin is unable to find their registered components?

I would really like to use your plugin in production, but on the other hand I'm not able to dismiss artifactory as of now.

If you need further information let me know.

Best regards,
Marvin K.
Statista

PS: Sorry for the bad JenkinsFile formatting, my Markdown skills are kinda bad.

Running jgitver should be optional

From @MattFriedman on September 9, 2017 3:22

If jgitver exists in the extensions.xml file, then it always runs, even if you are performing maven operations that don't require this versioning feature.

So, I hope you can implement a flag such as perhaps -Djgitver.versioning=true|false so that we can run the plugin or not depending on what is appropriate at the time.

Copied from original issue: jgitver/jgitver#30

allow to fail build when dirty

In order to allow automatic deployments, it would be great to allow by configuration the build to fail when a dirty version is detected.

version is not correct in deployed pom

impacted version: 0.0.1

description:
using jgitver-maven-plugin:0.0.1 maven build report the correct version but the pom deployed to repository is wrong and contains the version initially in the pom file

reproduction steps:

  • initialize a git repo using the following:
rm -rf /d/demo-jgitver-maven-plugin
mkdir /d/demo-jgitver-maven-plugin
cd /d/demo-jgitver-maven-plugin
git init
cat > pom.xml << EOF
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>fr.brouillard.oss.demo</groupId>
    <artifactId>demo-demo-jgitver-maven-plugin</artifactId>
    <version>0</version>
    <packaging>pom</packaging>
    <build>
        <plugins>
            <plugin>
                <groupId>fr.brouillard.oss</groupId>
                <artifactId>jgitver-maven-plugin</artifactId>
                <version>0.0.1</version>
                <extensions>true</extensions>
                <configuration></configuration>
            </plugin>
        </plugins>
    </build>
</project>
EOF
echo A > content
git add pom.xml
git add content
git commit -m "initial commit"
echo B > content && git add -u && git commit -m "added B data"
git tag 1.0 -m "release 1.0"
echo C > content && git add -u && git commit -m "added C data"
git checkout -b cool-feature
echo D > content && git add -u && git commit -m "added D data"
git checkout master
echo E > content && git add -u && git commit -m "added E data"
  • execute mvn install
  • the calculated version is good but the one used to deploy to the local repository is wrong
$ mvn install
[INFO] Scanning for projects...
[INFO] jgitver-maven-plugin is about to change project version
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building demo-demo-jgitver-maven-plugin 1.0.1-2
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-install-plugin:2.4:install (default-install) @ demo-demo-jgitver-maven-plugin ---
[INFO] Installing D:\demo-jgitver-maven-plugin\pom.xml to d:\dev\mlr\fr\brouillard\oss\demo\demo-demo-jgitver-maven-plugin\0\demo-demo-jgitver-maven-plugin-0.pom
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.431 s
[INFO] Finished at: 2016-04-28T10:09:58+02:00
[INFO] Final Memory: 13M/245M
[INFO] ------------------------------------------------------------------------

Use next snapshot version when dirty

On master branch after creating an annotated tag (like v1.0) version resolves to 1.0 as expected. If I make some local changes and do not commit the version is still 1.0. This is problematic as I could accidentally publish these changes to a repo (mvn install or deploy)

With useDirty=true the version changes to 1.0-dirty which is a bit better as it prevents the accidental override with deploy. But in my opinion it would be ideal if in this situation the version would already resolve to next snapshot (= 1.0.1-SNAPSHOT) like after I have commited the changes.

Not works with Java 7

When running Maven 3.3.9 under Oracle JDK 1.7.0_79, the following error shows up

[WARNING] Error injecting: fr.brouillard.oss.jgitver.JGitverExtension
java.lang.TypeNotPresentException: Type fr.brouillard.oss.jgitver.JGitverExtension not present
at org.eclipse.sisu.space.URLClassSpace.loadClass(URLClassSpace.java:147)
at org.eclipse.sisu.space.NamedClass.load(NamedClass.java:46)
at org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
at com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:81)
at com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:53)
at com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:65)
at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:115)
at org.eclipse.sisu.bean.BeanScheduler$Activator.onProvision(BeanScheduler.java:176)
at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:126)
at com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:68)
at com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:63)
at com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:45)
at com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1103)
at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
at com.google.inject.internal.SingletonScope$1.get(SingletonScope.java:145)
at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
at com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1016)
at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1092)
at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1012)
at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:81)
at org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
at org.eclipse.sisu.wire.EntryListAdapter$ValueIterator.next(EntryListAdapter.java:111)
at java.util.AbstractCollection.addAll(AbstractCollection.java:341)
at org.apache.maven.DefaultMaven.getLifecycleParticipants(DefaultMaven.java:400)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:262)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: java.lang.UnsupportedClassVersionError: fr/brouillard/oss/jgitver/JGitverExtension : Unsupported major.minor version 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:401)
at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)
at org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
at org.eclipse.sisu.space.URLClassSpace.loadClass(URLClassSpace.java:139)

Intellij doesn't refer to correct version in maven repository

version: 0.4.0
usage context: Intellij IDEA: 2016.1.4

Problem description: I have defined a dependency of one of my modules (let's refer it as A) with ${project.version} in other module (let's refer it as B).
Module A is not sub module of module B but they both share same root module.

As long as module A is imported in my intellij then module B recognize it and I can import and use its class and maven build goes fine.

I case this module A isn't exist in intellij but his artifact with generated version is exist in repository, then I can't use it for coding in my intellij. I'm getting in the editor an error that class can't be resolved.
Note: if I'll build the module using intellij plugin then it will pass although the errors in the editor.

My guess is that in IDE editor the dependencies resolving still works as default and it will use the original version to resolve each dependency.

Bottom line, we must that all project modules are imported in the IDE to manage work without editor errors.

NullPointerException in JGitverModelProcessor.provisionModel when POM unavailable.

Issue

version: 0.3.0-alpha3

usage context:

(everywhere)

Problem description:

Sometimes a JAR gets put into a repository without a POM. Our corporate repo holds several third-party JAR libraries that were not created by Maven (or any other tool that knows to generate a POM for it). Maven itself is OK with this. It warns that without a POM the dependency information is incomplete, but happily uses the JAR anyway.

JGitverModelProcessor fails in such cases.

I already have the code to fix this issue. I still need to figure out how to set up a test. So I'll get a pull request in soon as that's done.

Run "attach-modified-poms" earlier

I run into the problem that the gpg-plugin run before "attach-modified-poms".
That leads to invalid signatures since the gpg-plugin signs the original pom.xml

I'd suggest to run "attach-modified-poms" as early as possible. There might be other plugins in other phases that could run into the same issue.

Improved support for GitFlow like workflows: Differences between Branches

I am using GitFlow which is really, really great.

Development occurs in "develop". "master" always contains the latest, released version.

Example workflow can be seen in https://github.com/jschneider/jgitver-playing-ground

The version number calculation could be done like that:
in "master":

  • When a "real" git tag is set, use a release version (non snapshot)
  • Ignore lightweight tags even on the same commit

in "develop":

  • Always use a snapshot version
  • if there is a tag at the current commit, increase the version number and convert to snapshot.

GitFlow

add IT test with java project

Snipet for IT test project creation

rm -rf /d/demo-jgitver
mkdir -p /d/demo-jgitver
cd /d/demo-jgitver
mvn archetype:generate -B -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.1 -DgroupId=fr.brouillard.oss -DartifactId=demo-jgitver-java -Dversion=0 -Dpackage=fr.brouillard.oss.demo
cd demo-jgitver-java
mv pom.xml pom.origin.xml
head -n 16 pom.origin.xml > pom.xml
cat >> pom.xml << EOF

    <build>
        <plugins>
            <plugin>
                <groupId>fr.brouillard.oss</groupId>
                <artifactId>jgitver-maven-plugin</artifactId>
                <version>0.0.2-SNAPSHOT</version>
                <extensions>true</extensions>
            </plugin>
        </plugins>
    </build>

EOF
tail -n 9 pom.origin.xml >> pom.xml
rm pom.origin.xml
echo A > content
git init
git add .
git commit -m "initial commit"
echo B > content && git add -u && git commit -m "added B data"
git tag 1.0 -m "release 1.0"
echo C > content && git add -u && git commit -m "added C data"
git checkout -b cool-feature
echo D > content && git add -u && git commit -m "added D data"
git checkout master
echo E > content && git add -u && git commit -m "added E data"
mvn deploy -DaltDeploymentRepository=repo::default::file:target/repo

Non-resolvable parent POM when using jgitver

Issue

[ERROR] Non-resolvable parent POM when using jgitver

The parent version is clearly a specific "1.3.0" yet maven and jgitver are incorrectly trying to resolve the parent version as "3.1.1-pdot_224", which is the (correct) jgitver derived version for the artifact.

version: 0.3.0

usage context:

  • mvn --version
    Apache Maven 3.3.9

  • maven command line: mvn -P devopsProfileTest --file utd-lightbulb/ install

Problem description:
Here is the console error

[ERROR]   The project com.uptodate.microservice.lightbulb:utd-lightbulb:3.1.1-pdot_224 (C:\UNG\workspaces\NG\microservicetemplate\utd-lightbulb\pom.xml) has 1 error

[ERROR]     Non-resolvable parent POM for com.uptodate.microservice.lightbulb:utd-lightbulb:3.1.1-pdot_224: Failure to find com.uptodate.microservice.core:utd-core-parent:pom:3.1.1-pdot_224 in 

http://nexus01p:8081/nexus/content/repositories/releases was cached in the local repository, resolution will not be reattempted until the update interval of releases has elapsed or updates are forced and 'parent.relativePath' points at wrong local POM @ line 6, column 10 -> [Help 2]

pom.xml is:

<parent>
		<groupId>com.uptodate.microservice.core</groupId>
		<artifactId>utd-core-parent</artifactId>
		<version>1.3.0</version>
</parent>

.mvn\jgitver.config.xml is:

<configuration>

</configuration>

ie, use all jgitver default values.

  • explain how to reproduce
mvn -P devopsProfileTest --file utd-lightbulb/ install

Here are the tags

$ git tag --list
v1
v2
v3.1.1

The complete pom.xml is

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
	<modelVersion>4.0.0</modelVersion>

	<parent>
		<groupId>com.uptodate.microservice.core</groupId>
		<artifactId>utd-core-parent</artifactId>
		<version>1.3.0</version>
	</parent>

	<groupId>com.uptodate.microservice.lightbulb</groupId>
	<artifactId>utd-lightbulb</artifactId>
	<version>1.0.0-SNAPSHOT</version>
	<packaging>pom</packaging>
	<name>UTD Lightbulb</name>
	<description>UTD Lightbulb</description>

	<modules>
		<module>utd-lightbulb-client</module>
		<module>utd-lightbulb-service</module>
		<module>utd-lightbulb-api</module>
	</modules>

	<properties>
		<java.version>1.8</java.version>
		<utd.starter.dependencies.version>2.4.0</utd.starter.dependencies.version>
	</properties>

	<dependencyManagement>
		<dependencies>
			<dependency>
				<groupId>com.uptodate.microservice.core</groupId>
				<artifactId>utd-starter-dependencies</artifactId>
				<version>${utd.starter.dependencies.version}</version>
				<type>pom</type>
			</dependency>
		</dependencies>
	</dependencyManagement>

	<scm>
		<developerConnection>scm:git:ssh://${scm.bb.user}@bitbucket.utd.com:7999/NG/microservicetemplate.git</developerConnection>
	  <tag>HEAD</tag>
  </scm>  	

</project>

nonQualifierBranches: Support for wild cards

I would like to deploy (mvn deploy -DperformRelease) from a release branch that has a name like "release/1.2.3".
This results in a version number like "1.2.3-release" - which oviously is not what I want.

Therefore I'd like to set "nonQualifierBranches" to something like "release/*"

Thinking about naming conventions: Maybe more Maven like?

In the sample in the documentation the lightweight is named "v1.1.0".
I have played around a bit and I will use tag names that end with "-SNAPSHOT" instead.
E.g.: "1.1.0-SNAPSHOT"

I think this is more Maven-like and easier to explain.
No code changes are required. Only updates to the documentation.

IDENTITY BranchNameTransformation still replaces dashes with underscores in branchname

Hi,

we use the following configuration (using IDENTITY transformation)
but dashes (-) are still replaced by underscores (_) in branch name

thnx

<configuration xmlns="http://jgitver.github.io/maven/configuration/1.0.0-beta"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://jgitver.github.io/maven/configuration/1.0.0-beta https://jgitver.github.io/maven/configuration/jgitver-configuration-v1_0_0-beta.xsd ">
    <mavenLike>false</mavenLike>
    <autoIncrementPatch>false</autoIncrementPatch>
    <useCommitDistance>false</useCommitDistance>
    <useDirty>false</useDirty>
    <useGitCommitId>false</useGitCommitId>
    <gitCommitIdLength>20</gitCommitIdLength>  <!-- between [8,40] -->
    <nonQualifierBranches></nonQualifierBranches> <!-- comma separated, example "master,integration" -->
    <useDefaultBranchingPolicy>false</useDefaultBranchingPolicy>
    <branchPolicies>
        <branchPolicy>
            <pattern>(.*)</pattern>                  <!-- regex pattern -->
            <!-- list of transformations to apply, if empty, defaults to REPLACE_UNEXPECTED_CHARS_UNDERSCORE, LOWERCASE_EN -->
            <transformations>                           
                <transformation>IDENTITY</transformation> <!-- transformation name, one of jgitver#fr.brouillard.oss.jgitver.BranchingPolicy#BranchNameTransformations -->
            </transformations>
        </branchPolicy>
    </branchPolicies>
   
  
</configuration>

Multi module project: Building only a sub module does not resolve versions for deps

Multi module setup.
Defining dependencyManagement of module versions in root pom.xml

When building only one sub module, the version for dependencies to other sub modules is not updated.

E.g.:

root/
module1
module2

"module2" depends on "module1". The version is defined as "${project.version}" in the root/pom.xml.
When building in "root", everything works as expected.

But when I change the directory to "module2" and call "mvn install", Maven tries (and fails) to download

Could not resolve dependencies for project module2:jar:3.14.0-SNAPSHOT: The following artifacts could not be resolved: module2:jar:0

Multi module project: does not adopt versions of dependencies

(using version 0.4.0)

I have the following folder structure:

.
├── lib
│   └── pom.xml
├── other
│   └── pom.xml
└── pom.xml

where lib is a dependency of other and all versions are set to 0.0.0 (the files are listed below). mvn install runs fine without jgitver-maven-plugin.

Adding jgitver support and tagging 1.1.0 results in the following problem:

  • lib:jar:1.1.0 gets build but
  • other still depends on lib:jar:0.0.0 and thus fails.

Is there a simple solution to solve the problem?

./pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>some.id</groupId>
  <artifactId>test</artifactId>
  <packaging>pom</packaging>
  <version>0.0.0</version>

  <modules>
    <module>lib</module>
    <module>other</module>
  </modules>
</project>

./lib/pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <parent>
        <artifactId>test</artifactId>
        <groupId>some.id</groupId>
        <version>0.0.0</version>
    </parent>

    <artifactId>lib</artifactId>
</project>

./other/pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <parent>
        <artifactId>test</artifactId>
        <groupId>some.id</groupId>
        <version>0.0.0</version>
    </parent>

    <artifactId>other</artifactId>

    <dependencies>
        <dependency>
          <artifactId>lib</artifactId>
          <groupId>some.id</groupId>
          <version>0.0.0</version>
        </dependency>
    </dependencies>
</project>

./.mvn/extensions.xml

<extensions xmlns="http://maven.apache.org/EXTENSIONS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/EXTENSIONS/1.0.0 http://maven.apache.org/xsd/core-extensions-1.0.0.xsd">
  <extension>
    <groupId>fr.brouillard.oss</groupId>
    <artifactId>jgitver-maven-plugin</artifactId>
    <version>0.4.0</version>
  </extension>
</extensions>

document possible release process

As a maven user reading jgitver-maven-plugin I want to read a brief article in which I quickly understand how I can release with jgitver & what benefits I can expect.

Document continuous delivery process

Before submitting an issue I have first:

  • searched for similar already existing issue
  • read the documentation and wiki

(if you have performed all the above, remove the paragraph and continue describing the issue with template below)

Issue

As a user I would like to be able to follow a prescriptive guide to have a continuous delivery pipeline.
Related with jgitver/jgitver#21.

Problems when releasing: Invalid signature

I have this problem with different projects.
Latest case: https://github.com/jschneider/com.cedarsoft.commons/releases/tag/7.4.0

I try to deploy to oss.sonatype.org but run into an "Invalid Signature" with my pom/pom.asc
What I could find out so far:

  • I am doing a "mvn clean deploy -DperformRelease"
  • target/commons-7.4.0.pom is the same as "pom.xml" (contains "0" as version number)
  • the signature in target/commons-7.4.0.pom is valid
  • the pom in "target/nexus-staging/staging/3755bb868da9a4/com/cedarsoft/commons/7.4.0" looks different. The version number has changed and some other changes can be found (new lines removed, changed order of scm tag)

So my guess is:

  • jgitver modifiers the pom.xml (adds the version number)
    • (why are other things than the version number changed?)
  • the original pom.xml is signed (with "0" as version number) and copied to target (why?)
  • the changed pom.xml is staged for deployment - but with the old signature

I have a single module project - there everything seems to work fine. I have taken a look into "target". There is the modified version of the pom.xml...

So I think the question is: Why does the unmodified pom.xml end up in the target dir?
I think this might be the root problem.

missing explicit compile dependency to commons-lang3

Issue

The plugin makes use of commons-lang3, coming from transitive dependencies, without declaring it.

version: 0.3.0-alpha3

usage context:

  • maven command line: maven 3.3.3

Problem description:

On some internal jenkins slave running maven-3.3.3 a NoClassDefFoundError is thrown:

[jgitver] Running batch script
D:\DEV\CI\WS\ARCHITECTURE\HMEN_DEV_MULTIBRANCH_kapinga\jgitver>D:\DEV\CI\TOOLS\MAVEN\maven-3.3.x\bin\mvn -version 

D:\DEV\CI\WS\ARCHITECTURE\HMEN_DEV_MULTIBRANCH_kapinga\jgitver>D:\DEV\CI\TOOLS\MAVEN\maven-3.3.x\bin\mvn.cmd -version 
Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06; 2015-04-22T13:57:37+02:00)
Maven home: D:\DEV\CI\TOOLS\MAVEN\maven-3.3.x\bin\..
Java version: 1.8.0_74, vendor: Oracle Corporation
Java home: D:\DEV\CI\TOOLS\JDK-x32\jdk1.8\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows server 2012 r2", version: "6.3", arch: "x86", family: "dos"
[Pipeline] bat
[jgitver] Running batch script

D:\DEV\CI\WS\ARCHITECTURE\HMEN_DEV_MULTIBRANCH_kapinga\jgitver>D:\DEV\CI\TOOLS\MAVEN\maven-3.3.x\bin\mvn -Prun-its clean verify 

D:\DEV\CI\WS\ARCHITECTURE\HMEN_DEV_MULTIBRANCH_kapinga\jgitver>D:\DEV\CI\TOOLS\MAVEN\maven-3.3.x\bin\mvn.cmd -Prun-its clean verify 
[INFO] Scanning for projects...
[INFO] jgitver-maven-plugin is about to change project(s) version(s)
---------------------------------------------------
constituent[0]: file:/D:/DEV/CI/TOOLS/MAVEN/maven-3.3.x/bin/../lib/aether-api-1.0.2.v20150114.jar
constituent[1]: file:/D:/DEV/CI/TOOLS/MAVEN/maven-3.3.x/bin/../lib/aether-connector-basic-1.0.2.v20150114.jar
...
constituent[40]: file:/D:/DEV/CI/TOOLS/MAVEN/maven-3.3.x/bin/../lib/wagon-provider-api-2.9.jar
constituent[41]: file:/D:/DEV/CI/TOOLS/MAVEN/maven-3.3.x/bin/../conf/logging/
---------------------------------------------------
Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/lang3/StringUtils
    at fr.brouillard.oss.jgitver.JGitverModelProcessor.provisionModel(JGitverModelProcessor.java:134)
    at fr.brouillard.oss.jgitver.JGitverModelProcessor.read(JGitverModelProcessor.java:82)
    at org.apache.maven.model.building.DefaultModelBuilder.readModel(DefaultModelBuilder.java:529)
    at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:269)
    at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:469)
    at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:438)
    at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:401)
    at org.apache.maven.graph.DefaultGraphBuilder.collectProjects(DefaultGraphBuilder.java:419)
    at org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor(DefaultGraphBuilder.java:410)
    at org.apache.maven.graph.DefaultGraphBuilder.build(DefaultGraphBuilder.java:83)
    at org.apache.maven.DefaultMaven.buildGraph(DefaultMaven.java:491)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:219)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
    at org.apache.maven.cli.MavenCli.execute(MavenCli.java:862)
    at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:286)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:197)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: java.lang.ClassNotFoundException: org.apache.commons.lang3.StringUtils
    at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
    at org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
    at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
    at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
    ... 25 more
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
[BFA] Scanning build for known causes...
[BFA] No failure causes found
[BFA] Done. 0s
ERROR: script returned exit code 1
Finished: FAILURE

Release Notes

Could you create some release notes?
I have no idea what exactly has changed in 0.4.0. Would be helpful to learn about new features and bugfixes.

Configuration option 'useDirty' doesn't make any effect.

extensions.xml

<extensions xmlns="http://maven.apache.org/EXTENSIONS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:schemaLocation="http://maven.apache.org/EXTENSIONS/1.0.0 http://maven.apache.org/xsd/core-extensions-1.0.0.xsd">
    <extension>
        <groupId>fr.brouillard.oss</groupId>
        <artifactId>jgitver-maven-plugin</artifactId>
        <version>0.3.0</version>
    </extension>
</extensions>

jgitver.config.xml

<configuration>
    <mavenLike>true</mavenLike>
    <useDirty>false</useDirty>
</configuration>

The calculated version doesn't contain the 'dirty' as qualifier.

cleanup old plugin code

before 1.0.0 release, a cleanup of the unnecessary old code need to be done to ease community find its way in the code.

travis-ci build is not maven core extension compatible

the projects currently uses travis-ci as its continuous integration system.
With the introduction of the maven core extension usage, we are not able to build anymore from there.

  • either we find a way to have travis working (docker image, ...)
  • or we move to another CI build system

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.