Add archunit-junit5 pom aggregator

[eddumelendez]

Resolves #272

[ghost]

DeepCode's analysis on #8a7e45 found:

• ❌ 0 critical issues. ⚠️ 0 warnings and 0 minor issues. ✔️ 0 issues were fixed.

💬 This comment has been generated by the DeepCode bot, installed by the owner of the repository. The DeepCode bot protects your repository by detecting and commenting on security vulnerabilities or other critical issues.

---

☺️ If you want to provide feedback on our bot, here is how to contact us.

[rweisleder]

LGTM 👍
Thanks, @eddumelendez!

[codecholeric]

Thanks a lot for looking into this 😃 It seems to work, but I have two things to consider

a) I did get some exception during archunit-junit5:shadowJar, which actually did not let the build fail or broke the result, but we should still fix this (I did not see it in the console output of the Travis build though)
b) a bigger thing I wonder is, if we really want to create all those artifacts. I.e. now we create an empty JAR, and empty javadoc and an empty sources JAR. I've noticed that the JUnit team does the same, but I wonder why we would not simply use a POM of type pom? Similar to https://repo1.maven.org/maven2/com/google/guava/guava-parent/28.1-jre/. Shouldn't a simple POM without any artifacts attached to it also do the trick?

[eddumelendez]

@codecholeric the exception is displayed building against java 11 at least in my machine. You can see my findings below:

a) The new commit resolves the issue building against java 11. I couldn't upgrade to 4.0.4 due to one issue which was supposed to be fixed in that version but it wasn't until version 5.x. Upgrading to 5.x requires gradle version. I think there is more to see regarding this dependency upgrade. You can see more about shadow plugin building against java 11 in the release notes

b) That would be something that gradle understand and can resolve the dependencies but maven users will need to specify an additional line type meanwhile gradle users will not. Keeping the jar will benefit both.

[codecholeric]

@eddumelendez ah, cool, thanks a lot for looking into this 😄

a) Yes, we need to upgrade Gradle ☹️ Luckily there is light at the horizon thanks to @aaschmid (see #192)
b) Okay, I didn't consider the implication with the additional type 😉 Since the aggregator POM strives only to make including ArchUnit as simple as possible, I agree! It's probably best to produce the triplet of JAR, sources JAR and javadoc JAR then...

[codecholeric]

I have looked over it, looks good now 😄
I noticed that the upgraded Shadow plugin now was "too good" 😉 (started to aggregate some 3rd party stuff into archunit-junit5.jar) I've adjusted the config to simply exclude everything. Seems reasonable now, three empty JARs with just a Manifest and a POM with the correct dependencies.
I've adjusted the Maven integration test to now test JUnit 5 with the new aggregator dependency and it seems to work.
So thank you so much for your support!! 😃 Gonna merge it now...