modulepath and classpath mixture

[Ali Ebrahimi]

Just add these to Paul's response, what about multi-module apps? Do we
coming back to non-modular world?

On Wed, Mar 30, 2016 at 11:43 PM, Paul Benedict <pbenedict at apache.org>
wrote:

> Russell, you ask a good question. If an artifact is meant to be a module,
> wouldn't it make sense for it to run as a module during testing too? Those
> boundaries should be activated like they are in production to get good
> confidence in the code. Those are my two cents. I'd like to hear opposing
> opinions though why the boundaries shouldn't be there.
>
> Cheers,
> Paul
>
> On Wed, Mar 30, 2016 at 2:07 PM, Russell Gold <russell.gold at oracle.com>
> wrote:
>
> > Hi Paul,
> >
> > Why would you put your main code on the module path *during a unit test*?
> > It seems to me that unit tests are explicitly about making sure that the
> > code works, not the packaging. So you put both main and test code on the
> > classpath, and there is no problem. The unit test can be done before the
> > main code is packaged into a module.
> >
> > - Russ
> >
> > On Mar 30, 2016, at 10:47 AM, Paul Benedict <pbenedict at apache.org>
> wrote:
> >
> > Russell, if you have a module with package X and a classpath jar with
> > package X, the module can't see package X from the classpath.
> >
> > In the last several posts, there's been discussion on putting tests on
> the
> > classpath; keeping the "main" code in the module. So given what I stated
> > above, that's what I've been referring to.
> >
> > Cheers,
> > Paul
> >
> > On Wed, Mar 30, 2016 at 7:28 AM, Russell Gold <russell.gold at oracle.com>
> > wrote:
> >
> >> Hi Paul,
> >>
> >> Could you explain? What kind of code do you mean cannot access it? And
> >> what do you mean by “a split package situation”?
> >>
> >> From a conversation I had with Alan, earlier in this thread:
> >>
> >>
> >> On Mar 23, 2016, at 11:42 AM, Alan Bateman <Alan.Bateman at oracle.com>
> >> wrote:
> >>
> >> On 23/03/2016 14:15, Russell Gold wrote:
> >>
> >> Here are my assumptions, which you can correct.
> >>
> >> 1. A jar or classes directory placed on a class path are treated as part
> >> of the unnamed module
> >>
> >> Yes
> >>
> >>
> >> So if the tests and main code are both in directories, which they have
> >> been up to now in Maven, why would there be a problem? Both would be in
> the
> >> unnamed module and able to access one another.
> >>
> >> - Russ
> >>
> >> On Mar 29, 2016, at 10:47 PM, Paul Benedict <pbenedict at apache.org>
> wrote:
> >>
> >> Russell, when you drop a jar on the classpath, module code will not be
> >> able to access it in a split package situation. That's the big barrier
> >> here. Maven test projects are typically written with the same package
> >> shared with the "main" code.
> >>
> >> Cheers,
> >> Paul
> >>
> >> On Tue, Mar 29, 2016 at 11:33 AM, Russell Gold <russell.gold at oracle.com
> >
> >> wrote:
> >>
> >>> Hi Stephen,
> >>>
> >>> Why do you need any kind of friend access?
> >>>
> >>> It seems to me that this is making things harder than they need to be.
> >>> The tests can simply run with the production code on the class path,
> and
> >>> then there are no module issues at all.
> >>>
> >>> I think a larger problem is that you can do what I just said with the
> >>> jars, even a jar which has been designated as a module by virtue of
> having
> >>> a module-info.class in it. That means that, when users are up taking
> jars,
> >>> they are not prevented from accessing module internals. They can put
> the
> >>> jars on the module path, of course, but they can still use them on the
> >>> class path!
> >>>
> >>> - Russ
> >>>
> >>> >
> >>> > 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.
> >>> >
> >>> > 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).
> >>> >
> >>> > 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.
> >>> >
> >>> > Stephen
> >>> > (And to Paul Benedict, the classpath is going to die over time, so
> any
> >>> > solution that uses that is flawed IMO).
> >>> >
> >>> >
> >>> >> 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
> >>> >>>
> >>>
> >>
> >
>



-- 

Best Regards,
Ali Ebrahimi