Hello, With the felix maven-bundle-plugin it is possible to add a <manifestLocation> element. <manifestLocation>META-INF</manifestLocation> would place the generated Manifest.MF File in a META-INF folder at the root of your project and therefore enables eclipse pde To find your maven generated manifest.
HTH, Michael -----Ursprüngliche Nachricht----- Von: Peter Kriens [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 11. September 2008 10:21 An: [email protected] Betreff: Re: OSGI Tools question 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
