[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [equinox-dev] Good support for PDE in build systems anyone?
|
PN> works good with the PDE at https://scm.ops4j.org/repos/ops4j/
PN> laboratory/users/andreas/builder/
PN> - package the bundle with a similar structure as the development layout.
JM>Is this working for you?
It's a scaled down version of a build system we have developed for a
customer.
It can be used as a template on how to create an ant/ivy build system
for OSGI/PDE projects.
JM>What are the gotchas?
* You declare jar dependencies in ivy.xml. Once ivy has downloaded them
into your project you
have to include them in your manifest.
Some of the dependencies has to be declared in both the ivy.xml and
the manifest :(
Maybe one should generate the manifest from the ivy file (as Niclas
pointed out)
* Each dependency can be in one or more configuration, I have defined
the following conf:
api - jars which other projects can compile against, e.g if
bundle does not export any packages
the project does not expose an api configuration.
compile - jars which normally is not accessed from other projects,
the compile time classpath.
runtime - jars which should be included in the bundle classpath, also
included in the compile time classpath
test - jars which must not be included in the bundle classpath (
will be removed by the ant script )
bundle - jars which can be deployed on an OSGi container (i.e a bundle)
default - if a configuration has not been defined (i.e. common-lang
since we do not have control over that)
* You add test dependencies to your bundle classpath in the Manifest.
(We do not need to create a new project for this.)
* When ant builds your bundle it will only include runtime jar files.
It also filters
the Manifest file and removes all none runtime jars
* PDE launch files are parsed to generate an equinox ini file. It also
checks that the
ivy file contains all the bundles in the launch file.
* It does not build two jar files like knopflerfish: one for the
implementation and one for the API.
A-all.jar - contains api+implementation, A-api.jar only the api part.
It would be rather easy to implemenent this feature. (easy peasy with
jruby in ant :-)
Example of an ivy.xml:
...
<publications>
<!-- publish this project with bundle and api configurations -->
<!-- the same jar file is both used as an api and a bundle :( -->
<artifact name="bundle.a" type="jar" conf="api,bundle"/>
</publications>
<dependencies>
<!-- put the api configuration of org.eclipse.osgi into the
compile configuration of this bundle -->
<!-- we have an ivy file for this which publishes an api
configuration of it -->
<dependency org="org.eclipse" name="org.eclipse.osgi"
rev="3.2.0.v20060214" conf="compile->api"/>
<!-- bundle.b exports some packages we want to use -->
<dependency org="myorg" name="bundle.b" rev="1.2+"
conf="compile->api"/>
<!-- bundle.c exports some packages we use in our api -->
<dependency org="myorg" name="bundle.c" rev="integration+"
conf="api,compile->api"/>
<!-- runtime dependencies that will be included in the bundle
classpath -->
<dependency org="apache" name="commons-lang" rev="2.1"
conf="runtime->default"/>
<!-- test dependencies that will not be included in the
bundle classpath -->
<dependency org="junit" name="junit" rev="3.8.1"
conf="test->default"/>
</dependencies>
The ivy syntax conf="x->y" means that the dependency configuration y
will be included
in the project configuration x.
Example:
Project A has a <dependency name="B" conf="compile->api">
This means that the api configuration of B will be included in the
compile configuration of A.
If project C would need to compile against A and still be able to access
B's api
add the following dependency in C's ivy: <dependency name="A"
conf="compile->compile">
This is for example needed when you have a fragment project (C is a
fragment to A)
JM>BTW, what is hte license on Ivy?
BSD License
http://www.jayasoft.org/ivy/license
/Andreas
