Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Dec 03 13:52

    McFoggy on master

    Update README Merge pull request #110 from cc… (compare)

  • Nov 23 21:25

    McFoggy on integration

    checkout all commits for github… (compare)

  • Nov 23 21:21

    McFoggy on integration

    add github actions script (compare)

  • Nov 23 19:54

    McFoggy on 0.13.0

    (compare)

  • Nov 23 19:54

    McFoggy on master

    update dependencies to remove v… introduce compatibility classes… (compare)

  • Oct 28 07:15

    McFoggy on master

    Fix README to point to correct … Merge pull request #31 from nun… (compare)

  • Jul 28 16:05

    McFoggy on integration

    (compare)

  • Jul 28 16:05

    McFoggy on issue-85

    (compare)

  • Jul 28 16:04

    McFoggy on issue-106

    (compare)

  • Jul 28 16:04

    McFoggy on pr-108

    (compare)

  • Jul 28 16:03

    McFoggy on master

    introduce caching of maven arti… (compare)

  • Jul 28 15:43

    McFoggy on master

    New SCRIPT strategy Default scenario tests for SCRI… Other tests for SCRIPT strategy and 8 more (compare)

  • Jul 28 15:38

    McFoggy on pr-108

    New SCRIPT strategy Default scenario tests for SCRI… Other tests for SCRIPT strategy and 8 more (compare)

  • Jul 28 15:29

    McFoggy on pr-108

    New SCRIPT strategy Default scenario tests for SCRI… Other tests for SCRIPT strategy and 8 more (compare)

  • Jul 28 11:40

    McFoggy on master

    add forceComputation in README … (compare)

  • Jul 23 14:53

    McFoggy on master

    add travis-ci badge (compare)

  • Jul 23 14:53

    McFoggy on 0.10.0-rc03

    (compare)

  • Jul 23 14:33

    McFoggy on master

    use java 8 as target and source… introduce travis build file fi… (compare)

  • Jul 23 14:21

    McFoggy on master

    update gradle with useSnapshot update readme to document useSn… (compare)

  • Jul 23 13:45

    McFoggy on master

    use gradle-6.5.1 make gradlew for tests executab… use new version of changelog pl… and 11 more (compare)

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
Gerard Bosch
@gerardbosch

Hi there! Does anybody know if in Spring Boot the following "automatic property expansion at build time" will work using jgitver?

app.encoding=@project.build.sourceEncoding@
build.version=@project.version@

Will the app.java.version be captured properly?

Reference: https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#howto-automatic-expansion

Cool project & thx!!

P.S. The above is intended to be part of the bootstrap.properties of spring boot.
Gerard Bosch
@gerardbosch
(edited) Sorry I meant build.version=@project.version@
Matthieu Brouillard
@McFoggy
if it is at build time, it should work if the springboot plugin is written correctly
Gerard Bosch
@gerardbosch
Thanks @McFoggy I guessed so, but just to be sure if anyone had any experience about it. I will try to introduce jgitver in one of my work projects. Just wanted to be sure that breaks nothing and I noticed that property in the bootstrap.properties.
Matthieu Brouillard
@McFoggy
the springboot plugin should lookup values from the POM (as in-memory object model) ; if so it will work. If on the opposite it tries to do things on its own by reading the pom.xml file, then it will read a wrong value.
Matthieu Brouillard
@McFoggy
@gerardbosch just tested it with a generated springboot app from spring initialzr:
  • added : project.version=@project.version@ in application.proerties
  • mvn package
  • open the generated jar , look BOOT-INF\classes\application.properties , version is 0.0.1-SNAPSHOT as in the pom.xml file
  • add jgitver with the .mvn\extensions.xml file
  • mvn package
  • open the generated jar , look BOOT-INF\classes\application.properties , version is now the one generated by jgitver 0.0.0-NOT_A_GIT_REPOSITORY
Matthieu Brouillard
@McFoggy
otherwise, and for those not using spring, standard resource filtering will work for sure
Gerard Bosch
@gerardbosch
Great news! Thanks a lot Matthieu for making the test :)
Gerard Bosch
@gerardbosch

Hi, I'm looking at the docs if is there a way to not qualify a branch that matches a wildcard (or regex). In my particular case I would like to not qualify release/ branches. How would be the way to achieve sth like this:

<nonQualifierBranches>master,release/*</nonQualifierBranches>

N.B. Using the Maven strategy

Gerard Bosch
@gerardbosch
Just to clarify, what I waht is that the version computed when in branch e.g. release/1.0.0 is 1.0.0 and not 1.0.0-release_1.0.0
Gerard Bosch
@gerardbosch

I've finally managed to do it using a <branchPolicy> with IGNORE, but in this case I observe that I need to explicitly define a policy with IGNORE for each branch I do not want to qualify (master, develop, release). And that when configuring it this way, the <nonQualifierBranches> takes no longer effect.

I guess this is the intended way to achieve it. But I'm wondering myself if nonQualifierBranches> could accept regex or wildcards.
If I'm wrong at some point, anybody can correct me :)

Gerard Bosch
@gerardbosch
Hello @McFoggy , do you have any idea about my doubts/question above? :pray: thx!! :)
htrost
@htrost

Hi...if Im setting an empty JGITVER_BRANCH through export JGITVER_BRANCH= jgitver adds a - to the version.

foo@foo MINGW64 /c/model ((0.2.6))
$ export JGITVER_BRANCH=

foo@foo MINGW64 /c/model ((0.2.6))
$ mvn validate
[INFO] Using jgitver configuration file: C:\model\.mvn\jgitver.config.xml
[INFO] Using jgitver-maven-plugin [1.5.1] (sha1: e45d1669b39cedb98720dd33cc14d0185b455ca1)
[INFO]     version '0.2.6-' computed in 277 ms
[INFO]
[INFO] Scanning for projects...
[INFO] jgitver-maven-plugin is about to change project(s) version(s)
[INFO]     ngn::model::0 -> 0.2.6-
[INFO]
[INFO] ----------------------< ngn:model >-----------------------
[INFO] Building model 0.2.6-
[INFO] --------------------------------[ jar ]---------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  0.554 s
[INFO] Finished at: 2020-07-24T15:28:49+02:00
[INFO] ------------------------------------------------------------------------

Is this the expected behavior?

htrost
@htrost

I m using jgitver within gitlab and I now managed to get a workaround.

before_script:
  - if [ -z "$CI_COMMIT_BRANCH" ]]; then export JGITVER_BRANCH=$CI_COMMIT_BRANCH; fi

if jgitver doesnt add the - when JGITVER_BRANCH set to "" it would be easier and I could just do

JGITVER_BRANCH: $CI_COMMIT_BRANCH
Marvin Kruse
@gimmebytes
Hi @McFoggy! We're using the jgitver maven plugin and I've a quick question: is it somewhat possible in maven multi module project to have different versions per module set, based on specific tags used for calculating the actual versions?
I was thinking of structuring an internal API alongside with a spring boot starter and dropwizard bundle in the same repo, but the API and the starter and bundle can have different versions - if the plugin cant do that I might think about using git sub modules or such to reach the desired behaviour
Jörn Guy Süß
@jgsuess_gitlab
Hi!
I have a (possibly silly) question. Within a multi-module project, if I have dependencies among the different modules, how do I give the version number of the module I depend on. I have tried using <version>0</version>. That fails in POM resolution. Now I am using <version>${jgitver.calculated_version}</version>, this works for the build, but it means my IDE complains about an undeclared value and cannot resolve look-ups into the other code any more. Is this normal behaviour or am I missing something?
Marvin Kruse
@gimmebytes
@jgsuess_gitlab I think <version>${project.version}</version> is the thing you're looking for!
Jörn Guy Süß
@jgsuess
Oh man, the patently obvious. Thanks.
Marvin Kruse
@gimmebytes
@jgsuess_gitlab you're welcome (-:
Gerard Bosch
@gerardbosch

Hi, I've got the same question of @jgsuess_gitlab but my structure is like parent-pom <--- microservice where they are not packaged together (don't belong to the same build unit/aggregator) and have different versions. In parent-pom I have a dependency with the same version of parent-pom to another component. But if I declare it using something like ${project.version} when I compile microservice, the actual value of project.version is not the one of parent-pom but the microservice one.

I guess using ${jgitver.calculated_version} will be the same.
I'm looking how can I make it work without hardcoding the value of the version for that dependency so I can fully automate it with JGitVer. Can't find a Maven property that refers to "this exact POM version". Any idea? Thx!

Matthieu Brouillard
@McFoggy
Sorry for the loooooong absence.
@jgsuess_gitlab the answer is not that obvious because of the dynamic nature of versions with jgitver.
But for sure the answer within the multi-module is <version>${project.version}</version>. On the other hand I'd tend to deactivate jgitver inside the IDE.
@gerardbosch do you have a minimal example of what you want to achieve ?
@gimmebytes I do not see any possibility to achieve something like what you exposed. Even submodules will not help in this case I think.
Matthieu Brouillard
@McFoggy
also yesterday I have integrated and released the jgitver/jgitver#108 initiated by Cedric.
It lacks docs but for sure it will allow a lot of freedom.
see jgitver-0.13.0 & jgitver-maven-plugin-0.6.0
Gerard Bosch
@gerardbosch

Hi @McFoggy , I hope everything is fine.
I've tried to create a Gist with a sample structure of what I mean, I hope it helps to have an idea.
I think it is not a strictly speaking JGitVer question, but probably a Maven one. I tagged the problem with <!-- PROBLEM EXAMPLE -->.

https://gist.github.com/gerardbosch/cffd7bf8eaf6be4ea658e3599cb04e98

Matthieu Brouillard
@McFoggy
@gerardbosch please checkout https://github.com/jgitver/jgitver-samples/tree/external-microservice/external-microservice and tell me if the project structure fits what you expect (without jgitver at the moment).
do not hesitate to PR to update it
Gerard Bosch
@gerardbosch
Hello @McFoggy , thank you very much! Yes, the project structure you've created fits the use case I'm trying to solve. But, the version for the dependency in the application should not be there (it is a managed dependency). I've updated it and issued a PR.
I think that should be the right structure for the sake of the problem :)
28 replies
You will see the commit:
Remove dependency version for managed dependencies The version of the library is provided in a<dependencyManagement>block somewhere in the parent chain of this microservice application.
YaytayAtWork
@YaytayAtWork
I would like to have SNAPSHOT versions only when the repo is dirty.
Any builds that come from our CI should have a releasable version.
At the moment I don't think it's possible to get this because there aren't any conditional expressions in the pattern language.
Am I right, or is there a way around this?
Thanks
Matthieu Brouillard
@McFoggy
@YaytayAtWork you're right out of the box this is not possible but with the new SCRIPT strategy you can probably do something