You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ant.apache.org by hi...@apache.org on 2010/12/20 12:19:40 UTC
svn commit: r1051068 - in /ant/ivy/site/target/history/trunk: ./ osgi/
samples/eclipse-plugin/ samples/standard-osgi/ style/
Author: hibou
Date: Mon Dec 20 11:19:39 2010
New Revision: 1051068
URL: http://svn.apache.org/viewvc?rev=1051068&view=rev
Log:
Regenerated site
Modified:
ant/ivy/site/target/history/trunk/book.html
ant/ivy/site/target/history/trunk/osgi.html
ant/ivy/site/target/history/trunk/osgi/eclipse-plugin.html
ant/ivy/site/target/history/trunk/osgi/sigil.html
ant/ivy/site/target/history/trunk/osgi/standard-osgi.html
ant/ivy/site/target/history/trunk/osgi/target-platform.html
ant/ivy/site/target/history/trunk/samples/eclipse-plugin/build.xml
ant/ivy/site/target/history/trunk/samples/eclipse-plugin/ivy.xml
ant/ivy/site/target/history/trunk/samples/eclipse-plugin/ivysettings.xml
ant/ivy/site/target/history/trunk/samples/standard-osgi/ivysettings.xml
ant/ivy/site/target/history/trunk/style/style.css
Modified: ant/ivy/site/target/history/trunk/book.html
URL: http://svn.apache.org/viewvc/ant/ivy/site/target/history/trunk/book.html?rev=1051068&r1=1051067&r2=1051068&view=diff
==============================================================================
--- ant/ivy/site/target/history/trunk/book.html (original)
+++ ant/ivy/site/target/history/trunk/book.html Mon Dec 20 11:19:39 2010
@@ -4966,9 +4966,14 @@ calls ivy with given ivysettings file an
<pre>
java -jar ivy.jar -settings path/to/myivysettings.xml -dependency bar foo 2.0 -main org.bar.foo.FooMain
</pre>
-calls ivy with given ivysettings file and resolve bar foo 2.0, and then run org.foo.FooMain class with the resolved artifacts as classpath<br class="xooki-br"/><br class="xooki-br"/><br class="xooki-br"/> <hr/><div class='toc-title toc-title-3'>OSGi</div><br class="xooki-br"/><br class="xooki-br"/>Since Apache Ivy™ 2.3, some support for OSGi™ dependency management has been introduced.<br class="xooki-br"/><br class="xooki-br"/>So with a standard ivy.xml, you can express some dependency on some OSGi bundle and every of their trasitive dependencies will be resolved. You can also declare in your ivy.xml some OSGi dependency, like a <tt>Require-Bundle</tt>, an <tt>Import-Package</tt> or an <tt>Import-Service</tt>, miming an OSGi MANIFEST.MF.<br class="xooki-br"/><br class="xooki-br"/><h2>Note on the implementation</h2>
+calls ivy with given ivysettings file and resolve bar foo 2.0, and then run org.foo.FooMain class with the resolved artifacts as classpath<br class="xooki-br"/><br class="xooki-br"/><br class="xooki-br"/> <hr/><div class='toc-title toc-title-3'>OSGi</div><br class="xooki-br"/><br class="xooki-br"/>Since Apache Ivy™ 2.3, some support for OSGi™ dependency management has been introduced.<br class="xooki-br"/>
+<div class="notice">
+ 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>.
+</div>
+
+So with a standard ivy.xml, you can express some dependency on some OSGi bundle and every of their trasitive dependencies will be resolved. You can also declare in your ivy.xml some OSGi dependency, like a <tt>Require-Bundle</tt>, an <tt>Import-Package</tt> or an <tt>Import-Service</tt>, miming an OSGi MANIFEST.MF.<br class="xooki-br"/><br class="xooki-br"/><h2>Note on the implementation</h2>
-With OSGi we can declare different kind of capabilites of a bundle which can match different kind of requirements of some other bundles (<tt>Require-Bundle</tt>/<tt>Bundle-SymbolicName</tt>, <tt>Import-Package</tt>/<tt>Export-Package</tt>, <tt>Import-Service</tt>/<tt>Export-Service</tt>). In Ivy we only have one kind of requirement and one kind of capability: the symbolic name of the bundle. Due to that restriction Ivy may not resolve exactly how we would expect with OSGi. The runtime of Ivy won't be as smart as a pure OSGi dependency manager. But we think that the mapping is working for most of the use cases involing OSGi dependencies management.<br class="xooki-br"/><br class="xooki-br"/>Details on the mapping of the OSGi dependency model into Ivy's one can be found in that <a href="osgi/osgi-mapping.html">page<a>.<br class="xooki-br"/><br class="xooki-br"/><h2>Repository descriptor based resolvers</h2>
+With OSGi we can declare different kind of capabilites of a bundle which can match different kind of requirements of some other bundles (<tt>Require-Bundle</tt>/<tt>Bundle-SymbolicName</tt>, <tt>Import-Package</tt>/<tt>Export-Package</tt>, <tt>Import-Service</tt>/<tt>Export-Service</tt>). In Ivy we only have one kind of requirement and one kind of capability: the symbolic name of the bundle. Due to that restriction Ivy may not resolve exactly how we would expect with OSGi. The runtime of Ivy won't be as smart as a pure OSGi dependency manager. But we think that the mapping is working for most of the use cases involing OSGi dependencies management.<br class="xooki-br"/><br class="xooki-br"/>Details on the mapping of the OSGi dependency model into Ivy's one can be found in that <a href="osgi/osgi-mapping.html">page</a>.<br class="xooki-br"/><br class="xooki-br"/><h2>Repository descriptor based resolvers</h2>
Since the nature of the OSGi dependencies, resolving against a repository cannot be started before acquiring the metadata of every bundle of the repository. To resolve an <tt>Import-Package</tt>, Ivy has to find every bundle which has the proper <tt>Export-Package</tt>. So unlike the usual Ivy resolvers, the OSGi capable ones have to get the descriptor before starting a resolve.<br class="xooki-br"/><br class="xooki-br"/>The descriptor probably being not instantanly downloaded, the descriptor is put in cache. (FIXME not implemented)<br class="xooki-br"/><br class="xooki-br"/><h2>Use cases</h2>
@@ -5138,7 +5143,12 @@ The OSGi <tt>Bundle-RequiredExecutionEnv
<h2>Bundle Fragment</h2>
-Ivy doesn't support the header <tt>Fragment-Host</tt>.<br class="xooki-br"/><br class="xooki-br"/>The work around is to manually specify as dependencies in the ivy.xml the bundles which would fit to be the extensions of the host bundle.<br class="xooki-br"/><br class="xooki-br"/> <hr/><div class='toc-title toc-title-4'>Building an Eclipse plugin</div><br class="xooki-br"/><br class="xooki-br"/>This page describes how to build an Eclipse™ plugin with Apache Ivy™ and its OSGi™ capabilities.<br class="xooki-br"/><br class="xooki-br"/><h1>Quick setup</h1>
+Ivy doesn't support the header <tt>Fragment-Host</tt>.<br class="xooki-br"/><br class="xooki-br"/>The work around is to manually specify as dependencies in the ivy.xml the bundles which would fit to be the extensions of the host bundle.<br class="xooki-br"/><br class="xooki-br"/> <hr/><div class='toc-title toc-title-4'>Building an Eclipse plugin</div><br class="xooki-br"/>
+<div class="notice">
+This documentation is describing the <b>experimental</b> OSGi capability of Ivy. 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>.
+</div>
+
+This page describes how to build an Eclipse™ plugin with Apache Ivy™ and its OSGi™ capabilities.<br class="xooki-br"/><br class="xooki-br"/><h1>Quick setup</h1>
In few steps, we will setup a build to compile and package an Eclipse plugin.<br class="xooki-br"/><br class="xooki-br"/><ol>
<li>download this <a href="../samples/eclipse-plugin/ivy.xml">ivy.xml<a>, this <a href="../samples/eclipse-plugin/ivysettings.xml">ivysettings.xml</a>, this <a href="../samples/eclipse-plugin/ivysettings.properties">ivysettings.properties</a>, this <a href="../samples/eclipse-plugin/build.xml">build.xml</a>, and put them into your plugin folder;</li>
@@ -5165,7 +5175,12 @@ Nota Bene: to be resolved correctly Ivy
<h2>The repository</h2>
-When building an Eclipse plugin, we are relying on a "target platform", the Eclipse installation we want our plugin to be eventually installed into. For Ivy, this will represent the repository of artifacts.<br class="xooki-br"/><br class="xooki-br"/>Ivy needs an aggragation of the OSGi metadata in order to resolve a such repository. The Ant task <a href="../use/buildobr.html">buildobr</a> build a OBR (OSGi Bundle Repository) descriptor file from a set of OSGi bundles. So here we are using this Ant task to gather OSGi metadata from the Eclipse plugins in the "target platform". In the above exemple, the file is build in <tt>target/repo-eclipse.xml</tt>.<br class="xooki-br"/><br class="xooki-br"/>The plugin to be build has then a ivy.xml file describing its depedencies to be used by Ivy. Since the actual depedencies are in the MANIFEST.MF file, in the ivy.xml file we specify that it extends <tt>META-INF/MANIFEST.MF</tt>. So there not much dependencies specified in the ivy.xml.
But as Ivy doesn't support the <tt>Bundle-Fragment</tt> OSGi feature, the ivy.xml can help specify the missing dependencies. <br class="xooki-br"/><br class="xooki-br"/>Having this setup, it is then a standard Ant+Ivy build. Ivy computes the classpath to be then used by the <tt>javac</tt> tasks. Note that <tt>javac</tt> is not aware of the OSGi metadata and is then incapable of failing to compile if private packages are accessed.<br class="xooki-br"/><br class="xooki-br"/> <hr/><div class='toc-title toc-title-4'>Building a standard OSGi bundle</div><br class="xooki-br"/><br class="xooki-br"/>This page describes how to build an OSGi™ bundle with Apache Ivy™. In this use case, we just basically want to compute a classpath to compile, optionaly one for testing too, and then publish our bundle in a OSGi aware repository.<br class="xooki-br"/><br class="xooki-br"/>In oder to produce OSGi metadata of suffient quality and to avoid maintaining them manually, the <a href="h
ttp://www.aqute.biz/Code/Bnd">bnd</a> tool will be used. The approach taken is then an "Ivy file first" approach. The dependencies will be specified in the ivy.xml file, the MANIFEST.MF being generated from the computed classpath.<br class="xooki-br"/><br class="xooki-br"/><br class="xooki-br"/><h1>Quick setup</h1>
+When building an Eclipse plugin, we are relying on a "target platform", the Eclipse installation we want our plugin to be eventually installed into. For Ivy, this will represent the repository of artifacts.<br class="xooki-br"/><br class="xooki-br"/>Ivy needs an aggragation of the OSGi metadata in order to resolve a such repository. The Ant task <a href="../use/buildobr.html">buildobr</a> build a OBR (OSGi Bundle Repository) descriptor file from a set of OSGi bundles. So here we are using this Ant task to gather OSGi metadata from the Eclipse plugins in the "target platform". In the above exemple, the file is build in <tt>target/repo-eclipse.xml</tt>.<br class="xooki-br"/><br class="xooki-br"/>The plugin to be build has then a ivy.xml file describing its depedencies to be used by Ivy. Since the actual depedencies are in the MANIFEST.MF file, in the ivy.xml file we specify that it extends <tt>META-INF/MANIFEST.MF</tt>. So there not much dependencies specified in the ivy.xml.
But as Ivy doesn't support the <tt>Bundle-Fragment</tt> OSGi feature, the ivy.xml can help specify the missing dependencies. <br class="xooki-br"/><br class="xooki-br"/>Having this setup, it is then a standard Ant+Ivy build. Ivy computes the classpath to be then used by the <tt>javac</tt> tasks. Note that <tt>javac</tt> is not aware of the OSGi metadata and is then incapable of failing to compile if private packages are accessed.<br class="xooki-br"/><br class="xooki-br"/> <hr/><div class='toc-title toc-title-4'>Building a standard OSGi bundle</div><br class="xooki-br"/>
+<div class="notice">
+This documentation is describing the <b>experimental</b> OSGi capability of Ivy. 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>.
+</div>
+
+This page describes how to build an OSGi™ bundle with Apache Ivy™. In this use case, we just basically want to compute a classpath to compile, optionaly one for testing too, and then publish our bundle in a OSGi aware repository.<br class="xooki-br"/><br class="xooki-br"/>In oder to produce OSGi metadata of suffient quality and to avoid maintaining them manually, the <a href="http://www.aqute.biz/Code/Bnd">bnd</a> tool will be used. The approach taken is then an "Ivy file first" approach. The dependencies will be specified in the ivy.xml file, the MANIFEST.MF being generated from the computed classpath.<br class="xooki-br"/><br class="xooki-br"/><br class="xooki-br"/><h1>Quick setup</h1>
In few steps, we will setup a build to compile and publish an OSGi bundle.<br class="xooki-br"/><br class="xooki-br"/><ol>
<li>download this <a href="../samples/standard-osgi/ivy.xml">ivy.xml<a>, this <a href="../samples/standard-osgi/ivysettings.xml">ivysettings.xml</a>, this <a href="../samples/standard-osgi/build.xml">build.xml</a>, this <a href="../samples/standard-osgi/org.apache.ivy.sample.standard-osgi.bnd">bnd file</a>, and put them into your project folder;</li>
@@ -5175,9 +5190,20 @@ In few steps, we will setup a build to c
</ol>
- <hr/><div class='toc-title toc-title-4'>Managing a target platform</div><br class="xooki-br"/><br class="xooki-br"/>Building an OSGi™ bundle with standard tools like <tt>javac</tt> and a classpath computed by Apache Ivy™ can be erroneous as these tools doesn't take into account the package visibility enforced by the OSGi metadata. Then switching to OSGi dedicated tools like the Eclipse™ JTD can be prefered. This kind of tools still need a "target platform", a set of jars against to compile and then later run. A target platform can be easily managed with Ivy and its OSGi capabilities.<br class="xooki-br"/><br class="xooki-br"/>TODO<br class="xooki-br"/><br class="xooki-br"/> <hr/><div class='toc-title toc-title-4'>Apache Felix Sigil</div><br class="xooki-br"/><br class="xooki-br"/>Another initiative to manage OSGi™ dependencies with Ivy is the project <a href="http://felix.apache.org/site/apache-felix-sigil.html">Apache Felix Sigil™</a>. We will try
to explain here the different approach taken there compared to the build-in OSGi capabilities of Ivy.<br class="xooki-br"/><br class="xooki-br"/><h1>A different approach</h1>
+ <hr/><div class='toc-title toc-title-4'>Managing a target platform</div><br class="xooki-br"/>
+<div class="notice">
+This documentation is describing the <b>experimental</b> OSGi capability of Ivy. 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>.
+</div>
+
+Building an OSGi™ bundle with standard tools like <tt>javac</tt> and a classpath computed by Apache Ivy™ can be erroneous as these tools doesn't take into account the package visibility enforced by the OSGi metadata. Then switching to OSGi dedicated tools like the Eclipse™ JTD can be prefered. This kind of tools still need a "target platform", a set of jars against to compile and then later run. A target platform can be easily managed with Ivy and its OSGi capabilities.<br class="xooki-br"/><br class="xooki-br"/>TODO<br class="xooki-br"/><br class="xooki-br"/> <hr/><div class='toc-title toc-title-4'>Apache Felix Sigil</div><br class="xooki-br"/><br class="xooki-br"/>Another initiative to manage OSGi™ dependencies is the project <a href="http://felix.apache.org/site/apache-felix-sigil.html">Apache Felix Sigil™</a>. Sigil can used also together with Ivy. We will try to explain here the different approach taken there compared to the build-in OSGi capabi
lities of Ivy.<br class="xooki-br"/><br class="xooki-br"/><h1>A different approach</h1>
+
+Apache Felix Sigil is at its core about managing OSGi dependencies, not directly related to Ivy. Most of it core feature is about the implementation of the not yet released OBR (OSGi Bundle Repository) specification. It then provides integration layers with sevral tools so human being can actually use the OBR API. As "layer" there is an Eclipse plugin, and there are the Ant/Ivy tasks and resolver.<br class="xooki-br"/><br class="xooki-br"/>On the other hand the build in OSGi capabilities in Ivy are targeted against users already familiar with Ivy and their <a href="http://ant.apache.org/ivy/links.html">tools</a> like <a href="http://ant.apache.org/ivy/ivyde">Apache IvyDE™</a>. So with a minimum of effort, they can get OSGi dependency management.<br class="xooki-br"/><br class="xooki-br"/><h1>Resulting differences</h1>
+
+<h2>Resolve</h2>
+
+The build-in OSGi resolver is <i>obviously</i> using the Ivy engine to do the resolution of the dependencies. The OSGi capability of Ivy is mainly implemented with a module descriptor parser which understands the OSGi metadata of a MANIFEST.MF.<br class="xooki-br"/><br class="xooki-br"/>On the other hand, Sigil is using a separate "engine" to do the resolution, the OBR, an engine which is dedicated to understand the OSGi metadata and their semantics.<br class="xooki-br"/><br class="xooki-br"/>The immediate consequence of this difference is that the build-in resolver is probably less accurate than the Sigil one as to understand the OSGi dependencies semantics. As explained in this <a href="osgi-mapping.html">page</a>, the OSGi model doesn't fit well into the Ivy one.<br class="xooki-br"/><br class="xooki-br"/>Whereas Ivy is not ready yet to fill most OSGi use cases, OSGi dependency management at build time is not that complex, contrary to the runtime one. We hope that Ivy wil
l catch up soon.<br class="xooki-br"/><br class="xooki-br"/><h2>Source of metadata</h2>
-The difference between the build-in OSGi resolver and the Sigil one is about the "engine" used to resolve dependencies.<br class="xooki-br"/><br class="xooki-br"/>The build-in OSGi resolver is <i>obviously</i> using the Ivy engine to do the resolution of the dependencies. The OSGi capability of Ivy is mainly due to the dependency parser implemented to understand the OSGi metadata in a MANIFEST.MF.<br class="xooki-br"/><br class="xooki-br"/>On the other hand, Sigil is using a separate "engine" to do the resolution, an engine which is dedicated to understand the OSGi metadata and their semantics.<br class="xooki-br"/><br class="xooki-br"/>The immediate consequence of this difference is that the build-in resolver is probably less accurate than the Sigil one as to understand the OSGi dependencies semantics. As explained in this <a href="osgi-mapping.html">page</a>, the OSGi model doesn't fit well into the Ivy one.<br class="xooki-br"/><br class="xooki-br"/><br class="xooki-br"/>
<b>TO BE CONFIRMED</b>But then the drawback of Sigil is that it is less integrated with Ivy, and once the resolution happens in its dedicated enine, no conflit resolver and no resolver chaining can happen.<br class="xooki-br"/><br class="xooki-br"/> <hr/><div class='toc-title toc-title-2'>Developer doc</div><br class="xooki-br"/><h1>Building from source</h1>
+Apache Felix Sigil has its own format about specifying the OSGi dependencies. Whereas Ivy requires an ivysettings.xml and an ivy.xml, Sigil requires a sigil-repos.properties and a sigil.properties. Then if you want to use the Sigil resolver in Ivy, you will need 4 files, the 2 Ivy ones and the 2 Sigil ones, as described <a href="http://felix.apache.org/site/apache-felix-sigil-ivy-quickstart.html">there</a>.<br class="xooki-br"/><br class="xooki-br"/>To support OSGi directly in Ivy, you just need to add an extra namespace in the ivy.xml, and in the ivysettings.xml, just declare the proper resolver and latest revision strategy.<br class="xooki-br"/><br class="xooki-br"/> <hr/><div class='toc-title toc-title-2'>Developer doc</div><br class="xooki-br"/><h1>Building from source</h1>
To build Ivy from source it's really easy. <br class="xooki-br"/><h2>Requirements</h2>
All you need is
<ul>
Modified: ant/ivy/site/target/history/trunk/osgi.html
URL: http://svn.apache.org/viewvc/ant/ivy/site/target/history/trunk/osgi.html?rev=1051068&r1=1051067&r2=1051068&view=diff
==============================================================================
--- ant/ivy/site/target/history/trunk/osgi.html (original)
+++ ant/ivy/site/target/history/trunk/osgi.html Mon Dec 20 11:19:39 2010
@@ -96,9 +96,14 @@
<div id="main">
<h1 class="title">OSGi</h1>
- <br class="xooki-br"/><br class="xooki-br"/>Since Apache Ivy™ 2.3, some support for OSGi™ dependency management has been introduced.<br class="xooki-br"/><br class="xooki-br"/>So with a standard ivy.xml, you can express some dependency on some OSGi bundle and every of their trasitive dependencies will be resolved. You can also declare in your ivy.xml some OSGi dependency, like a <tt>Require-Bundle</tt>, an <tt>Import-Package</tt> or an <tt>Import-Service</tt>, miming an OSGi MANIFEST.MF.<br class="xooki-br"/><br class="xooki-br"/><h2>Note on the implementation</h2>
+ <br class="xooki-br"/><br class="xooki-br"/>Since Apache Ivy™ 2.3, some support for OSGi™ dependency management has been introduced.<br class="xooki-br"/>
+<div class="notice">
+ 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>.
+</div>
+
+So with a standard ivy.xml, you can express some dependency on some OSGi bundle and every of their trasitive dependencies will be resolved. You can also declare in your ivy.xml some OSGi dependency, like a <tt>Require-Bundle</tt>, an <tt>Import-Package</tt> or an <tt>Import-Service</tt>, miming an OSGi MANIFEST.MF.<br class="xooki-br"/><br class="xooki-br"/><h2>Note on the implementation</h2>
-With OSGi we can declare different kind of capabilites of a bundle which can match different kind of requirements of some other bundles (<tt>Require-Bundle</tt>/<tt>Bundle-SymbolicName</tt>, <tt>Import-Package</tt>/<tt>Export-Package</tt>, <tt>Import-Service</tt>/<tt>Export-Service</tt>). In Ivy we only have one kind of requirement and one kind of capability: the symbolic name of the bundle. Due to that restriction Ivy may not resolve exactly how we would expect with OSGi. The runtime of Ivy won't be as smart as a pure OSGi dependency manager. But we think that the mapping is working for most of the use cases involing OSGi dependencies management.<br class="xooki-br"/><br class="xooki-br"/>Details on the mapping of the OSGi dependency model into Ivy's one can be found in that <a href="osgi/osgi-mapping.html">page<a>.<br class="xooki-br"/><br class="xooki-br"/><h2>Repository descriptor based resolvers</h2>
+With OSGi we can declare different kind of capabilites of a bundle which can match different kind of requirements of some other bundles (<tt>Require-Bundle</tt>/<tt>Bundle-SymbolicName</tt>, <tt>Import-Package</tt>/<tt>Export-Package</tt>, <tt>Import-Service</tt>/<tt>Export-Service</tt>). In Ivy we only have one kind of requirement and one kind of capability: the symbolic name of the bundle. Due to that restriction Ivy may not resolve exactly how we would expect with OSGi. The runtime of Ivy won't be as smart as a pure OSGi dependency manager. But we think that the mapping is working for most of the use cases involing OSGi dependencies management.<br class="xooki-br"/><br class="xooki-br"/>Details on the mapping of the OSGi dependency model into Ivy's one can be found in that <a href="osgi/osgi-mapping.html">page</a>.<br class="xooki-br"/><br class="xooki-br"/><h2>Repository descriptor based resolvers</h2>
Since the nature of the OSGi dependencies, resolving against a repository cannot be started before acquiring the metadata of every bundle of the repository. To resolve an <tt>Import-Package</tt>, Ivy has to find every bundle which has the proper <tt>Export-Package</tt>. So unlike the usual Ivy resolvers, the OSGi capable ones have to get the descriptor before starting a resolve.<br class="xooki-br"/><br class="xooki-br"/>The descriptor probably being not instantanly downloaded, the descriptor is put in cache. (FIXME not implemented)<br class="xooki-br"/><br class="xooki-br"/><h2>Use cases</h2>
Modified: ant/ivy/site/target/history/trunk/osgi/eclipse-plugin.html
URL: http://svn.apache.org/viewvc/ant/ivy/site/target/history/trunk/osgi/eclipse-plugin.html?rev=1051068&r1=1051067&r2=1051068&view=diff
==============================================================================
--- ant/ivy/site/target/history/trunk/osgi/eclipse-plugin.html (original)
+++ ant/ivy/site/target/history/trunk/osgi/eclipse-plugin.html Mon Dec 20 11:19:39 2010
@@ -96,7 +96,12 @@
<div id="main">
<h1 class="title">Building an Eclipse plugin</h1>
- <br class="xooki-br"/><br class="xooki-br"/>This page describes how to build an Eclipse™ plugin with Apache Ivy™ and its OSGi™ capabilities.<br class="xooki-br"/><br class="xooki-br"/><h1>Quick setup</h1>
+ <br class="xooki-br"/>
+<div class="notice">
+This documentation is describing the <b>experimental</b> OSGi capability of Ivy. 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>.
+</div>
+
+This page describes how to build an Eclipse™ plugin with Apache Ivy™ and its OSGi™ capabilities.<br class="xooki-br"/><br class="xooki-br"/><h1>Quick setup</h1>
In few steps, we will setup a build to compile and package an Eclipse plugin.<br class="xooki-br"/><br class="xooki-br"/><ol>
<li>download this <a href="../samples/eclipse-plugin/ivy.xml">ivy.xml<a>, this <a href="../samples/eclipse-plugin/ivysettings.xml">ivysettings.xml</a>, this <a href="../samples/eclipse-plugin/ivysettings.properties">ivysettings.properties</a>, this <a href="../samples/eclipse-plugin/build.xml">build.xml</a>, and put them into your plugin folder;</li>
Modified: ant/ivy/site/target/history/trunk/osgi/sigil.html
URL: http://svn.apache.org/viewvc/ant/ivy/site/target/history/trunk/osgi/sigil.html?rev=1051068&r1=1051067&r2=1051068&view=diff
==============================================================================
--- ant/ivy/site/target/history/trunk/osgi/sigil.html (original)
+++ ant/ivy/site/target/history/trunk/osgi/sigil.html Mon Dec 20 11:19:39 2010
@@ -96,9 +96,15 @@
<div id="main">
<h1 class="title">Apache Felix Sigil</h1>
- <br class="xooki-br"/><br class="xooki-br"/>Another initiative to manage OSGi™ dependencies with Ivy is the project <a href="http://felix.apache.org/site/apache-felix-sigil.html">Apache Felix Sigil™</a>. We will try to explain here the different approach taken there compared to the build-in OSGi capabilities of Ivy.<br class="xooki-br"/><br class="xooki-br"/><h1>A different approach</h1>
+ <br class="xooki-br"/><br class="xooki-br"/>Another initiative to manage OSGi™ dependencies is the project <a href="http://felix.apache.org/site/apache-felix-sigil.html">Apache Felix Sigil™</a>. Sigil can used also together with Ivy. We will try to explain here the different approach taken there compared to the build-in OSGi capabilities of Ivy.<br class="xooki-br"/><br class="xooki-br"/><h1>A different approach</h1>
-The difference between the build-in OSGi resolver and the Sigil one is about the "engine" used to resolve dependencies.<br class="xooki-br"/><br class="xooki-br"/>The build-in OSGi resolver is <i>obviously</i> using the Ivy engine to do the resolution of the dependencies. The OSGi capability of Ivy is mainly due to the dependency parser implemented to understand the OSGi metadata in a MANIFEST.MF.<br class="xooki-br"/><br class="xooki-br"/>On the other hand, Sigil is using a separate "engine" to do the resolution, an engine which is dedicated to understand the OSGi metadata and their semantics.<br class="xooki-br"/><br class="xooki-br"/>The immediate consequence of this difference is that the build-in resolver is probably less accurate than the Sigil one as to understand the OSGi dependencies semantics. As explained in this <a href="osgi-mapping.html">page</a>, the OSGi model doesn't fit well into the Ivy one.<br class="xooki-br"/><br class="xooki-br"/><br class="xooki-br"/>
<b>TO BE CONFIRMED</b>But then the drawback of Sigil is that it is less integrated with Ivy, and once the resolution happens in its dedicated enine, no conflit resolver and no resolver chaining can happen.<br class="xooki-br"/><br class="xooki-br"/>
+Apache Felix Sigil is at its core about managing OSGi dependencies, not directly related to Ivy. Most of it core feature is about the implementation of the not yet released OBR (OSGi Bundle Repository) specification. It then provides integration layers with sevral tools so human being can actually use the OBR API. As "layer" there is an Eclipse plugin, and there are the Ant/Ivy tasks and resolver.<br class="xooki-br"/><br class="xooki-br"/>On the other hand the build in OSGi capabilities in Ivy are targeted against users already familiar with Ivy and their <a href="http://ant.apache.org/ivy/links.html">tools</a> like <a href="http://ant.apache.org/ivy/ivyde">Apache IvyDE™</a>. So with a minimum of effort, they can get OSGi dependency management.<br class="xooki-br"/><br class="xooki-br"/><h1>Resulting differences</h1>
+
+<h2>Resolve</h2>
+
+The build-in OSGi resolver is <i>obviously</i> using the Ivy engine to do the resolution of the dependencies. The OSGi capability of Ivy is mainly implemented with a module descriptor parser which understands the OSGi metadata of a MANIFEST.MF.<br class="xooki-br"/><br class="xooki-br"/>On the other hand, Sigil is using a separate "engine" to do the resolution, the OBR, an engine which is dedicated to understand the OSGi metadata and their semantics.<br class="xooki-br"/><br class="xooki-br"/>The immediate consequence of this difference is that the build-in resolver is probably less accurate than the Sigil one as to understand the OSGi dependencies semantics. As explained in this <a href="osgi-mapping.html">page</a>, the OSGi model doesn't fit well into the Ivy one.<br class="xooki-br"/><br class="xooki-br"/>Whereas Ivy is not ready yet to fill most OSGi use cases, OSGi dependency management at build time is not that complex, contrary to the runtime one. We hope that Ivy wil
l catch up soon.<br class="xooki-br"/><br class="xooki-br"/><h2>Source of metadata</h2>
+
+Apache Felix Sigil has its own format about specifying the OSGi dependencies. Whereas Ivy requires an ivysettings.xml and an ivy.xml, Sigil requires a sigil-repos.properties and a sigil.properties. Then if you want to use the Sigil resolver in Ivy, you will need 4 files, the 2 Ivy ones and the 2 Sigil ones, as described <a href="http://felix.apache.org/site/apache-felix-sigil-ivy-quickstart.html">there</a>.<br class="xooki-br"/><br class="xooki-br"/>To support OSGi directly in Ivy, you just need to add an extra namespace in the ivy.xml, and in the ivysettings.xml, just declare the proper resolver and latest revision strategy.<br class="xooki-br"/><br class="xooki-br"/>
</div><!-- main -->
</td>
</tr>
Modified: ant/ivy/site/target/history/trunk/osgi/standard-osgi.html
URL: http://svn.apache.org/viewvc/ant/ivy/site/target/history/trunk/osgi/standard-osgi.html?rev=1051068&r1=1051067&r2=1051068&view=diff
==============================================================================
--- ant/ivy/site/target/history/trunk/osgi/standard-osgi.html (original)
+++ ant/ivy/site/target/history/trunk/osgi/standard-osgi.html Mon Dec 20 11:19:39 2010
@@ -96,7 +96,12 @@
<div id="main">
<h1 class="title">Building a standard OSGi bundle</h1>
- <br class="xooki-br"/><br class="xooki-br"/>This page describes how to build an OSGi™ bundle with Apache Ivy™. In this use case, we just basically want to compute a classpath to compile, optionaly one for testing too, and then publish our bundle in a OSGi aware repository.<br class="xooki-br"/><br class="xooki-br"/>In oder to produce OSGi metadata of suffient quality and to avoid maintaining them manually, the <a href="http://www.aqute.biz/Code/Bnd">bnd</a> tool will be used. The approach taken is then an "Ivy file first" approach. The dependencies will be specified in the ivy.xml file, the MANIFEST.MF being generated from the computed classpath.<br class="xooki-br"/><br class="xooki-br"/><br class="xooki-br"/><h1>Quick setup</h1>
+ <br class="xooki-br"/>
+<div class="notice">
+This documentation is describing the <b>experimental</b> OSGi capability of Ivy. 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>.
+</div>
+
+This page describes how to build an OSGi™ bundle with Apache Ivy™. In this use case, we just basically want to compute a classpath to compile, optionaly one for testing too, and then publish our bundle in a OSGi aware repository.<br class="xooki-br"/><br class="xooki-br"/>In oder to produce OSGi metadata of suffient quality and to avoid maintaining them manually, the <a href="http://www.aqute.biz/Code/Bnd">bnd</a> tool will be used. The approach taken is then an "Ivy file first" approach. The dependencies will be specified in the ivy.xml file, the MANIFEST.MF being generated from the computed classpath.<br class="xooki-br"/><br class="xooki-br"/><br class="xooki-br"/><h1>Quick setup</h1>
In few steps, we will setup a build to compile and publish an OSGi bundle.<br class="xooki-br"/><br class="xooki-br"/><ol>
<li>download this <a href="../samples/standard-osgi/ivy.xml">ivy.xml<a>, this <a href="../samples/standard-osgi/ivysettings.xml">ivysettings.xml</a>, this <a href="../samples/standard-osgi/build.xml">build.xml</a>, this <a href="../samples/standard-osgi/org.apache.ivy.sample.standard-osgi.bnd">bnd file</a>, and put them into your project folder;</li>
Modified: ant/ivy/site/target/history/trunk/osgi/target-platform.html
URL: http://svn.apache.org/viewvc/ant/ivy/site/target/history/trunk/osgi/target-platform.html?rev=1051068&r1=1051067&r2=1051068&view=diff
==============================================================================
--- ant/ivy/site/target/history/trunk/osgi/target-platform.html (original)
+++ ant/ivy/site/target/history/trunk/osgi/target-platform.html Mon Dec 20 11:19:39 2010
@@ -96,7 +96,12 @@
<div id="main">
<h1 class="title">Managing a target platform</h1>
- <br class="xooki-br"/><br class="xooki-br"/>Building an OSGi™ bundle with standard tools like <tt>javac</tt> and a classpath computed by Apache Ivy™ can be erroneous as these tools doesn't take into account the package visibility enforced by the OSGi metadata. Then switching to OSGi dedicated tools like the Eclipse™ JTD can be prefered. This kind of tools still need a "target platform", a set of jars against to compile and then later run. A target platform can be easily managed with Ivy and its OSGi capabilities.<br class="xooki-br"/><br class="xooki-br"/>TODO<br class="xooki-br"/><br class="xooki-br"/>
+ <br class="xooki-br"/>
+<div class="notice">
+This documentation is describing the <b>experimental</b> OSGi capability of Ivy. 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>.
+</div>
+
+Building an OSGi™ bundle with standard tools like <tt>javac</tt> and a classpath computed by Apache Ivy™ can be erroneous as these tools doesn't take into account the package visibility enforced by the OSGi metadata. Then switching to OSGi dedicated tools like the Eclipse™ JTD can be prefered. This kind of tools still need a "target platform", a set of jars against to compile and then later run. A target platform can be easily managed with Ivy and its OSGi capabilities.<br class="xooki-br"/><br class="xooki-br"/>TODO<br class="xooki-br"/><br class="xooki-br"/>
</div><!-- main -->
</td>
</tr>
Modified: ant/ivy/site/target/history/trunk/samples/eclipse-plugin/build.xml
URL: http://svn.apache.org/viewvc/ant/ivy/site/target/history/trunk/samples/eclipse-plugin/build.xml?rev=1051068&r1=1051067&r2=1051068&view=diff
==============================================================================
--- ant/ivy/site/target/history/trunk/samples/eclipse-plugin/build.xml (original)
+++ ant/ivy/site/target/history/trunk/samples/eclipse-plugin/build.xml Mon Dec 20 11:19:39 2010
@@ -50,7 +50,7 @@
<target name="ivy:resolve" depends="ivy:configure">
<!-- classical resolve and cache-path -->
<ivy:resolve file="ivy.xml" conf="*" />
- <ivy:cachepath pathid="compile.classpath" conf="default" useOrigin="true" />
+ <ivy:cachepath pathid="compile.classpath" conf="compile" useOrigin="true" />
</target>
<target name="compile" depends="ivy:resolve" description="Compile the Eclipse plugin">
Modified: ant/ivy/site/target/history/trunk/samples/eclipse-plugin/ivy.xml
URL: http://svn.apache.org/viewvc/ant/ivy/site/target/history/trunk/samples/eclipse-plugin/ivy.xml?rev=1051068&r1=1051067&r2=1051068&view=diff
==============================================================================
--- ant/ivy/site/target/history/trunk/samples/eclipse-plugin/ivy.xml (original)
+++ ant/ivy/site/target/history/trunk/samples/eclipse-plugin/ivy.xml Mon Dec 20 11:19:39 2010
@@ -17,18 +17,23 @@
specific language governing permissions and limitations
under the License.
-->
-<ivy-module version="2.2">
- <info organisation="com.acme" module="myplugin">
- <extends location="META-INF/MANIFEST.MF" />
+<ivy-module version="2.2" xmlns:o="http://ant.apache.org/ivy/osgi">
+ <info organisation="" module="myplugin">
+ <extends organisation="" module="myplugin" revision="1.0.0.qualifier" location="META-INF/MANIFEST.MF" />
</info>
<configurations>
<conf name="compile" extends="default,embedded" description="Dependencies for the compilation" />
<conf name="embedded" description="Dependencies embedded into the plugin's jar" />
+ <conf name="win32" extends="compile" description="To run on Microsoft Windows" />
+ <conf name="macos" extends="compile" description="To run on Mac OS X" />
+ <conf name="gtk" extends="compile" description="To run on Linux" />
</configurations>
<dependencies>
<!-- exemple of a dependency that we can't declare in the MANIFEST.MF because we want it to be embedded -->
<!--dependency osgi="bundle" org="" module="org.apache.commons.httpcore" rev="4.1.0" conf="embedded->default" /-->
<!-- Ivy-Osgi doesn't understand bundle fragment -->
- <dependency osgi="bundle" org="" name="org.eclipse.swt.cocoa.macosx" rev="3.+" />
+ <dependency o:type="bundle" org="" name="org.eclipse.swt.win32.win32.x86" rev="3.+" conf="win32->default" />
+ <dependency o:type="bundle" org="" name="org.eclipse.swt.cocoa.macosx.x86_64" rev="3.+" conf="macos->default" />
+ <dependency o:type="bundle" org="" name="org.eclipse.swt.gtk.linux.x86" rev="3.+" conf="linux->default" />
</dependencies>
</ivy-module>
Modified: ant/ivy/site/target/history/trunk/samples/eclipse-plugin/ivysettings.xml
URL: http://svn.apache.org/viewvc/ant/ivy/site/target/history/trunk/samples/eclipse-plugin/ivysettings.xml?rev=1051068&r1=1051067&r2=1051068&view=diff
==============================================================================
--- ant/ivy/site/target/history/trunk/samples/eclipse-plugin/ivysettings.xml (original)
+++ ant/ivy/site/target/history/trunk/samples/eclipse-plugin/ivysettings.xml Mon Dec 20 11:19:39 2010
@@ -20,28 +20,8 @@
<!-- Load the properties where is defined the eclipse location -->
<properties file="ivysettings.properties" />
- <!-- We need some custom types -->
- <!-- The parser of ivy.xml that can reference a MANIFEST.MF-->
- <typedef name="osgi-ivyparser" classname="org.apache.ivy.osgi.ivy.OsgiIvyParser" />
- <!-- The Ivy Osgi repo resolver -->
- <typedef name="osgi-repo" classname="org.apache.ivy.osgi.repo.BundleRepoResolver" />
- <!-- Ivy Osgi's latest startegy -->
- <typedef name="osgi-latest" classname="org.apache.ivy.osgi.ivy.OsgiRevisionStrategy" />
- <!-- Ivy's default provider of OSGi execution environement profiles -->
- <typedef name="osgi-profileProvider" classname="org.apache.ivy.osgi.repo.osgi.ExecutionEnvironmentProfileProvider" />
-
- <!-- We will use Ivy Osgi's latest strategy -->
- <latest-strategies>
- <osgi-latest name="osgi-latest-revision" />
- </latest-strategies>
-
- <!-- We will use Ivy Osgi's parsers -->
- <parsers>
- <osgi-manifest-parser />
- </parsers>
-
<!-- We need to define the Ivy Osgi latest strategy as the default one -->
- <settings defaultResolver="eclipse" defaultLatestStrategy="osgi-latest-revision" />
+ <settings defaultResolver="eclipse" defaultLatestStrategy="latest-osgi" />
<!-- These are usual cache setup -->
<caches resolutionCacheDir="${ivy.settings.dir}/cache/resolution" useOrigin="true">
@@ -50,9 +30,7 @@
<!-- We just need to define our Ivy OSGi resolver -->
<resolvers>
- <obr name="eclipse" repoXmlFile="${ivy.settings.dir}/target/repo-eclipse.xml">
- <osgi-profileProvider />
- </obr>
+ <obr name="eclipse" repoXmlFile="${ivy.settings.dir}/target/repo-eclipse.xml" />
</resolvers>
</ivysettings>
Modified: ant/ivy/site/target/history/trunk/samples/standard-osgi/ivysettings.xml
URL: http://svn.apache.org/viewvc/ant/ivy/site/target/history/trunk/samples/standard-osgi/ivysettings.xml?rev=1051068&r1=1051067&r2=1051068&view=diff
==============================================================================
--- ant/ivy/site/target/history/trunk/samples/standard-osgi/ivysettings.xml (original)
+++ ant/ivy/site/target/history/trunk/samples/standard-osgi/ivysettings.xml Mon Dec 20 11:19:39 2010
@@ -18,33 +18,8 @@
-->
<ivysettings>
- <!-- We need some custom types -->
- <!-- The parser of MANIFEST.MF -->
- <typedef name="osgi-parser" classname="org.apache.ivy.osgi.repo.ManifestMDParser" />
- <!-- The parser of ivy.xml that can reference a MANIFEST.MF-->
- <typedef name="osgi-ivyparser" classname="org.apache.ivy.osgi.ivy.OsgiIvyParser" />
- <!-- The Ivy Osgi repo resolver -->
- <typedef name="osgi-repo" classname="org.apache.ivy.osgi.repo.BundleRepoResolver" />
- <!-- Ivy Osgi's latest startegy -->
- <typedef name="osgi-latest" classname="org.apache.ivy.osgi.ivy.OsgiRevisionStrategy" />
- <!-- Ivy's default provider of OSGi execution environement profiles -->
- <typedef name="osgi-profileProvider" classname="org.apache.ivy.osgi.repo.osgi.ExecutionEnvironmentProfileProvider" />
-
- <!-- We will use Ivy Osgi's latest strategy -->
- <latest-strategies>
- <osgi-latest name="osgi-latest-revision" />
- </latest-strategies>
-
- <!-- We will use Ivy Osgi's parsers -->
- <parsers>
- <osgi-ivyparser />
- <osgi-parser>
- <osgi-profileProvider />
- </osgi-parser>
- </parsers>
-
<!-- We need to define the Ivy Osgi latest strategy as the default one -->
- <settings defaultResolver="osgi-bundles" defaultLatestStrategy="osgi-latest-revision" />
+ <settings defaultResolver="osgi-bundles" defaultLatestStrategy="latest-osgi" />
<!-- These are usual cache setup -->
<caches resolutionCacheDir="${ivy.settings.dir}/cache/resolution" useOrigin="true">
@@ -53,9 +28,7 @@
<!-- We just need to define our Ivy Osgi resolver -->
<resolvers>
- <osgi-repo name="osgi-bundles" repoXmlFile="${ivy.settings.dir}/../repo/repo.xml">
- <osgi-profileProvider />
- </osgi-repo>
+ <obr name="osgi-bundles" repoXmlFile="${ivy.settings.dir}/../repo/repo.xml" />
</resolvers>
</ivysettings>
Modified: ant/ivy/site/target/history/trunk/style/style.css
URL: http://svn.apache.org/viewvc/ant/ivy/site/target/history/trunk/style/style.css?rev=1051068&r1=1051067&r2=1051068&view=diff
==============================================================================
--- ant/ivy/site/target/history/trunk/style/style.css (original)
+++ ant/ivy/site/target/history/trunk/style/style.css Mon Dec 20 11:19:39 2010
@@ -304,3 +304,9 @@ tr.homeitems a:hover {
}
.home img { border-width:0; }
+.notice {
+ padding: 5px;
+ border: 1px;
+ background-color: #FFFFCE;
+ margin: 10px;
+}