On 03/22/2016 07:06 AM, Peter Levart wrote:
On 02/24/2016 08:30 PM, Robert Scholte wrote:
On Wed, 24 Feb 2016 09:52:06 +0100, Alan Bateman
<alan.bate...@oracle.com> wrote:
On 23/02/2016 21:10, Robert Scholte wrote:
:
If I understand this correctly I need to know the module name.
Has there been any discussion around having the module name in the
POM? From the mails then it sounds like the project is mostly
"unaware" that it is creating a module. The other thing that comes to
mind is the source layout and whether it will get to the point where
the module name is in the file path. I'm mostly thinking of multi
module projects where one might have the source to multiple modules
in the same source tree.
-Alan
The name of the module with not end up in pom-4.0.0, it'll simply
break the xsd and would have effect on all other tools/IDEs/etc
depending on the pom.
The only place where one might specify the module name is in the
configuration of the maven-compiler-plugin.
In Brussels we talked about multimodules, but it makes more sense that
1 Maven project contains zero or one module-info[1].
And yes, I think a MavenProject will probably be unaware of its own
module name. It knows its source roots and outputdirectories (for both
main/java and test/java) and the packaged jar. Based on the
availability of the module-info in one of these locations it knows how
to construct the commandline arguments.
At least, this is what I'm hoping to achieve.
thanks,
Robert
[1] https://twitter.com/rfscholte/status/694599731515899904
Hi Robert,
Why do you want to support tests that "inject" classes into packages of
main artifact? Is this mainly because that's how it is done today? With
modules I would rather create tests in its own module and use qualified
exports from otherwise concealed packages of main module to give tests
access to types that are not accessible otherwise. This however means
that main module would have to use public qualifier on types and members
to allow test module to access them. In effect substituting the
package-private-nes with partly concealed packages to enable testability.
Perhaps jigsaw should realize that testabililty is an important aspect
to support. Forcing tools to compile a suitable set of javac and java
options to compile or inject new classes into an existing module and
augment it's dependencies is not very pleasant. Maybe this could be
supported with a little twist to the accessibility rules. Let me borrow
a rough idea that already circulated this list a while ago and modify it
to fit on the top of jigsaw accessibility rules.
Suppose that a qualified export of a package to the specific module(s)
could be augmented with say a "private" keyword:
module my.mod {
requires ...;
export private my.mod.internal to my.mod.test;
}
module my.mod.test {
requires my.mod;
requires junit;
}
...which would not only export the package to the specific module(s),
but also enable access to package-private types/members of that package
from the target module(s) as though those types/members were public for
them and for them only.
FWIW This is something I've been asking for in the JPMS EG. I think
this would be an incredibly powerful and useful security tool... and
could also potentially eliminate lots of "shared secrets" from the JDK
code base (and a few others as well). Not just for tests but also for
other existing code bases which today have to rely on
privacy-by-convention/documentation for this kind of sharing.
It would only be possible to specify "private" keyword with qualified
exports - not with unqualified.
Would that be against any jigsaw goals?
Regards, Peter
--
- DML
