blob: 1f6464499a24956119facea6bf58e1bfac607335 [file] [log] [blame]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-->
<html>
<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<script type="text/javascript">var xookiConfig = {level: 1};</script>
<script type="text/javascript" src="../xooki/xooki.js"></script>
</head>
<body>
<textarea id="xooki-source">
<table class="notice">
<tr>
<td style="vertical-align: top"><img src="../images/warning.png" style="float:left;" /></td>
<td>
Note that this feature is considered as <b>experimental</b>. 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 <a href="http://ant.apache.org/ivy/mailing-lists.html">ivy-user</a> mailing list, or discuss about implementation issues or improvement you may have found on <a href="http://ant.apache.org/ivy/mailing-lists.html">ant-dev</a>.
</td>
</tr>
</table>
The concept of "target platform" is a concept introduced by Eclipse&#153; to describe the set of bundle which will run together in an OSGi&#153; environement. Then when developping an OSGi bundle, we expect it to run in a such "target platform".
When developping a single OSGi bundle, a single ivy.xml (together with the use of the <a href="../use/fixdeps.html">fixdeps</a> 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.
<h1>A Target Platform Project</h1>
First you need a project (basically a folder) in which you will manage your target platform. In this project you'll need 3 files:
<ul>
<li>an <a href="../samples/target-platform/ivy.xml">ivy.xml</a> in which you will describe the bundles you need,</li>
<li>an <a href="../samples/target-platform/ivysettings.xml">ivysettings.xml</a> which will describe where to download bundles from,</li>
<li>and a <a href="../samples/target-platform/build.xml">build.xml</a> with which you'll manage your target platform.</li>
</ul>
In the build there is a first important target: <tt>'update-dependencies'</tt>. Since the OSGi dependencies are very sensible to the available resources to resolve against, it is important to make the resolve as tight and reproductible as possible. First this target will do a resolve with the <tt>ivy.xml</tt>: a resolve which is very sensible to the content of the remote repo, thus not much reproductible. And it is will generate an <tt>ivy-fixed.xml</tt> from the resolved depedencies: this Ivy file contains only fixed non transitive dependencies (see the <a href="../use/fixdeps.html">fixdeps</a> task for further info). With that <tt>ivy-fixed.xml</tt> file, resolves are then reproductible and will always generate the same set of artifacts.
Once generated, it is recommended to share that <tt>ivy-fixed.xml</tt> file into you version control system (subversion, git, etc...). The target <tt>'update-dependencies'</tt> is then to be launched each time you edit the <tt>ivy.xml</tt>, when you want to change the content of your target platform.
The second target <tt>'generate-target-platform'</tt> will generate an <tt>obr.xml</tt>, a OSGi Bundle repository descriptor. This file will list every artifact wich has been resolved by the <tt>ivy-fixed.xml</tt>. Then each of your bundles you develop will do its resolve against that <tt>obr.xml</tt> (see the <a href="../resolver/obr.html">obr resolver</a>).
The generated <tt>obr.xml</tt> 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 <tt>generate-retrieved-target-platform</tt>. It has the same principle than the <tt>'generate-target-platform'</tt> 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.
</textarea>
<script type="text/javascript">xooki.postProcess();</script>
</body>
</html>