From users-return-144180-archive-asf-public=cust-asf.ponee.io@maven.apache.org Sat Aug 3 07:36:52 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 5B8761802C7 for ; Sat, 3 Aug 2019 09:36:52 +0200 (CEST) Received: (qmail 19466 invoked by uid 500); 3 Aug 2019 07:36:47 -0000 Mailing-List: contact users-help@maven.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Maven Users List" Reply-To: "Maven Users List" Delivered-To: mailing list users@maven.apache.org Received: (qmail 19455 invoked by uid 99); 3 Aug 2019 07:36:47 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 03 Aug 2019 07:36:47 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 55D5AC0538 for ; Sat, 3 Aug 2019 07:36:46 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.003 X-Spam-Level: * X-Spam-Status: No, score=1.003 tagged_above=-999 required=6.31 tests=[KAM_LAZY_DOMAIN_SECURITY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=disabled Received: from mx1-he-de.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id DR8qCdzObAXx for ; Sat, 3 Aug 2019 07:36:43 +0000 (UTC) Received-SPF: None (mailfrom) identity=mailfrom; client-ip=212.27.42.3; helo=smtp3-g21.free.fr; envelope-from=herve.boutemy@free.fr; receiver= Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) by mx1-he-de.apache.org (ASF Mail Server at mx1-he-de.apache.org) with ESMTPS id 56BD27D3FB for ; Sat, 3 Aug 2019 07:36:43 +0000 (UTC) Received: from giga.localnet (unknown [IPv6:2a01:cb00:435:4f00:76:32ec:99b:b370]) (Authenticated sender: herve.boutemy) by smtp3-g21.free.fr (Postfix) with ESMTPSA id 2606D13F895 for ; Sat, 3 Aug 2019 09:36:42 +0200 (CEST) From: =?ISO-8859-1?Q?Herv=E9?= BOUTEMY To: Maven Users List Subject: Re: Using Git tags to cut releases to Maven Central from TravisCI Date: Sat, 03 Aug 2019 09:36:41 +0200 Message-ID: <3236305.rhqzvazdhr@giga> In-Reply-To: References: <1860360.hRc8RnYbOZ@giga> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" I'm torn: =2D I find commits for version management useful, then really want them (wi= th=20 clear SNAPSHOT during development and no SNAPSHOT at release points) =2D but I'd like to have naming in branch, this would be useful (we're lazy= , we=20 never update pom.xml, and if we did update, this would cause a commit that = we=20 don't want to merge back to master...) =2D and I don't like automatic project version policy: I really think that= =20 version is a matter of human choice there is really a question of taste: we'll need to document somewhere the=20 different solutions for different tastes in a neutral way and let people ch= oose=20 solutions based on their own preferences one key aspect: in this case, the version in pom.xml in source control is n= ot=20 the effective version In this case, I'd prefer to have a variable reference in the version tag of= =20 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 perfect= ly=20 manageable Regards, Herv=E9 Le vendredi 2 ao=FBt 2019, 08:37:58 CEST Matthieu BROUILLARD a =E9crit : > Hi Herve, >=20 > 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. >=20 > 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 > - ... >=20 > 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 nee= ds > 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. >=20 > Regards, >=20 > Matthieu >=20 > On Fri, Aug 2, 2019 at 8:03 AM Herv=E9 BOUTEMY wr= ote: > > thank you Matthieu for sharing > >=20 > > to me, one key interesting part is: > > > An issue with solutions like yours is reproducibility : `git checkout > >=20 > > X.Y.Z > >=20 > > > && mvn install`will not build again artifact-X.Y.Z ; but this can be > > > considered minor depending on the use cases & needs. > >=20 > > and with jgitver, there is the equivalent reproducibility issue: if a > > release > > creates a source tarball to be able to download and rebuild independent= ly > > from > > source control (=3D something that is mandatory at Apache level, and IM= HO a > > good > > practice), both Ben solution and jgitver fail at rebuilding > >=20 > > 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 relea= se > > where > > the version is strictly defined at a precise state for the whole source > > tree) > >=20 > >=20 > > What Maven could do better to me is avoiding modifying every pom.xml fi= le > > 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) > >=20 > >=20 > > 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 > >=20 > > Regards, > >=20 > > Herv=E9 > >=20 > > Le jeudi 1 ao=FBt 2019, 11:23:33 CEST Matthieu BROUILLARD a =E9crit : > > > Hi Ben, > > >=20 > > > several years ago I created jgitver to co= ver > > > such a use case and even more. > > >=20 > > > 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 brings more features & configurat= ion > > > capabilities without never modifying the pom files (like `mvn versions > > > -dnewVersion` does). > > >=20 > > > It is a solution among others but it is worthwhile trying it. > > >=20 > > > An issue with solutions like yours is reproducibility : `git checkout > >=20 > > X.Y.Z > >=20 > > > && mvn install`will not build again artifact-X.Y.Z ; but this can be > > > considered minor depending on the use cases & needs. > > >=20 > > > 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 > >=20 > > > - jgitver gradle plugin: > > https://github.com/jgitver/gradle-jgitver-plugin > >=20 > > > Regards, > > >=20 > > > Matthieu > > >=20 > > > On Wed, Jul 31, 2019 at 5:51 PM Ben Podgursky > >=20 > > wrote: > > > > I've been experimenting with setting up Maven Central publishing fr= om > > > > a > > > > TravisCI build (since it's free for my OSS GitHub project), and I > >=20 > > ended up > >=20 > > > > with a pattern that I think is pretty nice to work with (I've > > > > struggled > > > > with the maven-deploy-plugin in the past). > > > >=20 > > > > I've written it up here > >=20 > > https://bpodgursky.com/2019/07/31/using-travisci-to-deploy-to-maven-cen= tra > >=20 > > > > 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: > > > >=20 > > > > ``` > > > > if [ ! -z "$TRAVIS_TAG" ] > > > > then > > > >=20 > > > > mvn --settings "${TRAVIS_BUILD_DIR}/.travis/mvn-settings.xml" > > > >=20 > > > > org.codehaus.mojo:versions-maven-plugin:2.1:set > >=20 > > -DnewVersion=3D$TRAVIS_TAG > >=20 > > > > 1>/dev/null 2>/dev/null > > > > else > > > >=20 > > > > echo "No tags, using snapshot version from pom.xml" > > > >=20 > > > > fi > > > >=20 > > > > mvn deploy -P publish -DskipTests=3Dtrue --settings > > > > "${TRAVIS_BUILD_DIR}/.travis/mvn-settings.xml" > > > > ``` > > > >=20 > > > > This lets me cut a central release by just pushing a tag: > > > >=20 > > > > ``` > > > > $ git tag 1.23 > > > > $ git push origin 1.23 > > > > ``` > > > >=20 > > > > I've used Maven a fair amount but I wouldn't consider myself perfec= tly > >=20 > > in > >=20 > > > > 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. > > > >=20 > > > >=20 > > > > Thanks, > > > >=20 > > > > Ben > >=20 > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org > > For additional commands, e-mail: users-help@maven.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@maven.apache.org For additional commands, e-mail: users-help@maven.apache.org