Release a version to an artifactory like Bintray

[dnvriend]

Please release a version to an artifactory like eg. Bintray. Having vlingo available as a release artifact makes it easy to try it out.

[VaughnVernon]

Thanks for the suggestion, Dennis. I have not used Artifactory (or don't remember) but it seems to be quite expensive, at least as far as I can see. Is there a free edition for OSS projects? If so, can you point me to the resource so I can sign up?

[dnvriend]

For my project I use Bintray OSS, which is free for Open Source projects. You can sign up with the following url: https://bintray.com/signup/oss . How to publish artifacts is described in the following blog: https://blog.bintray.com/2015/09/17/publishing-your-maven-project-to-bintray/ There are also code examples https://github.com/bintray/bintray-examples/tree/master/maven-example

[d-led]

Hello @dnvriend, this is in the works: https://bintray.com/vlingo/vlingo-platform-java/vlingo-actors

  <repositories>
    <repository>
      <id>bintray-vlingo-vlingo-platform-java</id>
      <name>bintray</name>
      <url>https://dl.bintray.com/vlingo/vlingo-platform-java</url>
    </repository>
  </repositories>
  <dependencies>
    <dependency>
      <groupId>io.vlingo</groupId>
      <artifactId>vlingo-actors</artifactId>
      <version>0.4.1</version>
      <scope>compile</scope>
    </dependency>
  </dependencies>

dependencies {
    compile 'io.vlingo:vlingo-actors:0.4.1'
}

repositories {
    maven {
        url  "https://dl.bintray.com/vlingo/vlingo-platform-java"
    }
}

jcenter is coming if approved

[d-led]

check out the following repo https://github.com/d-led/hello_vlingo for an example project (once #9 is merged if you want to run it under Gradle and once the package is published)

[michaelajr]

Why not use Maven Central via Sonatype OSSRH (OSS Repository Hosting) https://central.sonatype.org/pages/ossrh-guide.html

[d-led]

@michaelajr no particular reason yet. Is it as convenient to register and manage?

jcenter seem to be the default choice in Gradle at least

[michaelajr]

@d-led I use Maven Central via Sonatype OSSRH (OSS Repository Hosting) for my Open source binaries. But I also use Maven as my build tool and for all my automated build pipeline steps. I do think that having Java deps in Maven Central is super convenient.

[VaughnVernon]

I signed up for Sonatype on Sunday night as the means to push to Maven Central and yesterday (Wednesday) they informed me that my request is "out of scope". I have no idea why but I nned to look into some docs and I really wish someone could help with this. Here is the email I received via Sonatype's JIRA:

 [ https://issues.sonatype.org/browse/MVNCENTRAL-3395?page=

com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joel Orlina resolved MVNCENTRAL-3395.

Resolution: Out of scope

Per our official guide:

http://central.sonatype.org/pages/ossrh-guide.html

please use the following link to create your New Project request:

https://issues.sonatype.org/secure/CreateIssue.jspa?issuetype=21&pid=10134

On Thu, May 17, 2018 at 1:22 PM, Michael Andrews notifications@github.com wrote:

@d-led https://github.com/d-led I use Maven Central via Sonatype OSSRH (OSS Repository Hosting) for my Open source binaries. But I also use Maven as my build tool and for all my automated build pipeline steps. I do think that having Java deps in Maven Central is super convenient.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/vlingo/vlingo-actors/issues/8#issuecomment-389998242, or mute the thread https://github.com/notifications/unsubscribe-auth/ACg87IQ75xcqdCYMEu4FxAgfucWKYE8qks5tzdv2gaJpZM4T8iXS .

[VaughnVernon]

Apparently I didn't use the correct ticket type (referenced an old user guide), which was rejected by Sonatype. I just now filled out another ticket for new project request. Let's hope they accept this one. Their JIRA form is far from one-size-fits-all. The form seems almost as if I would have to fill out one for each vlingo/platform repo because the SCM field allows for only one github.com/vlingo/vlingo-whatever.git URL.

[VaughnVernon]

@dnvriend @michaelajr Is this something either or both of you could contribute? If so, what do you need in terms of access, etc? There is also a discussion around the pom.xml files for various projects. Our goal is to use Travis-CI to publish all ongoing artifact releases to various public repositories. Certainly Maven Central is top priority.

[d-led]

jcenter is almost done: waiting for vlingo-actors approval: https://jcenter.bintray.com/io/vlingo/

that means, the default gradle config will work out of the box:

repositories {
    // Use jcenter for resolving your dependencies.
    // this is the default and will suffice then
    jcenter()

    // mavenLocal() //for development purposes

    // maven { //previously used
    //     url  "https://dl.bintray.com/vlingo/vlingo-platform-java"
    // }
}

[d-led]

so, here's a working example of a hello-vlingo-world running both from a maven and a gradle config: https://travis-ci.org/d-led/hello_vlingo/builds/381117104

all artifacts are fetched from bintray. @dnvriend feel free to try it out and close the issue.

[dnvriend]

@VaughnVernon I don't have the time to contribute, but I will try out the dependency as configured by @d-led

[michaelajr]

I'm more of a Maven person. I think when used right, it can be easily leveraged for local and IDE development (using life cycle goals likemvn clean, mvn test, mvn install, etc), and also in CI environments which require discrete pipeline steps (not life cycle goals). In a CI pipeline, the Unit Test step would simply call the needed plugins directly instead of executing a life cycle goal. E.g., mvn jacoco:prepare-agent@preTest surefire:test jacoco:report@postTest instead of mvn test which would start at the top of the lifecycle. To accomplish this, I use a parent-pom that sets up all the required plugins. Each child project then gets CI capabilities out of the box with no need to configure CI capabilities in their own pom. This makes for very clean project poms. See https://github.com/eonian-technologies/parent-pom for details. Happy to help where I can.

[michaelajr]

...should add that the parent pom brings everything needed to publish to Maven Central as well (given the correct local setting.xml file).

[VaughnVernon]

@michaelajr /cc @dnvriend Thanks for your feedback. The parent pom that you are referring to exists and is vlingo-platform. It already does a full build but doesn't include all of what you specified. I already applied for a Sonatype OSS Project Repository 7 days ago. They say to requires 2 business days, which should have ended this past Tuesday. I don't know what the hold up is, but 4 hours before this reply Sonatype support indicated that my request was "Inactive - Pending Closure" which I don't understand. If you have access to this and can advise, please do so:

https://issues.sonatype.org/browse/OSSRH-39917

[VaughnVernon]

@michaelajr /cc @dnvriend @d-led

We are chipping away at this. I was finally granted the io.vlingo namespace by Sonatype and need to now prepare to publish to Maven Central. It seems that my next two steps are to generate PGP signatures and update the pom files for each repository that is published with the platform, which I can work on.

• https://central.sonatype.org/pages/working-with-pgp-signatures.html
• https://central.sonatype.org/pages/requirements.html#a-complete-example-pom

What's next? Now do we push Bintray artifacts to Sonatype so that they get pushed to Central? ;)

• We have the artifacts published here: https://bintray.com/vlingo/vlingo-platform-java

Where now? It is not obvious after setting up the PGP and pom how the artifacts go to Sonatype and then to Maven Central. Or are we supposed to push them somehow from command line or from Travis-CI?

[d-led]

Bintray publishing via travis is a wrapper of sorts, and PGP signing seems to be at least prepared for: bintray deployment docs. This should probably work out of the box, but if it doesn't, one can resort to manual pushes with secret variables set up in the travis-ci UI. I have no experience with that yet, but indeed, @VaughnVernon, it is logical for you to own the GPG key.

[VaughnVernon]

@d-led Thanks! @michaelajr /cc @dnvriend Ok, the nexts steps were just revealed by Sonatype in another JIRA comment, and I took a look at your above referenced pom. It all makes sense now (well, mostly). I still have a question about whether we can publish to Sonatype directly from Bintray or if we must push from Travis-CI. Hopefully that will be intuitively obvious by the time I get there.

[michaelajr]

Sorry for the delay. Been in meetings all day. I have never released from travis-ci. I usually pipeline with Jenkins, and then there is a manual "release job" that strips -SNAPSHOT from the version using mvn versions:set. I then do a mvn -Psign,sources,docs deploy (-P are the profiles that turn on signing, and attaching sources and javadocs). That rebuilds the artifacts with the NON-SNAPSHOT version and deploys to Sonatype. I'll look at the Travis-CI best practices for this. Been wanting to move to that for some of my open source projects. Bintray might also have a way to push.

[VaughnVernon]

@michaelajr No worries, and thanks. Basically everything that you indicated about your Jenkins pipeline is handled already for us by Travis-CI (or in our Maven builds). At this time we don't use -SNAPSHOT because (actually @d-led knows better) it is apparently not supported by Bintray (and/or Travis-CI) so we have no naming to clean up. (Funny, Bintray docs say snapshots are not supported, but right on the repo control panel it indicates that snapshots can be pushed to Artifactory: "Deploy snapshot builds to the Artifactory server at oss.jfrog.org and promote releases to Bintray directly from Artifactory. See this for more details...") However, it is my goal to also push -SNAPSHOT builds when we figure out how.

This is our current workflow:

1. Modify source
2. git commit && git push
3. Travis-CI sees our pushes and does CI builds
4. Following a Travis-CI build, if the project pom version number changed, push to Bintray
5. [This is where we are now, and would like to just auto push to Sonatype->Maven Central]

[d-led]

The typical strategy is to push snapshots from master and versions from git tags.

The "snapshots not supported" comes from an early build result, where travis brought up this message via bintray. Need to follow up some time in the future. Bintray.json will need to be templatized for the approach to work (this seems a common strategy on github)

[VaughnVernon]

I just saw this:

https://twitter.com/djspiewak/status/1001589613121552384

On Wed, May 30, 2018, 1:04 AM Dmitry Ledentsov notifications@github.com wrote:

The typical strategy is to push snapshots from master and versions from git tags.

The "snapshots not supported" comes from an early build result, where travis brought up this message via bintray. Need to follow up some time in the future. Bintray.json will need to be templatized for the approach to work (this seems a common strategy on github)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/vlingo/vlingo-actors/issues/8#issuecomment-392975644, or mute the thread https://github.com/notifications/unsubscribe-auth/ACg87AxRAy8vu7B80X1nisn-qo3hLNm4ks5t3dP5gaJpZM4T8iXS .

[d-led]

For the balance: http://hintjens.com/blog:85

the strategy I described doesn't mean, the pom would contain snapshot dependencies. Only the library itself would be published as a snapshot, depending on last compatible version. But going too deep into incompatibility should probably be minimized

[VaughnVernon]

I didn't necessarily agree, I just thought the timing was interesting :) I can see the point of not using them, because you will likely break clients on a daily basis. It seems that's also what Hintjens was trying to avoid.

On Wed, May 30, 2018, 1:19 AM Dmitry Ledentsov notifications@github.com wrote:

For the balance: http://hintjens.com/blog:85

the strategy I described doesn't mean, the pom would contain snapshot dependencies. Only the library itself would be published as a snapshot, depending on last compatible version. But going too deep into incompatibility should probably be minimized

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/vlingo/vlingo-actors/issues/8#issuecomment-392978640, or mute the thread https://github.com/notifications/unsubscribe-auth/ACg87K9nQ7ev_FF7CXR7Yy51z9FBU7Lpks5t3ddsgaJpZM4T8iXS .

[VaughnVernon]

Allow me to rephrase that. What I meant to say is, I can see why a team would want to produce snapshots on a daily basis to support team development, but we would not want to encourage external clients to depend on them as they would likely cause breaking changes daily. However, a client can always choose to use snapshots if there is some urgent need to get fixes and they are not planning to put that patched code intro production.

[michaelajr]

I know there are lots of opinions on this, and my approach might be geared more toward development teams in a company rather than open-source projects. But when it comes to an SDLC, I tend to lean toward Maven conventions. I also use a slightly modified version of GitFlow for the branching strategy. The master branch contains the production code (the current release), and the develop branch is where work gets done for the next release.

In the following example, the POM of the master branch is set to 1.0 (the artifact has been built, pushed to a binary repo, and people are using it), and the POM of the develop branch is set to 1.1-SNAPSHOT.

To add a feature, developers branch off the develop branch into a feature branch. E.g., feature/cool-new-thing. When their work is done, they merge their feature back into the develop branch (via pull request or manually depending on the conventions of the team). If they are working from a fork, they would issue a pull request for their develop branch to be merged into the project’s develop branch. CI then kicks off and builds the project's develop branch resulting in the 1.1-SNAPSHOT artifact being being published to the binary repository. This can, and should, happen often.

When the develop branch has all the needed features for a release, a release branch is cut from the develop branch, creating the release/1.1 branch.

BACKGROUND: In the days of manual QA, the POM version in the release branch would be set to 1.1-RC1 (release candidate 1), and the develop branch would be set to the next development iteration, 1.2-SNAPSHOT. This allowed QA to find and report bugs to be fixed in the release branch, while not delaying work on the next iteration which was being done in the develop branch. Bugs would be fixed in the release branch and merged back into the develop branch. The POM version of the release branch would then be set to 1.1-RC2, a new build would be issued, and testing would start again. The process would continue until the release branch had a viable RC. This provided 3 paths of development. One in the release branch (fixing QA bugs), one in the develop branch (adding new features), and one in the master branch (patching production errors that could not wait for a new release, creating the 1.0.1 version). Using this branching strategy no one is blocked. Hot fixes (patches) are not blocked by a dirty master branch, and the RC was not blocked by a dirty develop branch, and the develop branch was not blocked by the RC. HOWEVER… since the days of manual QA are long gone :) … we modify this a bit…

The release is branch where you remove -SNAPSHOT from the version and commit the change. Something like, Preparing for the 1.1 release. There might also be other “release” commits needed, things like updating docs that reference the version, etc. The idea is that no new code is added here, and the only commits on this branch are things that “prepare” the code for release.

The release branch is then merged into the master branch and deleted. The master branch now has all the new code and the POM is set to the new version. The master branch is built, and the artifact is pushed to the binary repository. The develop branch is then set to the next development iteration 1.2-SNAPSHOT, and both branches (develop and master) are pushed to SCM.

The development cycle then repeats.

If you need to “patch” the 1.1 release before 1.2 is ready, you can create a hotfix/1.1.1 branch off master, do the work there, build and push the artifact, and then merge the hotfix back into master and develop. The take away is, you're not blocked from patching the current release because of development work.

Anyway. Long I know. Like I said, unsure if this is the best practice for open-source projects on GitHub. But figured I would add my two cents. :)

[michaelajr]

Btw, I wrote an article called Maven For Pipelining. Might not be applicable here, but thought I would link to it for those that are interested.

As far as not having SNAPSHOT dependencies, this is definitely the case for the release. It should never depend on SNAPSHOTs. If it does, people that are using the library will get transitive dependencies that are SNAPSHOTs. This could change their build from day-to-day. In turn... they should never directly depend on your SNAPSHOTs in their releases (for the same reasons).

However, having SNAPSHOT dependencies in your develop branch is fine. Just make sure to eventually move to the released version and make sure your tests still work. As part of the release process, you can then make sure there are no SNAPSHOTs dependencies.

[d-led]

gpg signature is now available. See e.g. vlingo-common files

[VaughnVernon]

Bingo:

Sonatype: https://oss.sonatype.org/#nexus-search;quick~vlingo Maven Central: https://search.maven.org/#search%7Cga%7C1%7Cio.vlingo

More repos will be pushed in the following days.