On Saturday, 25 October 2014 at 00:31, Neil Bartlett wrote:
> Thanks Stuart. He also had scope=compile|runtime and Embed-Transitive true.
> Does that change things?
>
>
No, I used exactly the same instructions (except the ones relating to his own
packages) and the JScience dependency as shown below:
<dependencies>
<dependency>
<groupId>org.jscience</groupId>
<artifactId>jscience</artifactId>
<version>4.3.1</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>2.3.7</version>
<extensions>true</extensions>
<configuration>
<instructions>
<Bundle-SymbolicName>${project.artifactId};singleton:=true</Bundle-SymbolicName>
<Bundle-Version>${project.version}</Bundle-Version>
<Embed-Dependency>!org.osgi.*;scope=compile|runtime;inline=true</Embed-Dependency>
<Embed-Transitive>true</Embed-Transitive>
</instructions>
</configuration>
</plugin>
</plugins>
</build>
the generated manifest was:
Manifest-Version: 1.0
Bnd-LastModified: 1414193667143
Build-Jdk: 1.7.0_72
Built-By: mcculls
Bundle-ManifestVersion: 2
Bundle-Name: JScience OSGi Example
Bundle-SymbolicName: jscience-osgi-example;singleton:=true
Bundle-Version: 0.1.0.SNAPSHOT
Created-By: Apache Maven Bundle Plugin
Embed-Dependency: !org.osgi.*;scope=compile|runtime;inline=true
Embed-Transitive: true
Import-Package: org.xml.sax
Tool: Bnd-1.50.0
But I do agree that there are a lot of projects out there with a lot of
unnecessary fan-out. So while embedding (especially with transitive turned on)
can help when it comes to creating uber-bundles, I’d always suggest people take
a look and see what exactly is getting bundled into the final jar. It’s also
worth checking the project documentation to see what minimal dependencies are
needed at runtime. For example, some projects declare optional dependencies to
various logging APIs/backends because they build against them, but don’t
actually need them at runtime.
PS. there is an ongoing discussion in maven-dev about improving the dependency
model to capture provides vs. consumes which may help in the future
>
> Neil
>
> From: Stuart McCulloch <[email protected]> (mailto:[email protected])
> Reply: OSGi Developer Mail List <[email protected]>>
> (mailto:[email protected])
> Date: 25 October 2014 at 00:23:02
> To: OSGi Developer Mail List <[email protected]>>
> (mailto:[email protected])
> Subject: Re: [osgi-dev] Solving OSGi Transitive Dependencies
>
> > On Saturday, 25 October 2014 at 00:10, Neil Bartlett wrote:
> > > We appear to be having the same discussion on both this list and the
> > > Felix list. To summarise what I posted there, I did a test with JScience
> > > (the library Pedro is trying to use) and found that it had ZERO
> > > dependencies other than Java SE packages!
> > >
> > > The transitive dependency fan-out problem does exist when you use
> > > libraries that have poor internal coherency, but this is not one of those
> > > libraries. It appears that in this case the problem was caused by Maven
> > > and the Embed-Dependency instruction.
> > FWIW, I just tried a simple pom.xml with the JScience dependency and
> > maven-bundle-plugin + Embed-Dependency and the manifest also had only one
> > import for org.xml.sax, so the extra imports must be from somewhere else.
> > >
> > > Neil
> > >
> > > From: Cristiano Gavião <[email protected]> (mailto:[email protected])
> > > Reply: OSGi Developer Mail List <[email protected]>>
> > > (mailto:[email protected])
> > > Date: 24 October 2014 at 23:53:18
> > > To: OSGi Developer Mail List <[email protected]>>
> > > (mailto:[email protected])
> > > Subject: Re: [osgi-dev] Solving OSGi Transitive Dependencies
> > >
> > > > Pedro, I'm using maven-bundle-plugin too.
> > > >
> > > > At the beginning I had the same kind of problems you are facing because
> > > > Bnd (the library behind MBP) automatically includes every import that
> > > > it finds searching the dependency chain. Sometimes it is necessary and
> > > > you just can't run away from this. but sometimes it is not.
> > > >
> > > > Part one of the solution that I'm using was to narrow the imports that
> > > > bnd calculates. I just run MBP one time to be able to extract from the
> > > > generated manifest what I really need and then set the <Import-Package>
> > > > tag manually.
> > > > see an example here:
> > > > https://github.com/jbehave/jbehave-osgi/blob/master/jbehave-osgi-bundles/org.jbehave.osgi.core/pom.xml#L188
> > > >
> > > > Part two was to create an R5 OSGi Repository containing all those
> > > > dependencies and install Felix BundleRepository in the container
> > > > instance that will handle the install of those dependencies.
> > > >
> > > > regards,
> > > >
> > > > Cristiano
> > > >
> > > > 2014-10-24 12:43 GMT-02:00 PedroD <[email protected]
> > > > (mailto:[email protected])>:
> > > > >
> > > > > Greetings,
> > > > >
> > > > > I’m using Felix Framework for my OSGi project, but I’ve came across a
> > > > > severe problem concerning third party dependencies.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > I’m using eclipse and maven-bundle-plugin to generate my bundles from
> > > > > the sources and the MANIFEST.MF from the POM.XML file. So far so
> > > > > good. however when I have some third party dependency in my bundle, I
> > > > > find myself looking for an infinite list of JARs, which usually are
> > > > > not bundles, and putting them in my /bundle Felix directory until no
> > > > > more dependencies are missing.
> > > > >
> > > > >
> > > > > I call this process “Downloading the Internet for my OSGi application
> > > > > to work”.
> > > > >
> > > > >
> > > > > What am I doing wrong? Sure I must be doing something very wrong,
> > > > > because I can’t imagine anyone having a bundle A that depends on B,
> > > > > which then depends on C and D, and then those two will depend on
> > > > > several others and so on… to go look for ALL those dependencies
> > > > > manually using google or maven central! That's insane!
> > > > >
> > > > >
> > > > > What is the correct way to automate this? I would love to have one of
> > > > > the two solutions:
> > > > >
> > > > >
> > > > > 1) Be able to create a massive JAR file with all of its dependencies
> > > > > embedded, but exporting only the packages I want, and, of corse, not
> > > > > importing any package.
> > > > >
> > > > >
> > > > > 2) (My preferred solution) Having a way to get all my dependencies
> > > > > into individual JAR files that I can simply paste into the /bundle
> > > > > directory.
> > > > >
> > > > >
> > > > > 3) (Even more preferred) Having a way to use third party JARs without
> > > > > downloading 8GB of dependencies to my project.
> > > > >
> > > > >
> > > > > I have found tools that do me this, but just for direct (1st degree)
> > > > > dependencies, leaving transitive dependencies for me to solve
> > > > > manually.
> > > > >
> > > > >
> > > > > This problem is critical. The lack of such a tool hampers the usage
> > > > > of OSGi. I’ve searched and searched and searched, I’ve came across
> > > > > all the 101 solutions such as PAX, bndtools, and friends, but it
> > > > > seems that they do not solve this issue…
> > > > >
> > > > >
> > > > > Please help me. Please provide a living example if you can, people
> > > > > like me around the world will benefit from the solution to this
> > > > > problem.
> > > > >
> > > > >
> > > > > Thanks!
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > OSGi Developer Mail List
> > > > > [email protected] (mailto:[email protected])
> > > > > https://mail.osgi.org/mailman/listinfo/osgi-dev
> > > >
> > > >
> > > >
> > > > --
> > > > "Tudo vale a pena se a alma não é pequena..."
> > > > _______________________________________________
> > > > OSGi Developer Mail List
> > > > [email protected] (mailto:[email protected])
> > > > https://mail.osgi.org/mailman/listinfo/osgi-dev
> > > _______________________________________________
> > > OSGi Developer Mail List
> > > [email protected] (mailto:[email protected])
> > > https://mail.osgi.org/mailman/listinfo/osgi-dev
> > >
> > >
> >
> >
> > _______________________________________________
> > OSGi Developer Mail List
> > [email protected] (mailto:[email protected])
> > https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
