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>
>>> <groupId>org.junit</groupId>
>>> <artifactId>com.springsource.org.junit</artifactId>
>>> </dependency>
>>> <dependency>
>>> <groupId>net.jcip</groupId>
>>> <artifactId>com.springsource.net.jcip.annotations</artifactId>
>>> <version>1.0.0</version>
>>> <scope>compile</scope>
>>> <optional>true</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>
>>> <groupId>net.leangen.expedition.util</groupId>
>>> <artifactId>expedition_object_api</artifactId>
>>> <scope>provided</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 <extensions>true</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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>
--
Cheers, Stuart
