Maven release plugin

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

Maven release plugin

Petar Tahchiev
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
Reply | Threaded
Open this post in threaded view
|

Re: Maven release plugin

Robert Scholte-8
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 <[hidden email]>  
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 <[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]
>>
>>
>

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