modulepath and classpath mixture

[Alan Bateman]

On 23/03/2016 14:42, Stephen Colebourne wrote:
> :
>
> I don't particularly care what the mechanism is for this, but at the
> requirements level:
> - there are two modules - main and test
> - each has its own source tree
> - each has its own dependencies
> - each is released separately
> - each could be hosted on a central repo
> - the test module needs to be able to contain the same packages as the
> main module
> - the test module needs to be able to invoke package-scoped code in
> the same package in the main module
>
> To clarify further consider 4 modules, A, B, A-test and B-test where B
> depends on A. Module A-test may have a method foo() that uses package
> scope to access something in A. Module B-test will depend on A-test
> and rely on foo() to get access to that internal object.
To your list, I would add the ability to make use of testing frameworks 
like TestNG and JUnit.

In any case, and as things currently stand, you've got most of the 
above. One differences is that the tests are not a separate module, they 
are instead compiled and run in a way that patches the main module. The 
second difference is that they don't have their own module declaration, 
instead the compilation or run augments the dependences with any 
additional dependences that the tests have. As I said, if they tools 
makes it easy then I don't think it's too bad.

>
> (Note that I view the thread discussion of
> references to test classes on the classpath as another hack.
>
Packages can't be split between modules and classpath so there is no 
support for that.

-Alan