modulepath and classpath mixture

[Paul Benedict]

Remi, it's really untenable to give tests a different version. Tests are
currently built under the same version as the main project under one master
parent project. Split packages are still going to be a necessary because
that's the world of thousands of existing projects. So that might be
against jigsaw canon but hopefully a compromise can be found.

Cheers,
Paul

On Tue, Mar 29, 2016 at 10:41 AM, Remi Forax <forax at univ-mlv.fr> wrote:

>
>
> ----- Mail original -----
> > De: "Stephen Colebourne" <scolebourne at joda.org>
> > À: "jigsaw-dev" <jigsaw-dev at openjdk.java.net>
> > Envoyé: Mardi 29 Mars 2016 15:24:15
> > Objet: Re: modulepath and classpath mixture
> >
> > On 28 March 2016 at 11:13, Remi Forax <forax at univ-mlv.fr> wrote:
> > > Hi Stephen, Hi all,
> > > I think that delivering tests as a separated module is a bad idea.
> > >
> > > I see that from the point of a developer, seeing the code and the test
> as
> > > different modules can be attractive because everything seems to be put
> at
> > > the right place but there is a big drawback. Because modules are
> reified
> > > at runtime, it means that the runtime environment of the tests will be
> > > different from the production environment.
> >
> > This last sentence doesn't make sense to me - tests are not run in a
> > production environment.
>
> yes, you just want your tests to run in a runtime which is as close as
> possible to the runtime of the production environment.
> It's like when a test fails because JUnit calls the test concurrently when
> in production the code always run under a giant lock.
>
> >
> > Tests have all the qualities of modules - code, dependencies,
> > compilation phase, deployment. The only special part is the need for
> > special "friend-like" access, which Jigsaw already has for other cases
> > (the export...to clause).
>
> You also need to support split packages or a kind of export...to that
> allows to export package private method as public.
> These are two major deviations from the jigsaw canon.
>
> Instead of considering tests as a separated module, i prefer to consider
> them as a separated version (1.0 vs 1.0-test),
> the test version includes the code, the tests, and have several more
> dependencies on JUnit like modules.
>
> >
> > Put simply, I consider that module =
> > deployment-artifact-with-dependencies. With that mental model, putting
> > tests inside the module is just not acceptable, because tests should
> > not be deployed with the main application and they have different
> > dependencies. If we disagree that module =
> > deployment-artifact-with-dependencies, then perhaps we have bigger
> > problems to solve here.
>
> We agree that a module = deployment-artifact-with-dependencies, but we
> disagree because for me the test should be a module with the same name but
> a different version (by example with a test suffix) while you think it
> should be a different module.
>
> >
> > Stephen
> > (And to Paul Benedict, the classpath is going to die over time, so any
> > solution that uses that is flawed IMO).
>
> I don't think the classpath will die but if you want to use things like
> jlink, it will not work if you have jars in the a classpath.
>
> Rémi
>
> >
> >
> > > So as Alan said, from the jigsaw point of view at runtime, the tests
> and
> > > the code should be in the same module.
> > >
> > > So the building tools have to come with a way to support to have 2
> > > different module-info.java in two different folders and package them as
> > > one module,
> > > maybe javac should help by providing a way to merge 2 module-info at
> > > compile time.
> > >
> > > Rémi
> > >
> > > ----- Mail original -----
> > >> De: "Alan Bateman" <Alan.Bateman at oracle.com>
> > >> À: "Stephen Colebourne" <scolebourne at joda.org>, "jigsaw-dev"
> > >> <jigsaw-dev at openjdk.java.net>
> > >> Envoyé: Mercredi 23 Mars 2016 16:18:50
> > >> Objet: Re: modulepath and classpath mixture
> > >>
> > >>
> > >> 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
> > >>
> >
>