Hello,

Robert Scholte <[email protected]> schrieb am Do., 24. Nov. 2016 um
20:44 Uhr:

> Hi Benedikt,
>
> I noticed a new thread on the jigsaw mailinglist[1].
> It is close related to the issue I have: you don't want to "patch" java
> with arguments just to allow split packages for certain modules. I really
> hope that by chaining classloaders we can prevent this.
>

Thank you Robert. I've also forwarded this to the JUnit team.

Benedikt


>
> Robert
>
> [1]
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-November/010233.html
>
> On Tue, 22 Nov 2016 20:51:44 +0100, Benedikt Ritter <[email protected]>
> wrote:
>
> > Hello again,
> >
> > Benedikt Ritter <[email protected]> schrieb am Fr., 18. Nov. 2016 um
> > 08:40 Uhr:
> >
> >> Hi,
> >>
> >> I had the pleasure to meet Robert Scholte and Herve Boutemy here at
> >> ApacheCon in Seville. We talked al little bit about the progress of the
> >> JUnit 5 integration. This let us to create two sample projects which may
> >> indicate problems both within surefire and within JUnit. We're still
> >> investigating whether this are really issues. I'm in contact with the
> >> JUnit
> >> team to find out what they might need to fix and I'm reaching out to the
> >> Maven community to find out what we need to fix.
> >>
> >> The first sample project is https://github.com/britter/junit-cl
> >> It uses the configuration described at
> >>
> http://junit.org/junit5/docs/snapshot/user-guide/#running-tests-build-maven-engines-configure
> >> to
> >> configure the JUnit Jupiter test engine to run some tests. What we want
> >> to
> >> find out is, whether the test class can see the classes of the test
> >> engine
> >> (which they should not) and whether the production classes can see the
> >> test
> >> classes or the test engine classes (which they should not). This is what
> >> Robert called the "classpath problem", because everything in mangled
> >> together in one classpath. This probably needs to be fixed inside JUnit.
> >> Unfortunately currently the configuration described in the JUnit docs
> >> does
> >> not work. So instead of configuring the jupiter engine, it just reports
> >> that it can not find any engines.
> >>
> >
> > I've fixed the problem. The build now works an it fails for the right
> > reason :-)
> >
> > I tried to explain this problem to Marc Philipp from JUnit but I failed
> > to
> > understand why this is an issue at all. I mean, okay it may be cleaner if
> > we had separate classloaders, but what would be a really error scenario a
> > user might encounter when the same Classloader loads production and test
> > classes?
> >
> >
> >>
> >> The second example is https://github.com/britter/junit-java9 and it is
> >> about JUnit and Java 9 modules. Robert was sure that there is a problem
> >> with modules and that it needs to be fixed in surefire. However we did
> >> not
> >> get that example working at all, so Robert decided to investigate this
> >> some
> >> more when he is back home.
> >> Here is what we expect to fail: Suppose we have a package com.example
> >> with
> >> some classes. Then we add some tests in src/test/java in the same
> >> package.
> >> When we compile this and execute the tests, Java 9 should report that
> >> there
> >> are several jars providing classes for the com.example package.
> >>
> >
> > I've also applied the fix from above to the java9 example.
> >
> > Marc Philipp and I agreed upon tackling the Java 9 issue from both (maven
> > and junit) sites. He will talk to Sam Brannen from the Spring project and
> > ask them how they do reflection in Java 9. Furthermore he things about
> > writing to the OpenJDK Mailing list.
> > On the Maven site, Robert wanted to take a look into this. @Robert: Did
> > you
> > have some time to investigate this some more?
> >
> > Regards,
> > Benedikt
> >
> >
> >>
> >> Hope I was able to give you a heads up on what we were talking about :-)
> >>
> >> Regards,
> >> Benedikt
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

Reply via email to