Junit5: Package junit-platform-console as a fat JAR

[aalmiray]

https://github.com/johnrengelman/shadow plugin can be used to achieve this goal. This plugjn is capable of merging metadata files (such as META-INF/services) and others. It's also friendly with the application plugin; it can produce an executable fat jar when both plugins are applied.

[sormuras]

Related to #146 ?

[sbrannen]

@sormuras, yes this is related to #146.

In contrast to #146, this issue proposes a fat JAR instead of a ZIP for distributing the Console Runner.

[aalmiray]

Be aware that both fat JAR and ZIP options can be had when applying application and shadow plugins.

[sbrannen]

@aalmiray, I just tried it out...

java -jar junit-console-5.0.0-SNAPSHOT-all.jar -a

Works like a charm! 👍

[sbrannen]

Yes, I _meant_ to say "this issue proposes a fat JAR _in addition to_ a ZIP for distributing the Console Runner". 😉

[sormuras]

Great! One JAR to test 'em all. :guitar:

Perhaps that JAR can also be used as a single classpath entry for manually managed projects -- just like the plain old junit-4.x.jar.

[sbrannen]

Perhaps that JAR can also be used as a single classpath entry for manually managed projects -- just like the plain old junit-4.x.jar.

Yes, AFAIK, that should also work.

[sormuras]

Nit: the JAR names contains console and all. IMHO, it could be destilled down to junit-5.0.0-SNAPSHOT-all.jar or even smaller junit-5.0.0-SNAPSHOT.jar ... which then really comes close the well-known naming pattern used in 4.x releases. Imaging a junit-5.0.0.jar release...

[aalmiray]

given the existence of junit5-console-x.y.z-all.jar, is it deemed necessary to publish plain junit5-console-x.y.z.jar to a maven repo too? IOW, should the project junit5-console publish only the fat JAR?

[aalmiray]

configuring the baseNameand classifier properties on the shadowJar task would do the trick, for example

shadowJar {
  baseName = 'junit5'
  classifier = ''
}

would generate a junit5-<version>.jar fat JAR.

[sbrannen]

I'm in favor of only publishing the fat JAR variant of the Console Runner and dropping the classifier as you have suggested above.

But let's see what the rest of the @junit-team/junit-lambda has to say.

[sormuras]

I'm with @sbrannen -- and as a side effect, it solves #146 in elegant way.

[marcphilipp]

I think we should keep the name junit-console (instead of junit) to avoid confusion. I would be ok with only publishing the fat JAR if we didn't have dependencies on it. However, our Gradle plugin adds it as a testRuntime dependency. Therefore, I think a junit-console-all-5.0.0-SNAPSHOT.jar is the way to go.

[sbrannen]

Yeah, it's a bit unfortunate that JUnit5Plugin adds junit-console as a testRuntime dependency since that would automatically pull in JUnit 4 if junit-console were a fat JAR. 😞

With that in mind, I agree that we need to have to distinct JARs for the console runner for the current implementation of the JUnit5Plugin.

However, it makes me wonder if we shouldn't revise the JUnit5Plugin so that it automatically disables use of the JUnit4TestEngine if runJunit4 is set to false (which is the default).

[smoyer64]

Unless there are technical problems with it, I'd like to recommend Simon Tuff's One-JAR classloader as opposed to a simple fat JAR. I've only used it manually and via Maven but there's a Gradle plugin at https://github.com/rholder/gradle-one-jar.

[aalmiray]

among other considerations are:

• one-jar license must be compatible with EPL, see http://one-jar.sourceforge.net/index.php?page=documents&file=license
• custom classloader, will it work in an OSGi environment? see #195

[marcphilipp]

I'll get in touch with @pholser (the author of jopt-simple) to see if he's ok with us distributing his library in ZIP/JAR.

[pholser]

@marcphilipp OK by me.

[nipafx]

While the console runner is important now, I'm sure it will be way less relevant once major IDEs and tools have built-in JUnit-5-support. The JAR names should be chose accordingly.

In the future the vast majority of projects should only depend on junit-5-api. So if any one JUnit 5 module gets promoted to junit-5 it should be this one. I hence think that the fat JAR's file name should include console in one way or other. Otherwise users might get confused and add it as a test dependency instead of the junit-5-api.

[sbrannen]

Just to be perfectly clear, I was not suggesting that we change the baseName for the junit-console artifact to just junit.

I am personally not in favor of any artifact named simply junit-5.0.0.jar.

[sbrannen]

Assigned to M2 for now.

[marcphilipp]

Team decision:
We will publish an additional artifact that includes console + dependencies, jupiter, and vintage. called junit-console-x.y.z-standalone.jar.

[sormuras]

Does the decision imply the removal of the ZIP-based distribution?

[marcphilipp]

Yes, it does.

[sormuras]

Then, I'll enhance PR https://github.com/junit-team/junit5/pull/633 to include the removal of the ZIP distro.

[marcphilipp]

Thanks! 👍

[sbrannen]

We will publish an additional artifact that includes console + dependencies, jupiter, and vintage. called junit-console-x.y.z-standalone.jar.

@junit-team/junit-lambda

Did we agree to call it junit-console-x.y.z-standalone.jar or junit-platform-console-x.y.z-standalone.jar?

I'm in favor of the latter, since the module itself is aptly named junit-platform-console.

[sormuras]

Let's clarify the x.y.z part, too: use the main project version 5.0.0 or the platform version 1.0.0 ?

[sbrannen]

It is an artifact for a _Platform_ module that happens to include Jupiter and Vintage modules.

So, following that logic, the only version that makes sense is the platform version.

[sbrannen]

In other words, the first GA release of this artifact would be called junit-platform-console-1.0.0-standalone.jar.

[sbrannen]

Though, now that I think about it -- in order to align with Maven versioning semantics -- I believe it should actually be called junit-platform-console-standalone-1.0.0.jar.

@junit-team/junit-lambda, thoughts?

[sormuras]

In other words, the first GA release of this artifact would be called junit-platform-console-1.0.0-standalone.jar.

Updated #633 accordingly, see screenshot in the description:

Though, now that I think about it -- in order to align with Maven versioning semantics -- I believe it should actually be called junit-platform-console-standalone-1.0.0.jar.

iirc, that indicates an entire and self-contained module with the base name of junit-platform-console-standalone. The former feels more like "an additional artifact" of the already existing module junit-platform-console.