Re: Loading providers in named modules with ServiceLoader using a plugin class realm

[Igor Fedorenko]

Can you explain little more why plugins won't see classes loaded by
maven core or maven core extensions classloaders? This is implemented in
classwords and I was under impression that java9 still allowed custom
classloading schemes like what we do or like what OSGi does.

-- 
Regards,
Igor

On Sun, Jun 25, 2017, at 07:08 PM, Guillaume Boué wrote:
> 
> Le 25/06/2017 à 22:03, Chas Honton a écrit :
> > Under what circumstances would a plugin not want the platform classloader?
> >
> > Chas
> 
> Thinking about this more, with the current situation, it actually means 
> that potential providers, located in named modules loaded for example by 
> Maven core classloader or extension classloader, will not be available 
> to plugins using ServiceLoader. So this is bigger than platform 
> classloader. As Robert said, I think there needs to be a way for plugins 
> to know about modules.
> 
> Reading more into the docs, this may be possible using a ModuleLayer. 
> Each plugin would have its own module layer composed of modules found in 
> its dependencies. Their parent would be a module layer associated to 
> Maven core, and its parent would be the boot layer. This would solve the 
> ServiceLoader issue for named modules in a plugin realm, since it would 
> locate providers in all modules in the module layer of the plugin, and 
> then do the same for their parents, up to the boot layer. However, for 
> it to work, I'm not sure if this implies that everything be made modular 
> (plugins and Maven itself). I will try to do some testing on this.
> 
> Guillaume
> 
> >
> >> On Jun 25, 2017, at 12:40 PM, Robert Scholte  wrote:
> >>
> >> Hi Guillaume,
> >>
> >> I don't know all the details about the Platform classloader, but it has 
> >> been introduced with a reason.
> >> So I don't think we should switch to it by default. I think the plugin is 
> >> well aware which classloaders / modules it wants to use (it should be), so 
> >> I think we need to find a mechanism for plugins to select their 
> >> classloaders and modules.
> >>
> >> thanks,
> >> Robert
> >>
> >>> On Sun, 25 Jun 2017 17:19:07 +0200, Guillaume Boué  
> >>> wrote:
> >>>
> >>> Hi,
> >>>
> >>> With the introduction of modules in JDK 9, there were changes with
> >>> regard to how classloading works, and this impacts class realms created
> >>> in Maven. Today, the parent (as per ClassLoader.getParent()) of a class
> >>> realm is null, which represents the bootstrap classloader. In JDK 9, the
> >>> change is that some classes were moved to a named module other than
> >>> java.base, and they are not loaded with the bootstrap classloader
> >>> anymore, but with the platform classloader (which was previously the
> >>> extension classloader, see JDK-814637).
> >>>
> >>> This has consequences, like MANTRUN-200, where locating providers with
> >>> the ServiceLoader API, using the plugin class realm, will miss JDK
> >>> internal implementation classes. In the case of MANTRUN-200, it is
> >>> Nashorn of the jdk.scripting.nashorn module, that cannot be found
> >>> because of the way ServiceLoader works
> >>> http://download.java.net/java/jdk9/docs/api/java/util/ServiceLoader.html#load-java.lang.Class-java.lang.ClassLoader-.
> >>> During the search in named modules, the class realm will not be able to
> >>> use its strategy since that process relies on parent delegation
> >>> implemented as explicit calls to ClassLoader.getParent()
> >>> (http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/f3cf7fd26baa/src/java.base/share/classes/java/util/ServiceLoader.java#l1062),
> >>> which, for a class realm, corresponds to the base classloader, i.e. the
> >>> bootstrap classloader. And since the Nashorn script engine factory was
> >>> loaded with the platform classloader, it is missed.
> >>>
> >>> It seems that the fix here would be to make all class realms have as
> >>> base classloader the platform classloader starting with JDK 9, instead
> >>> of the bootstrap classloader (there is a new utility method in
> >>> ClassLoader to obtain the platform classloader). I verified that this
> >>> solves the problem described in MANTRUN-200, but before I create an MNG
> >>> issue, I'm wondering if this is the correct approach.
> >>>
> >>> What do you think of this change to class realms? The other possibility
> >>> I can think of would be to have a way in the JDK to override the search
> >>> in named modules, so that our ClassRealm can also delegate to its parent
> >>> classloader. It is possible for unnamed modules (since the search
> >>> process then relies on the ClassLoader.getResources method, that can be
> >>> overriden) but it doesn't look like (and probably intentionally so) to
> >>> be possible for named modules.
> >>>
> >>> Guillaume
> >>>
> >>>
> >>> ---
> >>> L'absence de virus dans ce courrier électronique a été vérifiée par le 
> >>> logiciel antivirus Avast.
> >>> https://www.avast.com/antivirus
> >>>
> >>>
> >>> 

Re: Loading providers in named modules with ServiceLoader using a plugin class realm

[Guillaume Boué]

Le 25/06/2017 à 22:03, Chas Honton a écrit :

Under what circumstances would a plugin not want the platform classloader?

Chas


Thinking about this more, with the current situation, it actually means 
that potential providers, located in named modules loaded for example by 
Maven core classloader or extension classloader, will not be available 
to plugins using ServiceLoader. So this is bigger than platform 
classloader. As Robert said, I think there needs to be a way for plugins 
to know about modules.


Reading more into the docs, this may be possible using a ModuleLayer. 
Each plugin would have its own module layer composed of modules found in 
its dependencies. Their parent would be a module layer associated to 
Maven core, and its parent would be the boot layer. This would solve the 
ServiceLoader issue for named modules in a plugin realm, since it would 
locate providers in all modules in the module layer of the plugin, and 
then do the same for their parents, up to the boot layer. However, for 
it to work, I'm not sure if this implies that everything be made modular 
(plugins and Maven itself). I will try to do some testing on this.


Guillaume




On Jun 25, 2017, at 12:40 PM, Robert Scholte  wrote:

Hi Guillaume,

I don't know all the details about the Platform classloader, but it has been 
introduced with a reason.
So I don't think we should switch to it by default. I think the plugin is well 
aware which classloaders / modules it wants to use (it should be), so I think 
we need to find a mechanism for plugins to select their classloaders and 
modules.

thanks,
Robert


On Sun, 25 Jun 2017 17:19:07 +0200, Guillaume Boué  wrote:

Hi,

With the introduction of modules in JDK 9, there were changes with
regard to how classloading works, and this impacts class realms created
in Maven. Today, the parent (as per ClassLoader.getParent()) of a class
realm is null, which represents the bootstrap classloader. In JDK 9, the
change is that some classes were moved to a named module other than
java.base, and they are not loaded with the bootstrap classloader
anymore, but with the platform classloader (which was previously the
extension classloader, see JDK-814637).

This has consequences, like MANTRUN-200, where locating providers with
the ServiceLoader API, using the plugin class realm, will miss JDK
internal implementation classes. In the case of MANTRUN-200, it is
Nashorn of the jdk.scripting.nashorn module, that cannot be found
because of the way ServiceLoader works
http://download.java.net/java/jdk9/docs/api/java/util/ServiceLoader.html#load-java.lang.Class-java.lang.ClassLoader-.
During the search in named modules, the class realm will not be able to
use its strategy since that process relies on parent delegation
implemented as explicit calls to ClassLoader.getParent()
(http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/f3cf7fd26baa/src/java.base/share/classes/java/util/ServiceLoader.java#l1062),
which, for a class realm, corresponds to the base classloader, i.e. the
bootstrap classloader. And since the Nashorn script engine factory was
loaded with the platform classloader, it is missed.

It seems that the fix here would be to make all class realms have as
base classloader the platform classloader starting with JDK 9, instead
of the bootstrap classloader (there is a new utility method in
ClassLoader to obtain the platform classloader). I verified that this
solves the problem described in MANTRUN-200, but before I create an MNG
issue, I'm wondering if this is the correct approach.

What do you think of this change to class realms? The other possibility
I can think of would be to have a way in the JDK to override the search
in named modules, so that our ClassRealm can also delegate to its parent
classloader. It is possible for unnamed modules (since the search
process then relies on the ClassLoader.getResources method, that can be
overriden) but it doesn't look like (and probably intentionally so) to
be possible for named modules.

Guillaume


---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


-
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




-
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: Loading providers in named modules with ServiceLoader using a plugin class realm

[Chas Honton]

Under what circumstances would a plugin not want the platform classloader?

Chas

> On Jun 25, 2017, at 12:40 PM, Robert Scholte  wrote:
> 
> Hi Guillaume,
> 
> I don't know all the details about the Platform classloader, but it has been 
> introduced with a reason.
> So I don't think we should switch to it by default. I think the plugin is 
> well aware which classloaders / modules it wants to use (it should be), so I 
> think we need to find a mechanism for plugins to select their classloaders 
> and modules.
> 
> thanks,
> Robert
> 
>> On Sun, 25 Jun 2017 17:19:07 +0200, Guillaume Boué  wrote:
>> 
>> Hi,
>> 
>> With the introduction of modules in JDK 9, there were changes with
>> regard to how classloading works, and this impacts class realms created
>> in Maven. Today, the parent (as per ClassLoader.getParent()) of a class
>> realm is null, which represents the bootstrap classloader. In JDK 9, the
>> change is that some classes were moved to a named module other than
>> java.base, and they are not loaded with the bootstrap classloader
>> anymore, but with the platform classloader (which was previously the
>> extension classloader, see JDK-814637).
>> 
>> This has consequences, like MANTRUN-200, where locating providers with
>> the ServiceLoader API, using the plugin class realm, will miss JDK
>> internal implementation classes. In the case of MANTRUN-200, it is
>> Nashorn of the jdk.scripting.nashorn module, that cannot be found
>> because of the way ServiceLoader works
>> http://download.java.net/java/jdk9/docs/api/java/util/ServiceLoader.html#load-java.lang.Class-java.lang.ClassLoader-.
>> During the search in named modules, the class realm will not be able to
>> use its strategy since that process relies on parent delegation
>> implemented as explicit calls to ClassLoader.getParent()
>> (http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/f3cf7fd26baa/src/java.base/share/classes/java/util/ServiceLoader.java#l1062),
>> which, for a class realm, corresponds to the base classloader, i.e. the
>> bootstrap classloader. And since the Nashorn script engine factory was
>> loaded with the platform classloader, it is missed.
>> 
>> It seems that the fix here would be to make all class realms have as
>> base classloader the platform classloader starting with JDK 9, instead
>> of the bootstrap classloader (there is a new utility method in
>> ClassLoader to obtain the platform classloader). I verified that this
>> solves the problem described in MANTRUN-200, but before I create an MNG
>> issue, I'm wondering if this is the correct approach.
>> 
>> What do you think of this change to class realms? The other possibility
>> I can think of would be to have a way in the JDK to override the search
>> in named modules, so that our ClassRealm can also delegate to its parent
>> classloader. It is possible for unnamed modules (since the search
>> process then relies on the ClassLoader.getResources method, that can be
>> overriden) but it doesn't look like (and probably intentionally so) to
>> be possible for named modules.
>> 
>> Guillaume
>> 
>> 
>> ---
>> L'absence de virus dans ce courrier électronique a été vérifiée par le 
>> logiciel antivirus Avast.
>> https://www.avast.com/antivirus
>> 
>> 
>> -
>> 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
> 
> 


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

Re: Loading providers in named modules with ServiceLoader using a plugin class realm

[Robert Scholte]

Hi Guillaume,

I don't know all the details about the Platform classloader, but it has  
been introduced with a reason.
So I don't think we should switch to it by default. I think the plugin is  
well aware which classloaders / modules it wants to use (it should be), so  
I think we need to find a mechanism for plugins to select their  
classloaders and modules.


thanks,
Robert

On Sun, 25 Jun 2017 17:19:07 +0200, Guillaume Boué   
wrote:



Hi,

With the introduction of modules in JDK 9, there were changes with
regard to how classloading works, and this impacts class realms created
in Maven. Today, the parent (as per ClassLoader.getParent()) of a class
realm is null, which represents the bootstrap classloader. In JDK 9, the
change is that some classes were moved to a named module other than
java.base, and they are not loaded with the bootstrap classloader
anymore, but with the platform classloader (which was previously the
extension classloader, see JDK-814637).

This has consequences, like MANTRUN-200, where locating providers with
the ServiceLoader API, using the plugin class realm, will miss JDK
internal implementation classes. In the case of MANTRUN-200, it is
Nashorn of the jdk.scripting.nashorn module, that cannot be found
because of the way ServiceLoader works
http://download.java.net/java/jdk9/docs/api/java/util/ServiceLoader.html#load-java.lang.Class-java.lang.ClassLoader-.
During the search in named modules, the class realm will not be able to
use its strategy since that process relies on parent delegation
implemented as explicit calls to ClassLoader.getParent()
(http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/f3cf7fd26baa/src/java.base/share/classes/java/util/ServiceLoader.java#l1062),
which, for a class realm, corresponds to the base classloader, i.e. the
bootstrap classloader. And since the Nashorn script engine factory was
loaded with the platform classloader, it is missed.

It seems that the fix here would be to make all class realms have as
base classloader the platform classloader starting with JDK 9, instead
of the bootstrap classloader (there is a new utility method in
ClassLoader to obtain the platform classloader). I verified that this
solves the problem described in MANTRUN-200, but before I create an MNG
issue, I'm wondering if this is the correct approach.

What do you think of this change to class realms? The other possibility
I can think of would be to have a way in the JDK to override the search
in named modules, so that our ClassRealm can also delegate to its parent
classloader. It is possible for unnamed modules (since the search
process then relies on the ClassLoader.getResources method, that can be
overriden) but it doesn't look like (and probably intentionally so) to
be possible for named modules.

Guillaume


---
L'absence de virus dans ce courrier électronique a été vérifiée par le  
logiciel antivirus Avast.

https://www.avast.com/antivirus


-
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

Loading providers in named modules with ServiceLoader using a plugin class realm

[Guillaume Boué]

Hi,

With the introduction of modules in JDK 9, there were changes with
regard to how classloading works, and this impacts class realms created
in Maven. Today, the parent (as per ClassLoader.getParent()) of a class
realm is null, which represents the bootstrap classloader. In JDK 9, the
change is that some classes were moved to a named module other than
java.base, and they are not loaded with the bootstrap classloader
anymore, but with the platform classloader (which was previously the
extension classloader, see JDK-814637).

This has consequences, like MANTRUN-200, where locating providers with
the ServiceLoader API, using the plugin class realm, will miss JDK
internal implementation classes. In the case of MANTRUN-200, it is
Nashorn of the jdk.scripting.nashorn module, that cannot be found
because of the way ServiceLoader works
http://download.java.net/java/jdk9/docs/api/java/util/ServiceLoader.html#load-java.lang.Class-java.lang.ClassLoader-.
During the search in named modules, the class realm will not be able to
use its strategy since that process relies on parent delegation
implemented as explicit calls to ClassLoader.getParent()
(http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/f3cf7fd26baa/src/java.base/share/classes/java/util/ServiceLoader.java#l1062),
which, for a class realm, corresponds to the base classloader, i.e. the
bootstrap classloader. And since the Nashorn script engine factory was
loaded with the platform classloader, it is missed.

It seems that the fix here would be to make all class realms have as
base classloader the platform classloader starting with JDK 9, instead
of the bootstrap classloader (there is a new utility method in
ClassLoader to obtain the platform classloader). I verified that this
solves the problem described in MANTRUN-200, but before I create an MNG
issue, I'm wondering if this is the correct approach.

What do you think of this change to class realms? The other possibility
I can think of would be to have a way in the JDK to override the search
in named modules, so that our ClassRealm can also delegate to its parent
classloader. It is possible for unnamed modules (since the search
process then relies on the ClassLoader.getResources method, that can be
overriden) but it doesn't look like (and probably intentionally so) to
be possible for named modules.

Guillaume


---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

[ANN] Apache Maven Shared Component: Maven Reporting Impl Version 3.0.0 Released

[Karl Heinz Marbaise]

The Apache Maven team is pleased to announce the release of the 
Apache Maven Shared Component: Maven Reporting Implementation 3.0.0

https://maven.apache.org/shared/maven-reporting-impl/

You should specify the version in your project:
 

  org.apache.maven.reporting
  maven-reporting-impl
  3.0.0


You can download the appropriate sources etc. from the download page:
 
https://maven.apache.org/shared/maven-reporting-impl/download.cgi
 
Release Notes Maven Reporting Impl 3.0.0

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

Bugs:

 * [MSHARED-392] - AbstractMavenReportRenderer#applyPattern(String) chokes on 
some specific input and produces useless segments
 * [MSHARED-489] - AbstractMavenReportRenderer#linkPatternedText ignores name 
if href is invalid
 * [MSHARED-608] - Remove index.html-adding block in 
AbstractMavenReportRenderer#getValidHref()

Improvements:

 * [MSHARED-430] - Update JDK requirement to 1.6 / upgrade Maven Core 
dependencies to 3.0
 * [MSHARED-582] - Upgrade maven-shared-components parent to version 30
 * [MSHARED-583] - Make three digit version number
 * [MSHARED-642] - Upgrade to maven-shared-utils 3.2.0

Tasks:

 * [MSHARED-606] - Upgrade to Commons Validator 1.5.1
 * [MSHARED-609] - Partially revert MSHARED-429
 * [MSHARED-611] - Drop any href validation and pass as-is
 * [MSHARED-612] - Upgrade to Doxia 1.7
 * [MSHARED-613] - Upgrade to Doxia Sitetools 1.7.4
 * [MSHARED-614] - Upgrade to Maven Shared Utils 3.1.0

Wish:

 * [MSHARED-488] - Make input source file encoding default to platform encoding

Enjos,
 
-The Apache Maven team

Karl Heinz Marbaise

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

[GitHub] maven-plugins pull request #120: MJAVADOC-486 Upgrade to Doxia 1.7

[marschall]

GitHub user marschall opened a pull request:

https://github.com/apache/maven-plugins/pull/120

MJAVADOC-486 Upgrade to Doxia 1.7

Patch for https://issues.apache.org/jira/browse/MJAVADOC-486

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

$ git pull https://github.com/marschall/maven-plugins MJAVADOC-486

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

https://github.com/apache/maven-plugins/pull/120.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 #120


commit f83b2d1180fad6032a795919f4e7c0b7744168e6
Author: Philippe Marschall 
Date:   2017-06-25T11:47:03Z

MJAVADOC-486 Upgrade to Doxia 1.7

Patch for https://issues.apache.org/jira/browse/MJAVADOC-486




---
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

[GitHub] maven-plugins pull request #119: MJAVADOC-485 Upgrade to commons-lang3

[marschall]

GitHub user marschall opened a pull request:

https://github.com/apache/maven-plugins/pull/119

MJAVADOC-485 Upgrade to commons-lang3

Patch for https://issues.apache.org/jira/browse/MJAVADOC-485

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

$ git pull https://github.com/marschall/maven-plugins MJAVADOC-485

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

https://github.com/apache/maven-plugins/pull/119.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 #119


commit 6fb3bad87194efe3cfcce5f5787d0b18250a19d8
Author: Philippe Marschall 
Date:   2017-06-25T11:27:01Z

MJAVADOC-485 Upgrade to commons-lang3

Patch for https://issues.apache.org/jira/browse/MJAVADOC-485




---
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

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

[Karl Heinz Marbaise]

Hi,

The vote has passed with the following result:

+1 : Hervé Boutemy, Robert Scholte, Michael Osipov, Karl Heinz Marbaise

PMC quorum: reqched.

I will promote the artifacts to the central repo.

Kind regards
Karl Heinz Marbaise

-
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

[Karl Heinz Marbaise]

Hi,

+1 from me too.

Kind regards
Karl Heinz Marbaise
On 21/06/17 20:16, 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

Re: Maven release plugin

[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 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






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