deploy the jars on central repo (Maven or other)

[vincent-fuchs]

Hi,

One thing that I feel would help people to experiment various things with Zally would be to publish the jars on a central repository (Maven central or another, doesn't make much difference - but I see there's already a zalando namespace existing on https://mvnrepository.com/artifact/org.zalando )

The advantage of such approach is that we can reuse very easily all Zally components in a different context. It's the approach I've followed on some of my projects, (see https://github.com/societe-generale/github-crawler#extending-the-crawler-and-contributing-to-it- for an example) : for instance, I could reuse part of your github-integration components into my existing custom webhooks.

Also, that would be one way of implementing #560 to use easily custom rules : start the application "from the imported jar" , use Spring Boot conditional beans to load Zalando and/or Zally rules by default, if no other RuleSet is provided in the config.
If I want to use my own RuleSet, then I instanciate it (potentially mixing some out of the box rules from the jar, with mine that are in a separate jar or declared in my custom project) - similar to what I do in this custom project : using the jar of the "official" project mentionned previously, I instanciate a customOutput that takes precendence on the default one.
And the day you publish a new Zally version, all I need to do is to upgrade the Zally dependency version on my side.

I've done it in a couple of projects using Maven and Travis-CI, where the jars get deployed when the code is tagged. It's a good opportunity for me to learn to do the same with Gradle, so let me know if you would you be interested in a PR implementing that change, I can probably take care of it !

Thanks

Notes

• Need Change package name from "de.zalando" to "org.zalando"  #1157 first

[natrem]

I propose to follow Vincent's example on his projects:

• update the build.gradle to declare the release repositories
• add a few secrets in Travis (maven central credentials and signature) --> your job ;)
• perform the build in 2 steps:
  1. equivalent of mvn release:prepare that builds the project and add a tag
  2. let Travis react on tag to call equivalent of mvn release:perform

There are other examples available online but for a project with "not-too-frequent" releases this allows control and ease of use once it's set.

@roxspring @maxim-tschumak @zeitlinger would you be ok with that?

[roxspring]

Clearly one of the Zalando team needs to find/create appropriate credentials, which may have an impact on the repository we publish to. Looking at other Zalando open source projects it appears opentracing-sqs-java might offer some inspiration. Hopefully one of the Zalando team can pitch in with some answers here.

I'm not certain about the next steps. Not least I'm unclear on the Gradle equivalents of the maven release plugin! But once the credentials are in place I figure we can try something along these lines and iterate if it's not right. I'm happy to help any way I can.

Hopefully we will eventually get to a point where every master build publishes a SNAPSHOT, release builds are easily triggered by pushing a tag, and releases can be an easy-and-often affair.

[vincent-fuchs]

A couple of useful links, when I needed to do this on my projects last year (it's maven based instead of gradle, but there's still some useful infos on how t configure travis, the env variables you need to declare etc :

• https://www.phillip-kruger.com/post/continuous_integration_to_maven_central/
• https://dzone.com/articles/publish-your-artifacts-to-maven-central
• http://www.debonair.io/post/maven-cd/

One thing that we need to do for the jars to be accepted on Maven central : we also need to publish the javadoc for each version. For Kotlin, you can have a look at Dokka (https://github.com/JetBrains/kotlin-examples/blob/master/gradle/dokka-gradle-example/build.gradle)

Not sure how you want to manage it internally in Zalando, but if you don't have a personal OSS Nexus account, you'll need to create one, then one of the owners of Zalando group in Nexus will need to create a ticket asking them to add you in the group - here's an example : https://issues.sonatype.org/browse/OSSRH-46504

[maxim-tschumak]

@vincent-fuchs @natrem @roxspring I'm happy to do this! Hopefully, I can start already this week. I'll keep you posted.

[roxspring]

• chore(server): Build source jars #978 introduces the source jars as required.
• chore(server): Build javadoc jar #979 attempts to introduce javadoc jars but they're incomplete - see PR for details.

[maxim-tschumak]

Update from my side: I'm currently in the process of setting up a Sonatype Maven account, it can take some days...

[maxim-tschumak]

I've got a Sonatype OSS account and could technically proceed with the task. Unfortunately, I don't have time for this and have to put this on hold (for now).

[vincent-fuchs]

@natrem : do you think you could help ? I assume there's mainly the part around Gradle's way of doing "maven release" left.. once it's there, @maxim-tschumak would be able to do some tests after configuring few things in Travis.

[natrem]

After some test I have a sample partially working for sonatype deployment.

My sample project is built on travis and published on sonatype.

This is for the publication part but not the versioning nor the 'trigger a release from a tag'

I could make a PR for this part but I won't be able to test it so I'm not completely fond of it (also ok to do it if you're ok with that).

[maxim-tschumak]

@natrem Great! Please create a PR.

[vincent-fuchs]

so what is left to do on this issue ? just update the Travis config with a deploy section, to push the jars when we push a tag, no ? something similar to this

[roxspring]

@maxim-tschumak, @tkrop, @zeitlinger is there anybody inside that can move this further forward? Seems everything that can be done from outside Zalando has been but we need somebody on this inside to join the final dots.

Once we have publishing infrastructure nailed down then it also opens up the door to also opens the door to implementing Maven and/or Gradle plugins (as mentioned in Gitter) that people could use without having to build them locally.

[roxspring]

One more thing on this topic: It looks like JitPack can't be our solution for jar deployment right now either as it doesn't work. I think it's failing to decide whether to build from the server vs github-integration. We could address this by adding a custom command or alternatively we could remove the GitHub integration from the primary repo seeing as I don't think anybody is using it yet anyway??

Obviously deploying to maven central dodges this problem for the official builds, but it might be worth fixing this for fork builds anyway.

[zeitlinger]

I'm all for removing the GitHub integration - it's probably not working anymore.

…

On Mon, Feb 10, 2020, 22:16 Rob Oxspring ***@***.***> wrote: One more thing on this topic: It looks like JitPack can't be our solution for jar deployment right now either as it doesn't work. I think it's failing to decide whether to build from the server vs github-integration. We could address this by adding a custom command <https://jitpack.io/docs/BUILDING/#custom-commands> or alternatively we could remove the GitHub integration from the primary repo seeing as I don't think anybody is using it yet anyway?? Obviously deploying to maven central dodges this problem for the official builds, but it might be worth fixing this for fork builds anyway. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#964?email_source=notifications&email_token=AAVTR4YCB3JROTGE5P3V5OTRCG7ZHA5CNFSM4HCCSQU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELKJRWA#issuecomment-584358104>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAVTR44NMI3HRJJL3A5L23DRCG7ZHANCNFSM4HCCSQUQ> .

[vadeg]

Maven Central requirements

[gsdatta]

Wonder if this is easier now that #1116 has been merged. Would be great to have the zally-core (and rulesets) published so that they can be pulled into other projects!

[vadeg]

Let's close it when we have artefacts deployed.

[vadeg]

Artifacts are available at Maven Central