You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by "Lewis, Eric" <Er...@ipi.ch> on 2009/07/14 11:00:35 UTC
Create Eclipse plugin from all dependencies - how?
Hi
I need to gather all dependencies from a Maven POM and copy them to an Eclipse plugin directory and then create that plugin from that which covers all the JARs and exports all the packages.
The question is: How can I do that?
One of the tools would be the 'bundleall' goal of the Felix Maven plugin, but somehow it looks for way too many dependencies. When I use the similar dependency:copy-depencies, I don't run into the same trouble. Specifically, it seems that deep down, somewhere, I have a dependency which can't be resolved, because the artefact 'stax:stax-ri:jar:1.0' can't be found.
So the question is: Can I configure the 'bundleall' goal to exclude certain dependencies? From debugging the Maven output, I don't see any configuration possibility:
[DEBUG] Configuring mojo 'org.apache.felix:maven-bundle-plugin:2.0.0:bundleall' -->
[DEBUG] (f) baseDir = C:\jp\client
[DEBUG] (f) buildDirectory = C:\jp\client\target
[DEBUG] (f) localRepository = [local] -> file://C:\Documents and Settings\lewis_lee\.m2\repository
[DEBUG] (f) manifestLocation = C:\jp\client\target\classes\META-INF
[DEBUG] (f) outputDirectory = C:\jp\client\target\bundles
[DEBUG] (f) project = MavenProject: ch.ipi:client:1.0.0-SNAPSHOT @ C:\jp\client\pom.xml
[DEBUG] (f) remoteRepositories = [[repository.central] -> http://repository/content/groups/public, [central] -> http://repo1.maven.org/maven
2]
[DEBUG] (f) supportedProjectTypes = [jar, bundle, ejb]
[DEBUG] (f) wrapImportPackage = *
Or could I use the dependency plugin, download what I need and trick the Felix plugin into believing that the target directory is my repository?
Ok, the other question then is: How do I create an Eclipse plugin from this? Would the POM described under 'Eclipse/PDE integration' be sufficient to create an Eclipse project?
Thanks for any help! I don't know a lot about OSGi, I just have to build it ;-)
Best regards,
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Create Eclipse plugin from all dependencies - how?
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/7/15 Lewis, Eric <Er...@ipi.ch>
> So, I tried the pax:eclipse plugin as a substitute for eclipse:eclipse.
>
> First of all, I'm confused about the only configuration parameter which
> seems useful to me, 'fixDependencies'.
> If it's a switch, why isn't it a boolean? Default is EXTERNAL, but what
> else is there?
>
long story, basically we had to support different policies regarding which
dependencies are 'fixed'
( fixing means changing the automatic type applied by the
maven-eclipse-plugin so that they're
treated as normal Eclipse dependencies rather than OSGi dependencies -
this is because the
maven-eclipse-plugin assumes Eclipse will do the wiring for OSGi
dependencies via the target
platform, but this is not always true - especially when you have test
classes in your project )
Anyway, I see that everything is copied over to target/pax-eclipse and
> partially unpacked.
>
> But things are done multiple times... Here are my dependencies:
> [INFO] ch.ipi:esvclient-serverlib:bundle:1.0.0-SNAPSHOT
> [INFO] +- ch.ipi:util-type:jar:1.0.0-SNAPSHOT:compile
> [INFO] | +- commons-lang:commons-lang:jar:2.4:compile
> [INFO] | +- ch.ipi:util-global:jar:1.0.0-SNAPSHOT:compile
> [INFO] | +- findbugs:annotations:jar:1.0.0:compile
> [INFO] | \- com.google.code.findbugs:jsr305:jar:1.3.8:compile
> [INFO] +- junit:junit:jar:4.5:test
> [INFO] +- ch.qos.logback:logback-classic:jar:0.9.14:test
> [INFO] | \- ch.qos.logback:logback-core:jar:0.9.14:test
> [INFO] \- org.slf4j:slf4j-api:jar:1.5.6:test (scope not updated to compile)
>
> I get the following .classpath, where that dreaded M2_REPO is used again
> :-)
well that's par for the course - the maven-eclipse-plugin code uses the
M2_REPO variable
so that project files can be shared between teams (it doesn't expect that
you'll be copying
the files locally) - I guess we could remove the entries as they're not
strictly required now,
but up to now no-one's really had an issue with them
mvn -Declipse.workspace=<path-to-eclipse-workspace>
eclipse:add-maven-repo
will set the M2_REPO variable for you in Eclipse (or you can add this
variable manually)
Also for instance annotations-1.0.0.jar is used twice (plus unpacked as
> well)
>
> <classpath>
> <classpathentry path="target/classes" kind="output"/>
> <classpathentry path="org.eclipse.jdt.launching.JRE_CONTAINER"
> kind="con"/>
> <classpathentry path="org.eclipse.pde.core.requiredPlugins" kind="con"/>
> <classpathentry
> path="M2_REPO/findbugs/annotations/1.0.0/annotations-1.0.0.jar" kind="var"/>
> <classpathentry
> path="M2_REPO/commons-lang/commons-lang/2.4/commons-lang-2.4.jar"
> kind="var"/>
> <classpathentry
> path="M2_REPO/com/google/code/findbugs/jsr305/1.3.8/jsr305-1.3.8.jar"
> kind="var"/>
> <classpathentry path="M2_REPO/junit/junit/4.5/junit-4.5.jar" kind="var"/>
> <classpathentry
> path="M2_REPO/ch/qos/logback/logback-classic/0.9.14/logback-classic-0.9.14.jar"
> kind="var"/>
> <classpathentry
> path="M2_REPO/ch/qos/logback/logback-core/0.9.14/logback-core-0.9.14.jar"
> kind="var"/>
> <classpathentry
> path="M2_REPO/org/slf4j/slf4j-api/1.5.6/slf4j-api-1.5.6.jar" kind="var"/>
> <classpathentry
> path="M2_REPO/ch/ipi/util-global/1.0.0-SNAPSHOT/util-global-1.0.0-SNAPSHOT.jar"
> kind="var"/>
> <classpathentry
> path="M2_REPO/ch/ipi/util-type/1.0.0-SNAPSHOT/util-type-1.0.0-SNAPSHOT.jar"
> kind="var"/>
> <classpathentry path="target/pax-eclipse" exported="true" kind="lib"/>
> <classpathentry path="target/pax-eclipse/util-global-1.0.0-SNAPSHOT.jar"
> exported="true" kind="lib"/>
> <classpathentry path="target/pax-eclipse/commons-lang-2.4.jar"
> exported="true" kind="lib"/>
> <classpathentry path="target/pax-eclipse/jsr305-1.3.8.jar" exported="true"
> kind="lib"/>
> <classpathentry path="target/pax-eclipse/annotations-1.0.0.jar"
> exported="true" kind="lib"/>
> <classpathentry path="target/pax-eclipse/util-type-1.0.0-SNAPSHOT.jar"
> exported="true" kind="lib"/>
> </classpath>
>
> Since I do my own dependency copying, I now have the same artefact four
> times
well the whole point of the pax:eclipse goal is that you don't need to do
your own copying ;)
> - in the root as JAR
you shouldn't need this anymore if you decide to use the pax plugin
> - in the M2_REPO as JAR
this is another side-effect of building on the maven-eclipse-plugin code,
again we could
remove this entry as you're embedding it but it hasn't caused any problems
so we just
leave it there
also note that the M2_REPO is your local Maven repository, so you'll always
have jars
sitting there because that's how Maven works...
> - in the target/pax-eclipse as JAR
ok, this is the expected embedded dependency as "munged" by the pax-plugin
> - in the target/pax-eclipse/... as class
>
and this is an inlined class because you're still using
<Export-Package>*</Export-Package>
> So... still not there, it seems.
>
well removing your own copying of dependencies and using <_exportcontents>
instead
of <Export-Package> should remove most of the extraneous entries - the
M2_REPO
classpath entries that related to embedded dependencies could also be
removed by
a small tweak to the pax-plugin code, but from experience they're mostly
harmless
I've received your example project, will send you some suggested changes
--
Cheers, Stuart
Best regards,
> Eric
>
>
> >
> > Yes, I'm now down to one (!) dependency (and its transitive
> > dependencies) - still doesn't work (26 errors).
> >
> > >
> > > Now, I know that these packages do exist in the
> > dependencies, so it's
> > > > probably some kind of misconfiguration. One of the RCP
> > > developers mentioned
> > > > that the 'uses:=' part might be the troublemaker...?
> > >
> > >
> > > yes, PDE doesn't like excessive "uses" constraint (but there are
> > > places where you need them to avoid potential loader problems)
> > >
> > > it's only when you're exporting lots of inter-related packages that
> > > the "uses" constraints becomes an issue, I've never had trouble
> > > using them with plug-ins that export well-defined APIs
> > >
> > > to turn it off put <_nouses>true</_nouses> in your Bnd instructions
> >
> > Thanks, but first I'll try the maven-pax-plugin.
> >
> > >
> > > Also, I'm generating an Eclipse PDE project as described on
> > > the Felix page,
> > > > but really, it's a total mess.
> > > > Only about a third of the dependencies are in the visible
> > > 'Referenced
> > > > Libraries', about half of them use the M2_REPO environment
> > > variable, the
> > > > rest is hard-coded as linked resource in the .project file,
> > > and of course
> > > > all of them point to my local Maven repo instead of the project!
> > >
> > >
> > > well that's the Eclipse plug-in for you - which is why I
> > adapted it in
> > > the maven-pax-plugin to try and improve the project metadata for
> > > OSGi / plug-in projects
> >
> > I'll try that next.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
AW: Create Eclipse plugin from all dependencies - how?
Posted by "Lewis, Eric" <Er...@ipi.ch>.
So, I tried the pax:eclipse plugin as a substitute for eclipse:eclipse.
First of all, I'm confused about the only configuration parameter which seems useful to me, 'fixDependencies'.
If it's a switch, why isn't it a boolean? Default is EXTERNAL, but what else is there?
Anyway, I see that everything is copied over to target/pax-eclipse and partially unpacked.
But things are done multiple times... Here are my dependencies:
[INFO] ch.ipi:esvclient-serverlib:bundle:1.0.0-SNAPSHOT
[INFO] +- ch.ipi:util-type:jar:1.0.0-SNAPSHOT:compile
[INFO] | +- commons-lang:commons-lang:jar:2.4:compile
[INFO] | +- ch.ipi:util-global:jar:1.0.0-SNAPSHOT:compile
[INFO] | +- findbugs:annotations:jar:1.0.0:compile
[INFO] | \- com.google.code.findbugs:jsr305:jar:1.3.8:compile
[INFO] +- junit:junit:jar:4.5:test
[INFO] +- ch.qos.logback:logback-classic:jar:0.9.14:test
[INFO] | \- ch.qos.logback:logback-core:jar:0.9.14:test
[INFO] \- org.slf4j:slf4j-api:jar:1.5.6:test (scope not updated to compile)
I get the following .classpath, where that dreaded M2_REPO is used again :-)
Also for instance annotations-1.0.0.jar is used twice (plus unpacked as well)
<classpath>
<classpathentry path="target/classes" kind="output"/>
<classpathentry path="org.eclipse.jdt.launching.JRE_CONTAINER" kind="con"/>
<classpathentry path="org.eclipse.pde.core.requiredPlugins" kind="con"/>
<classpathentry path="M2_REPO/findbugs/annotations/1.0.0/annotations-1.0.0.jar" kind="var"/>
<classpathentry path="M2_REPO/commons-lang/commons-lang/2.4/commons-lang-2.4.jar" kind="var"/>
<classpathentry path="M2_REPO/com/google/code/findbugs/jsr305/1.3.8/jsr305-1.3.8.jar" kind="var"/>
<classpathentry path="M2_REPO/junit/junit/4.5/junit-4.5.jar" kind="var"/>
<classpathentry path="M2_REPO/ch/qos/logback/logback-classic/0.9.14/logback-classic-0.9.14.jar" kind="var"/>
<classpathentry path="M2_REPO/ch/qos/logback/logback-core/0.9.14/logback-core-0.9.14.jar" kind="var"/>
<classpathentry path="M2_REPO/org/slf4j/slf4j-api/1.5.6/slf4j-api-1.5.6.jar" kind="var"/>
<classpathentry path="M2_REPO/ch/ipi/util-global/1.0.0-SNAPSHOT/util-global-1.0.0-SNAPSHOT.jar" kind="var"/>
<classpathentry path="M2_REPO/ch/ipi/util-type/1.0.0-SNAPSHOT/util-type-1.0.0-SNAPSHOT.jar" kind="var"/>
<classpathentry path="target/pax-eclipse" exported="true" kind="lib"/>
<classpathentry path="target/pax-eclipse/util-global-1.0.0-SNAPSHOT.jar" exported="true" kind="lib"/>
<classpathentry path="target/pax-eclipse/commons-lang-2.4.jar" exported="true" kind="lib"/>
<classpathentry path="target/pax-eclipse/jsr305-1.3.8.jar" exported="true" kind="lib"/>
<classpathentry path="target/pax-eclipse/annotations-1.0.0.jar" exported="true" kind="lib"/>
<classpathentry path="target/pax-eclipse/util-type-1.0.0-SNAPSHOT.jar" exported="true" kind="lib"/>
</classpath>
Since I do my own dependency copying, I now have the same artefact four times
- in the root as JAR
- in the M2_REPO as JAR
- in the target/pax-eclipse as JAR
- in the target/pax-eclipse/... as class
So... still not there, it seems.
Best regards,
Eric
>
> Yes, I'm now down to one (!) dependency (and its transitive
> dependencies) - still doesn't work (26 errors).
>
> >
> > Now, I know that these packages do exist in the
> dependencies, so it's
> > > probably some kind of misconfiguration. One of the RCP
> > developers mentioned
> > > that the 'uses:=' part might be the troublemaker...?
> >
> >
> > yes, PDE doesn't like excessive "uses" constraint (but there are
> > places where you need them to avoid potential loader problems)
> >
> > it's only when you're exporting lots of inter-related packages that
> > the "uses" constraints becomes an issue, I've never had trouble
> > using them with plug-ins that export well-defined APIs
> >
> > to turn it off put <_nouses>true</_nouses> in your Bnd instructions
>
> Thanks, but first I'll try the maven-pax-plugin.
>
> >
> > Also, I'm generating an Eclipse PDE project as described on
> > the Felix page,
> > > but really, it's a total mess.
> > > Only about a third of the dependencies are in the visible
> > 'Referenced
> > > Libraries', about half of them use the M2_REPO environment
> > variable, the
> > > rest is hard-coded as linked resource in the .project file,
> > and of course
> > > all of them point to my local Maven repo instead of the project!
> >
> >
> > well that's the Eclipse plug-in for you - which is why I
> adapted it in
> > the maven-pax-plugin to try and improve the project metadata for
> > OSGi / plug-in projects
>
> I'll try that next.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Create Eclipse plugin from all dependencies - how?
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/7/15 Lewis, Eric <Er...@ipi.ch>
> Hi Stuart
>
> >
> > no, if you use the 2.0.0 bundleplugin (which is the latest
> > stable version)
>
> Yes, I do.
>
> > then:
> >
> > <Export-Package>*</Export-Package>
> >
> > will pull in all classes from your dependencies (ie. the
> > entire project
> > classpath)
> > into the bundle - so if you do a "jar tvf" on the bundle
> > you'll see lots of
> > classes
> > inlined into the final jar
> >
> > now if you also have:
> >
> > <Embed-Dependency>*</Embed-Dependency>
> >
> > then you're also telling the Bnd Tool to embed each
> > dependency jar inside
> > the
> > final jar - so basically you end up with duplicate content
> > (inlined and
> > embedded)
>
> Well, I don't know if I mentioned it, but I'm doing this to create one
> Eclipse plugin which contains all our dependencies. Basically we're doing a
> client/server application, and of course the client has to know all the
> server objects (a couple of JARs with their dependencies) to work.
> We've been messing around with this topic for some time now, and there
> seems to be no really elegant solution.
> Either all dependencies have to be OSGi bundles (and good luck finding
> them) or you glue up some super-plugin with all the JARs in the
> build.properties and all the packages exported in the MANIFEST.MF
>
> Perhaps we're totally wrong with this second approach, but it a short test
> (done by hand) worked. However, building this with Maven and friends seems a
> bit more difficult.
>
> >
> > Every package should be exported.
> >
> >
> > right, and using:
> >
> > <_exportcontents>*</_exportcontents>
> > <Embed-Dependency>*</Embed-Dependency>
> >
> > will tell the Bnd Tool to embed all dependencies and make all
> > the packages
> > contained inside them public - but without then inlining any of their
> > contents
> >
> > of course, if you're happy using inlined content then you
> > could just use:
> >
> > <Export-Package>*</Export-Package>
> >
> > instead of bothering with any Embed-Dependency instructions
> >
> >
> > no, <Export-Package> applies to your entire compilation
> > classpath not just
> > your local sources - however, the default <Export-Package> is
> > calculated to
> > only export your local packages
> >
> >
> > if you use <Export-Package>*</Export-Package> with the 2.0.0
> > bundleplugin
> > you will end up inlining your entire compilation classpath,
> > which is usually
> > not
> > what you want
>
> I think your explanation is good but goes over my head ;-)
> As I mentioned, since we don't know better, we just want to export every
> package of the dependencies and their transitive dependencies.
>
> > it sounds like you have a large amount of packages in this one plug-in
> > and you're attempting to export all of them (which is kind of opposite
> > to the idea behind OSGi)
>
> Right, but we've come to the conclusion that it's the only thing that works
> :-(
> I did discuss with the Eclipse guys that (from my newbie OSGi view), all
> dependencies should be OSGi bundles, and that the plugins should just pick
> whatever they like. But it seems that this results in classloader problems.
>
> >
> > the problem with this export-all approach is that you basically end up
> > with a load of spaghetti that PDE then has to wire up, and
> > when it gets
> > stuck on one part then it starts reporting lots of errors
> > (because they're
> > all interconnected)
> >
> > so it may be it's just one error stopping PDE from resolving
> > the bundle
>
> Yes, I'm now down to one (!) dependency (and its transitive dependencies) -
> still doesn't work (26 errors).
>
> >
> > Now, I know that these packages do exist in the dependencies, so it's
> > > probably some kind of misconfiguration. One of the RCP
> > developers mentioned
> > > that the 'uses:=' part might be the troublemaker...?
> >
> >
> > yes, PDE doesn't like excessive "uses" constraint (but there are
> > places where you need them to avoid potential loader problems)
> >
> > it's only when you're exporting lots of inter-related packages that
> > the "uses" constraints becomes an issue, I've never had trouble
> > using them with plug-ins that export well-defined APIs
> >
> > to turn it off put <_nouses>true</_nouses> in your Bnd instructions
>
> Thanks, but first I'll try the maven-pax-plugin.
>
> >
> > Also, I'm generating an Eclipse PDE project as described on
> > the Felix page,
> > > but really, it's a total mess.
> > > Only about a third of the dependencies are in the visible
> > 'Referenced
> > > Libraries', about half of them use the M2_REPO environment
> > variable, the
> > > rest is hard-coded as linked resource in the .project file,
> > and of course
> > > all of them point to my local Maven repo instead of the project!
> >
> >
> > well that's the Eclipse plug-in for you - which is why I adapted it in
> > the maven-pax-plugin to try and improve the project metadata for
> > OSGi / plug-in projects
>
> I'll try that next.
>
> >
> > Do you have any idea how I could force the Eclipse plugin to
> > do the right
> > > thing? I see in the example that there seems to be a
> > plugin.xml which I
> > > don't have, perhaps the path configuration is in there?
> > >
> >
> > plugin.xml is how the plug-in contributes to the Extension registry,
> > it doesn't really affect the operation of the maven-eclipse-plugin or
> > how the paths get configured
> >
> > you could create an example POM over at http://www.ops4j.org
> > (see http://wiki.ops4j.org/display/ops4j/Committers for access
> > - it's as simple as signing up) - or pick another hosting site and
> > put the example there (or failing that just email the project zip)
> >
> > that would make it easier to see what's going on and help out,
> > rather than trying to reconstruct it based on email fragments
>
> Would it be ok if I send you a ZIP to your personal email address?
>
sure, ok with me
Best regards,
> Eric
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
--
Cheers, Stuart
AW: Create Eclipse plugin from all dependencies - how?
Posted by "Lewis, Eric" <Er...@ipi.ch>.
I forgot to mention: Basically, this is what the Eclipse developers did:
http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse.pde.doc.user/guide/tools/project_wizards/plugin_from_archives.htm
> -----Ursprüngliche Nachricht-----
> Von: Lewis, Eric [mailto:Eric.Lewis@ipi.ch]
> Gesendet: Mittwoch, 15. Juli 2009 13:42
> An: users@felix.apache.org
> Betreff: AW: Create Eclipse plugin from all dependencies - how?
>
> Hi Stuart
>
> >
> > no, if you use the 2.0.0 bundleplugin (which is the latest
> > stable version)
>
> Yes, I do.
>
> > then:
> >
> > <Export-Package>*</Export-Package>
> >
> > will pull in all classes from your dependencies (ie. the
> > entire project
> > classpath)
> > into the bundle - so if you do a "jar tvf" on the bundle
> > you'll see lots of
> > classes
> > inlined into the final jar
> >
> > now if you also have:
> >
> > <Embed-Dependency>*</Embed-Dependency>
> >
> > then you're also telling the Bnd Tool to embed each
> > dependency jar inside
> > the
> > final jar - so basically you end up with duplicate content
> > (inlined and
> > embedded)
>
> Well, I don't know if I mentioned it, but I'm doing this to
> create one Eclipse plugin which contains all our
> dependencies. Basically we're doing a client/server
> application, and of course the client has to know all the
> server objects (a couple of JARs with their dependencies) to work.
> We've been messing around with this topic for some time now,
> and there seems to be no really elegant solution.
> Either all dependencies have to be OSGi bundles (and good
> luck finding them) or you glue up some super-plugin with all
> the JARs in the build.properties and all the packages
> exported in the MANIFEST.MF
>
> Perhaps we're totally wrong with this second approach, but it
> a short test (done by hand) worked. However, building this
> with Maven and friends seems a bit more difficult.
>
> >
> > Every package should be exported.
> >
> >
> > right, and using:
> >
> > <_exportcontents>*</_exportcontents>
> > <Embed-Dependency>*</Embed-Dependency>
> >
> > will tell the Bnd Tool to embed all dependencies and make all
> > the packages
> > contained inside them public - but without then inlining
> any of their
> > contents
> >
> > of course, if you're happy using inlined content then you
> > could just use:
> >
> > <Export-Package>*</Export-Package>
> >
> > instead of bothering with any Embed-Dependency instructions
> >
> >
> > no, <Export-Package> applies to your entire compilation
> > classpath not just
> > your local sources - however, the default <Export-Package> is
> > calculated to
> > only export your local packages
> >
> >
> > if you use <Export-Package>*</Export-Package> with the 2.0.0
> > bundleplugin
> > you will end up inlining your entire compilation classpath,
> > which is usually
> > not
> > what you want
>
> I think your explanation is good but goes over my head ;-)
> As I mentioned, since we don't know better, we just want to
> export every package of the dependencies and their transitive
> dependencies.
>
> > it sounds like you have a large amount of packages in this
> one plug-in
> > and you're attempting to export all of them (which is kind
> of opposite
> > to the idea behind OSGi)
>
> Right, but we've come to the conclusion that it's the only
> thing that works :-(
> I did discuss with the Eclipse guys that (from my newbie OSGi
> view), all dependencies should be OSGi bundles, and that the
> plugins should just pick whatever they like. But it seems
> that this results in classloader problems.
>
> >
> > the problem with this export-all approach is that you
> basically end up
> > with a load of spaghetti that PDE then has to wire up, and
> > when it gets
> > stuck on one part then it starts reporting lots of errors
> > (because they're
> > all interconnected)
> >
> > so it may be it's just one error stopping PDE from resolving
> > the bundle
>
> Yes, I'm now down to one (!) dependency (and its transitive
> dependencies) - still doesn't work (26 errors).
>
> >
> > Now, I know that these packages do exist in the
> dependencies, so it's
> > > probably some kind of misconfiguration. One of the RCP
> > developers mentioned
> > > that the 'uses:=' part might be the troublemaker...?
> >
> >
> > yes, PDE doesn't like excessive "uses" constraint (but there are
> > places where you need them to avoid potential loader problems)
> >
> > it's only when you're exporting lots of inter-related packages that
> > the "uses" constraints becomes an issue, I've never had trouble
> > using them with plug-ins that export well-defined APIs
> >
> > to turn it off put <_nouses>true</_nouses> in your Bnd instructions
>
> Thanks, but first I'll try the maven-pax-plugin.
>
> >
> > Also, I'm generating an Eclipse PDE project as described on
> > the Felix page,
> > > but really, it's a total mess.
> > > Only about a third of the dependencies are in the visible
> > 'Referenced
> > > Libraries', about half of them use the M2_REPO environment
> > variable, the
> > > rest is hard-coded as linked resource in the .project file,
> > and of course
> > > all of them point to my local Maven repo instead of the project!
> >
> >
> > well that's the Eclipse plug-in for you - which is why I
> adapted it in
> > the maven-pax-plugin to try and improve the project metadata for
> > OSGi / plug-in projects
>
> I'll try that next.
>
> >
> > Do you have any idea how I could force the Eclipse plugin to
> > do the right
> > > thing? I see in the example that there seems to be a
> > plugin.xml which I
> > > don't have, perhaps the path configuration is in there?
> > >
> >
> > plugin.xml is how the plug-in contributes to the Extension registry,
> > it doesn't really affect the operation of the
> maven-eclipse-plugin or
> > how the paths get configured
> >
> > you could create an example POM over at http://www.ops4j.org
> > (see http://wiki.ops4j.org/display/ops4j/Committers for access
> > - it's as simple as signing up) - or pick another hosting site and
> > put the example there (or failing that just email the project zip)
> >
> > that would make it easier to see what's going on and help out,
> > rather than trying to reconstruct it based on email fragments
>
> Would it be ok if I send you a ZIP to your personal email address?
>
>
> Best regards,
> Eric
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
AW: Create Eclipse plugin from all dependencies - how?
Posted by "Lewis, Eric" <Er...@ipi.ch>.
Hi Stuart
>
> no, if you use the 2.0.0 bundleplugin (which is the latest
> stable version)
Yes, I do.
> then:
>
> <Export-Package>*</Export-Package>
>
> will pull in all classes from your dependencies (ie. the
> entire project
> classpath)
> into the bundle - so if you do a "jar tvf" on the bundle
> you'll see lots of
> classes
> inlined into the final jar
>
> now if you also have:
>
> <Embed-Dependency>*</Embed-Dependency>
>
> then you're also telling the Bnd Tool to embed each
> dependency jar inside
> the
> final jar - so basically you end up with duplicate content
> (inlined and
> embedded)
Well, I don't know if I mentioned it, but I'm doing this to create one Eclipse plugin which contains all our dependencies. Basically we're doing a client/server application, and of course the client has to know all the server objects (a couple of JARs with their dependencies) to work.
We've been messing around with this topic for some time now, and there seems to be no really elegant solution.
Either all dependencies have to be OSGi bundles (and good luck finding them) or you glue up some super-plugin with all the JARs in the build.properties and all the packages exported in the MANIFEST.MF
Perhaps we're totally wrong with this second approach, but it a short test (done by hand) worked. However, building this with Maven and friends seems a bit more difficult.
>
> Every package should be exported.
>
>
> right, and using:
>
> <_exportcontents>*</_exportcontents>
> <Embed-Dependency>*</Embed-Dependency>
>
> will tell the Bnd Tool to embed all dependencies and make all
> the packages
> contained inside them public - but without then inlining any of their
> contents
>
> of course, if you're happy using inlined content then you
> could just use:
>
> <Export-Package>*</Export-Package>
>
> instead of bothering with any Embed-Dependency instructions
>
>
> no, <Export-Package> applies to your entire compilation
> classpath not just
> your local sources - however, the default <Export-Package> is
> calculated to
> only export your local packages
>
>
> if you use <Export-Package>*</Export-Package> with the 2.0.0
> bundleplugin
> you will end up inlining your entire compilation classpath,
> which is usually
> not
> what you want
I think your explanation is good but goes over my head ;-)
As I mentioned, since we don't know better, we just want to export every package of the dependencies and their transitive dependencies.
> it sounds like you have a large amount of packages in this one plug-in
> and you're attempting to export all of them (which is kind of opposite
> to the idea behind OSGi)
Right, but we've come to the conclusion that it's the only thing that works :-(
I did discuss with the Eclipse guys that (from my newbie OSGi view), all dependencies should be OSGi bundles, and that the plugins should just pick whatever they like. But it seems that this results in classloader problems.
>
> the problem with this export-all approach is that you basically end up
> with a load of spaghetti that PDE then has to wire up, and
> when it gets
> stuck on one part then it starts reporting lots of errors
> (because they're
> all interconnected)
>
> so it may be it's just one error stopping PDE from resolving
> the bundle
Yes, I'm now down to one (!) dependency (and its transitive dependencies) - still doesn't work (26 errors).
>
> Now, I know that these packages do exist in the dependencies, so it's
> > probably some kind of misconfiguration. One of the RCP
> developers mentioned
> > that the 'uses:=' part might be the troublemaker...?
>
>
> yes, PDE doesn't like excessive "uses" constraint (but there are
> places where you need them to avoid potential loader problems)
>
> it's only when you're exporting lots of inter-related packages that
> the "uses" constraints becomes an issue, I've never had trouble
> using them with plug-ins that export well-defined APIs
>
> to turn it off put <_nouses>true</_nouses> in your Bnd instructions
Thanks, but first I'll try the maven-pax-plugin.
>
> Also, I'm generating an Eclipse PDE project as described on
> the Felix page,
> > but really, it's a total mess.
> > Only about a third of the dependencies are in the visible
> 'Referenced
> > Libraries', about half of them use the M2_REPO environment
> variable, the
> > rest is hard-coded as linked resource in the .project file,
> and of course
> > all of them point to my local Maven repo instead of the project!
>
>
> well that's the Eclipse plug-in for you - which is why I adapted it in
> the maven-pax-plugin to try and improve the project metadata for
> OSGi / plug-in projects
I'll try that next.
>
> Do you have any idea how I could force the Eclipse plugin to
> do the right
> > thing? I see in the example that there seems to be a
> plugin.xml which I
> > don't have, perhaps the path configuration is in there?
> >
>
> plugin.xml is how the plug-in contributes to the Extension registry,
> it doesn't really affect the operation of the maven-eclipse-plugin or
> how the paths get configured
>
> you could create an example POM over at http://www.ops4j.org
> (see http://wiki.ops4j.org/display/ops4j/Committers for access
> - it's as simple as signing up) - or pick another hosting site and
> put the example there (or failing that just email the project zip)
>
> that would make it easier to see what's going on and help out,
> rather than trying to reconstruct it based on email fragments
Would it be ok if I send you a ZIP to your personal email address?
Best regards,
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Create Eclipse plugin from all dependencies - how?
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/7/14 Lewis, Eric <Er...@ipi.ch>
> > > <Export-Package>*</Export-Package>
> >
> >
> > FYI, when embedding dependencies use <_exportcontents> not
> > <Export-Package>
> > as explained here:
> >
> >
> > http://felix.apache.org/site/apache-felix-bundle-plugin-faq.ht
> > ml#ApacheFelixBundlePluginFAQ-WhenIembedadependencywhydoIseedu
> > plicatedcontent%3F
>
> Umm... This actually creates private packages again, which I don't want.
no, if you use the 2.0.0 bundleplugin (which is the latest stable version)
then:
<Export-Package>*</Export-Package>
will pull in all classes from your dependencies (ie. the entire project
classpath)
into the bundle - so if you do a "jar tvf" on the bundle you'll see lots of
classes
inlined into the final jar
now if you also have:
<Embed-Dependency>*</Embed-Dependency>
then you're also telling the Bnd Tool to embed each dependency jar inside
the
final jar - so basically you end up with duplicate content (inlined and
embedded)
Every package should be exported.
right, and using:
<_exportcontents>*</_exportcontents>
<Embed-Dependency>*</Embed-Dependency>
will tell the Bnd Tool to embed all dependencies and make all the packages
contained inside them public - but without then inlining any of their
contents
of course, if you're happy using inlined content then you could just use:
<Export-Package>*</Export-Package>
instead of bothering with any Embed-Dependency instructions
If I understand the feature right, it applies only if I have packages in my
> source code which match packages in my dependencies.
no, <Export-Package> applies to your entire compilation classpath not just
your local sources - however, the default <Export-Package> is calculated to
only export your local packages
> Since I don't have any source code in that project, it shouldn't matter,
> right?
>
if you use <Export-Package>*</Export-Package> with the 2.0.0 bundleplugin
you will end up inlining your entire compilation classpath, which is usually
not
what you want
> > >
> > > Now the Eclipse RCP developer is telling me that Eclipse
> > doesn't like the
> > > MANIFEST format that Felix generates... weird!
> > > Have you ever heard of such problems? (He previously
> > created the MANIFEST
> > > by hand, putting every JAR and every package in its own line)
> > >
> >
> > sometimes a refresh (F5) is needed to get Eclipse in sync with the
> > file-system, if you run the build on the command line
> > otherwise double-click on the manifest then click on the
> > MANIFEST.MF tab and
> > it should show which lines it doesn't like
> > - then post the errors here (or perhaps capture a screenshot?)
> >
> > ( PS. don't use PDE Tools -> Organize Manifests... as that
> > will definitely
> > mess things up! )
> >
>
> Well, there are 535 errors, so it would be a BIG screenshot ;-)
> There are these kinds of errors (one example for each):
>
> - Bundle 'ch.ipi.esv.client.serverlib' exporting package
> 'org.apache.commons.io.comparator' is unresolved
> - No available bundle exports package 'javax.interceptor'
> - Package 'com.google.inject.matcher' does not exist in this plug-in
> - Unsatisfied constraint: 'Import-Package: org.apache.commons.lang.math;
> version="2.4.0"'
>
it sounds like you have a large amount of packages in this one plug-in
and you're attempting to export all of them (which is kind of opposite
to the idea behind OSGi)
the problem with this export-all approach is that you basically end up
with a load of spaghetti that PDE then has to wire up, and when it gets
stuck on one part then it starts reporting lots of errors (because they're
all interconnected)
so it may be it's just one error stopping PDE from resolving the bundle
Now, I know that these packages do exist in the dependencies, so it's
> probably some kind of misconfiguration. One of the RCP developers mentioned
> that the 'uses:=' part might be the troublemaker...?
yes, PDE doesn't like excessive "uses" constraint (but there are
places where you need them to avoid potential loader problems)
it's only when you're exporting lots of inter-related packages that
the "uses" constraints becomes an issue, I've never had trouble
using them with plug-ins that export well-defined APIs
to turn it off put <_nouses>true</_nouses> in your Bnd instructions
Also, I'm generating an Eclipse PDE project as described on the Felix page,
> but really, it's a total mess.
> Only about a third of the dependencies are in the visible 'Referenced
> Libraries', about half of them use the M2_REPO environment variable, the
> rest is hard-coded as linked resource in the .project file, and of course
> all of them point to my local Maven repo instead of the project!
well that's the Eclipse plug-in for you - which is why I adapted it in
the maven-pax-plugin to try and improve the project metadata for
OSGi / plug-in projects
Do you have any idea how I could force the Eclipse plugin to do the right
> thing? I see in the example that there seems to be a plugin.xml which I
> don't have, perhaps the path configuration is in there?
>
plugin.xml is how the plug-in contributes to the Extension registry,
it doesn't really affect the operation of the maven-eclipse-plugin or
how the paths get configured
you could create an example POM over at http://www.ops4j.org
(see http://wiki.ops4j.org/display/ops4j/Committers for access
- it's as simple as signing up) - or pick another hosting site and
put the example there (or failing that just email the project zip)
that would make it easier to see what's going on and help out,
rather than trying to reconstruct it based on email fragments
Best regards,
> Eric
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers, Stuart
AW: Create Eclipse plugin from all dependencies - how?
Posted by "Lewis, Eric" <Er...@ipi.ch>.
> > <Export-Package>*</Export-Package>
>
>
> FYI, when embedding dependencies use <_exportcontents> not
> <Export-Package>
> as explained here:
>
>
> http://felix.apache.org/site/apache-felix-bundle-plugin-faq.ht
> ml#ApacheFelixBundlePluginFAQ-WhenIembedadependencywhydoIseedu
> plicatedcontent%3F
Umm... This actually creates private packages again, which I don't want. Every package should be exported.
If I understand the feature right, it applies only if I have packages in my source code which match packages in my dependencies. Since I don't have any source code in that project, it shouldn't matter, right?
> >
> > Now the Eclipse RCP developer is telling me that Eclipse
> doesn't like the
> > MANIFEST format that Felix generates... weird!
> > Have you ever heard of such problems? (He previously
> created the MANIFEST
> > by hand, putting every JAR and every package in its own line)
> >
>
> sometimes a refresh (F5) is needed to get Eclipse in sync with the
> file-system, if you run the build on the command line
> otherwise double-click on the manifest then click on the
> MANIFEST.MF tab and
> it should show which lines it doesn't like
> - then post the errors here (or perhaps capture a screenshot?)
>
> ( PS. don't use PDE Tools -> Organize Manifests... as that
> will definitely
> mess things up! )
>
Well, there are 535 errors, so it would be a BIG screenshot ;-)
There are these kinds of errors (one example for each):
- Bundle 'ch.ipi.esv.client.serverlib' exporting package 'org.apache.commons.io.comparator' is unresolved
- No available bundle exports package 'javax.interceptor'
- Package 'com.google.inject.matcher' does not exist in this plug-in
- Unsatisfied constraint: 'Import-Package: org.apache.commons.lang.math; version="2.4.0"'
Now, I know that these packages do exist in the dependencies, so it's probably some kind of misconfiguration. One of the RCP developers mentioned that the 'uses:=' part might be the troublemaker...?
Also, I'm generating an Eclipse PDE project as described on the Felix page, but really, it's a total mess.
Only about a third of the dependencies are in the visible 'Referenced Libraries', about half of them use the M2_REPO environment variable, the rest is hard-coded as linked resource in the .project file, and of course all of them point to my local Maven repo instead of the project!
Do you have any idea how I could force the Eclipse plugin to do the right thing? I see in the example that there seems to be a plugin.xml which I don't have, perhaps the path configuration is in there?
Best regards,
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Create Eclipse plugin from all dependencies - how?
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/7/14 Lewis, Eric <Er...@ipi.ch>
> >
> > well it asks the Maven runtime for the list of resolved project
> > dependencies,
> > which could trigger download of missing/updated dependencies
> > to your local
> > Maven repo, but it doesn't copy these dependencies to your
> > project directory
> >
> > if you use Embed-Dependency the plugin will look for matching
> > dependencies
> > and add the appropriate "Include-Resource" instructions to
> > add the jars to
> > the
> > bundle (the Bnd Tool http://aqute.biz/Code/Bnd does the adding)
> >
> > but note that the Bnd Tool won't copy them to the build
> > directory - instead
> > they
> > are added to the jar in memory, and the jar is written out at
> > the end of the
> > build
>
> Ok, everything is totally clear now, thanks!
>
> >
> > also remember that the Bnd Tool only adds whatever
> > packages/resources you
> > instruct it to add (ie. it doesn't simply zip up
> > "target/classes" like the
> > jar plugin)
>
> Actually, I don't have any classes in that project, it's just a bundle
> containing all the dependencies from the app server.
>
> >
> > alternatively you could unpack the bundle after it has been
> > packaged by
> > using
> > the <unpackBundle> setting - however, the problem with this
> > is that you'll
> > want
> > to unpack under "target" (ie. a temporary directory) but PDE
> > expects paths
> > to
> > be relative to the project directory - so the
> > Bundle-ClassPath won't match
> >
> > this is where the "pax:eclipse" goal helps, because it munges
> > the entries in
> > the
> > Bundle-ClassPath in the Eclipse/PDE manifest so dependencies
> > and classes
> > appear to be in the right place for PDE (eg. "." becomes
> > "target/classes",
> > etc.)
>
> Thanks, but I'll definitely stick to the JAR files.
>
> >
> > I'm asking because at the moment, I have 40 JAR files downloaded as
> > > dependencies (by the dependencies plugin), but even though I specify
> > > <Bundle-ClassPath>.,{maven-dependencies}</Bundle-ClassPath>
> > > I only have 37 JARs in there.
> > >
> >
> > hard to say without seeing the dependency graph and your
> > embed instruction,
> > do you happen to notice anything in common wrt. the missing
> > dependencies?
>
>
> Ok, after adding dependency:tree and configuring things a bit better,
> they're now in sync.
>
> I'll add the relevant parts of my POM, just to be sure:
>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-dependency-plugin</artifactId>
> <executions>
> <execution>
> <id>copy-dependencies</id>
> <phase>validate</phase>
> <goals>
> <goal>copy-dependencies</goal>
> </goals>
> <configuration>
> <includeScope>runtime</includeScope>
> <excludeTypes>pom</excludeTypes>
> <outputDirectory>${basedir}</outputDirectory>
> <overWriteReleases>true</overWriteReleases>
> <overWriteSnapshots>true</overWriteSnapshots>
> <overWriteIfNewer>true</overWriteIfNewer>
> </configuration>
> </execution>
> </executions>
> </plugin>
>
> <plugin>
> <groupId>org.apache.felix</groupId>
> <artifactId>maven-bundle-plugin</artifactId>
> <extensions>true</extensions>
> <configuration>
> <manifestLocation>META-INF</manifestLocation>
> <instructions>
>
> <Bundle-SymbolicName>ch.ipi.esv.client.serverlib</Bundle-SymbolicName>
> <Export-Package>*</Export-Package>
FYI, when embedding dependencies use <_exportcontents> not <Export-Package>
as explained here:
http://felix.apache.org/site/apache-felix-bundle-plugin-faq.html#ApacheFelixBundlePluginFAQ-WhenIembedadependencywhydoIseeduplicatedcontent%3F
> <Embed-Dependency>*;scope=compile|runtime;type=!pom</Embed-Dependency>
> <Embed-Transitive>true</Embed-Transitive>
> <Import-Package>org.slf4j,*</Import-Package>
> </instructions>
> </configuration>
> </plugin>
>
> >
> > btw, you don't need to set Bundle-ClassPath when embedding
> > dependencies,
> > unless you want to re-order the entries - the plugin
> > automatically updates
> > the
> > Bundle-ClassPath to include any embedded dependencies
>
> Thanks, deleted.
>
> >
> > if you're using the dependency plugin to put dependent jars
> > at the project
> > root
> > then you don't need to use <Embed-Directory> - you'd only
> > need to use that
> > if you wanted to put the dependent jars in a sub-directory
> > (people sometimes
> > put them under target, so they don't litter the main directory)
>
>
> Since (as you said) I have to have them in the root directory, this part
> deleted as well.
>
>
> Now the Eclipse RCP developer is telling me that Eclipse doesn't like the
> MANIFEST format that Felix generates... weird!
> Have you ever heard of such problems? (He previously created the MANIFEST
> by hand, putting every JAR and every package in its own line)
>
sometimes a refresh (F5) is needed to get Eclipse in sync with the
file-system, if you run the build on the command line
otherwise double-click on the manifest then click on the MANIFEST.MF tab and
it should show which lines it doesn't like
- then post the errors here (or perhaps capture a screenshot?)
( PS. don't use PDE Tools -> Organize Manifests... as that will definitely
mess things up! )
Best regards,
> Eric
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
--
Cheers, Stuart
AW: Create Eclipse plugin from all dependencies - how?
Posted by "Lewis, Eric" <Er...@ipi.ch>.
>
> well it asks the Maven runtime for the list of resolved project
> dependencies,
> which could trigger download of missing/updated dependencies
> to your local
> Maven repo, but it doesn't copy these dependencies to your
> project directory
>
> if you use Embed-Dependency the plugin will look for matching
> dependencies
> and add the appropriate "Include-Resource" instructions to
> add the jars to
> the
> bundle (the Bnd Tool http://aqute.biz/Code/Bnd does the adding)
>
> but note that the Bnd Tool won't copy them to the build
> directory - instead
> they
> are added to the jar in memory, and the jar is written out at
> the end of the
> build
Ok, everything is totally clear now, thanks!
>
> also remember that the Bnd Tool only adds whatever
> packages/resources you
> instruct it to add (ie. it doesn't simply zip up
> "target/classes" like the
> jar plugin)
Actually, I don't have any classes in that project, it's just a bundle containing all the dependencies from the app server.
>
> alternatively you could unpack the bundle after it has been
> packaged by
> using
> the <unpackBundle> setting - however, the problem with this
> is that you'll
> want
> to unpack under "target" (ie. a temporary directory) but PDE
> expects paths
> to
> be relative to the project directory - so the
> Bundle-ClassPath won't match
>
> this is where the "pax:eclipse" goal helps, because it munges
> the entries in
> the
> Bundle-ClassPath in the Eclipse/PDE manifest so dependencies
> and classes
> appear to be in the right place for PDE (eg. "." becomes
> "target/classes",
> etc.)
Thanks, but I'll definitely stick to the JAR files.
>
> I'm asking because at the moment, I have 40 JAR files downloaded as
> > dependencies (by the dependencies plugin), but even though I specify
> > <Bundle-ClassPath>.,{maven-dependencies}</Bundle-ClassPath>
> > I only have 37 JARs in there.
> >
>
> hard to say without seeing the dependency graph and your
> embed instruction,
> do you happen to notice anything in common wrt. the missing
> dependencies?
Ok, after adding dependency:tree and configuring things a bit better, they're now in sync.
I'll add the relevant parts of my POM, just to be sure:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>validate</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<includeScope>runtime</includeScope>
<excludeTypes>pom</excludeTypes>
<outputDirectory>${basedir}</outputDirectory>
<overWriteReleases>true</overWriteReleases>
<overWriteSnapshots>true</overWriteSnapshots>
<overWriteIfNewer>true</overWriteIfNewer>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<manifestLocation>META-INF</manifestLocation>
<instructions>
<Bundle-SymbolicName>ch.ipi.esv.client.serverlib</Bundle-SymbolicName>
<Export-Package>*</Export-Package>
<Embed-Dependency>*;scope=compile|runtime;type=!pom</Embed-Dependency>
<Embed-Transitive>true</Embed-Transitive>
<Import-Package>org.slf4j,*</Import-Package>
</instructions>
</configuration>
</plugin>
>
> btw, you don't need to set Bundle-ClassPath when embedding
> dependencies,
> unless you want to re-order the entries - the plugin
> automatically updates
> the
> Bundle-ClassPath to include any embedded dependencies
Thanks, deleted.
>
> if you're using the dependency plugin to put dependent jars
> at the project
> root
> then you don't need to use <Embed-Directory> - you'd only
> need to use that
> if you wanted to put the dependent jars in a sub-directory
> (people sometimes
> put them under target, so they don't litter the main directory)
Since (as you said) I have to have them in the root directory, this part deleted as well.
Now the Eclipse RCP developer is telling me that Eclipse doesn't like the MANIFEST format that Felix generates... weird!
Have you ever heard of such problems? (He previously created the MANIFEST by hand, putting every JAR and every package in its own line)
Best regards,
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Create Eclipse plugin from all dependencies - how?
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/7/14 Lewis, Eric <Er...@ipi.ch>
> Hi Stuart
> > look at Embed-Dependency in
> > http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html
> > to see how to pull dependencies into your plug-in - this will
> > also let you
> > filter out unwanted jars
>
> Thanks, I know it works because I've done it for individual projects
> already.
> Just to be sure: The Felix plugin doesn't download and copy any
> dependencies, right?
well it asks the Maven runtime for the list of resolved project
dependencies,
which could trigger download of missing/updated dependencies to your local
Maven repo, but it doesn't copy these dependencies to your project directory
if you use Embed-Dependency the plugin will look for matching dependencies
and add the appropriate "Include-Resource" instructions to add the jars to
the
bundle (the Bnd Tool http://aqute.biz/Code/Bnd does the adding)
but note that the Bnd Tool won't copy them to the build directory - instead
they
are added to the jar in memory, and the jar is written out at the end of the
build
also remember that the Bnd Tool only adds whatever packages/resources you
instruct it to add (ie. it doesn't simply zip up "target/classes" like the
jar plugin)
Which means I have to use the dependencies plugin to do that.
>
yes, if you want the dependency jars in the place expected by Eclipse/PDE
then you'll need to use the dependency plugin (as shown in the online docs)
or the "org.ops4j:maven-pax-plugin:eclipse" goal as used in Pax-Construct
alternatively you could unpack the bundle after it has been packaged by
using
the <unpackBundle> setting - however, the problem with this is that you'll
want
to unpack under "target" (ie. a temporary directory) but PDE expects paths
to
be relative to the project directory - so the Bundle-ClassPath won't match
this is where the "pax:eclipse" goal helps, because it munges the entries in
the
Bundle-ClassPath in the Eclipse/PDE manifest so dependencies and classes
appear to be in the right place for PDE (eg. "." becomes "target/classes",
etc.)
I'm asking because at the moment, I have 40 JAR files downloaded as
> dependencies (by the dependencies plugin), but even though I specify
> <Bundle-ClassPath>.,{maven-dependencies}</Bundle-ClassPath>
> I only have 37 JARs in there.
>
hard to say without seeing the dependency graph and your embed instruction,
do you happen to notice anything in common wrt. the missing dependencies?
btw, you don't need to set Bundle-ClassPath when embedding dependencies,
unless you want to re-order the entries - the plugin automatically updates
the
Bundle-ClassPath to include any embedded dependencies
> >
> > you can use the configuration under 'Eclipse/PDE integration'
> > to generate
> > the manifest in the place
> > that PDE expects it and arrange for embedded jars to be where
> > PDE expects
> > them (PDE basically
> > assumes the bundle is unpacked under the project directory,
> > which conflicts
> > with the Maven layout)
>
> I'm a bit confused about <Embed-Directory> - do I have to specify it for
> Felix to work correctly?
> I let the dependencies plugin download all JARs into the project root.
>
if you're using the dependency plugin to put dependent jars at the project
root
then you don't need to use <Embed-Directory> - you'd only need to use that
if you wanted to put the dependent jars in a sub-directory (people sometimes
put them under target, so they don't litter the main directory)
>
> > alternatively look at
> > http://www.ops4j.org/projects/pax/construct - you can
> > use these scripts to create
> > plug-in projects (uses Maven archetypes underneath) and the generated
> > projects have built-in support
> > for Eclipse/PDE - just uncomment the "ide-support" execution in the
> > top-level POM to update the PDE
> > project information automatically on each build, or use "mvn install
> > pax:eclipse" (it's like eclipse:eclipse
> > but has better OSGi support)
> >
> > http://www.jroller.com/habuma/entry/pax_construct_from_zero_to
>
> Thanks, but I'm getting to know Felix better, and I'm already very glad for
> what I'm getting here! :-)
> So, if I can do it with Felix (and Maven's Eclipse plugin), I will.
>
well that project also uses the bundleplugin ;) it basically generates POMs
and sample source code with useful defaults. I originally designed it to
help
save time writing OSGi tutorials, but others now use it to develop plug-ins
>
> > also have a look at the Tycho project, which might be a
> > better fit if you're
> > primarily working in Eclipse:
> >
> >
> > http://www.sonatype.com/people/2008/11/building-eclipse-plugin
> s-with-maven-tycho/<http://www.sonatype.com/people/2008/11/building-eclipse-plugin%0As-with-maven-tycho/>
> > http://docs.codehaus.org/display/M2ECLIPSE/Tycho+user+docs
> >
>
> Thanks, Tycho looks promising for the future, but right now it looks like
> overkill for what I'm trying to do.
>
> Best regards,
> Eric
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
--
Cheers, Stuart
AW: Create Eclipse plugin from all dependencies - how?
Posted by "Lewis, Eric" <Er...@ipi.ch>.
Hi Stuart
>
> the 'bundleall' goal simply takes all your project
> dependencies and turns
> them into separate bundles
> using a very simple "export all" approach - it wasn't
> designed to be used to
> create Eclipse plugins,
> but was more of a 'mass-conversion' tool for simple projects
>
>
> you can configure the maximum dependency depth for
> 'bundleall', but you
> can't exclude specific items
Ok, so I'll skip 'bundleall' totally.
I was trying to avoid having to create a new Maven project, since we're running our Eclipse PDE build as one huge 'blackbox' Maven 'project'.
>
> the simplest way is to ignore the 'bundleall' goal and change
> your POM to
> use the 'bundle' packaging,
> you'd then get automatic manifest generation, fine control over
> embedding/inlining dependencies, and
> generation of OBR metadata (handy for when you're deploying bundles)
>
> look at Embed-Dependency in
> http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html
> to see how to pull dependencies into your plug-in - this will
> also let you
> filter out unwanted jars
Thanks, I know it works because I've done it for individual projects already.
Just to be sure: The Felix plugin doesn't download and copy any dependencies, right?
Which means I have to use the dependencies plugin to do that.
I'm asking because at the moment, I have 40 JAR files downloaded as dependencies (by the dependencies plugin), but even though I specify
<Bundle-ClassPath>.,{maven-dependencies}</Bundle-ClassPath>
I only have 37 JARs in there.
>
> you can use the configuration under 'Eclipse/PDE integration'
> to generate
> the manifest in the place
> that PDE expects it and arrange for embedded jars to be where
> PDE expects
> them (PDE basically
> assumes the bundle is unpacked under the project directory,
> which conflicts
> with the Maven layout)
I'm a bit confused about <Embed-Directory> - do I have to specify it for Felix to work correctly?
I let the dependencies plugin download all JARs into the project root.
>
> alternatively look at
> http://www.ops4j.org/projects/pax/construct - you can
> use these scripts to create
> plug-in projects (uses Maven archetypes underneath) and the generated
> projects have built-in support
> for Eclipse/PDE - just uncomment the "ide-support" execution in the
> top-level POM to update the PDE
> project information automatically on each build, or use "mvn install
> pax:eclipse" (it's like eclipse:eclipse
> but has better OSGi support)
>
> http://www.jroller.com/habuma/entry/pax_construct_from_zero_to
Thanks, but I'm getting to know Felix better, and I'm already very glad for what I'm getting here! :-)
So, if I can do it with Felix (and Maven's Eclipse plugin), I will.
>
> also have a look at the Tycho project, which might be a
> better fit if you're
> primarily working in Eclipse:
>
>
> http://www.sonatype.com/people/2008/11/building-eclipse-plugin
s-with-maven-tycho/
> http://docs.codehaus.org/display/M2ECLIPSE/Tycho+user+docs
>
Thanks, Tycho looks promising for the future, but right now it looks like overkill for what I'm trying to do.
Best regards,
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Create Eclipse plugin from all dependencies - how?
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/7/14 Lewis, Eric <Er...@ipi.ch>
> Hi
>
> I need to gather all dependencies from a Maven POM and copy them to an
> Eclipse plugin directory and then create that plugin from that which covers
> all the JARs and exports all the packages.
>
> The question is: How can I do that?
>
> One of the tools would be the 'bundleall' goal of the Felix Maven plugin,
the 'bundleall' goal simply takes all your project dependencies and turns
them into separate bundles
using a very simple "export all" approach - it wasn't designed to be used to
create Eclipse plugins,
but was more of a 'mass-conversion' tool for simple projects
but somehow it looks for way too many dependencies. When I use the similar
> dependency:copy-depencies, I don't run into the same trouble. Specifically,
> it seems that deep down, somewhere, I have a dependency which can't be
> resolved, because the artefact 'stax:stax-ri:jar:1.0' can't be found.
>
> So the question is: Can I configure the 'bundleall' goal to exclude certain
> dependencies?
you can configure the maximum dependency depth for 'bundleall', but you
can't exclude specific items
> From debugging the Maven output, I don't see any configuration possibility:
> [DEBUG] Configuring mojo
> 'org.apache.felix:maven-bundle-plugin:2.0.0:bundleall' -->
> [DEBUG] (f) baseDir = C:\jp\client
> [DEBUG] (f) buildDirectory = C:\jp\client\target
> [DEBUG] (f) localRepository = [local] -> file://C:\Documents and
> Settings\lewis_lee\.m2\repository
> [DEBUG] (f) manifestLocation = C:\jp\client\target\classes\META-INF
> [DEBUG] (f) outputDirectory = C:\jp\client\target\bundles
> [DEBUG] (f) project = MavenProject: ch.ipi:client:1.0.0-SNAPSHOT @
> C:\jp\client\pom.xml
> [DEBUG] (f) remoteRepositories = [[repository.central] ->
> http://repository/content/groups/public, [central] ->
> http://repo1.maven.org/maven
> 2]
> [DEBUG] (f) supportedProjectTypes = [jar, bundle, ejb]
> [DEBUG] (f) wrapImportPackage = *
>
> Or could I use the dependency plugin, download what I need and trick the
> Felix plugin into believing that the target directory is my repository?
>
> Ok, the other question then is: How do I create an Eclipse plugin from
> this? Would the POM described under 'Eclipse/PDE integration' be sufficient
> to create an Eclipse project?
>
the simplest way is to ignore the 'bundleall' goal and change your POM to
use the 'bundle' packaging,
you'd then get automatic manifest generation, fine control over
embedding/inlining dependencies, and
generation of OBR metadata (handy for when you're deploying bundles)
look at Embed-Dependency in
http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html
to see how to pull dependencies into your plug-in - this will also let you
filter out unwanted jars
you can use the configuration under 'Eclipse/PDE integration' to generate
the manifest in the place
that PDE expects it and arrange for embedded jars to be where PDE expects
them (PDE basically
assumes the bundle is unpacked under the project directory, which conflicts
with the Maven layout)
alternatively look at http://www.ops4j.org/projects/pax/construct - you can
use these scripts to create
plug-in projects (uses Maven archetypes underneath) and the generated
projects have built-in support
for Eclipse/PDE - just uncomment the "ide-support" execution in the
top-level POM to update the PDE
project information automatically on each build, or use "mvn install
pax:eclipse" (it's like eclipse:eclipse
but has better OSGi support)
http://www.jroller.com/habuma/entry/pax_construct_from_zero_to
also have a look at the Tycho project, which might be a better fit if you're
primarily working in Eclipse:
http://www.sonatype.com/people/2008/11/building-eclipse-plugins-with-maven-tycho/
http://docs.codehaus.org/display/M2ECLIPSE/Tycho+user+docs
HTH
Thanks for any help! I don't know a lot about OSGi, I just have to build it
> ;-)
>
> Best regards,
> Eric
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers, Stuart