My experience is that most people are application developers and MR JARS
are meant for libraries, not applications.
And even for libraries you often don't need to turn it into a MRJAR.
Only for those "special" libraries it might make sense, but I consider
these specials and their developers are often Java specialists. I would
expect from them to understand the requirements and consequences of MR
Jars.
As described, testing is the hardest part and there's just no "best"
strategy. Every MR JAR library must decide what's their best fit.
One way or another, you must execute your tests with all specified Java
versions and Maven is not going to dictate that.
For example: plexus-java is a multi-release jar, which relies heavily on
the CI-server. When it runs on Java 7, it is building and testing only
Java7 related code. For 9+ it builds the complete project.
Trying to solve this with toolchains is possible, but requires a specific
setup by the developer. None of the solutions could be solved by a simple
surefire improvement.
Unless I've overseen a option, I don't see any way how to solve this "by
default"/"out-of-the-box" with surefire. I would expect that Maven needs
to be improved first to understand this concept.
Robert
[1]
https://github.com/codehaus-plexus/plexus-languages/tree/master/plexus-java/src/main
On Thu, 04 Apr 2019 20:00:33 +0200, Russell Gold <[email protected]>
wrote:
Yes, I know that’s how it works. The question is, how will developers
use it? If MR jars are common, many developers will run into this
problem, and it would be nice if Maven handled it by default. If it’s
not common… those of with the issue will need to find workarounds. I
have two open-source projects that create MR jars at present.
On Apr 4, 2019, at 1:29 PM, Robert Scholte <[email protected]> wrote:
The specification you're talking about is the Multi Release Jar, and
especially the last word is important: Jar.
This only works with Jars and with a MANIFEST file containing
Multi-Release: true
Compiling and packaging has never been the issue, the tricky part is
testing.
If you want to test the jar, you must use the failsafe plugin (or bind
surefire to the integration-test phase)
All is described on the multirelease page of the
maven-compiler-plugin[1]
thanks,
Robert
[1]
https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html
On Thu, 04 Apr 2019 18:14:58 +0200, Russell Gold
<[email protected]> wrote:
As of 3.8.0, the maven-compiler-plugin will place javaNNN source under
META-INF/versions/NNN, which makes them ready for the jar plugin. But
the surefire plugin ignores them! Is there a way to get the surefire
plugin to run against them? They would need to be added on the class
path ahead of the main output directory. I tried the
<additionalClasspathElements> setting, but that adds them later on the
path, which is worthless.
Or the tests could run against the built jar, but that violates the
maven lifecycle order.
My multirelease parent strategy doesn’t seem to work well for the
multi-module case, as it can either build the MR jar normally, letting
later modules test against it (but breaking the MR module’s unit
tests), or copy the META-INF/versions classes into the output
directory, letting the module’s unit test use them, but breaking jar
building.
I can see making the configuration much more complex, but it would be
easier if there was a way to get the surefire plugin to recognize MR
modules.
Thanks,
Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
