On Tue, 22 Mar 2016 13:06:05 +0100, Peter Levart <peter.lev...@gmail.com>
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?
Yes, that's why. The success of modularization depends on the ease of
migration. Javac already comes with a lot of options and flags to make
this possible, it is Mavens task to set these with the right values. My
current opinion is that I don't want to force users to add module-info
files to the test sources, but the module structure of the main sources
should be respected.
If you want a separate module for testing, that's up to you. If people
want to patch the main module, that fine too. If javac supports it, then
Maven should support that too.
thanks,
Robert
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.
It would only be possible to specify "private" keyword with qualified
exports - not with unqualified.
Would that be against any jigsaw goals?
Regards, Peter
