2008/9/11 Brad Cox, Ph.D. <[EMAIL PROTECTED]> > 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. >
the disconnect is that Eclipse/PDE uses the manifest as a recipe to build a bundle - whereas the bundleplugin uses instructions in the pom.xml to assemble both the manifest and the bundle so when building with the bundleplugin you don't really need to provide a manifest as it will be generated (and verified) automatically from the bundle content - this is imho a big plus, as for example you don't have to worry about updating the import directive, because it is (by default) automatically updated to include any packages that you use but aren't inside the bundle the major issue when working with Maven and Eclipse is how to reconcile these 2 different approaches - personally I treat the pom as *the* place where the bundle is defined, and use the bundleplugin and maven-eclipse-plugin to generate the various files needed by Eclipse (along with extracting the manifest to the expected place) this means other IDE users aren't disadvantaged, but I have to remember that any changes I make to the manifest in Eclipse/PDE may be lost when I rebuild in Maven unless I also update the pom.xml (for example when adding dependencies) My mental model is the pom is the input and MANIFEST.MF is produced by felix > maven plugin based on that pom. that is correct - the pom instructions define the content, which shapes the manifest > 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. can you provide more detail about these broken references? the generated manifest should be correct (ie. you can deploy the bundle) but there may be things that PDE doesn't like - for example it doesn't work well with large "uses" clauses, even though other frameworks (like Felix) can handle them without error, so you could try setting <_nouses>true</_nouses> to remove them from the manifest feel free to open a JIRA issue with the generated manifest and "re-organized" manifest along with the pom.xml and any other instructions used to configure the bundleplugin 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). > I can't say without knowing more about your pom and also what you mean by bogus references (this could cover almost anything) - it could be a simple mis-configuration or a bug - I do know several developers who are successfully using the bundleplugin with Eclipse without needing to repair the manifest... There also seems to be vast differences between running mvn install in the > command line and running the same thing in eclipse. do you mean running Maven inside Eclipse using m2eclipse - or doing a PDE build? > 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. > are you importing as an existing project? ie. using the maven-eclipse-plugin to generate the.project/.classpath? > 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). > again, I'd need to see the actual generated manifest and bundle, as this could be due to all sorts of reasons (misconfiguration, import conflicts, etc.) > 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/> > ok - here you are asking the bundleplugin to embed all dependencies as separate jarfiles inside the target/dependency directory, this means you should be careful with your Export-Package setting - as remember that BND uses Export-Package to decide what classes to pull into the bundle... > > <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> you don't need the split package setting on imports - personally I prefer to start with the default <Import-Package>*</Import-Package> and then add explicit version ranges and mark packages as optional as required > <Export-Package> > ., > *;-split-package:=merge-first, > this is wrong - by using * you're asking BND to pull in all the classes from the build classpath (including dependency classes) directly into the bundle, which means you'll have the same files both inlined and embedded... as mentioned in the online docs, if you want to export packages from embedded jars, you should use the <_exportcontents> instruction as this doesn't change the bundle content. there may be further changes needed for the Eclipse side but I can't be sure without hands-on access to the example... > 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, keep this com.gestalt... in Export-Package though as this isn't part of a dependency (afaik) and so you'll want this pulled in directly > <!-- > 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] > -- Cheers, Stuart
