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

Custom Search