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;
+}
