The arguments of 'Maybe this would cause problems' don't really seem to be borne out by the Maven repository, which has over 400G of versioned artefacts that have gone through the -SNAPSHOT process during development and rarely, if ever, has any problems in versioned code. (That's not to say mistake can never happen; but it's easy enough to publish a new asset with a new patch version if required, as has been done occasionally before such as the javax.jms releases.)
The problem with the existence of the OSGi build qualifier is that it means Eclipse developers don't actually take care to version code properly. Instead, the build process just spits out recompiled bundles, often without a corresponding bump in version number where required or needed.
]]>The issue is whether or not SNAPSHOTs shold be built in a 'lower' numerical
namespace using 1.2.3-456 which sorts less than 1.2.3. By encouraging
a difference between 'unreleased' and 'released' versions, it becomes clear
whether there are changes which are important, and allows developers to report
bugs against a specific version (instead of just 'the latest version').
According to both the Semantic Versioning and the Eclipse Version Numbering rules, the patch number (third segment) should be changed whenever there is a difference between build artefacts. As I've listed on the InfoQ article, that plainly doesn't happen in some cases:
The point of showing the cross-section of the above is not to highlight
specific projects, but to show this is a widespread problem that goes
across all projects. The problem is, there is no 'penalty' for leaving a
1.2.3.qualifier as the Manifest entry and just spinning out builds with
new build qualifiers in place.
The key advantage of having a different version numbering format between release versions and pre-release versions is to ensure that at release, the version number is updated appropriately. This means that the development process generally follows:
The decision as to what to call the next number can either be tracked by updates to the -SNAPSHOT itself (e.g. moving to 1.1.0-SNAPSHOT) or can be deferred to later in the process. There's even tooling to help you do that (the mvn release plugin) -- though this just removes the -SNAPSHOTS for you rather than doing any semantic analysis.
This pattern is so common that it's even codified as a bullet point in the Semantic Versioning specification:
A pre-release version MAY be denoted by appending a dash and a series of dot separated identifiers immediately following the patch version. Identifiers MUST be comprised of only ASCII alphanumerics and dash [0-9A-Za-z-]. Pre-release versions satisfy but have a lower precedence than the associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.
The 'pre-release versions satisfy but have a lower precedence than' sums
up the rule in a nutshell: in other words, anywhere a 1.2.3 is valid then
all 1.2.3- are valid as well; anywhere a 1.2.3 is not valid then
all 1.2.3- are not valid. So, in a range like [1.2.3,4.5.6) then any
pre-release state of 1.2.3- is included, but any pre-release state of
4.5.6- is not included.
This was even implemented successfully in Equinox, with an implementation in 3.8M6.
Unfortunately, the concerns listed by the CPEG were out of touch with how developers work outside of the OSGi space, and instead of reaching out with a mechanism which would have been compatible for released artifacts (whilst providing a SNAPSHOT style build system that would not be loadable on older OSGi runtimes) it has been removed from the specification. Given that OSGi R5 is a major release of the runtime, this would have been the ideal time for introducing a new version syntax, and one that would have been quickly adopted elsewhere.
So instead of having 'memorable' artifact names like org.eclipse.ui_3.7.0.jar
we'll be stuck with unmemorable names like
org.eclipse.ui_3.7.0.v20110928-1505.jar for the forseeable future in
the OSGi world. This causes more cognitive work for humans (trying to
remember the name) whilst introducing more opportunity for mistakes (by
releasing the same major/minor/patch with different builds).
This is what I refer to as humans solving the tooling problem, rather than the other way around.
]]>This poses somewhat of a problem if you want to publish objects in the OSGi service registry of types which you don't control. According to the Declarative Services specification, you need to have an object which has a default constructor. The object is then fully configured with a number of bind and unbind methods, which means the object goes through a series of states where it is not fully valid.
There's also the category of classes which aren't under your control (e.g. an existing API) or are acquired elsewhere (e.g. a third party library). These often can't be extended or otherwise mutated.
Example
Let's say we want to have a list of URLs stored as services in the registry. We'll be publishing URL objects as the service (and using java.net.URL as the interface type as well; it is a contrived example, after all). Now, the URL doesn't have a default constructor; every URL must have a url. So we can use it for registering a component which needs a service (e.g. BookmarkService) quite happily. But we can't register a URL with DS.
This presents us with a challenge. We might have a component which can register URL services, but given a 1..n BookmarkService and no URLs published, Declarative Services can't help us. In essence, there's no way to have a delayed URL service in DS.
What you can do is provide a URLFactoryService with DS. This can be activated on demand, and a registerURLs() method called which in turn registers a bunch of URL objects in the registry; and once that's done, DS can kick off the BookmarkService.
Unfortunately, there's no way of being able to tell DS that the URLFactoryService is something which is capable of generating URL objects, so DS never knows it needs to start the URLFactoryService to acquire the URLs.
Solution
The solutions are either to not use DS to populate the initial set of URLs (and require an earlyStart or startlevel hack to bring the initial bundle on-line) or to modify DS in a way which allows the implementation class to be a factory for the interface type but without being a subtype of it. The existing factory specification currently requires that the factory class is still an instance of the interface class; all that changes is the cardinality.
Here's what the solution might look like:
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" name="URLdemo"> <implementation class="URLService"/> <service> <provide interface="java.net.URL"/> </service> </scr:component>
In this case, the URLFactoryService doesn't implement/extend java.net.URL. But this tells DS that when this component is activated, it gets a URL out of it, which is what we want DS to know.
We could use a new API, like ServiceOnDemand, which is a generified type that can provide us with a service when we need it:
public interface ServiceOnDemand<T> { public T getService(); }
If the URLFactoryService implemented the ServiceOnDemand<URL> interface, then a call to getService would return us with the URL object that could subsequently be registered on our behalf into the service registry. We can still use the bind and unbind calls as before; they just affect the ServiceOnDemand dataset. After each change of the properties (and providing the component was valid) the getService() could be treated as a factory for these object types, being called only when it is in a fully configured state.
For tear down, it becomes just as easy. Instead of removing the URLFactoryService from the registry, we can just remove its previously generated URL objects. The new DS would have to co-ordinate to know which services were registered and associated with which factory; but this shouldn't be significantly different to the way the factory works at the moment.
We could also use this in conjunction with the DS factory class. The key difference here is that the factory class must implement the interface provided, which isn't necessarily always possible.
Summary
DS, and in particular its lazy activation of components, is a great way of providing systems which evolve into being. Unfortunately, the current system is constrained to allowing only objects to be registered to which the user has full control. Although the above used URL as an example, the same could also be said for network-discovered services such as over LDAP or DNS service records, or even database connections (which typically can't be subclassed since they are binary only drivers). Finally, this could be the missing link between config admin and declarative services, which have never really played well together. Being able to use DS to fire up a factory, which consumes its configuration and then is able to generate multiple services would allow us all to avoid the pain and effort that is otherwise trying to control start ordering in order to provide services dynamically.