Aaron Siri wrote:
Only dependencies that are of type bundle. Plain old jars would be added to
the classpath. I guess it doesn't have to be the default behavior - just
possible.
As a side note. You create bundles that are dependent on other bundles (to
compile, I assume) but then you don't want them to be required during
runtime?
The issue is Import-Package vs. Require-Bundle. I prefer Import-Package
over Require-Bundle for my dependencies.
-> richard
-Aaron
-----Original Message-----
From: Richard S. Hall [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 05, 2006 1:56 PM
To: felix-dev@incubator.apache.org
Subject: Re: Bundle plugin: Importing packages from non-bundles
Aaron Siri wrote:
I guess I'm expecting it to behave a little more like the war-plugin
with respect to dependency jars. Any dependency that is of type jar
and has a scope of something like compile will be included in the
bundle jar (and on the manifest classpath). For that matter, any
dependency that is of type bundle I'd expect to be included in the manifest
Required-Bundles property.
Well, I definitely would not want the default handling of dependencies to be
converted to require-bundle...
-> richard
-Aaron
-----Original Message-----
From: Peter Kriens [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 05, 2006 12:46 PM
To: Aaron Siri
Cc: felix-dev@incubator.apache.org
Subject: Re[6]: Bundle plugin: Importing packages from non-bundles
Sorry for the previous mail, was not finished yet.
I think it is :
<configuration>
<instructions>
<Include-Resource>plugin.xml</Include-Resource>
</instructions>
</configuration>
And not
<configuration>
<Include-Resource>plugin.xml</Include-Resource>
</configuration>
You can always package the bundles as jars, you just have to Include
them as resources. However, this implies you know where to find them.
Please realize that the plugin was build for the OSGi model where you
have many small bundles. This implies that not all scenarios are
targeted with this plugin.
Kind regards,
Peter Kriens
AS> I was going to start asking similar questions. I'm wondering how
AS> I get my dependencies packaged in the bundle (I prefer them as
AS> jars and not inlined.) Does this thread imply that there is no way
AS> for library jars to be packaged in the bundle using
maven-bundle-plugin?
AS> I'm also trying to get the plugin.xml file included into the bundle
via:
AS> <configuration>
AS> <Include-Resource>plugin.xml</Include-Resource>
AS> </configuration>
AS> Which doesn't seem to be working. Is this the right way to get it
included?
AS> -Aaron
AS> -----Original Message-----
AS> From: Emil Eifrém [mailto:[EMAIL PROTECTED]
AS> Sent: Tuesday, December 05, 2006 10:10 AM
AS> To: Peter Kriens
AS> Cc: felix-dev@incubator.apache.org
AS> Subject: Re: Re[4]: Bundle plugin: Importing packages from
AS> non-bundles
AS> On 12/5/06, Peter Kriens <[EMAIL PROTECTED]> wrote:
I am not a maven expert so maybe there are better ways to do it.
I never understood "provided" to mean include? If that is the
definition I can automatically include them. Can someone point me to
the relevant literature?
AS> Neither am I, but it actually means exclude. From
AS> http://maven.apache.org/pom.html:
--- >>8 ---
AS> * scope: This element refers to the classpath of the task at hand
AS> (compiling and runtime, testing, etc.) as well as how to limit the
AS> transitivity of a depedency. There are five scopes available:
AS> * compile - this is the default scope, used if none is specified.
AS> Compile dependencies are available in all classpaths.
AS> * provided - this is much like compile, but indicates you
AS> expect the JDK or a container to provide it. It is only available
AS> on the compilation classpath, and is not transitive.
AS> * runtime - this scope indicates that the dependency is not
AS> required for compilation, but is for execution. It is in the
AS> runtime and test classpaths, but not the compile classpath.
AS> * test - this scope indicates that the dependency is not
AS> required for normal use of the application, and is only available
AS> for the test compilation and execution phases.
AS> * system - this scope is similar to provided except that you
AS> have to provide the JAR which contains it explicitly. The artifact
AS> is always available and is not looked up in a repository.
--- >>8 ---
The <type>bundle</type> is required by maven as far as I know, as is
the messy plugin setup. If you know a better way let me know.
AS> Unfortunately, I'm even less of an expert on Maven than I am on OSGi.
AS> I just want stuff to work so I can build apps. :) But this is an
AS> Apache list, I'm sure others can chime in!
AS> What I meant in my previous mail was that I don't understand why
AS> the plugin needs to know the <type> of the dependencies. It's an
AS> OSGi-aware
plugin...
AS> just have a peek in the jar file and figure it out? If it is, then
AS> generate Import-Package, if not then embed or inline it. Would
AS> work nicely. But maybe there's some Maven core <-> Maven plugin
AS> interaction going on there that I'm missing. In either case, this
AS> would be nice-to-have functionality but it's not a showstopper for us.
AS> [snip]
Inlining or Bundle-Classpath both make no difference for the
Import-Package. The import header is calculated from the references
from all the classes on the Bundle-Classpath.
AS> Here's where I don't get it. Let's go back to the simple original
AS> example with my one-class bundle which depended on commons-logging.
AS> If the plugin would embed or inline the commons-logging jar AND
AS> generate Import-Package statements... that would break when we
AS> load it into the OSGi framework, right? No other bundle will
AS> export commons-logging stuff and, moreover, even if there is I
AS> want my bundle to
use the embedded stuff like I said in my POM.
AS> This is the core of the issue, as I see it.
AS> Cheers,
AS> -EE
