Java Reference
In-Depth Information
When to share and not to share
In this example, the bundle you're sharing represents the core API of your applica-
tion. We've chosen this bundle because it's a good example of the type of bundle
that can be safely shared. In the general case, it's unlikely that you'd want to share
the internal API of your application, so it isn't particularly valuable to do so. The
best things to share are common libraries that are used, or are likely to be used, in
multiple applications.
defaulted as core content and could be provisioned as a resolved dependency. Unfor-
tunately, this isn't possible with the development stack you have. Your other option is
to leave the
API
bundle in the
EBA
, which is what you'll do here.
This information is easily added to your application manifest. Note that the data-
source bundle isn't part of your application content, but it's required for the
EBA
to
run on your development stack:
Application-Content: fancyfoods.web;version="[1.0.0,2.0.0)",
fancyfoods.web.nls.fr;version="[1.0.0,2.0.0)",
fancyfoods.persistence;version="[1.0.0,2.0.0)",
fancyfoods.business;version="[1.0.0,2.0.0)",
fancyfoods.department.chocolate;version="[1.0.0,2.0.0)",
fancyfoods.department.cheese;version="[1.0.0,2.0.0)"
Adding this line to your existing application manifest changes it significantly, but if
you deploy the application again you can see the framework still contains the
API
bun-
dle (see figure 4.9).
The
API
bundle is still installed because the resolver determined that it was needed
to provide the dangling dependencies of your
EBA
. If your runtime supported provi-
sioning from a repository, you'd be able to remove the
API
bundle from the
EBA
entirely, reducing the size and complexity of your
EBA
.
Figure 4.9
The resolved EBA. As before, all of the application bundles are visible using the
ss
command. This also shows that the API bundle has been installed, even though it wasn't part of
the application content, because it was needed as a dependency.
