Re: Migration of remaining plugins to Git
OK, I tried something new. *Goal*: all the plugins in one Git repo (less CI jobs to set up - just one recursive multi-module maven build). *Constraint*: Plugins must be independently releasable. *Test:* Take two modules from the Svn repo and check them in to master (the rest were deleted - test needs two and a parent pom in master). *Repository*: https://github.com/paul-hammant/ph_testplugins Of the two modules checked in, maven-changes-plugin is the one I attempted to release to my com/paulhammant/ group on 'Central. The workflow for the release of that single module is here https://github.com/paul-hammant/ph_testplugins/blob/master/CHANGES_PLUGIN_RELEASE_WORKFLOW.md *Result of Test:* failed, but in a surprising way and at a very late stage During the release:perform stage the maven tried to push to https://oss.sonatype.org/content/repositories/snapshots /com/paulhammant/testplugins-ph-chgs-pi/3.0.0-SNAPSHOT/testplugins-ph-chgs-pi-3.0.0-20170627.234743-1.jar which is nuts because I'm not trying to push to a SNAPSHOT, I'm trying to do a proper release of 3.0.0 (of my renamed to an obscure name plugin). The documentation for the part of the pom says that it honors the name of the local branch for the sequence of commits that the release plugin does. Which is exactly what you'd want. I've already tested it a dozen times and it does the right thing by way of tags too. It's only that SNAPSHOT weirdness during the upload that ends the experiment, and that's a fairly late stage piece. My plan was to go onto oss.sonatype.org and delete it from staging so it would ultimately go nowhere. Barring that bug, this would work for all of the Maven plugins in a single repo, meaning a lot less permutations for CI, albeit with a longer build per commit. I don't think that last is a big issue for this proposed repository. Any of you could clone the repo I have made, and do the same steps as CHANGES_PLUGIN_RELEASE_WORKFLOW.md document to get to the same place I got to (a 401 error from Sonatype's DAV infra). And one of you could tell me what I did wrong with the setup to encounter that snapshot issue :) - Paul
Re: Maven release plugin
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
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
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
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
Re: Maven release plugin
Petar Tahchiev 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].
What you can do as workaround is to add an empty relativePath element to the
[DEMO_STORE] as a temporary modification just for the release. Annoying, but
that should limit the multi-project to the subtree.
> 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.
Dependency resolution is too early for such modifications.
Cheers,
Jörg
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven release plugin
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
> 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
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
