As some of you may know, I regularly holiday just outside Roundstone in
If you haven’t yet been to the west of
From ground level, the profusion of little stone walls can appear as a complex pattern, perhaps even fractal-like. But viewed from a
I came back to
Well, also while I was away in
- Cloudsmith keeps meta-data about assemblies of software components.
- Software components can be sourced from any number of public and private repositories worldwide. Of course, components from private repositories are only available to those duly authorized to use them.
- Cloudsmith does not store the components themselves: but it knows where they are worldwide and how it can access them in the appropriate repository formats.
- A software publisher – an individual, project, or company – can register one or more specific software component assemblies with Cloudsmith.
- A software consumer – an individual, project, or company – can search and browse for available assemblies; and can readily download and install any particular one – “materialize” in Cloudsmith-speak – onto his local machine (or indeed another machine if appropriately authorized).
In effect, Cloudsmith is building a global map of software components (in various forms: source, binary, versioned, and optionally with test suites, documentation and license agreements). Professional software developers - individually or in a community project or working on a commercial offering – can publish interesting new assemblies of components, sourced across one or more repositories.
One of the neatest capabilities of Cloudsmith is a Cloudlink. A Cloudlink is simply a URL: it can be sent in an email, or given in a blog or whatever. When a Cloudlink is clicked, the software assembly which it denotes is then materialized without further intervention, onto the local machine. This gives a very simple download mechanism: publish a Cloudlink, and anyone clicking on it within a recent-vintage web browser can download your software. In practice, when a Cloudlink is clicked, behind the scenes the Cloudsmith site is contacted, and it resolves the differences between the assembly of software components identified by the Cloudlink, and those already available on the local machine, and then fetches (as appropriate from various repositories worldwide) and downloads the missing components.
Cloudlinking in turn enables “virtual distributions”. A software publisher can create a virtual distro, whose components reside across multiple (eg open source) projects and repositories: materializing a virtual distro requires nothing more than a web browser.
If your project is looking for a simple way to make its software available to the worldwide community; if your project is itself using software from multiple sources and multiple projects; if you want to keep your community regularly updated with patches and extensions; if you want to manage installation and distribution processes; then Cloudsmith should be worth taking a look.
Software components, and configurations and assemblies of them, are very malleable. It is relatively easy to define new interesting configurations, as well as new components. Looking at the world wide activity, and the multitude of repositories and projects, it is easy to become overwhelmed. It is possible to detect patterns, and different styles of construction, but sometimes it can be very confusing to see overall themes, to understand how other people are using configurations, and what changes have occurred.
I’m reminded of
Cloudsmith is giving clarity to the construction of assemblies of software components.
5 comments:
Chris,
Speaking as a small farmer's son from the West of Ireland, I loved this analogy. However, working at home a few weeks back with my brother building those things, I suggested to him, wouldn't it be great if we got a concrete pump to fill up all the gaps for better support. Also in IT, my brother thought there might be something to it, as we were both sick of maintaining them. Far from being low maintenance:
* Cattle love to scratch their necks on them
* Wind will knock the stones over
* Ground subsidence will cause them over time to de-stabilise, or create weak spots that you always seem to be building.
* Constant rebuilding causes the stones to become rounded (and that's a big pain!)
So in one sense it got me to thinking of Buckminster. While my initial investigations of it have been very promising, the same problems that stone walls face are also here. I will give you though that cattle can't use Buckminster for scratches, so it's safe there!.
Dependencies that builds rely on can change, and if the meta-data that Cloudsmith maintains goes stale it can cause problems. So for example, there can be some brittleness for me where a cloud can be materialized fine today, but not tomorrow because one of the pieces I depended on has changed.
I see similar problems with Maven where we use SNAPSHOTS and they can disappear at any time (or a new one breaks a build).
I guess this is my slightly meandering way to say that we will still need to provide some means of allowing builds to be concreted, or made permanent. A "release" needs to be materialized at any time, not just today or tomorrow. So a means to say, this "virtual distro" is gonna be "good" and will not become stale because one of its components had a change recently.
Adrian Skehill,
IONA.
I’ll pass on experience working with stone walls in Connemara – I’ve been a mere regular visitor there for 27 years, but not frequently worked the land.
Buckminster has a number of facilities to aid dependency changes. The Introduction to Buckminster
and Buckminter specification documents
give the details, but here’s a summary.
A specific, fixed, physical configuration of interdependent components can be given by a bill of materials (BOM). A BOM is auto-generated by Buckminster during resolution and then used during materialization to fetch specific (versioned) components. In addition a BOM can be saved (via the materialization wizard) and then re-submitted at a later date by the same or another user so as to materialize precisely the same set of components, assuming of course that they still exist in the various repositories concerned.
More typically however, (logical) version schemes are used to allow more flexibility during resolution and materialization. Buckminster supports multiple version schemes – OSGi, string, timestamped, triplet – and also an extension point to add further version types.
Version dependency information can be given within CSPECs. Note that CSPECSs – for Eclipse developers at least, at this point in time – are automatically generated by Buckminster during resolution – that is Buckminster uses whatever meta-data is currently available for each resolution/materialization. Thus, per se, Buckminster itself does not maintain meta-data: instead, it converts meta-data “on the fly”, reducing the possibility of the stale meta-data situation which you mention in your comment.
In addition, the auto-generated CSPECs can be manually extended (or extended by a tool outside of Buckminster) with CSPECXs – CSPEC Extensions. A CSPECX can also contain version data (in any of the version schemes..): however since the CSPECX is given to Buckminster by a developer or external tool, it is the responsibility of that developer or external tool to ensure that the CSPECX does not used stale meta-data.
In practice, CSPECs (rather than CSPECXs) are prevalent, and are of course auto-generated.
Finally, Advisor Nodes provide very considerable flexibility to extend the semantics of resolution and materialization.
As an aside, all the Buckminster artifacts I mention above - CSPECs, CSPECXs, etc - are XML files in the format prescribed by the Buckminster specification.
Now: what I have just written, was all about Buckminster (the Eclipse plugin). What about Cloudsmith’s (the web site’s) meta-data ?
Cloudsmith is engineered using Buckminster. Cloudsmith is a place (on the internet) at which Buckminster artifacts – and in particular CQUERYs (each of which is a pre-formatted query identifying a useful collection of components) and RMAPs (each of which identifies a repository on the internet or an intranet) – can be easily found, browsed, searched for, etc. Any dependency information between components is handled by Buckminster (as above) rather than Cloudsmith.
Having said all that, if you chose to go ahead and sign up at Cloudsmith – its completely optional to do so – then if you read the sign up page carefully, you will note that we say “Our policy is that whatever starts off free, stays free. So if we want to find new ways of making money, we have to find new ways of adding value.” I won’t go into details here, but you might imagine some of the optional added value features we have on our roadmap, and for which we intend to charge a modest amount (“We have not decided exactly how much the annual fee will be, but we want users to think it is an incredible value. We can safely say it will be somewhere between €25 and €75, per user, per year.”)
Finally, we are acutely conscious that the “kickstart” sections of the Cloudsmith web site are not yet live: we really do hope to have those available soon. They should hope also clarify and explain how to use Cloudsmith – and its features – even better.
Adrian,
Your comment is very much on point. In the sense of being something we have thought a lot about, rather than not!
Bear in mind that this is an alpha release. If you start playing with Cloudsmith now, by the time your distro changes, you may find that Cloudsmith may be of some help there!
Whether this does anything for the cows, however, I will leave to others...
||mitch
The kickstarts are there now...
initial version at least...improvements on the way..
Post a Comment