Representing Java Dependencies

Transparency around composite libraries

We recently did a big refactor around how we can better represent build plugin relationships, and component change logs.

Continuing this trend, we’ve extended this same philosophy to representing the supplied Java composite dependencies.

Composites are collections of dependencies that are maintained and consumed from a single unit. Ultimately this means that instead of juggling lots of different dependencies per project (which can make updating a nightmare - depending on how many services are utilising those dependencies), these can be maintained and brought in from a single layer.

This change will represent the different libraries that are brought in by including the composite in your own project, with relevant links to the component in question.

Instructions on how to include the composite library in your projects is now also available in each composites’ documentation.

To get started, take a look at some of our build libraries to check out how some of our supplied composites are represented.

This is just another step towards full transparency of our services.

Thanks!

Max