Carlos Sanchez wrote:
the reason i heard to discourage require-bundle was that only specific
packages of a bundle may be needed. Maven encourages splitting big
projects into reusable components so you usually end with few packages
in each bundle, being pretty close to the import-packages is.
Yes, that is one of the reasons. The spec goes into several more reasons
why require-bundle should be avoided and I think the new R4.1 spec will
include one or two more.
the point is to compliment both by easily generating OSGi bundles from
any Maven project.
Yes, this was the work that Peter Kriens was doing with Jason van Zyl,
to make it so that all Maven JARs were OSGi bundles.
afaik the current status of the bundle plugin doesn't read pom
dependencies to generate the import-packages but the imports in the
classes. The only thing used from the pom if not explicitly configured
is the Maven generated classpath, am I wrong?
The current plugin defaults to (from the doc page):
* <Bundle-SymbolicName> is assumed to be "${groupId}.${artifactId}".
* <Export-Package> is assumed to be "${groupId}.${artifactId}.*",
unless <Private-Package> is specified, then <Export-Package> is
assumed to be empty.
* <Private-Package> is assumed to be empty by default.
* <Import-Package> is assumed to be "*", which imports everything
referred to by the bundle content, but not contained in the bundle.
* <Include-Resource> is assumed to be "src/main/resources/", which
will copy the specified project directory hierarchy into the
resulting bundle JAR file, mirroring standard Maven behavior.
* <Bundle-Version> is assumed to be "${pom.version}" with '-'
character separator of the qualifier replaced with a '.' character.
* <Bundle-Name> is assumed to be "${pom.name}".
* <Bundle-Description> is assumed to be "${pom.description}".
* <Bundle-License> is assumed to be "${pom.licenses}".
* <Bundle-Vendor> is assumed to be "${pom.organization.name}".
* <Bundle-DocURL> is assumed to be "${pom.organization.url}".
This means that is a person did nothing and assuming they followed the
package naming pattern of "${groupId}.${artifactId}", they would get a
bundle that exports all packages contained in the project (just like a
normal JAR file exposes everything) and imports everything external to
the project with the various default manifest header values as specified
above.
-> richard
