Yikes, that sounds similar to OSGi. Adding modules makes testing into more of an integration exercise since traditional JUnit usage assumes a flat class path.
On Sun, May 17, 2020 at 00:10 Ralph Goers <ralph.go...@dslextreme.com> wrote: > I played around with this today. I don’t think it is possible to make the > tests work. The reason is that from what I understand the multi-release > format only works when the classes are packaged in a jar, which hasn’t > happened when the tests are compiled. This causes the compile to fail since > it can’t find the Java 9+ classes. > > The only way around that would be to package the files in a jar before > running the tests, which is opposite of what Maven is trying to do. > > Ralph > > > On Apr 11, 2020, at 9:39 AM, Matt Sicker <boa...@gmail.com> wrote: > > > > I was playing around with the pom a little bit yesterday when I came > > across a relatively new maven-compiler-plugin configuration element > > called <multiReleaseOutput> which can be used to output the compiled > > classes relative to META-INF/versions/N rather than the root. This > > looks like it would likely remove the need to use > > maven-assembly-plugin as an intermediary step. > > > > I found an interesting approach linked in [1] as the multi-release > > parent strategy with source code at [2]. I attempted to refactor > > log4j-api to use this pattern, but I couldn't figure out how to make > > the same pattern work for test classes (which made it impossible to > > compile log4j-api/src/test/java9). > > > > I'm going to continue experimenting a bit with this, but has anyone > > tried out the more recent multi-version tooling support? We were early > > users of some things, so I'd imagine tooling has caught up by now. > > > > [1]: > https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html > > [2]: > https://github.com/meterware/multirelease-parent/blob/master/pom.xml > > > > -- > > Matt Sicker <boa...@gmail.com> > > > > > -- Matt Sicker <boa...@gmail.com>
