Current release is readily available to developers without needing to build locally

[jvanderhoof]

All releases should publicly available so a developer only needs to use Maven/Gradle to pull this library into their project.

[orenbm]

Do we have a repository manager (Nexus etc.) that we're working with?
@dustinmm80

[kgilpin]

Is there a completely public repository to which we can publish this?

[orenbm]

I didn't look for one online as I first wanted to see if we already have one. I'm guessing we don't have.

[kgilpin]

Not ours. A public one

https://maven.apache.org/repository/

[kgilpin]

I think for our own development purposes it's probably sufficient to download to the local repository.

[dustinmm80]

We an set up Artifactory to do this for internal test releases.

https://maven.apache.org/repository/ seems fine for a public publish.

[cgallemore]

+1 for this, we are using this and I just wanted to be able to add the dependency in my pom.xml, the central maven repository would be a great place to push this so then we could consume it easily.

[izgeri]

@h-artzi can you please add some info to this issue description with the work remaining to be done to get this project published in maven? we might take on this work soon, so I want to be sure we have all of the required info.

[h-artzi]

Tutorial used:

• https://central.sonatype.org/pages/apache-maven.html
  I would recommend that someone go through this tutorial. Some of the work is completed on this branch

OSSRH

@garymoon and I were able to create an OSSRH account. We secured the groupId com.cyberark which gives us access to any subgroup of com.cyberark. Here is the slack discussion regarding the groupId and artifactId. The naming convention can be discussed again.

Pushing up to Maven repository:

The goal was to push snapshots (which can change) nightly and released versions (permanent) to the maven repository. In the branch (linked above) we have a script ./get-version.sh and a ./build.sh which attempts to automate the versioning of the jars. mvn versions:set -DnewVersion=$VERSION sets/overwrites the version in the pom file. However, this command would need to be run locally before merging a branch into master, to ensure the pom in the repo has the appropriate version.

There are several credentials that need to be passed on to whoever is tackling this ticket, ping me and I will pass them on securely!

[BradleyBoutcher]

For updates on my work, I will be using the following branch:
6-maven-central-publishing

Due to significant work in this repository since the last progress on this story, I'm going to create a new branch for this project, borrowing from Hadar's work as needed. To start, I will focus on only publishing releases, while publishing snapshots can be a separate story we can focus on afterward, if it seems too large. It should be simple enough to separate them using the triggers for being on master branch (for snapshots) or on tagged versions (for releases), but I am going to prioritize having a stable workflow for releases first.

1. Following this guide, there are several prerequisites that I need to verify we have in place, in terms of what we have in our pom.xml. These are the required configurations for a project that is available on Maven Central, and I believe we already have most of them.

2. We will make use of the Open Source Software Repository Hosting (OSSRH), which is an approved repository provided by Sonatype for any OSS Project that want to get their artifacts into the Central Repository.

Based off the work Hadar has already done, we have secured a namespace, com.cyberark, that the api's classes will need to make use of. These changes to the java classes were made by Hadar, and I will make them as well.

3. We will use Apache Maven for publishing to OSSRH. This will require some work, but I should be able to use some of the information Hadar has provided and written in his branch.

4. In combination with Apache Maven, we will use Maven GPG Plugin for signing our artifacts. While complicated, it is required by Maven and this is the most straightforward option supported by the environment we use. The implementation instructions are found in the Apache Maven instructions, while the detailed setup instructions for GPG itself can be found here.

5. Finally, all the configuration above can be isolated in a profile within our pom.xml that will allow us to run builds for branches without each build being required to go through the stages of building the release, signing, etc. This is recommended by Apache Maven and should be simple to implement in combination with our jenkinsfile conditions.

What I need:
There are two sets of credentials we will add to a settings.xml file that Apache Maven and GPG can refer to. I also noted the placeholder name for these credentials in the instructions for their respective configurations.

1. OSSRH Credentials (your-jira-id and your-jira-pwd)
   We do have an account and credentials used for logging in to the OSSRH UI and monitoring our repositories. I will need these credentials to be accessible during our deployment process in Jenkins. Specifically, I need them for the Distribution Management and Authentication step of Apache Maven setup.

2. GPG Passphrase (the_pass_phrase)
   This is trickier. I will need assistance from Infrastructure here as well to set up this plugin for use by Jenkins during a pipeline build for a release. Detailed instructions can be found here.

cc @garymoon @hughsaunders for assistance / feedback on the two credential sections
cc @izgeri

[sgnn7]

👍 from me though I would like to see the @cyberark/conjur-infra-team create and manage the GPG keys, not just provide the password for it. This may be already in the proposal but it should be cleared up.

[BradleyBoutcher]

Follow up work:

• Any projects that use net.conjur.api may need to be updated to use com.cyberark.conjur.api to use the published release of our build.

• Update documentation to reflect availability on Maven Central. Issue created here.

[sgnn7]

@BradleyBoutcher Makes sense. That will be a big change and we should make sure we bump at least the minor semver for it (probably the major version should be the changed one given that nothing will work after the change).

[garymoon]

Infra will indeed be generating the key.

I agree a major version bump is in order, though for anyone unfamiliar the group ID change will break any and all code in existence using this library.

[izgeri]

@alexkalish fyi ^

I'd be glad to get your 👍 on this that the next version of this project will include a major version bump (and of course, the docs on proper usage with Maven, issue link TBA)

[BradleyBoutcher]

I'm excited to announce that our latest release of the Conjur Java API is now available to download from Maven Central simply by including the dependency in your pom.xml.

For instructions on updating your project to use the latest Maven build, or update your project that will continue to build latest locally, please refer to the UPGRADING.md in the top level directory for the project.

Additionally, I've created a PR in dap-intro that implements these upgrading instructions for a project that previously cloned and built the project locally each time. Feel free to check it out here!

All future tagged releases will also be made available in Maven Central as part of our build pipeline, as well as nightly master builds which are published as snapshots. You can view all of these releases and snapshots in the Nexus Repository Manager, which manages hosting for this project.