Propose release cycle / process for binary artifacts

[MarkusTiede]

Github Package registry example: baloise/repository-template-java#4

[culmat]

consider

1. https://jitpack.io/
2. https://bintray.com/baloise
3. https://search.maven.org/search?q=com.baloise

( in order of my personal priority)

[culmat]

we can also use sonatype OSS / Maven central, see https://github.com/baloise/ossrh-pipeline-demo

Shall we update
https://github.com/baloise/open-source/blob/master/docs/md/guides/practice.md#releasing
https://github.com/baloise/repository-template-java
to reflect the most popular options.

I don't see a big advantage in using bintray any more.

Bintray will be discontinued by 1st of May

Also we do have 2 bintray namespaces:

• https://bintray.com/baopso/ ( not used any more )
• https://bintray.com/baloise/ ( use by TAF)

Github has it's own disadvantages

• no repo browsing
• no anonymous access : 10.5k views, no solution

Known current users

Github

• https://github.com/baloise/corellia/ @schlijo
• https://github.com/baloise/test-automation-framework @seejaybee

Maven central

• jenkins- solr- and orchestra-maven-plugins @culmat

[culmat]

I started to collect features / pro / con @ https://github.com/baloise/open-source/wiki/Public-Maven-repository

[culmat]

If your favorite is Github react to this comment

[culmat]

If your favorite is Central react to this comment

[schlijo]

I am not that deep into all the possible registries. In the past I had some issues with maven, because at least the initial effort for creating a component was quite high, but that's years ago.
For me it's important, that it ist easy to use from within baloise (it's our contribution, it should be ease to use our open source projects within the company).
It should be easy to generate the artifact and bring them to the repo without baloise infrastructure (not our jenkins to say).
When this is given, I don't have any stakes in one of the solutions.

[MarkusTiede]

Bintray is shutting down (https://twitter.com/droy_eclipse/status/1357034875409354753)

[MarkusTiede]

If your favorite is Central react to this comment

IMHO if we're publishing on maven central we have to make sure to "only" publish IP clean artifacts with respect to open-source best practices. Being on maven central will potentially lead to a quick distribution.

[culmat]

@schlijo

for github and for maven central you need credentials to deploy.
For central you additionally need to sign the code and there is a quality check on the POM ( author, javadoc ... )
Both rely on maven for the deploy, credentials for both are already configured in the baloise github org, and for a "works on my machine" build you can find them on our internal wiki.

There is a working demo @ https://github.com/baloise/ossrh-pipeline-demo

[culmat]

@MarkusTiede : I get your point about quality. My conclusion is slightly different: we already publish the source code (= IP ) on github, which is currently the platform with the most public attention. Should we make life hard with binaries, when source is already available? Is it better to have hidden (IP) bugs that open ones? IMHO quality is precisely one argument for going open source, and Maven Central does have some quality checks in their deployment process ( code signing, POM quality, javadoc ).
What about npm? We need quality / reviews independent from package managers.

Release early, release often, build quality in > security ( safety) by obscurity

[MarkusTiede]

IMHO we should improve the quality in our process first

• enhance transitive IP dependency cleanliness
• external IP cleanliness (CLA)
• internal IP cleanliness - e.g. via finos.org ODP

I'm just cautious here due to my experience within the releng context of the Eclipse Foundation ; this is how the EF releases to maven central:

https://git.eclipse.org/c/platform/eclipse.platform.releng.git/tree/publish-to-maven-central

[MarkusTiede]

Maybe we should also broaden the scope here a bit to e.g. also cover releasing of

• javascript such as npm artifacts
• container on docker hub
• what else to come ...