Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for dynamic versioning (and possibly Maven CI Friendly) #9

Closed
jimisola opened this issue Sep 3, 2024 · 10 comments · Fixed by #20
Closed

Add support for dynamic versioning (and possibly Maven CI Friendly) #9

jimisola opened this issue Sep 3, 2024 · 10 comments · Fixed by #20

Comments

@jimisola
Copy link
Contributor

jimisola commented Sep 3, 2024

Other langauges and build systems have something called dynamic versioning which means that the project version can be left out in the project configuration file (here: pom.xml) and instead the version is set dynamically based on tag in git repo. It the current comment does not have tag with valid semantic version then the nearest is found and the number of commits to that commit from HEAD will be build number.

Due to a limitation in Maven the current "solution" of MojoHaus Versions Maven plugin goal does not work. @cstamas described it here and as a the idea is to migrate the MojoHaus Versions Plugin goal to nisse as core extension.

The current goal has few optional parameters:

  • appendSnapshot: Whether the SNAPSHOT qualifier shall be apppended or not. Default: true
  • defaultVersion: The default version used when SCM repository has no commit or no version tag.
  • propertyName: The name of the property that will contain the resolved version. Default: revisionUser
  • useVersion: Use this version instead of resolving from SCM tag information.

I'm currently not sure how configuration can be made for a core extension. Any input here would be appreciated.

Also, I'm not sure if there is any benefit of using ${revision} as Maven CI Friendly.

@jimisola
Copy link
Contributor Author

jimisola commented Sep 3, 2024

My plan is to hopefully start with this next week when we gave a new sprint a work and then provide a PR.

@cstamas
Copy link
Member

cstamas commented Sep 3, 2024

Just some context: idea with Nisse is "Maven 3 CI friendly versions done right", is just a showcase with some usable extensions.

Problems with vanilla Maven CI Friendly versions:

  • has limited "vocabulary" (just 3 predefined values)
  • allows use of those prefefined properties in project.version
  • biggest problem: does not ensure that interpolation did happen, hence Maven either install/deploy unusable POMs, or you need hoops and loops w/ flatten etc.

Nisse (extension) approach is:

  • allows any property that exists (is defined and has a value)
  • inlines detected properties into POM, hence vanilla install/deploy works, no need for hoops and loops
  • introduces a simple API for property sources
  • implements several simple sources (like "demo")

Word of warning: Nisse features will most probably be absorbed into Maven 4, while Nisse remains Maven 3 extension. But be prepared for the future 😄

@gnodet

@cstamas
Copy link
Member

cstamas commented Sep 3, 2024

@jimisola
Copy link
Contributor Author

jimisola commented Sep 9, 2024

We will jump on Maven 4 as soon as other plugins/extensions that we use have support for it.

There seem to have been a lot of activity around CI Friendly builds last 1-2 weeks as I followed the reference you provided.
How far out is Maven 4 and do you expect Nisse features to be absorbed into the initial stable release of Maven 4?

Also, I reckon that the "dynamic versioning" goal that I contributed to MojoHaus Versions Maven plugin would still have to be implemented for Maven 4 and it would not be made available as default property sources in core but still as an extension. Correct?

I've allocated time for this during this and next work week, but I have no idea if enough time has been allocated since this something completely new for me.

@jimisola
Copy link
Contributor Author

@cstamas What is your suggestion regarding implementing it for Maven 3.9? Is it a waste of time and better to do it for Maven 4. I can see that gnodet is working a lot on CI Friendly for Maven 4.

@cstamas
Copy link
Member

cstamas commented Sep 17, 2024

Nisse is for M3, and Nisse functionality is "built in" into M4 (this was the idea, need to verify it with @gnodet )

@jimisola
Copy link
Contributor Author

Ok. So, if I write it now for M3 then it should be quite easy to migrate to M4 then. Thanks!

@lfvjimisola
Copy link
Contributor

@cstamas FYI, I just found https://github.com/pascalgn/properties-maven-extension. It's not exactly what we need (resolving a correct version from git tags and commits) but similar. However, I think it's a mix of Nisse (with the properties) and the dynamic versioning part.

@lfvjimisola
Copy link
Contributor

lfvjimisola commented Oct 2, 2024

@cstamas So, I've started on the code and it works but no PR yet: https://github.com/jimisola/nisse/pull/new/feature/add_dynamic_versioning)

I have a few questions if you have the time:

  1. the mojohaus goal made use of VersionsInformation which is MIT License. Is that an issue?
  2. When running mvn eu.maveniverse.maven.plugins:toolbox:dump -Dverbose -N on nisse no USER PROPERTIES are shown, but with 'X there is the log message "Nisse injecting n properties into User Properties" and if I add a log statement to NisseConfiguration I see all the properites. What are they not shown with dump?
  3. there are things in the extension that needs to be configurable but .mvn/extensions.xml doesn't allow for a (that .m2/extensions.xml with would have been very convenient). Since, it also needs to work with -Dmaven.ext.class.path= I reckon it either environment variables or system properties. how about e.g.

-Dnisse.jgit.appendSnapshot=false

@jimisola
Copy link
Contributor Author

jimisola commented Oct 3, 2024

@cstamas Sadly, it's quite cumbersome to then activate the extension on local dev machine and in pipeline since it's not possible to:

  1. point out extensions.xml like we can do with e.g. settings.xml and --settings
  2. can't add extensions to settings.xml

@cstamas cstamas closed this as completed in 3561549 Oct 7, 2024
cstamas added a commit that referenced this issue Oct 16, 2024
Git has two types of tags, lightweight and annotated: https://git-scm.com/book/en/v2/Git-Basics-Tagging

The previous version only handled lightweight and not annotated tags.

This PR includes:

* fix for annotated tags including an integration test for it (see comment for more info)
* extracted lastCommit/latestCommit to a method as it is used twice
* some minor refactoring

Relates to: #9 

---------

Co-authored-by: Jimisola Laursen <jimisola.laursen@lfv.se>
Co-authored-by: Tamas Cservenak <tamas@cservenak.net>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants