Re: Releasing Maven Resolver 1.1.0

2017-05-29 Thread Stephen Colebourne
The module name should in almost all cases be the super-package of the project. Don't use underscores in the module name unless they are also used in the package name. If the super-package is "org.apache.maven.resolver.api" then that is what the module name should be. But if the super-package is

[GitHub] maven-surefire pull request #151: Fixing build on Windows cmd.exe.

2017-05-29 Thread Tunaki
Github user Tunaki closed the pull request at: https://github.com/apache/maven-surefire/pull/151 --- 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

Re: Releasing Maven Resolver 1.1.0

2017-05-29 Thread Robert Scholte
This makes it an interesting case :) In short: the name "Aether" is owned by Eclipse and we are not allowed to use it. However, we are allowed to use these packages for compatibility reasons as long as needed. Module names are not part of this compatibility requirement, so we shouldn't

Re: Releasing Maven Resolver 1.1.0

2017-05-29 Thread Stephen Colebourne
Well, you have my opinion. I don't think there is an exemption here just because the component has a tricky history, and I personally think that any exemption for the package name necessarily applies to the module name (since it is now generally agreed that the module name derives from the package

[GitHub] maven-plugins pull request #114: Add support for "parameters" flag

2017-05-29 Thread snicoll
GitHub user snicoll opened a pull request: https://github.com/apache/maven-plugins/pull/114 Add support for "parameters" flag This requires a change in plexus compiler first, see https://github.com/codehaus-plexus/plexus-compiler/pull/29 You can merge this pull request into a Git

Re: Releasing Maven Resolver 1.1.0

2017-05-29 Thread Robert Scholte
How about ignoring the testutil? It should never become a runtime dependency, so I don't expect any project will refer to it, hence why give it a module name? Robert On Tue, 30 May 2017 01:26:52 +0200, Hervé BOUTEMY wrote: commit proposed in a new branch and

Re: Releasing Maven Resolver 1.1.0

2017-05-29 Thread Hervé BOUTEMY
another complementary reaction while reviewing consistency between java package names and modules names: perhaps we should change org.apache.maven.resolver.testutil to org.apache.maven.resolver.internal.test.util Regards, Hervé Le mardi 30 mai 2017, 00:50:51 CEST Hervé BOUTEMY a écrit : > one

Re: Releasing Maven Resolver 1.1.0

2017-05-29 Thread Hervé BOUTEMY
one associated question I had in mind: how do we document to end users what are the module names? Should we add a report to MPIR? And how could this report work, particularly on Automatic Module Name? I'm torn on choosing module name for this component: I think I understand Stephen's logic.

Re: Releasing Maven Resolver 1.1.0

2017-05-29 Thread Hervé BOUTEMY
commit proposed in a new branch and generated site from this branch published for review: - aggregated javadoc https://maven.apache.org/resolver-archives/resolver-LATEST/apidocs/index.html - API javadoc https://maven.apache.org/resolver-archives/resolver-LATEST/maven-resolver-api/

[GitHub] maven-plugins pull request #114: Add support for "parameters" flag

2017-05-29 Thread asfgit
Github user asfgit closed the pull request at: https://github.com/apache/maven-plugins/pull/114 --- 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