Added a new option to the version number to indicate whether the workspace is clean by theit · Pull Request #143 · maveniverse/nisse (original) (raw)

The dynamic version property can now indicate whether the local workspace is clean or dirty, i.e. contains modifications.

Changes:

introduced nisse.jgit.clean property that is true|false and is present always
based on config nisse.source.jgit.appendDirty (by def false) will append -DIRTY to dynamicVersion
added ITs (dirty-clean that run on clean git checkout and dirty-dirty that runs on dirty git checkout)

Fixes #142

The dynamic version property can now indicate whether the local workspace is clean or dirty, i.e. contains modifications.

formatting issue, pls run mvn spotless:apply and push reformatted source

Will update in parent soon maveniverse/parent#28

formatting issue, pls run mvn spotless:apply and push reformatted source

Will update in parent soon maveniverse/parent#28

Fixed. I was sure I already did that...

I personally do new features like this:

by default they are disabled (as all IT verison assertion failed due -DIRTY) - "least surprise"
add IT that enables new feature and perform assertions with new expectations

Also, expose "clean" as property, may be handy

I personally do new features like this:

by default they are disabled (as all IT verison assertion failed due -DIRTY) - "least surprise"

add IT that enables new feature and perform assertions with new expectations

Ok, sure, that makes sense :-)
I'm changing the new feature to be off by default and try to add a corresponding IT.

It's all already in, plus added ITs. Pls take a peek and comment here.

If you are fine with changes, am ready to release 😉

Wow, that was pretty quick :-)
I'm just running a local build with "-Prun-its" in the background. One thing I saw is that using Java 25 gives a couple of errors when performing the ITs: Groovy complains about unsupported class file major version 70. However using Java 21 works...

Yes, groovy pulls asm and hence lags with latest Java versions. Given those are tests, I think we are fine here.

Hm, Java 25 gives errors? ITs pass on Java 25, so let me try locally... (maybe you meant warnings? or Java 26?)

Note: spotted you mention class file major version 70, so that is Java 26.

All fine with Java 25:

[cstamas@angeleyes nisse (jgit-add-dirty)]$ mvn -v
Apache Maven 3.9.14 (996c630dbc656c76214ce58821dcc58be960875b)
Maven home: /home/cstamas/.sdkman/candidates/maven/current
Java version: 25.0.2, vendor: Eclipse Adoptium, runtime: /home/cstamas/.sdkman/candidates/java/25.0.2-tem
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "6.19.8-200.fc43.x86_64", arch: "amd64", family: "unix"
[cstamas@angeleyes nisse (jgit-add-dirty)]$

no errors or warnings in fact. Are you sure you used Java 25?

Doing a release, new PR and new release can happen anytime, so we are fine.

All fine with Java 25:

[cstamas@angeleyes nisse (jgit-add-dirty)]$ mvn -v
Apache Maven 3.9.14 (996c630dbc656c76214ce58821dcc58be960875b)
Maven home: /home/cstamas/.sdkman/candidates/maven/current
Java version: 25.0.2, vendor: Eclipse Adoptium, runtime: /home/cstamas/.sdkman/candidates/java/25.0.2-tem
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "6.19.8-200.fc43.x86_64", arch: "amd64", family: "unix"
[cstamas@angeleyes nisse (jgit-add-dirty)]$

no errors or warnings in fact. Are you sure you used Java 25?

Yes, that was on Windows 11 on my employer's workspace. But perhaps not with all changes you committed in the meantime. Anyway, I'm fine with merging if you don't mind :)

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})