I think your problem is that you want Ecipse PDE and Maven to work
together. Unfortunately, they are more or less oblivious of each other
and both want to be in charge of your classpath and manifest. Looking
at your POM, you seem to be completely entangled in the clash between
Maven, and PDE. Not a pretty picture :-(
I think Maven is not a friend of PDE. The main reason is that PDE
maintains a set of bundles in the Target platform (see Eclipse
preferences) and more or less randomly picks providers from that set
if you organize your manifest. At the same time you have Maven that is
selecting imports from its repository. So you have two programs both
wanting to be in charge of the classpath and manifest. Looking at your
POM, your classpath must be a total entangled mess, e.g. split package
directives are rarely necessary, they usually indicate your classpath
is not managed and contains the same jars several times.
So you should make a choice between Maven OR PDE. If you pick Maven,
you should, imho, use JDT. The normal Java development environment. I
think maven can create an eclipse project for you and that is how it
works (or at least worked the last time I looked, I am not a maven
expert). This puts Maven in charge of your classpath and manifest.
I.e. when you change your pom, you have to let maven update the
Eclipse classpath (in the .classpath file). This model works quite
well for normal bundles. However, if you make Eclipse plugins, PDE has
features that are quite nice, for one the debugging of Eclipse itself.
In that case, PDE is in charge of the classpath AND te manifest.
I really would not know how to combine Maven and PDE :-( I know some
people are including the manifest from PDE in the pom:
<_include>~META-INF/MANIFEST.MF</_include>
This will read the manifest from PDE, which means you have at least a
single definition of the manifest data shared between Maven and
Eclipse. The ~ indicates that any properties from the POM have
priority over manifest headers. However, it still means you have 2
classpaths. PDE has his internal magic class path based on the Target
platform, which can not be read externally. Maven will have his
repository based classpath. That is, you will have to make sure these
classpaths match, and this a manual job last time I looked.
I know Jason van Zyl (Maven) and Jeff McAffer (Eclipse) are working on
creating an Eclipse plugin for maven. This would solve many of your
problems.
The maven plugin uses bnd (of which I do know something). bnd works
from a given classpath. In the maven plugin it gets the classpath and
manifest headers derived from the POM. It will take your Export-
Package and Private-Package instructions (ok, <export-package>),
construct a jar file from these packages (they can come from your
project but also from anywhere on your classpath), and then analyzes
the resulting content. Any reference to outside packages is placed on
the referred list. This referred list is then filtered against the
<import-package> instructions. In almost all cases, the default
<import-package>*</import-package> is more than sufficient. It
basically means that any referred package is included.
The <import-package> instruction can be useful if you include code
from other jars that refer to packages you know will never be used.
I.e. some code has an ant task creating a reference to the ant jar but
you only use it as an Eclipse plugin. In that case you exclude imports:
<import-package>!org.apache.ant.*,*</import-package>
In your pom, you manually add a zillion split-package: directives. I
guess you got a warning that there were split packages. This means
that bnd found multiple jars exporting the same package and was unsure
what to do: merge, first, or last. In my opinion, it is usually always
wrong and just means the same jar is on the classpath twice. Just
cleanup the classpath and the message goes away. The bnd diagnostic
shows in which jars it found the duplicate packages.
You also use <_failok/>, this instruction is only there so we could
build test cases that have invalid manifests. Using this is production
always means something is wrong (or please tell me). It is very
dangerous because real errors are not causing the build to fail
because of it.
Overall, trying to use maven + Eclipse is a bit of a mess. For this
reason I am personally using ant with bnd and Eclipse with JDT. bnd
can read the Eclipse JDT .classpath file and that means that I can
maintain the classpath in JDT and bnd follows. In my lab I currently
have a bnd that works reverse. It contains an Eclipse classpath
container so Eclipse will read the bnd information. This was necessary
because bnd now has a repository model so Eclipse needed to know where
the classpath entries are stored. This should come out (and described)
soon ...
That said, bnd itself is a project that combines PDE and bnd. Because
bnd contains an Eclipse plugin, I wanted to use the Eclipse debugging
facilities to debug Eclipse itself. For this purpose I let Eclipse PDE
maintain a "dummy" manifest. This manifest is used for debugging.
However, when ant builds the project, it only puts the project output
directory on the classpath. bnd does not require any references to be
on the classpath, it just assumes they are imports. The only
disadvantage is, is that these imports have no metadata. That is, when
bnd can find the matching export it can use the metadata for the
import. E.g., if you your code refers to foo.bar, and the provider of
that package has foo.bar;version=1.2.3 metadata, then the import
statement will become foo.bar;version=1.2, obviously if there is no
exporter information, you will have to set this information yourself
with the <import-package> instruction (<import-
package>foo.bar;version=1.2,*</import-package>).
You could do the same thing with maven, but then you miss out of a lot
of the functions of maven, like for example testing because the
classpath will not be complete.
You might want to read the bnd manual: http://www.aQute.biz/Code/Bnd
for some more background.
So my suggestion is to use JDT and let maven be in charge, until the
Eclipse Maven plugin becomes available. Or take a look what standalone
bnd can do for you.
Kind regards,
Peter Kriens
On 10 sep 2008, at 20:24, Brad Cox, Ph.D. wrote:
Reposted; first one got buried somewhere.
I'm using felix's maven plugin to build OSGI apps in eclipse. I
understand OSGI overall but the tools chain is driving me nuts.
What I don't understand is the interaction between pom.xml, the
felix maven plugin, MANIFEST.MF, and the "Organize Manifest Wizard"
in eclipse. And should META-INF be in the bundle root or src/main/
resources? Putting a copy in src/... does seem to be noticed there
but breaks everything, including command line builds. Apparently due
to a broken com.ibm.icu.something according to posted bugs.
My mental model is the pom is the input and MANIFEST.MF is produced
by felix maven plugin based on that pom. This model seems inaccurate
somehow. Felix maven plugin's output is voluminous with lots of
broken references which eclipse's "organize manifest wizard" seems
there to repair. Where do the bogus references come from? In
practice, it seems necessary for me to do further repairs to
MANIFEST.MF by hand, but these seem to somehow persist after I
change the pom (thus the conflict with my mental model).
There also seems to be vast differences between running mvn install
in the command line and running the same thing in eclipse. Using the
command line then importing into eclipse results in bundles that are
broken in eclipse and another round of whack a mole to sort things
out again. This often results in multiply-defined jar errors with
the same jar in "PDE Dependencies" and "Maven Dependencies".
Removing PDE dependencies in build settings seems to sort that out;
sometimes.
The specific problem I'm struggling with is
org.osgi.framework.BundleException: The activator
com.gestalt.soakit.core.CoreActivator for bundle soakit.core is
invalid when that class is definitely defined. I think this means
there's a conflict between the BundleActivator class from OSGI vs
Equinox, but nothing I've tried seems to repair it (importing
org.eclipse.osgi.everything, not org.osgi.whatever).
The main problem here is that I'm confused about how the tools chain
works; broken mental model. Can someone set me straight?
Here's one of the key poms.
<?xml version="1.0" encoding="UTF-8"?>
<project
xmlns="http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd
"
>
<modelVersion>4.0.0</modelVersion>
<groupId>soakit</groupId>
<artifactId>soakit.core</artifactId>
<version>1.0-SNAPSHOT</version>
<name>soakit.core</name>
<description>SoaKit Core Abstraction Layer. Defines interfaces and
abstract classes for the components defined in sub-modules. Provides
a factory class for defining soakit composites with an XML
configuration file.</description>
<packaging>bundle</packaging>
<parent>
<groupId>soakit</groupId>
<artifactId>soakit</artifactId>
<version>1.0-SNAPSHOT</version>
</parent>
<dependencies>
<dependency>
<groupId>commons-collections</groupId>
<artifactId>commons-collections</artifactId>
<version>3.2</version>
</dependency>
<dependency>
<groupId>jdom</groupId>
<artifactId>jdom</artifactId>
<version>1.0</version>
</dependency>
<dependency>
<groupId>javax.xml.parsers</groupId>
<artifactId>jaxp-api</artifactId>
<version>1.4</version>
</dependency>
<dependency>
<groupId>javax.xml.ws</groupId>
<artifactId>jaxws-api</artifactId>
<version>2.1-1</version>
</dependency>
<dependency>
<groupId>xerces</groupId>
<artifactId>xercesImpl</artifactId>
<version>2.8.1</version>
</dependency>
<dependency>
<groupId>org.eclipse</groupId>
<artifactId>osgi</artifactId>
<version>3.4.0.v20080605-1900</version>
</dependency>
<dependency>
<groupId>jaxen</groupId>
<artifactId>jaxen</artifactId>
<version>1.1-beta-9</version>
</dependency>
</dependencies>
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
</resource>
<resource>
<directory>.</directory>
<includes>
<include>plugin.xml</include>
</includes>
</resource>
</resources>
<plugins>
<plugin>
<artifactId>maven-eclipse-plugin</artifactId>
<configuration>
<pde>true</pde>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>1.4.3</version>
<extensions>true</extensions>
<configuration>
<unpackBundle>true</unpackBundle>
<manifestLocation>META-INF</manifestLocation>
<instructions>
<Bundle-Version>${pom.version}</Bundle-Version>
<Bundle-Name>${artifactId}</Bundle-Name>
<Bundle-SymbolicName>${artifactId}</Bundle-SymbolicName>
<Bundle-Description>Soakit Core Bundle</
Bundle-Description>
<Bundle-Activator>com.gestalt.soakit.core.CoreActivator</Bundle-
Activator>
<Embed-Dependency>*;scope=compile|runtime;inline=true</Embed-
Dependency>
<Embed-Transitive>true</Embed-Transitive>
<Embed-Directory>target/dependency</Embed-Directory>
<_failok/>
<Bundle-RequiredExecutionEnvironment>J2SE-1.5</Bundle-
RequiredExecutionEnvironment>
<Import-Package>
.,
*;-split-package:=merge-first,
org.apache.commons.collections.*;-split-package:=merge-
first;version="3.2"
org.apache.commons.collections.iterators.*;-split-package:=merge-
first;version="3.2",
org.jdom;-split-package:=merge-first;version="1.0",
org.jdom.*;-split-package:=merge-first;version="1.0",
org.jdom.input.*;-split-package:=merge-first;version="1.0",
org.jdom.output.*;-split-package:=merge-first;version="1.0",
org.apache.xerces.parsers;-split-package:=merge-first,
<!--
javax.*;-split-package:=merge-first,
javax.jws.*;-split-package:=merge-first,
javax.xml.bind.*;-split-package:=merge-
first,
javax.annotation.*;-split-package:=merge-
first,
javax.xml.soap.*;-split-package:=merge-
first,
javax.xml.stream.*;-split-package:=merge-
first,
javax.activation.*;-split-package:=merge-
first,
-->
</Import-Package>
<Export-Package>
.,
*;-split-package:=merge-first,
org.apache.commons.collections.*;-split-package:=merge-
first;version="3.2",
org.apache.commons.collections.iterators.*;-split-package:=merge-
first;version="3.2",
org.jdom;-split-package:=merge-first;version="1.0",
org.jdom.*;-split-package:=merge-first;version="1.0",
org.jdom.input.*;-split-package:=merge-first;version="1.0",
org.jdom.output.*;-split-package:=merge-first;version="1.0",
org.apache.xerces.parsers.*;-split-package:=merge-first,
com.gestalt.soakit.core.*;-split-package;=merge-first,
<!--
javax.*;-split-package:=merge-first,
javax.jws.*;-split-package:=merge-first,
javax.xml.bind;-split-package:=merge-first,
javax.annotation;-split-package:=merge-
first,
javax.xml.soap;-split-package:=merge-first,
javax.xml.stream;-split-package:=merge-
first,
javax.activation;-split-package:=merge-
first,
-->
</Export-Package>
</instructions>
</configuration>
</plugin>
<!--
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-eclipse-plugin</artifactId>
<configuration>
<projectNameTemplate>[artifactId]-[version]</projectNameTemplate>
<wtpmanifest>true</wtpmanifest>
<wtpapplicationxml>true</wtpapplicationxml>
<wtpversion>2.0</wtpversion>
<manifest>${basedir}/src/main/resources/META-INF/MANIFEST.MF</
manifest>
</configuration>
</plugin>
-->
</plugins>
<extensions>
</extensions>
</build>
</project>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
