Java Reference
In-Depth Information
in the target directory of the application/application-tooling-repository-generator. If
you copy the contents of this directory to somewhere a little more accessible, then you
can use them to build your repository.xml using a single, simple command. Before
you can launch the generator, you must remember to add the bundles that supply the
namespace extensions that you used in your application. In this case, you need the
transactions and
JPA
namespace handlers.
The transactions namespace handler is available as a released bundle called trans-
action.blueprint, or from a build in the transaction/transaction-blueprint/target
directory. It also depends on the
JTA
API
; this bundle can easily be retrieved from the
test stack you used in chapter 3:
java -jar
org.apache.aries.application.tooling.repository.generator-<version
id>.jar [repository xml location] url1 [url2...]
In the command to launch the repository generator, you need to replace the
<ver-
sion
id>
with the build
ID
of your repository generator
JAR
. The
repository
xml
location
parameter is optional, and defaults to ./repository.xml. The
URL
that you
supply points to a directory of bundles that you wish to build a repository from, and
you may optionally supply further
URL
s to scan and aggregate into a single repository.
7.5
Summary
This chapter has covered the provisioning process in a lot of depth. We hope that by
now you have a good understanding of how resolvers can solve the constraint prob-
lems offered by bundle dependency graphs. You've also learned how bundle reposito-
ries work and, if you wanted to, you could probably write your own tool for generating
a repository, both at runtime and in
XML
.
You may have come to the end of this chapter thinking that there isn't much rea-
son for you to know about repositories and modeling to this level of detail. We, on the
other hand, would disagree. The most common problem we come across when people
are building enterprise
OSG
i applications is that their application doesn't resolve. The
next-most-common problem is that the application
does
resolve, but not in the way the
developer was expecting. For many people, the errors output by the resolution pro-
cess are completely opaque, as is the underlying process itself. Armed with the infor-
mation in this chapter, you should have no difficulty in diagnosing any resolution
problems you see; other developers will probably seek you out to help them as well!
Now that you've seen how repositories can be a useful tool for locating dependen-
cies, it's time for us to look at other tools that can speed and ease the enterprise
OSG
i
development cycle.
