by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jan 31 18:13

    dependabot[bot] on maven

    Bump checkstyle from 8.21 to 8.… (compare)

  • Jan 02 15:47

    McFoggy on master

    Update README.md (compare)

  • Jan 02 15:26

    McFoggy on integration

    Update README.md (compare)

  • Nov 29 2019 09:25

    McFoggy on 0.11.3

    (compare)

  • Nov 29 2019 09:22

    McFoggy on 0.11.3

    (compare)

  • Nov 29 2019 09:22

    McFoggy on 0.12.0

    (compare)

  • Nov 29 2019 08:50

    McFoggy on master

    Add DIRTY_TEXT metadata add explicit tests for DIRTY_TE… (compare)

  • Nov 29 2019 07:54

    McFoggy on integration

    Add DIRTY_TEXT metadata add explicit tests for DIRTY_TE… (compare)

  • Nov 25 2019 07:48

    McFoggy on master

    Bump picocli version (4.0.0 and… Picocli parse depcrecated in fa… Add branchPolicy configuration and 3 more (compare)

  • Nov 25 2019 07:42

    McFoggy on integration

    add git commit for tags add unit test (compare)

  • Nov 25 2019 07:36

    McFoggy on integration

    Bump picocli version (4.0.0 and… Picocli parse depcrecated in fa… Add branchPolicy configuration and 1 more (compare)

  • Nov 04 2019 07:34

    McFoggy on master

    for travis-ci build, use Ubuntu… add snapshot usage to configura… add @SuppressWarnings annotatio… and 1 more (compare)

  • Nov 04 2019 07:20

    McFoggy on integration

    add @SuppressWarnings annotatio… add CLI parameters to control p… (compare)

  • Nov 04 2019 07:16

    McFoggy on integration

    for travis-ci build, use Ubuntu… add snapshot usage to configura… (compare)

  • Nov 04 2019 07:08

    McFoggy on integration

    improve performance and prevent… Add snapshot Use travis trusty for oraclejdk8 (compare)

  • Jul 16 2019 14:10

    McFoggy on rc01

    compute jgitver version during … update jgitver version, do not … (compare)

  • Jul 13 2019 16:38

    McFoggy on master

    update with 0.9.1 version (compare)

  • Jun 21 2019 07:42

    McFoggy on 0.9.1

    (compare)

  • Jun 21 2019 07:42

    McFoggy on master

    integrate jgitver fix with late… add sonatype repository for dep… (compare)

  • Jun 21 2019 07:33

    McFoggy on 0.11.2

    (compare)

anessi
@anessi

I have tested the version 0.10.0-rc01 of the plugin on two of our repositories. It works fine and solves the mentioned problem.
I left a comment on the issue: https://github.com/jgitver/gradle-jgitver-plugin/issues/25#issuecomment-513186424

One related question: is the problem that the version calculation is executed multiple times on multi module projects addressed as well with this change (see jgitver/jgitver#82 (comment))? I could not notice any difference in execution time before and after this change.
Should I create a new issue for this?
What would also be great is a parameter to enable debug logging on the library. I did not find an easy way how to see if the problem mentioned (too many executions of version calculation) above still exists. Is this possible somehow?

Matthieu Brouillard
@McFoggy
unfortunately there is no logging system int he core library at the moment.
please open an issue on the gradle project with a small reproducer
for the multiple execution issue
anessi
@anessi
I did some more investigation and created a new plugin test that shows if jgitver gets initialized multiple times. See https://github.com/anessi/gradle-jgitver-plugin/pull/new/multimodule_multiple_initializations (needs some cleanup, but maybe the general plugin test approach can be of use)
The good news is that it actually works fine. The problem was that we applied the plugin in the allprojects {} block which results in multiple calls to apply of the plugin. Moving this to the root build file fixes the issues. The only thing that does not work anymore is to call e.g. gradle submodule1:version as the task is not found on sub module level. Anyway, that shouldn't be a problem.
Matthieu Brouillard
@McFoggy
@anessi ok thanks for clarification
Julien Hattier
@julien.hattier_gitlab
Hi Matthieu :-) Just checked out jgitver and it looks very nice so far.
I was wondering if you ever thought of making a plugin version (not an extension) that would use the Maven CI friendly variables for version ?
Matthieu Brouillard
@McFoggy
Hi Julien, I think you mean https://maven.apache.org/maven-ci-friendly.html isn't it?
If so then no I did not look that much in using them.
Would you see some benefits in using them?
Can you describe your use case/need?
Julien Hattier
@julien.hattier_gitlab
I believe the direct benefit would be to avoid extensions, that are not fully contained in a parent POM file for example.
It would also make the POM look nice, with version=${revision}, and the role of the jgitver plugin would be to fill up the revision variable
In my case, we are trying to make sure creating a project comes with default template/rules, or that you could update those rules mainly by changing a parent POM content. Having to make sure one goal secures the .mvn/extensions.xml file is just an additional concern, but not a huge obstacle either.
Julien Hattier
@julien.hattier_gitlab
Let me know if I'm taking the wrong path in my thinking there
Matthieu Brouillard
@McFoggy

POM look nice

in my projects I set it to 0.

for the rest, I understand that you would like to enforce the jgitver usage by a corporate parent pom. Unfortunately jgitver is defined as a core extension for a good reason : it is (or at least was) the only way to correctly update the Project Object Model (in memory representation of the pom.xml).
Gerard Bosch
@gerardbosch
Hi there, is there any problem using jgitver for a project that depends on a higher level corporate parent POM?
Matthieu Brouillard
@McFoggy
with the quite recent introduction in 3.5.0-beta-1 of the CI friendly properties perhaps there is another way. But honestly I do not know where the evaluation of those properties is done but I would bet it is somewhere deep in the core

is there any problem using jgitver for a project that depends on a higher level corporate parent POM

it should not

Gerard Bosch
@gerardbosch
:+1:
Matthieu Brouillard
@McFoggy
@julien.hattier_gitlab a compromise that could help such usage in corporate world would be to switch the configuration from a dedicated file to a configuration section of a plugin (without explicit goal definition). But in this case, there would be a kind of duplication of the declaration of jgitver. But we could give it a try...
other way of enforcing configuration/usage:
  • a plugin that checks/configure the .mvn folder
  • a docker image for building (with prepared .mvn folder)
  • ...
acnesiac
@acnesiac
hi, a question why does jgiterver tries to changes product version to snapshot?
is this a natural behavior and how to stop it
jgitver-maven-plugin is about to change project(s) version(s) com.gm.gcc.cvc_162609.sales::catalog-retail::0.0.2 -> 0.0.2-SNAPSHOT
Matthieu Brouillard
@McFoggy
@acnesiac hi ; thanks for your interest in the project. For maven projects, producing snapshots for non tagged commits is the default behavior of jgitver. This can be changed by changing the configuration (https://github.com/jgitver/jgitver-maven-plugin#configuration)
you'll have to first switch to <strategy>CONFIGURABLE</strategy>and then play with the other parameters to adapt to what you want
Matthieu Brouillard
@McFoggy
During the past days I received several contributions which lead in the delivery of jgiver-0.11.3 and to new documentation on https://jgitver.github.io/
many thanks to Thibaud aka Zomzog, Jack and all the community
JaydeepUniverse
@JaydeepUniverse

Hi All, I'm new to this jgitver. I've simple configuration as " <autoIncrementPatch>true</autoIncrementPatch>" but when I do mvn validate patch version is not incrementing, please advise

plugin extension file version - 1.5.1
config file

<configuration xmlns="http://jgitver.github.io/maven/configuration/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://jgitver.github.io/maven/configuration/1.0.0 https://jgitver.github.io/maven/configuration/jgitver-configuration-v1_0_0.xsd">
<autoIncrementPatch>true</autoIncrementPatch>
</configuration>

latest i've git tagged 2.0 then next version built 2.0.1-SNAPSHOT but after all changes same version is built, its not like 2.0.2-SNAPSHOT, 2.0.3-SNAPSHOT
werkins
@werkins
Hi guys! First of all, thanks for this fantastic project, it is a huge improvement in the automatic versioning field. In my current project we use maven and I would like to only use annotated tags and drive the next version calculation based on branch names, i.e. assuming master is tagged as 1.0.0, bugfix/ branches would just increment the patch version 1.0.1-SNAPSHOT and feature/ would increment the minor 1.1.0-SNAPSHOT; however, I haven' been able to configure this behaviour, not even using the pattern strategy. Could you please confirm if this is possible and how? Thanks in advance!
Matthieu Brouillard
@McFoggy

@JaydeepUniverse
In maven world, a version under development is by default a SNAPSHOT. That means that each commit for version Vx that does not represent a new version is named Vx-SNAPSHOT.

Then when you use jgitver via maven plugin it uses a default configuration tha respect the previous sentence.
The autoIncrementPatch attribute means that the base version (normally the one of latest tag found) is taken and the patch number is incremented by one. If the commit is a standard one (not a release with a tag) then -SNAPSHOT is appended to that.
In your case, with autoIncrementPatch=true, every commit on top of tag 2.0 will have the version 2.0.1-SNAPSHOT.

If you want distinct commit number for each commits then you can use CONFIGURABLE strategy:

<strategy>CONFIGURABLE</strategy>
<autoIncrementPatch>true</autoIncrementPatch>
<useCommitDistance>true</autoIncrementPatch>

In your example, the version on top of tag 2.0 would have been 2.0.1-1, 2.0.1-2, 2.0.1-3, ...

Matthieu Brouillard
@McFoggy
@werkins there is no solution currently to do it out of the box. The only way to do it would be to tag (lightweight probably) the first commit of each branch.
JaydeepUniverse
@JaydeepUniverse

@McFoggy Thanks for answer. I've explored jgitver and getting versions now as 2.0.1-1, 2.0.1-2, 2.0.1-3.. that seems fine at some extent.. and I'd like to continue to use jgitver but with -SNAPSHOT until I define release version to promote for prod deployment using git tag and then jgitver take care and again start with -SNAPSHOT.. I'm using jfrog artifactory to store artifacts and images built within maven process, now without -SNAPSHOT versions like 2.0.1-1 would automatically upload to 'release' type repository, which we use to store only artifacts which will be going to use for prod deployment, and in this repo there isn't any purging mechanism for storage control whereas we have for 'snapshot' type repo with purging configuration, so before we decide for promotion of artifact all should go to 'snapshot' type repo with -SNAPSHOT suffix..

please explain how to achieve this solution with jgitver usage as well OR i'd like to hear any alternate versioning strategy if you might have for your applications as well using jgitver, i'd like to explore the same... thanks

JaydeepUniverse
@JaydeepUniverse
2 more questions - how this increment number is calculated ? because I've multibranch jenkins pipeline in which created new branch for jgiver configuration and it has started version like 1.0.1-32 and so on..
is it possible to use jenkins build number as patch increment number ?
Matthieu Brouillard
@McFoggy
@JaydeepUniverse try to think about your process. On one hand you want incremental numbers and on the other hand you want SNAPSHOTS. This is a bit contradictory. If what you want is not to pollute the "release" repository, then just create another one in artifactory to push items when you're not on a tag. This way you will push X.Y.Z-n to repository R1 and you will push X.Y.Z to repository R2. Both repository would be of type 'release' from artifactory point of view but yu could then have different purge policies.

how this increment number is calculated

it is the distance between the HEAD and the commit that served as base for the version computation (normally the one one holding the tag)

is it possible to use jenkins build number as patch increment number ?

yes it is possible whe using te mode 'PATTERN' mode, see https://jgitver.github.io/#_pattern_mode

this mode is not very documented and used but was thought to offer some extended configuration capabilities
mheck136
@mheck136
Hi there, we want to use jgitver, but we're running into some problems with multi module mavnen builds. We have a parent project with multiple child modules (maven modules and parent relations), all in one repository. We'd like to build the parent and the child modules all together using the same jgitver-generated version. It almost works. The only thing, that doesn't work is setting the version of the parent module in the child modules to the version generated by jgitver. Is there a setting to accomplish that?
Matthieu Brouillard
@McFoggy
@mheck136 what did not work for you ? the materialized poms should contain the good version.
look at the sample project (https://github.com/jgitver/jgitver-samples) you'll find a multi-module there. Do a mvn install and check the published files in the MLR. They should contain the computed version.
Brendan Lawlor
@blawlor
Hi - has anyone had issues running jgitver when using mvnw? I run ./mvnw valdiate as recommended by the docs, but it's as if the extensions were completely ignored.
Matthieu Brouillard
@McFoggy
which maven version is behind your wrapper ?
Brendan Lawlor
@blawlor
Sorry for the noise - the wrapper itself was quite out-of-date. All good now :-)
Matthieu Brouillard
@McFoggy
:+1:
Brendan Lawlor
@blawlor
I wonder is it possible, or would it be possible, to have a different value for autoIncrementPatch depending on what branch you are on?
Here's what I'd like to have in place: When I'm on a release branch (identified using the branchPolicy regex), I'd like the patch increment to happen.
But when I'm on master or develop, then I'd prefer the minor release number to be autoincremented.
At the moment, to get this to happen, then I have to add a simple tag to master or develop to give the hint to jgitver. But this requires an extra commit on the master or develop, and avoiding useless commits is one of the things that attracts me to jgitver.
Brendan Lawlor
@blawlor
(the reason for the extra commit is to have a place to attach the simple tag, which is not part of the history of the release branch)
Matthieu Brouillard
@McFoggy
@blawlor there is no possibility for this in current implementation