Re: Resolution of embedded dependencies during compilation
2009/4/29 David Leangen o...@leangen.net
Hi,
I just updated to maven-bundle-plugin 2.0.0. It appears that there have
been a few changes to the way things compile, and I'm just discovering many
interesting things in my own projects. This is of course a good thing, as
it's bringing out many erroneous interpretations I made earlier.
Anyway, here's my current issue.
In project A, I have an embedded jar that I want to export. POM and bnd
file below.
In project B, I want to use the embedded package, but I only want to depend
on the containing bundle, not the embedded bundle. Since the containing
bundle exports this, my assumption is that this should be possible.
However, the embedded jar in project A is only contained in the final
installed jar, not in the target/classes directory. The problem is that
maven wants to read from the target/classes directory rather than from the
installed jar, so it can't find the embedded packages.
Any ideas?
Here's the essential of project A:
dependencies
dependency
groupIdorg.junit/groupId
artifactIdcom.springsource.org.junit/artifactId
/dependency
dependency
groupIdnet.jcip/groupId
artifactIdcom.springsource.net.jcip.annotations/artifactId
version1.0.0/version
scopecompile/scope
optionaltrue/optional
/dependency
/dependencies
and the bnd file:
Export-Package: ${bundle.namespace}.*;version=${pom.version}
Embed-Dependency:
com.springsource.net.jcip.annotations;groupId=net.jcip;inline=false
Bundle-RequiredExecutionEnvironment: J2SE-1.5
-exportcontents: net.jcip.*;version=1.0
And here's the POM from project B:
dependencies
...
dependency
groupIdnet.leangen.expedition.util/groupId
artifactIdexpedition_object_api/artifactId
scopeprovided/scope
/dependency
...
/dependencies
The output from Maven looks like this:
[DEBUG] Classpath:
[/Users/dleangen/bioscene/dev/trunk/domains/lsd/model/impl/target/classes
/Users/dleangen/.m2/repository/org/osgi/org.osgi.core/4.1.0/org.osgi.core-4.1.0.jar
/Users/dleangen/bioscene/dev/trunk/domains/lsd/model/si/target/classes
/Users/dleangen/bioscene/dev/trunk/platform/util/object/api/target/classes
/Users/dleangen/.m2/repository/org/ops4j/pax/logging/pax-logging-api/1.3.0/pax-logging-api-1.3.0.jar
/Users/dleangen/.m2/repository/org/osgi/org.osgi.compendium/4.1.0/org.osgi.compendium-4.1.0.jar]
[DEBUG] Output directory:
/Users/dleangen/bioscene/dev/trunk/domains/lsd/model/impl/target/classes
So, in some cases it uses the jar file from the local cache, but in others,
the output in the target/classes dir.
this is a core Maven issue, specifically code in MavenProject.java:
http://jira.codehaus.org/browse/MNG-2720
apparently it's fixed in Maven 2.1.0 so you might want to try that
BTW, you might not have noticed this before if you're using Pax-Construct
generated
projects because the maven-pax-plugin does some unpacking to make sure that
the
compilation classpath has the additional classes from the embedded
dependencies
(but this is only if you have extensionstrue/extensions for the paxplugin
and not
set for the bundleplugin, otherwise Maven will use the bundleplugin
lifecycle)
you can get the same effect by unpacking the final bundle into
target/classes after
the packaging step (either by using the maven-ant-plugin or the
maven-exec-plugin)
so I'd give Maven 2.1.0 a whirl and report back if that fixes your problem
Thanks!
=David
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
--
Cheers, Stuart
Re: Resolution of embedded dependencies during compilation
Stuart,
As always, your reply is very quick, timely, and extremely
informative. Thanks!
I updated to maven 2.1.0, and this indeed _appears_ to fix the
classpath problem:
[DEBUG] Classpath: [/Users/dleangen/bioscene/dev/trunk/domains/lsd/
model/impl/target/classes
/Users/dleangen/.m2/repository/net/leangen/expedition/util/
expedition_object_api/0.1.1-SNAPSHOT/expedition_object_api-0.1.1-
SNAPSHOT.jar
/Users/dleangen/.m2/repository/com/bioscene/lsd/lsd-model-si/0.1.1-
SNAPSHOT/lsd-model-si-0.1.1-SNAPSHOT.jar
/Users/dleangen/.m2/repository/org/osgi/org.osgi.core/4.1.0/
org.osgi.core-4.1.0.jar
/Users/dleangen/.m2/repository/org/osgi/org.osgi.compendium/4.1.0/
org.osgi.compendium-4.1.0.jar
/Users/dleangen/.m2/repository/org/ops4j/pax/logging/pax-logging-api/
1.3.0/pax-logging-api-1.3.0.jar]
So, now rather than using the output from target/classes, it is using
the installed jar file. Great!
However, I'm still getting this:
/Users/dleangen/bioscene/dev/trunk/domains/lsd/model/impl/src/main/
java/com/bioscene/lsd/model/impl/TranslationImpl.java:[3,28] package
net.jcip.annotations does not exist
/Users/dleangen/bioscene/dev/trunk/domains/lsd/model/impl/src/main/
java/com/bioscene/lsd/model/impl/TranslationImpl.java:[7,1] cannot
find symbol
symbol: class Immutable
@Immutable
I'll try inlining to see what happens...
=David
On Apr 29, 2009, at 3:11 PM, Stuart McCulloch wrote:
2009/4/29 David Leangen o...@leangen.net
Hi,
I just updated to maven-bundle-plugin 2.0.0. It appears that there
have
been a few changes to the way things compile, and I'm just
discovering many
interesting things in my own projects. This is of course a good
thing, as
it's bringing out many erroneous interpretations I made earlier.
Anyway, here's my current issue.
In project A, I have an embedded jar that I want to export. POM and
bnd
file below.
In project B, I want to use the embedded package, but I only want
to depend
on the containing bundle, not the embedded bundle. Since the
containing
bundle exports this, my assumption is that this should be possible.
However, the embedded jar in project A is only contained in the final
installed jar, not in the target/classes directory. The problem is
that
maven wants to read from the target/classes directory rather than
from the
installed jar, so it can't find the embedded packages.
Any ideas?
Here's the essential of project A:
dependencies
dependency
groupIdorg.junit/groupId
artifactIdcom.springsource.org.junit/artifactId
/dependency
dependency
groupIdnet.jcip/groupId
artifactIdcom.springsource.net.jcip.annotations/artifactId
version1.0.0/version
scopecompile/scope
optionaltrue/optional
/dependency
/dependencies
and the bnd file:
Export-Package: ${bundle.namespace}.*;version=${pom.version}
Embed-Dependency:
com.springsource.net.jcip.annotations;groupId=net.jcip;inline=false
Bundle-RequiredExecutionEnvironment: J2SE-1.5
-exportcontents: net.jcip.*;version=1.0
And here's the POM from project B:
dependencies
...
dependency
groupIdnet.leangen.expedition.util/groupId
artifactIdexpedition_object_api/artifactId
scopeprovided/scope
/dependency
...
/dependencies
The output from Maven looks like this:
[DEBUG] Classpath:
[/Users/dleangen/bioscene/dev/trunk/domains/lsd/model/impl/target/
classes
/Users/dleangen/.m2/repository/org/osgi/org.osgi.core/4.1.0/
org.osgi.core-4.1.0.jar
/Users/dleangen/bioscene/dev/trunk/domains/lsd/model/si/target/
classes
/Users/dleangen/bioscene/dev/trunk/platform/util/object/api/target/
classes
/Users/dleangen/.m2/repository/org/ops4j/pax/logging/pax-logging-
api/1.3.0/pax-logging-api-1.3.0.jar
/Users/dleangen/.m2/repository/org/osgi/org.osgi.compendium/4.1.0/
org.osgi.compendium-4.1.0.jar]
[DEBUG] Output directory:
/Users/dleangen/bioscene/dev/trunk/domains/lsd/model/impl/target/
classes
So, in some cases it uses the jar file from the local cache, but in
others,
the output in the target/classes dir.
this is a core Maven issue, specifically code in MavenProject.java:
http://jira.codehaus.org/browse/MNG-2720
apparently it's fixed in Maven 2.1.0 so you might want to try that
BTW, you might not have noticed this before if you're using Pax-
Construct
generated
projects because the maven-pax-plugin does some unpacking to make
sure that
the
compilation classpath has the additional classes from the embedded
dependencies
(but this is only if you have extensionstrue/extensions for the
paxplugin
and not
set for the bundleplugin, otherwise Maven will use the bundleplugin
lifecycle)
you can get the same effect by unpacking the final bundle into
target/classes after
the packaging step (either by using the maven-ant-plugin or the
maven-exec-plugin)
so I'd give Maven 2.1.0 a whirl and report back if that fixes your
problem
Thanks!
=David
-
To
Re: Resolution of embedded dependencies during compilation
2009/4/29 David Leangen o...@leangen.net
Stuart,
As always, your reply is very quick, timely, and extremely informative.
Thanks!
I updated to maven 2.1.0, and this indeed _appears_ to fix the classpath
problem:
[DEBUG] Classpath:
[/Users/dleangen/bioscene/dev/trunk/domains/lsd/model/impl/target/classes
/Users/dleangen/.m2/repository/net/leangen/expedition/util/expedition_object_api/0.1.1-SNAPSHOT/expedition_object_api-0.1.1-SNAPSHOT.jar
/Users/dleangen/.m2/repository/com/bioscene/lsd/lsd-model-si/0.1.1-SNAPSHOT/lsd-model-si-0.1.1-SNAPSHOT.jar
/Users/dleangen/.m2/repository/org/osgi/org.osgi.core/4.1.0/org.osgi.core-4.1.0.jar
/Users/dleangen/.m2/repository/org/osgi/org.osgi.compendium/4.1.0/org.osgi.compendium-4.1.0.jar
/Users/dleangen/.m2/repository/org/ops4j/pax/logging/pax-logging-api/1.3.0/pax-logging-api-1.3.0.jar]
So, now rather than using the output from target/classes, it is using the
installed jar file. Great!
However, I'm still getting this:
/Users/dleangen/bioscene/dev/trunk/domains/lsd/model/impl/src/main/java/com/bioscene/lsd/model/impl/TranslationImpl.java:[3,28]
package net.jcip.annotations does not exist
/Users/dleangen/bioscene/dev/trunk/domains/lsd/model/impl/src/main/java/com/bioscene/lsd/model/impl/TranslationImpl.java:[7,1]
cannot find symbol
symbol: class Immutable
@Immutable
I'll try inlining to see what happens...
Remember that javac can't handle embedded jars, so you will need to inline
dependencies
if you want to be able to compile against the bundle. The alternative is of
course to compile
against the original (non-OSGi) dependencies, as the bundle is more of a
runtime artifact...
( FYI, this is also another thing the maven-pax-plugin lifecycle helps out
with, as it modifies
the compilation phase to support compilation against embedded jars -
however, this does
sometimes make bundle compilation slower )
=David
On Apr 29, 2009, at 3:11 PM, Stuart McCulloch wrote:
2009/4/29 David Leangen o...@leangen.net
Hi,
I just updated to maven-bundle-plugin 2.0.0. It appears that there have
been a few changes to the way things compile, and I'm just discovering
many
interesting things in my own projects. This is of course a good thing, as
it's bringing out many erroneous interpretations I made earlier.
Anyway, here's my current issue.
In project A, I have an embedded jar that I want to export. POM and bnd
file below.
In project B, I want to use the embedded package, but I only want to
depend
on the containing bundle, not the embedded bundle. Since the containing
bundle exports this, my assumption is that this should be possible.
However, the embedded jar in project A is only contained in the final
installed jar, not in the target/classes directory. The problem is that
maven wants to read from the target/classes directory rather than from
the
installed jar, so it can't find the embedded packages.
Any ideas?
Here's the essential of project A:
dependencies
dependency
groupIdorg.junit/groupId
artifactIdcom.springsource.org.junit/artifactId
/dependency
dependency
groupIdnet.jcip/groupId
artifactIdcom.springsource.net.jcip.annotations/artifactId
version1.0.0/version
scopecompile/scope
optionaltrue/optional
/dependency
/dependencies
and the bnd file:
Export-Package: ${bundle.namespace}.*;version=${pom.version}
Embed-Dependency:
com.springsource.net.jcip.annotations;groupId=net.jcip;inline=false
Bundle-RequiredExecutionEnvironment: J2SE-1.5
-exportcontents: net.jcip.*;version=1.0
And here's the POM from project B:
dependencies
...
dependency
groupIdnet.leangen.expedition.util/groupId
artifactIdexpedition_object_api/artifactId
scopeprovided/scope
/dependency
...
/dependencies
The output from Maven looks like this:
[DEBUG] Classpath:
[/Users/dleangen/bioscene/dev/trunk/domains/lsd/model/impl/target/classes
/Users/dleangen/.m2/repository/org/osgi/org.osgi.core/4.1.0/org.osgi.core-4.1.0.jar
/Users/dleangen/bioscene/dev/trunk/domains/lsd/model/si/target/classes
/Users/dleangen/bioscene/dev/trunk/platform/util/object/api/target/classes
/Users/dleangen/.m2/repository/org/ops4j/pax/logging/pax-logging-api/1.3.0/pax-logging-api-1.3.0.jar
/Users/dleangen/.m2/repository/org/osgi/org.osgi.compendium/4.1.0/org.osgi.compendium-4.1.0.jar]
[DEBUG] Output directory:
/Users/dleangen/bioscene/dev/trunk/domains/lsd/model/impl/target/classes
So, in some cases it uses the jar file from the local cache, but in
others,
the output in the target/classes dir.
this is a core Maven issue, specifically code in MavenProject.java:
http://jira.codehaus.org/browse/MNG-2720
apparently it's fixed in Maven 2.1.0 so you might want to try that
BTW, you might not have noticed this before if you're using Pax-Construct
generated
projects because the maven-pax-plugin does some unpacking to make sure
that
the
compilation classpath has
Re: Resolution of embedded dependencies during compilation
Once again, many thanks! I'll try inlining to see what happens... That worked, and is sufficient for now. ( FYI, this is also another thing the maven-pax-plugin lifecycle helps out with, as it modifies the compilation phase to support compilation against embedded jars - however, this does sometimes make bundle compilation slower ) Ahhh, that's what you were getting at in your last message. Guess that went over my head, but now I think I get it. I'll keep this in mind if there comes a time I don't want to inline embedded packages. Thanks again! =David - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
