Automatic deployment of snapshot versions

[manuel-mauky]

I've seen that you have added travis-ci. This is great.
A cool feature would be setup travis-ci to automatically deploy a snapshot version every time a PullRequest is merged. This way we can use and test new features quicker.

We have done this setup for mvvmFX three years ago. Maybe this can be helpful as a template (However, we are using Sonatype-Snapshot-Repository. It might be different for bintray):

• in maven it's not possible to define username and password for a third-party maven server like sonatype-snapshot-repository. Instead these have to be defined in the maven settings.xml which is problematic for a travis build. To automatically create a settings.xml with the needed configuration we use this python script. After that you set the environment variables $SONATYPE_USERNAME and $SONATYPE_PASSWORD for your server credentials in the travis-ci admin frontend.
• we have a bash script which checks the git branch and if we are on the main branch we first execute the python script to add the maven repository server and after that we execute a maven deploy command.
• this bash script is invoked after each travis-ci build by using this config in travis.yml
• to be able to use environment variables from travis-ci admin frontend in the build script you have to define them in the travic.yml like this

As I've said: Maybe for bintray there is another procedure available. This config scripts are 3 years old now so maybe in the mean time someone has found an easier way of doing this but it might help as a starting point.

[netopyr]

Good idea, I am looking into it. The procedure looks quite complicated. But I am hopeful that JFrog's solution will be easier. :)

[manuel-mauky]

As far as I know it's more a problem of maven and not the repository. For example with gradle it's a one-liner in travis.yml. The reason is that the maven commandline tool doesn't accept the credentials as commandline arguments. Or at least 3 years ago when I created the scripts this was the case. Maybe a newer maven version fixed this in the mean time.

[netopyr]

I am giving up on the JFrog solution. It appears as if something with my access right is wrong - even after several attempts. The fact, that I have no idea how to reach out to somebody at JFrog to help me out, does not make it easer...