I'm torn: - I find commits for version management useful, then really want them (with clear SNAPSHOT during development and no SNAPSHOT at release points) - but I'd like to have naming in branch, this would be useful (we're lazy, we never update pom.xml, and if we did update, this would cause a commit that we don't want to merge back to master...) - and I don't like automatic project version policy: I really think that version is a matter of human choice
there is really a question of taste: we'll need to document somewhere the different solutions for different tastes in a neutral way and let people choose solutions based on their own preferences one key aspect: in this case, the version in pom.xml in source control is not the effective version In this case, I'd prefer to have a variable reference in the version tag of pom.xml to clearly show that the version in not managed in pom.xml I hope that with future consumer vs build pom, such options will be perfectly manageable Regards, Hervé Le vendredi 2 août 2019, 08:37:58 CEST Matthieu BROUILLARD a écrit : > Hi Herve, > > you're right for the source tarball, if it is a need for you or your > project then your need a not so clever solution. > everything depends on the needs. If a project needs an offline build then > maven will probably fail also. > > The thing is that part of maven users would like the build process to be > smarter than it is today and even if you tomorrow you modify only the root > pom then you'll have two commits. > jgitver, like other core extension, tries to bring some new capabilities > which bring value to the users who want those features: > - no commit for version management > - naming in branch > - shared & enforced automatic project policy to compute project version > - ... > > We're probably no so aligned in this area of having the version changes in > the source control but that's also good to me ; it reflects different needs > in the community. > And the fact that people try to find workarounds to the 'standard' way of > doing things prove that there is some place for additional workflows/tools > like jgitver. > > Regards, > > Matthieu > > On Fri, Aug 2, 2019 at 8:03 AM Hervé BOUTEMY <[email protected]> wrote: > > thank you Matthieu for sharing > > > > to me, one key interesting part is: > > > An issue with solutions like yours is reproducibility : `git checkout > > > > X.Y.Z > > > > > && mvn install`will not build again artifact-X.Y.Z ; but this can be > > > considered minor depending on the use cases & needs. > > > > and with jgitver, there is the equivalent reproducibility issue: if a > > release > > creates a source tarball to be able to download and rebuild independently > > from > > source control (= something that is mandatory at Apache level, and IMHO a > > good > > practice), both Ben solution and jgitver fail at rebuilding > > > > I personally find these version changing commits *a key useful feature*: > > when I > > checkout any point in a projet scm history, whatever the scm (no Git is > > not > > the only scm in the world), I precisely know what precise version I'm > > building > > (be it a SNAPSHOT, where by definition the version is fuzzy, or a release > > where > > the version is strictly defined at a precise state for the whole source > > tree) > > > > > > What Maven could do better to me is avoiding modifying every pom.xml file > > in > > multi-module project: yes, here, modifying only the root pom would be an > > improvement. > > I know there is a MNG Jira issue (even if I can't find it right now) > > > > > > But definitely, trying to remove versions changes at source level seems to > > me > > not not a good objective because these commits are useful: the codebase is > > really switching from PREV-SNAPSHOT to RELEASE to NEXT-SNAPSHOT > > And even the fact that: > > - you can't really predict how RELEASE value will really be related to > > PREV > > - you'll have to make a guess at choosing NEXT > > proves that these changes at source level are useful. > > What we should do is making them easier > > > > Regards, > > > > Hervé > > > > Le jeudi 1 août 2019, 11:23:33 CEST Matthieu BROUILLARD a écrit : > > > Hi Ben, > > > > > > several years ago I created jgitver <https://jgitver.github.io> to cover > > > such a use case and even more. > > > > > > It uses git information (tags, branches, commits, metadatas, ...) to > > > automatically compute a version based on configurable rules. > > > So like you I can simply do: `git tag X.Y.Z && mvn deploy` > > > jgitver <https://jgitver.github.io> brings more features & configuration > > > capabilities without never modifying the pom files (like `mvn versions > > > -dnewVersion` does). > > > > > > It is a solution among others but it is worthwhile trying it. > > > > > > An issue with solutions like yours is reproducibility : `git checkout > > > > X.Y.Z > > > > > && mvn install`will not build again artifact-X.Y.Z ; but this can be > > > considered minor depending on the use cases & needs. > > > > > > FYI here are the projects I maintain related to the topic: > > > - jgitver library: https://github.com/jgitver/jgitver > > > - jgitver maven extension: > > > https://github.com/jgitver/jgitver-maven-plugin > > > > > - jgitver gradle plugin: > > https://github.com/jgitver/gradle-jgitver-plugin > > > > > Regards, > > > > > > Matthieu > > > > > > On Wed, Jul 31, 2019 at 5:51 PM Ben Podgursky <[email protected]> > > > > wrote: > > > > I've been experimenting with setting up Maven Central publishing from > > > > a > > > > TravisCI build (since it's free for my OSS GitHub project), and I > > > > ended up > > > > > > with a pattern that I think is pretty nice to work with (I've > > > > struggled > > > > with the maven-deploy-plugin in the past). > > > > > > > > I've written it up here > > > > https://bpodgursky.com/2019/07/31/using-travisci-to-deploy-to-maven-centra > > > > > > l-via-git-tagging-aka-death-to-commit-clutter/ but > > > > tl,dr, the key thing I haven't seen used widely is the use of tags to > > > > define release versions, eg: > > > > > > > > ``` > > > > if [ ! -z "$TRAVIS_TAG" ] > > > > then > > > > > > > > mvn --settings "${TRAVIS_BUILD_DIR}/.travis/mvn-settings.xml" > > > > > > > > org.codehaus.mojo:versions-maven-plugin:2.1:set > > > > -DnewVersion=$TRAVIS_TAG > > > > > > 1>/dev/null 2>/dev/null > > > > else > > > > > > > > echo "No tags, using snapshot version from pom.xml" > > > > > > > > fi > > > > > > > > mvn deploy -P publish -DskipTests=true --settings > > > > "${TRAVIS_BUILD_DIR}/.travis/mvn-settings.xml" > > > > ``` > > > > > > > > This lets me cut a central release by just pushing a tag: > > > > > > > > ``` > > > > $ git tag 1.23 > > > > $ git push origin 1.23 > > > > ``` > > > > > > > > I've used Maven a fair amount but I wouldn't consider myself perfectly > > > > in > > > > > > tune with best practices, so I'm curious what others think of this > > > > approach, or if there are other streamlined central deploy setups > > > > (especially from CI/Travis) that I missed. > > > > > > > > > > > > Thanks, > > > > > > > > Ben > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
