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
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:
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.
Search WWH ::