Migrate build to "maven-publish" plugin

[aaschmid]

Finally got it running @codecholeric. But haven't had a look at the new "shadow" plugin and it's possibilities in order to get rid of dependencies removal in published poms, yet.

See commit message for still open points and tell me what you think about these as well as with I should get fixed.

You can check the results of a publish run at https://oss.sonatype.org/content/repositories/snapshots/com/tngtech/archunit/, version 0.13.0-SNAPSHOT or run publishToMavenLocal yourself. I also created a release (which is again dropped) and run checkUAr -PtngRepoId=1202 besides some pom formattings - at least as far as I could see manually ;-) - quite successfully IMO.
Note: Only thing was that I needed to run ./gradlew --no-parallel publish multiple times to have all artifacts in the OSS Sonatype repo but could not find out why this is the case ...

Unfortunately, the upgrade to Gradle version 5 (first commit) is required unless you want to add enableFeaturePreview('STABLE_PUBLISHING') to your settings.

[ghost]

Congratulations 🍻. DeepCode analyzed your code in 0.108 seconds and we found no issues. Enjoy a moment of no bugs ☀️.

💬 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.

[aaschmid]

BTW: I like the check logic for the upload quite much. Maybe I will use it for the junit-dataprovider as well some day ...

[aaschmid]

@codecholeric: Any feedback on this?

[codecholeric]

Thanks a lot for your support! 😃

I've rebased this against master and fixed some parts. To answer the questions from your commit message:

• I think we should keep the parallel check, because I've had many problems with broken uploads otherwise. I've improved it though, that it also detects if you run with --no-parallel
• I removed the distributed repackagesAsm. Seemed like a good idea at the time, but in fact it will always only be archunit that repackages ASM, any other ArchUnit artifact would simply depend on that within archunit. And it only affects license handling, so I think it's fine to keep it locally within license.gradle (the way you had it)
• I don't think we need the signing.dependsOn finishArchive, because the order seems correct anyway. publish depends on build and build on finishArchive, so I don't think we have a problem there anymore.
• I did not completely get your last point about "refactor code to use JUnit* module mechanism"

There is one problem left (maybe you know how to fix this out of your head?): In the JUnit 5 aggregator POM the scope of the runtime dependency archunit-junit5-engine is now suddenly compile instead of runtime like before ☹️

[aaschmid]

Thanks for the rebase and the reply.

There is one problem left (maybe you know how to fix this out of your head?): In the JUnit 5 aggregator POM the scope of the runtime dependency archunit-junit5-engine is now suddenly compile instead of runtime like before.

I think I know how to fix and will try during the next days.

[aaschmid]

868b6aa fixes your last issue. I (only) tested it locally by using your checkUploadedArtifacts with file:/home/user/.m2/repository/... :-)

In general, I think, we should migrate the whole project to java-library which has more features (see also https://docs.gradle.org/current/userguide/java_plugin.html) and interoperates better with maven-publish. I can do this if you want. I would also migrate the build to Gradle 6, if you agree.

[aaschmid]

Addtional note:

I had to use --no-build-cache in order to get reproducable results. As soon as I used the build cache I got blinking "tests" (= failing/succeeding checkUploadedArtifcats tasks) with:

There exists a third party folder. Expression: (jarFile.getEntry(com/tngtech/archunit/thirdparty) == null)

I haven't looked at the root cause intensively but on a quick look it turns up that addCleanThirdPartyTask could likely cause this behavior.

[aaschmid]

Follow up PR upgrading to Gradle 6 can be find on https://github.com/TNG/ArchUnit/tree/gradle.6

[codecholeric]

Looks good now 😄 I've tested it a little more as well, artifacts, manifests and POMs look good and the project where I tried the aggregator POM worked fine as well.
It's well possible, that there is something shifty going on with the cleanThirdPartyTask, that was always a little hacky ☹️ Maybe once we've migrated everything to Gradle 6 and java-library we can model this in a correct way and get rid of this abomination...
Anyway, thank you so much for your support! I'll look into the Gradle 6 upgrade ASAP, then we're finally current again 😄

[aaschmid]

@codecholeric: I just rebased the https://github.com/TNG/ArchUnit/tree/gradle.6 branch. I haven't had time to try to cleanup the dependencies more properly, especially test dependencies but IMO this should be done also.
The build is working on Gradle 6 branch and locally tests on the deployment also. Feel free to integrate it :-)

However, trying to further use the shadow plugin provided features was not successful yet (built poms are incorrect again; code in local stash...). And I also wanted to clean up / simplifiy the test dependencies which was not time for yet.