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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

Re: Maven release plugin

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