Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id A1EB0200D43 for ; Tue, 21 Nov 2017 19:41:57 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id A087C160BFC; Tue, 21 Nov 2017 18:41:57 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id C01A9160BE3 for ; Tue, 21 Nov 2017 19:41:56 +0100 (CET) Received: (qmail 12453 invoked by uid 500); 21 Nov 2017 18:41:55 -0000 Mailing-List: contact dev-help@maven.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Maven Developers List" Reply-To: "Maven Developers List" Delivered-To: mailing list dev@maven.apache.org Received: (qmail 12442 invoked by uid 99); 21 Nov 2017 18:41:55 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 Nov 2017 18:41:55 +0000 Received: from desktop-2khsk44.dynamic.ziggo.nl (5248749D.cm-4-1b.dynamic.ziggo.nl [82.72.116.157]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 0087B1A006D for ; Tue, 21 Nov 2017 18:41:54 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Maven Developers List" Subject: Re: Maven release plugin References: Date: Tue, 21 Nov 2017 19:41:54 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Robert Scholte" Organization: Apache Software Foundation Message-ID: In-Reply-To: User-Agent: Opera Mail/12.18 (Win64) archived-at: Tue, 21 Nov 2017 18:41:57 -0000 My current proposal: the start situation is a folder containing several checked out projects. the folder contains an aggregator pom, which is NOT under version control. release:prepare should start as normal, but it should end with a commit+tag+commit on every checked out folder. release:perform uses target/checkout, where you copy the aggregator-pom. And you also check out the projects by tag. Ensure they're using the same directory-name. That should be about it. The wording is probably easier compared to the implementation. Have a look at project-utils[1]. It should help with determining what kind of project every pom is. It hasn't been released yet, but it was written to help the maven-release-plugin I hope this makes sense, Robert [1] http://svn.apache.org/repos/asf/maven/shared/trunk/maven-project-utils/ On Tue, 21 Nov 2017 10:31:07 +0100, Petar Tahchiev wrote: > Hi Robert, > i'll give it a try. Can you please summarize what needs to be done, or > perhaps point me the right direction? > > 2017-11-20 21:32 GMT+02:00 Robert Scholte : > >> Hi Petar, >> >> would be great if you could pick this up. >> There's enough work I want to finish first, maven-release-plugin is not >> one of them right now. >> >> thanks, >> Robert >> >> >> On Mon, 20 Nov 2017 18:38:56 +0100, Petar Tahchiev >> >> wrote: >> >> Hi Robert, >>> >>> any updates on the release-aggregator? Is there anything I can do to >>> help? >>> >>> 2017-06-27 22:43 GMT+03:00 Robert Scholte : >>> >>> Hi Petar, >>>> >>>> This is a clear sign that ${project} should not be used to resolve >>>> this. >>>> Instead the pom should be analyzed again and if there's a system >>>> property >>>> matching the parent, it should be replaced before loading the parent. >>>> That'll require quite some new lines of code :) >>>> The suggested release-aggregator will require this same feature, so >>>> sooner >>>> or later this must be fixed. >>>> >>>> Robert >>>> >>>> >>>> On Tue, 27 Jun 2017 09:50:37 +0200, Petar Tahchiev < >>>> paranoiabla@gmail.com> >>>> wrote: >>>> >>>> Hey guys, >>>> >>>>> >>>>> my pull-request worked fine to not show the prompt to specify a >>>>> version. >>>>> However, it fails to update snapshot dependency versions when you >>>>> resolve >>>>> the parent to a concrete version. >>>>> Particularly in my case: >>>>> >>>>> >>>>> [BOM] >>>>> / \ >>>>> [PLATFORM] [DEMO_STORE] >>>>> -module1 - platform:module1 >>>>> -module2 - platform:module2 >>>>> .... ..... >>>>> - moduleN - platform:moduleN >>>>> >>>>> The [BOM] defines in dependencyManagement section all the versions of >>>>> the >>>>> modules of the [PLATFORM]. Then the [DEMO_STORE] can reference them >>>>> without >>>>> specifying a version. During release what I do is I first release the >>>>> [BOM], then release the [PLATFORM] and up to here I see no problems. >>>>> But >>>>> then I try to release the DEMO_STORE] and even though I specify on >>>>> the >>>>> command line the version of the parent [BOM]: >>>>> >>>>> -Ddependency.com.nemesis:bom.release=1.5.2.RELEASE >>>>> -Ddependency.com.nemesis:bom.development=1.5.3.BUILD-SNAPSHOT >>>>> >>>>> >>>>> it still asks me for versions of dependencies which are specified in >>>>> the >>>>> released [BOM]. I tried patching the code and specifying a new >>>>> version >>>>> of >>>>> the parent >>>>> >>>>> project.getParentArtifact().setVersion("1.5.2.RELEASE") >>>>> >>>>> just to see if it works, but the problem is that the dependencies in >>>>> the >>>>> project are already resolved: when I call project.getDependencies() I >>>>> get >>>>> the SNAPSHOT versions. >>>>> >>>>> Is there any way to reload the project model after I specify a new >>>>> parentVersion()? So that It understands the [BOM] is no longer a >>>>> snapshot >>>>> version. >>>>> >>>>> Thanks >>>>> >>>>> 2017-06-25 12:11 GMT+03:00 Robert Scholte : >>>>> >>>>> MRELEASE-362[1] is probably the matching issue. >>>>> >>>>>> Be aware that some are talking about tagging every module. In most >>>>>> situations I don't like that. If the structure is hierarchical and >>>>>> the >>>>>> root >>>>>> is tagged, then all the modules are already tagged. All tags must be >>>>>> checked out during release:perform, keep that in mind. >>>>>> I see options with a flat structure and with the release-aggregator. >>>>>> >>>>>> Robert >>>>>> >>>>>> [1] https://issues.apache.org/jira/browse/MRELEASE-362 >>>>>> >>>>>> >>>>>> On Sat, 24 Jun 2017 22:59:48 +0200, Petar Tahchiev < >>>>>> paranoiabla@gmail.com> >>>>>> wrote: >>>>>> >>>>>> Hi Paul, >>>>>> >>>>>> >>>>>>> I think you misunderstood. The [BOM] is a separate project and the >>>>>>> [PLATFORM] and [DEMO_STORE] are also separate projects, both of >>>>>>> which >>>>>>> declare as their parent the [BOM]. >>>>>>> >>>>>>> @Robert: I have added the test-case: >>>>>>> https://github.com/apache/maven-release/pull/18/commits/ >>>>>>> Release-aggregator is exactly what's missing. Is there an issue I >>>>>>> can >>>>>>> subscribe and track? >>>>>>> >>>>>>> >>>>>>> 2017-06-24 14:15 GMT+03:00 Robert Scholte : >>>>>>> >>>>>>> What we're still missing is a release-aggregator, which can release >>>>>>> >>>>>>> multiple release-roots at once. That would probably be the >>>>>>> preferred >>>>>>>> fix, >>>>>>>> the suggested patch is just an easy work-around. >>>>>>>> It is still on my todo-list. >>>>>>>> >>>>>>>> Robert >>>>>>>> >>>>>>>> >>>>>>>> On Sat, 24 Jun 2017 12:42:22 +0200, Paul Hammant >>>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Easy to fix. Have a profile 'platformOnly' in the root module >>>>>>>> (I'm >>>>>>>> not >>>>>>>> >>>>>>>> sure if 'BOM' should mean anything to me) that includes only >>>>>>>> 'platform' >>>>>>>> >>>>>>>>> as >>>>>>>>> a child module. >>>>>>>>> >>>>>>>>> mvn release:prepare -PplatformOnly # etc >>>>>>>>> >>>>>>>>> Later when you're ready to do the demo store release, use another >>>>>>>>> (from >>>>>>>>> root): >>>>>>>>> >>>>>>>>> mvn release:prepare -PdemoOnly # etc >>>>>>>>> >>>>>>>>> Of course, you man not need to stuff demo in your >>>>>>>>> Artifactory/Nexus/etc >>>>>>>>> in >>>>>>>>> which case just do your deploy fu after an 'install' w/o the >>>>>>>>> release >>>>>>>>> plugin >>>>>>>>> involved or that second profile. >>>>>>>>> >>>>>>>>> - Paul >>>>>>>>> >>>>>>>>> >>>>>>>>> On Sat, Jun 24, 2017 at 2:58 AM, Petar Tahchiev < >>>>>>>>> paranoiabla@gmail.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hey guys, >>>>>>>>> >>>>>>>>> >>>>>>>>> I'm facing a number of challenges when I release the project at >>>>>>>>> my >>>>>>>>>> company. >>>>>>>>>> Here's my setup: >>>>>>>>>> >>>>>>>>>> [BOM] >>>>>>>>>> / \ >>>>>>>>>> [PLATFORM] [DEMO_STORE] >>>>>>>>>> >>>>>>>>>> I have a master BOM project which holds all the version as >>>>>>>>>> defined >>>>>>>>>> properties. This BOM is the parent to two other projects - >>>>>>>>>> [PLATFORM] >>>>>>>>>> and >>>>>>>>>> [DEMO_STORE], The [PLATFORM] is a project with more than 60 >>>>>>>>>> modules >>>>>>>>>> inside, >>>>>>>>>> and the [DEMO_STORE] is a project that declares those modules as >>>>>>>>>> dependencies. >>>>>>>>>> >>>>>>>>>> Now what I want is to release all three from Jenkins. I can >>>>>>>>>> release >>>>>>>>>> the >>>>>>>>>> [BOM] with no problems, then I start release of the [PLATFORM] >>>>>>>>>> and >>>>>>>>>> all >>>>>>>>>> of a >>>>>>>>>> sudden Jenkins blocks because Maven asks me on the command line >>>>>>>>>> if >>>>>>>>>> I >>>>>>>>>> want >>>>>>>>>> to resolve the SNAPSHOT dependencies (remember the parent of the >>>>>>>>>> [PLATFORM] >>>>>>>>>> is the [BOM] SNAPSHOT version). >>>>>>>>>> >>>>>>>>>> So I created this issue https://issues.apache.org/jira >>>>>>>>>> /browse/MRELEASE-985 >>>>>>>>>> to be able to specify the [BOM] parent version when I start the >>>>>>>>>> release >>>>>>>>>> of >>>>>>>>>> [PLATFORM]. I think I also fixed it with this pull-request: >>>>>>>>>> https://github.com/apache/maven-release/pull/18 >>>>>>>>>> >>>>>>>>>> Can someone have a look at this pull request and tell me if it >>>>>>>>>> is >>>>>>>>>> OK? >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Regards, Petar! >>>>>>>>>> Karlovo, Bulgaria. >>>>>>>>>> --- >>>>>>>>>> Public PGP Key at: >>>>>>>>>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550 >>>>>>>>>> C3110611 >>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 >>>>>>>>>> 0611 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ------------------------------------------------------------ >>>>>>>>>> >>>>>>>>> --------- >>>>>>>>> >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org >>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------------------------------------ >>>>>>> --------- >>>>>>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org >>>>>> For additional commands, e-mail: dev-help@maven.apache.org >>>>>> >>>>>> >>>>>> >>>>>> >>>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org >>>> For additional commands, e-mail: dev-help@maven.apache.org >>>> >>>> >>>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org >> For additional commands, e-mail: dev-help@maven.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For additional commands, e-mail: dev-help@maven.apache.org