- Documentation (trunk)
- Release Notes
- Settings Files
- Ivy Files
- Ant Tasks
- post resolve tasks
- Using standalone
- Developer doc
Managing a target platform
Note that this feature is considered as experimental. It should work with simple configuration but may not in complex ones. If you have any issue with that feature, you are welcomed to come discussed your use case on the ivy-user mailing list, or discuss about implementation issues or improvement you may have found on ant-dev.
When developping a single OSGi bundle, a single ivy.xml (together with the use of the fixdeps task) is sufficent to describe precisely how the bundle requirements.
But when developping several bundles, it will be error prone to declare for each bundle its dependencies. Because once deployed in an OSGi environement, the bindings are sensitive to the available bundles. So when developping, we must ensure that the set of bundles will be the same set as the one at deploy time.
The concept of "target platform" is a perfect fit to describe the set of bundles to resolve against. Here is a recipe to handle it with just Ant+Ivy.
A Target Platform ProjectFirst you need a project (basically a folder) in which you will manage your target platform. In this project you'll need 3 files:
- an ivy.xml in which you will describe the bundles you need,
- an ivysettings.xml which will describe where to download bundles from,
- and a build.xml with which you'll manage your target platform.
Once generated, it is recommended to share that ivy-fixed.xml file into you version control system (subversion, git, etc...). The target 'update-dependencies' is then to be launched each time you edit the ivy.xml, when you want to change the content of your target platform.
The second target 'generate-target-platform' will generate an obr.xml, a OSGi Bundle repository descriptor. This file will list every artifact wich has been resolved by the ivy-fixed.xml. Then each of your bundles you develop will do its resolve against that obr.xml (see the obr resolver).
The generated obr.xml contains paths to the local filesystem, so it is recommended to not share it between developpers.
If it is required to develop your plugin with the Eclipse PDE plugin, you can then use the alternative target generate-retrieved-target-platform. It has the same principle than the 'generate-target-platform' but the artifacts are also retrieved in a single folder, just like are plugins in an Eclipse install. That way you can define your target platform within Eclipse quite easily.