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 generated site from this br
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
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/
apidocs/index.ht
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 a
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.
Wha
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
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 us
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 feature
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 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 r
10 matches
Mail list logo
