consumer, then this is a breaking change that needs a major version increment. After
all, it would be pretty disastrous for most web applications if you were suddenly
expected to implement a new doSuperGet() method on all your servlets!
Semantic versions and marketing versions
It's important to remember that semantic versions are different from marketing ver-
sions. Versioning is about communication, and it only works if everyone uses the same
language. Because not everyone is using semantic versioning, marketing versions can
go out of step with semantic versions. This can feel counterintuitive; for example, the
Servlet 3 API is correctly versioned at 2.6. Similarly, JPA 2 packages should be versioned
at 1.1. The OSG i Enterprise Specification specifies versions for these packages, but sev-
eral of the servers we discussed in chapter 13 include bundles that were released into
the wild with incorrect versions of the javax.servlet and javax.persistence pack-
ages. This can cause difficulties for consumers of these packages, which can't use the
semantic versioning rules on the imports.
Bundles are one of the most basic OSG i constructs. A bundle is a normal Java JAR , but
with extra metadata in its manifest that identifies it as an OSG i bundle. Bundles have
special dependency management and classloading behavior that allow much greater
modularity. Unlike normal JAR s, bundles also have a lifecycle.
The most important OSG i manifest header is the bundle symbolic name, but there are
many other possible headers. Table A.1 lists the defined OSG i manifest headers. We've
included all of the core and enterprise OSG i headers; more are defined in the Com-
pendium Specification. (Confused about which specification is which? Have a look at
OSGi manifest headers
Attributes and directives
See section A.4.
See section A.4.2.
See section 2.3.3.
Defaults to "." . Particu-
larly useful for WABs,
classes is a sensible