Re: Migration of remaining plugins to Git

[Hervé BOUTEMY]

I was thinking at something like the Maven Jenkins Seeding experiment [1] that 
was done, with its DSL code [2]

IIUC, this new Jenkins feature could provide a more generic seeding?
Looks promising.

Whether we go with first or second option will be a matter of ETA and people 
wanting to work on it: I'm supportive of both approaches :)

Regards,

Hervé

[1] https://builds.apache.org/view/M-R/view/Maven/job/maven-jenkins-seeding/

[2] http://svn.apache.org/viewvc/maven/jenkins-seeding/

Le mardi 20 juin 2017, 22:02:14 CEST Stephen Connolly a écrit :
> On Tue 20 Jun 2017 at 20:29, Arnaud Héritier  wrote:
> > Stephen knows more the ASF infra than me to tell if it is possible but in
> > Jenkins we have the notion of organization folder for GitHub which allow
> > to
> > automatically browse an org in GitHub and create/update/delete
> > multibranches jobs for each repo. If we can also create shared libraries
> > in
> > Jenkins our JenkinsFile could just be a line: buildPlugin() like we do in
> > jenkins project.
> 
> Now that I have landed JENKINS-43507 it should be relatively easy for me to
> write a SCMNavigator for the ASF hosted repositories.
> 
> That would give us a folder where all jobs for plugins etc would be
> auto-created based on the presence of a Jenkinsfile.
> 
> With a shared library we can then give them all a standard build with a
> nice simple Jenkinsfile that is just one line.
> 
> If people are interested I can prototype the SCMNavigator
> 
> > Le mar. 20 juin 2017 à 21:14, Hervé BOUTEMY  a
> > 
> > écrit :
> > > as explained in the git migration status [1], the biggest issue with
> > > plugins 1
> > > svn repo to 41 git repo migration is the maintenance of Jenkins job
> > 
> > files,
> > 
> > > with
> > > their java + maven version matrix.
> > > With Jenkinsfile as worked out in Mavne core, same type of configuration
> > > could
> > > help us to change our 10 aggregate Jenkins jobs to 41 individual jobs
> > > 
> > > Would it be possible to create an aggregator Jenkins job that would
> > 
> > create
> > 
> > > the
> > > 41 plugins jobs?
> > > 
> > > Regards,
> > > 
> > > Hervé
> > > 
> > > [1] https://cwiki.apache.org/confluence/display/MAVEN/Git
> > 
> > +Migration#GitMigration-Migratinganaggregatortreeintoacollectionofgitrepos
> > 
> > > Le lundi 19 juin 2017, 16:10:39 CEST Paul Hammant a écrit :
> > > > I think the plugins are descoped for a while.
> > > > 
> > > > How about  https://github.com/apache-maven/ ?
> > > > 
> > > > Luckily GitHub does 302s just find if things get renamed or moved
> > 
> > between
> > 
> > > > orgs.
> > > > 
> > > > - Paul
> > > > 
> > > > On Mon, Jun 19, 2017 at 3:34 PM, Bindul Bhowmik <
> > 
> > bindulbhow...@gmail.com
> > 
> > > > wrote:
> > > > > Paul,
> > > > > 
> > > > > On Mon, Jun 19, 2017 at 12:42 PM, Paul Hammant 
> > > 
> > > wrote:
> > > > > > Back from Github's suggestions team: "Currently, we don't have the
> > > > > 
> > > > > ability
> > > > > 
> > > > > > to group repos beyond the organization level, but I'll definitely
> > > > > 
> > > > > consider
> > > > > 
> > > > > > this a feature request."
> > > > > 
> > > > > Until such time, how about grouping the repositories by name, like
> > > > > https://github.com/apache/maven-plugin-
> > > > > 
> > > > > A number of other projects in Apache have done this, for example
> > > > > https://git-wip-us.apache.org/repos/asf?a=project_list=
> > > > > incubator-predictionio
> > > > > or https://gitbox.apache.org/repos/asf?a=project_list=
> > > > > incubator-openwhisk
> > > > > 
> > > > > - Bindul
> > > > > 
> > > > > > - Paul
> > > > > > 
> > > > > > On Sun, Jun 18, 2017 at 7:04 PM, Paul Hammant 
> > > 
> > > wrote:
> > > > > >> I met Chris Wanstrath at a meetup in Cincinatti about four years
> > > 
> > > ago,
> > > 
> > > > > and
> > > > > 
> > > > > >> bent his ear about how fantastic Github-Pages (and Jekyll) was as
> > 
> > a
> > 
> > > > > CMS. I
> > > > > 
> > > > > >> suggested that if they could add themes for "high school",
> > > 
> > > "community
> > > 
> > > > > >> group", etc they could pull in another category of user of the
> > > > > 
> > > > > platform, and
> > > > > 
> > > > > >> that the themes that are available for gh-pages are not that
> > 
> > useful
> > 
> > > as
> > > 
> > > > > they
> > > > > 
> > > > > >> are.
> > > > > >> 
> > > > > >> 
> > > > > >> 
> > > > > >> ^ screencap from today: unchanged :(
> > > > > >> 
> > > > > >> On Sun, Jun 18, 2017 at 6:46 PM, Stephen Connolly
> > > > > >> 
> > > > > >>  wrote:
> > > > > >>> Polite, yes, just non commital ;-)
> > > > > >>> 
> > > > > >>> On Sun 18 Jun 2017 at 23:10, Paul Hammant 
> > > 
> > > wrote:
> > > > > >>> > They're always very polite for things that I ask for, but I
> > 
> > can't
> > 
> > > > > claim
> > > > > 
> > > > > >>> > to
> > > > > >>> > have suggested anything that got implemented. 

Re: Migration of remaining plugins to Git

[Arnaud Héritier]

Using JobDSL is effectively another approach
It's main avantage is to easily keep the control at Jenkins Admin level of
what is done instead of delegating it to projects developers

On Sat, Jun 24, 2017 at 8:44 AM, Hervé BOUTEMY 
wrote:

> I was thinking at something like the Maven Jenkins Seeding experiment [1]
> that
> was done, with its DSL code [2]
>
> IIUC, this new Jenkins feature could provide a more generic seeding?
> Looks promising.
>
> Whether we go with first or second option will be a matter of ETA and
> people
> wanting to work on it: I'm supportive of both approaches :)
>
> Regards,
>
> Hervé
>
> [1] https://builds.apache.org/view/M-R/view/Maven/job/maven-
> jenkins-seeding/
>
> [2] http://svn.apache.org/viewvc/maven/jenkins-seeding/
>
> Le mardi 20 juin 2017, 22:02:14 CEST Stephen Connolly a écrit :
> > On Tue 20 Jun 2017 at 20:29, Arnaud Héritier 
> wrote:
> > > Stephen knows more the ASF infra than me to tell if it is possible but
> in
> > > Jenkins we have the notion of organization folder for GitHub which
> allow
> > > to
> > > automatically browse an org in GitHub and create/update/delete
> > > multibranches jobs for each repo. If we can also create shared
> libraries
> > > in
> > > Jenkins our JenkinsFile could just be a line: buildPlugin() like we do
> in
> > > jenkins project.
> >
> > Now that I have landed JENKINS-43507 it should be relatively easy for me
> to
> > write a SCMNavigator for the ASF hosted repositories.
> >
> > That would give us a folder where all jobs for plugins etc would be
> > auto-created based on the presence of a Jenkinsfile.
> >
> > With a shared library we can then give them all a standard build with a
> > nice simple Jenkinsfile that is just one line.
> >
> > If people are interested I can prototype the SCMNavigator
> >
> > > Le mar. 20 juin 2017 à 21:14, Hervé BOUTEMY  a
> > >
> > > écrit :
> > > > as explained in the git migration status [1], the biggest issue with
> > > > plugins 1
> > > > svn repo to 41 git repo migration is the maintenance of Jenkins job
> > >
> > > files,
> > >
> > > > with
> > > > their java + maven version matrix.
> > > > With Jenkinsfile as worked out in Mavne core, same type of
> configuration
> > > > could
> > > > help us to change our 10 aggregate Jenkins jobs to 41 individual jobs
> > > >
> > > > Would it be possible to create an aggregator Jenkins job that would
> > >
> > > create
> > >
> > > > the
> > > > 41 plugins jobs?
> > > >
> > > > Regards,
> > > >
> > > > Hervé
> > > >
> > > > [1] https://cwiki.apache.org/confluence/display/MAVEN/Git
> > >
> > > +Migration#GitMigration-Migratinganaggregatortreeintoa
> collectionofgitrepos
> > >
> > > > Le lundi 19 juin 2017, 16:10:39 CEST Paul Hammant a écrit :
> > > > > I think the plugins are descoped for a while.
> > > > >
> > > > > How about  https://github.com/apache-maven/ ?
> > > > >
> > > > > Luckily GitHub does 302s just find if things get renamed or moved
> > >
> > > between
> > >
> > > > > orgs.
> > > > >
> > > > > - Paul
> > > > >
> > > > > On Mon, Jun 19, 2017 at 3:34 PM, Bindul Bhowmik <
> > >
> > > bindulbhow...@gmail.com
> > >
> > > > > wrote:
> > > > > > Paul,
> > > > > >
> > > > > > On Mon, Jun 19, 2017 at 12:42 PM, Paul Hammant  >
> > > >
> > > > wrote:
> > > > > > > Back from Github's suggestions team: "Currently, we don't have
> the
> > > > > >
> > > > > > ability
> > > > > >
> > > > > > > to group repos beyond the organization level, but I'll
> definitely
> > > > > >
> > > > > > consider
> > > > > >
> > > > > > > this a feature request."
> > > > > >
> > > > > > Until such time, how about grouping the repositories by name,
> like
> > > > > > https://github.com/apache/maven-plugin-
> > > > > >
> > > > > > A number of other projects in Apache have done this, for example
> > > > > > https://git-wip-us.apache.org/repos/asf?a=project_list=
> > > > > > incubator-predictionio
> > > > > > or https://gitbox.apache.org/repos/asf?a=project_list=
> > > > > > incubator-openwhisk
> > > > > >
> > > > > > - Bindul
> > > > > >
> > > > > > > - Paul
> > > > > > >
> > > > > > > On Sun, Jun 18, 2017 at 7:04 PM, Paul Hammant <
> p...@hammant.org>
> > > >
> > > > wrote:
> > > > > > >> I met Chris Wanstrath at a meetup in Cincinatti about four
> years
> > > >
> > > > ago,
> > > >
> > > > > > and
> > > > > >
> > > > > > >> bent his ear about how fantastic Github-Pages (and Jekyll)
> was as
> > >
> > > a
> > >
> > > > > > CMS. I
> > > > > >
> > > > > > >> suggested that if they could add themes for "high school",
> > > >
> > > > "community
> > > >
> > > > > > >> group", etc they could pull in another category of user of the
> > > > > >
> > > > > > platform, and
> > > > > >
> > > > > > >> that the themes that are available for gh-pages are not that
> > >
> > > useful
> > >
> > > > as
> > > >
> > > > > > they
> > > > > >
> > > > > > >> are.
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> ^ 

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=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

Re: Maven release plugin

[Robert Scholte]

Hi Peter,

This fix looks good to me, but I would appreciate one integration test to  
confirm it and to prevent regression in the future.


thanks,
Robert

On Sat, 24 Jun 2017 08:58:58 +0200, 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 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?


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Apache Maven Shared Component: Maven Reporting Impl 3.0.0

[Robert Scholte]

+1

On Wed, 21 Jun 2017 20:16:08 +0200, Karl Heinz Marbaise  
 wrote:



Hi,

We solved 14 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12332979

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-reporting-impl%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC

Staging repo:
https://repository.apache.org/content/repositories/maven-1343

https://repository.apache.org/content/repositories/maven-1343/org/apache/maven/reporting/maven-reporting-impl/3.0.0/maven-reporting-impl-3.0.0-source-release.zip

Source release checksum(s):
maven-reporting-impl-3.0.0-source-release.zip sha1:  
8061dad7d5a3518aa36f5304e9a618d346dc46cb


Staging site:
http://maven.apache.org/shared-archives/maven-reporting-impl-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.

[ ] +1
[ ] +0
[ ] -1

Kind regards
Karl Heinz Marbaise

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven-release pull request #18: MRELEASE-985

[ptahchiev]

GitHub user ptahchiev opened a pull request:

https://github.com/apache/maven-release/pull/18

MRELEASE-985

This commit copies resolved snapshot dependencies system properties to the 
release descriptor
and then checks if the those resolved snapshot dependencies contain the 
SNAPSHOT artifact before
before adding it as a SNAPSHOT dependency.

Fixes: https://issues.apache.org/jira/browse/MRELEASE-985

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ptahchiev/maven-release MRELEASE-985

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-release/pull/18.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #18


commit f2775c83af6b5347e266f74c99edbb920046824b
Author: petar.tahchiev 
Date:   2017-06-24T06:44:35Z

Override snapshot dependencies from command line.

This commit copies resolved snapshot dependencies system properties to the 
release descriptor
and then checks if the those resolved snapshot dependencies contain the 
SNAPSHOT artifact before
before adding it as a SNAPSHOT dependency.

Fixes: https://issues.apache.org/jira/browse/MRELEASE-985




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Apache Maven Shared Component: Maven Reporting Impl 3.0.0

[Hervé BOUTEMY]

+1

Regards,

Hervé

Le mercredi 21 juin 2017, 20:16:08 CEST Karl Heinz Marbaise a écrit :
> Hi,
> 
> We solved 14 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922
> rsion=12332979
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20r
> esolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-reporting-impl%
> 20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1343
> 
> https://repository.apache.org/content/repositories/maven-1343/org/apache/mav
> en/reporting/maven-reporting-impl/3.0.0/maven-reporting-impl-3.0.0-source-re
> lease.zip
> 
> Source release checksum(s):
> maven-reporting-impl-3.0.0-source-release.zip sha1:
> 8061dad7d5a3518aa36f5304e9a618d346dc46cb
> 
> Staging site:
> http://maven.apache.org/shared-archives/maven-reporting-impl-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for at least 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> Kind regards
> Karl Heinz Marbaise
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Apache Maven Shared Component: Maven Reporting Impl 3.0.0

[Michael Osipov]

Am 2017-06-21 um 20:16 schrieb Karl Heinz Marbaise:

Hi,

We solved 14 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12332979


There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-reporting-impl%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC


Staging repo:
https://repository.apache.org/content/repositories/maven-1343

https://repository.apache.org/content/repositories/maven-1343/org/apache/maven/reporting/maven-reporting-impl/3.0.0/maven-reporting-impl-3.0.0-source-release.zip


Source release checksum(s):
maven-reporting-impl-3.0.0-source-release.zip sha1:
8061dad7d5a3518aa36f5304e9a618d346dc46cb

Staging site:
http://maven.apache.org/shared-archives/maven-reporting-impl-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.


+1


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven release plugin

[Petar Tahchiev]

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 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=0x19658550C3110611
>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>
>>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


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

Re: Maven release plugin

[Paul Hammant]

Yup. I don't think I understand the problem, and shouldn't comment.

On Sat, Jun 24, 2017 at 4:59 PM, 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 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=0x19658550C3110611
> >>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
> >>>
> >>
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> http://pgp.mit.edu:11371/pks/lookup?op=get=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>

Re: Maven release plugin

[Paul Hammant]

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 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=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>

Re: Maven release plugin

[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 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=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org