Re: Maven release plugin

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Maven release plugin

Robert Scholte-8
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 <[hidden email]>  
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 <[hidden email]>:
>
>> 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 <[hidden email]>  
>> 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 <[hidden email]>
>>> 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=0x19658550C3110611
>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven release plugin

Petar Tahchiev
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 <[hidden email]>:

> 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 <[hidden email]>
> 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 <[hidden email]>:
>>
>> 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 <[hidden email]>
>>> 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 <[hidden email]>
>>>> 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=0x19658550C3110611
>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
Reply | Threaded
Open this post in threaded view
|

Re: Maven release plugin

Petar Tahchiev
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 <[hidden email]>:

> 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 <[hidden email]>
> 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 <[hidden email]>:
>>
>> 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 <
>>> [hidden email]>
>>> 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 <[hidden email]>:
>>>>
>>>> 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 <[hidden email]>
>>>>> 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 <
>>>>>> [hidden email]>
>>>>>> 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=0x19658550C3110611
>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------
>>>>>> ---------
>>>>>>
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
Reply | Threaded
Open this post in threaded view
|

Re: Maven release plugin

Robert Scholte-8
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 <[hidden email]>  
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 <[hidden email]>:
>
>> 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  
>> <[hidden email]>
>> 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 <[hidden email]>:
>>>
>>> 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 <
>>>> [hidden email]>
>>>> 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 <[hidden email]>:
>>>>>
>>>>> 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 <[hidden email]>
>>>>>> 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 <
>>>>>>> [hidden email]>
>>>>>>> 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=0x19658550C3110611
>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311  
>>>>>>>> 0611
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------
>>>>>>> ---------
>>>>>>>
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven release plugin

Petar Tahchiev
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 <[hidden email]>:

> 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 <[hidden email]>
> 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 <[hidden email]>:
>>
>> 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 <
>>> [hidden email]>
>>> 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 <[hidden email]>:
>>>>
>>>> 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 <
>>>>> [hidden email]>
>>>>> 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 <[hidden email]>:
>>>>>>
>>>>>> 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 <[hidden email]>
>>>>>>> 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 <
>>>>>>>> [hidden email]>
>>>>>>>> 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: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------
>>>>>> ---------
>>>>>>
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611