dracoblue.net

When I was developing on the http-response-headers open source library for spring boot, I was curious how difficult it would be to make this available at maven central. And of course: everything should work automatically with travis ;).

To make your jars available at http://search.maven.org/, you can submit your open source project to "Sonatype OSSRH".

Basically you have 3 steps (OSSRH Guide):

1. Create a Jira Account at Sonatype
2. Create a Project Ticket
3. Deploy to https://oss.sonatype.org/content/repositories/snapshots or https://oss.sonatype.org/service/local/staging/deploy/maven2/. Therefor you need to:
   • Modify your pom.xml
   • Add build plugins for binaries, javadoc and sources jar files and gpg signing
   • Create a gpg key
   • Sign your builds
   • Integrate this with travis secured environment variables

The steps 1 and 2 took me some minutes and the response of the sonatype staff came a workday later. Nice.

Since I wanted to automate step 3, the following lines are more like a reminder for myself how I got this working. You can follow the following steps to set this up for your self, too.

While reading in Chapter 13 "Managing Components and Dependencies" of Continous Delivery (July 2010, Addision Weslay) I asked myself how would one implement this if you implement the components (parts of the system, which change often) and libraries (internal/external parts, which change very seldom) in your own project.

A while back (1) for example contributing to PHPUnit was kinda tricky. You had to git clone the main repository and 11 different component repositorys. If you wanted to change something in these components, you could do that there. If you run continous integration, every change to those components needed to be in git master of those components. But how does one do a release then? Lots of tooling and in the end the release version number was hardcoded (2) and committed.

I am pretty sure that you know of some java project with dependencies, which work in a similar fashion.

When discussing this with my co-workers at exozet, we have been thinking how one approaches these concerns of lean development and safe releases with Java and Maven (or gradle). Of course we are using SemVer 2.0 as semantic versioning strategy. So I want to present an approach, which I infered out of the books example and would like to hear your opinion!

This reference by @phillip_webb is a really good in depth introduction into all details of spring boot. Even though it's not about spring-data and all the other spring projects, it always provides as much information, which is necessary to understand what's spring boots role in the play.

In 2011 mnot wrote about json linking. Now it's like 4 years later and time to take a look at the link formats in json, which are used by lots of people.

In HTML5 we have a <link> tag defined like this:

<link rel="author license" href="/about">

The attributes of this link are defined like this (taken from the W3C-page):

• href — Address of the hyperlink
• crossorigin — How the element handles crossorigin requests
• rel — Relationship between the document containing the hyperlink and the destination resource
• media — Applicable media
• hreflang — Language of the linked resource
• type — Hint for the type of the referenced resource
• sizes — Sizes of the icons (for rel="icon")
• Also, the title attribute has special semantics on this element: Title of the link; alternative style sheet set name.

The advantage of the <link> tag in XML is, that you could put it anywhere in your document (like the <a> tag in HTML). If you want to achieve web linking (rfc5988) in JSON, there are multiple approaches.

This post shows some of the widely used JSON media types and how they deal with links. I will have a short look at HAL, Collection+JSON, Hydra/JSON-LD, Mason, Siren and UBER. Example files for all of them are in this json links gist.

With this setup we will make two servers using a shared storage as high availabile mount. Both of them host the data, if one of them is down, the other one will stay the source of truth for so long. Disadvantage of this approach is, that the files exist 4 times: at server1 and server2 each with /mnt/barrel (the mounted directory) + /var/glusterfs/barrel (the glusterfs working directory).

Install glusterfs server and client

On both machines run as root:

$ sudo apt-get install glusterfs-server glusterfs-client

This makes the glusterfs server available and will allows us to connect to the server later on.