You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Costin Leau <co...@gmail.com> on 2007/05/07 22:09:34 UTC
classpath issues with felix-maven-bundle
Hello,
I've upgraded today from the 'old' plugin to the new one and I got
blocked by a classpath problem.
Basically I have two modules which both use the 'bundle' package:
spring-core (which osgifies the original spring-core maven jar).
and
spring-osgi-io which depends on the osgi bundle of the bundle above.
(see the attached poms)
If ran individually, each module works fine. If I ran them together (as
part of a bigger project), the second doesn't compile and throws weird
errors.
I've ran maven -X and it seems that the problem is caused by the
classpath which doesn't get updated:
[DEBUG] Source directories: [D:\work\i21\spring-osgi-sf\io\src\main\java]
[DEBUG] Classpath: [D:\work\i21\spring-osgi-sf\io\target\classes
C:\Documents and
Settings\User\.m2\repository\org\slf4j\slf4j-api\1.3.1\slf4j-api-1.3.1.jar
C:\Documents and
Settings\User\.m2\repository\org\slf4j\jcl104-over-slf4j\1.3.1\jcl104-over-slf4j-1.3.1.jar
C:\Documents and
Settings\User\.m2\repository\org\osgi\org.osgi.core\4.0\org.osgi.core-4.0.jar
**********
D:\work\i21\spring-osgi-sf\spring-modules\spring-core\target\classes
**********
C:\Documents and
Settings\User\.m2\repository\org\slf4j\slf4j-log4j12\1.3.1\slf4j-log4j12-1.3.1.jar
C:\Documents and
Settings\User\.m2\repository\org\eclipse\osgi\org.eclipse.osgi\3.2.2\org.eclipse.osgi-3.2.2.jar
C:\Documents and
Settings\User\.m2\repository\log4j\log4j\1.2.13\log4j-1.2.13.jar]
[DEBUG] Output directory: D:\work\i21\spring-osgi-sf\io\target\classes
Basically, it seems that the spring-core dependency is replaced with a
target/classes folder which is empty.
When ran by itself, the classpath is the one expected:
C:\Documents and
Settings\User\.m2\repository\org\springframework\osgi\spring-core\2.1-m2-SNAPSHOT\spring-core-2.1-m2-SNAPSHOT.jar
>From what I can see, it seems that the bundle plugin keeps the old
classpath between runs.
Any ideas or workarounds are welcomed. This is a blocking issue before a
release ...
P.S. I'm using the latest 0.9.0 SNAPSHOT.
Thanks,
--
Costin
Re: classpath issues with felix-maven-bundle
Posted by Costin Leau <co...@gmail.com>.
Stuart McCulloch wrote:
> Hi Costin,
>
> Is it possible to get access to your modified branch of the build?
> would make it easier to find and test possible solutions, instead
> of trying to suggest things based on a couple of poms.
I hope to commit today my changes to Spring/OSGi trunk. I'll let you
know once its up.
>
> I usually end up exploding wrapped libraries under target/classes
> as it makes Eclipse happy - that's why I don't see this problem.
>
We used to do this before by unpacking the jar but that's redundant and
useless now.
--
Costin
Re: classpath issues with felix-maven-bundle
Posted by Costin Leau <co...@gmail.com>.
Stuart McCulloch wrote:
> Tracked the issue to the org.apache.maven.project.MavenProject class.
>
Thanks for looking into this Stuart, I really appreciate it.
> When it adds an artifact to the compilation classpath it has an explicit
> check to see if the artifact's project is in the project references (ie.
> is it
> part of the current build cycle?)
>
> If so then it just adds the project's build output directory to the
> classpath,
> instead of the file in the local repo. Perhaps it should add both, or check
> to see if the output directory exists?
>
> I found a bug (http://jira.codehaus.org/browse/MNG-2720) from Dec '06
> which describes the same problem - but it's not been assigned/updated
>
> Until this is fixed inside Maven the only workarounds are:
>
> 1) unpack the jar during wrapping process so target/classes exists
We used to do that before. It's a bit annoying since it takes more time
and duplicates the functionality already available in the plugin. Not to
mention about the size of your pom.
>
> 2) build the spring-modules in a separate cycle (as you're doing now)
Right - works wonders. Though you have to get used to it.
>
> 3) change (or add) the dependency to non-osgi artifact, for example:
>
> <dependency>
> <groupId>org.springframework</groupId>
> <artifactId>spring-core</artifactId>
> <version>${spring.version}</version>
> <scope>compile</scope>
> </dependency>
>
> which works as we don't build this locally - but is a messy solution
Right, I figured this one out by accident but it just ruins the
transitive dependency since for an osgi bundle you need the non-osgi bundle.
It's better to go for 1) then this one :).
>
> all in all, not a good situation, but I hope this sheds some light...
Still, it's good to know that it's not me and Maven.
Thanks again.
>
> On 09/05/07, Costin Leau <co...@gmail.com> wrote:
>> Stuart McCulloch wrote:
>> > Hi Costin,
>> >
>> > Is it possible to get access to your modified branch of the build?
>> > would make it easier to find and test possible solutions, instead
>> > of trying to suggest things based on a couple of poms.
>> >
>> Hi Stuart,
>>
>> you can find the repo at
>> http://springframework.svn.sourceforge.net/viewvc/springframework/spring-osgi/trunk/
>>
>>
>> The root pom has spring-modules commented out - I've managed after hours
>> of trial and error, to bootstrap them through the maven invoker plugin.
>> If you uncomment the module, make sure you comment the invoker so it
>> doesn't run the modules twice.
>>
>>
>> > I usually end up exploding wrapped libraries under target/classes
>> > as it makes Eclipse happy - that's why I don't see this problem.
>> >
>>
>> Thanks in advance,
>> --
>> Costin
>>
>
>
Cheers,
--
Costin
Re: classpath issues with felix-maven-bundle
Posted by Stuart McCulloch <st...@jayway.net>.
Tracked the issue to the org.apache.maven.project.MavenProject class.
When it adds an artifact to the compilation classpath it has an explicit
check to see if the artifact's project is in the project references (ie. is it
part of the current build cycle?)
If so then it just adds the project's build output directory to the classpath,
instead of the file in the local repo. Perhaps it should add both, or check
to see if the output directory exists?
I found a bug (http://jira.codehaus.org/browse/MNG-2720) from Dec '06
which describes the same problem - but it's not been assigned/updated
Until this is fixed inside Maven the only workarounds are:
1) unpack the jar during wrapping process so target/classes exists
2) build the spring-modules in a separate cycle (as you're doing now)
3) change (or add) the dependency to non-osgi artifact, for example:
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>${spring.version}</version>
<scope>compile</scope>
</dependency>
which works as we don't build this locally - but is a messy solution
all in all, not a good situation, but I hope this sheds some light...
On 09/05/07, Costin Leau <co...@gmail.com> wrote:
> Stuart McCulloch wrote:
> > Hi Costin,
> >
> > Is it possible to get access to your modified branch of the build?
> > would make it easier to find and test possible solutions, instead
> > of trying to suggest things based on a couple of poms.
> >
> Hi Stuart,
>
> you can find the repo at
> http://springframework.svn.sourceforge.net/viewvc/springframework/spring-osgi/trunk/
>
> The root pom has spring-modules commented out - I've managed after hours
> of trial and error, to bootstrap them through the maven invoker plugin.
> If you uncomment the module, make sure you comment the invoker so it
> doesn't run the modules twice.
>
>
> > I usually end up exploding wrapped libraries under target/classes
> > as it makes Eclipse happy - that's why I don't see this problem.
> >
>
> Thanks in advance,
> --
> Costin
>
--
Cheers, Stuart
Re: classpath issues with felix-maven-bundle
Posted by Costin Leau <co...@gmail.com>.
Stuart McCulloch wrote:
> Hi Costin,
>
> Is it possible to get access to your modified branch of the build?
> would make it easier to find and test possible solutions, instead
> of trying to suggest things based on a couple of poms.
>
Hi Stuart,
you can find the repo at
http://springframework.svn.sourceforge.net/viewvc/springframework/spring-osgi/trunk/
The root pom has spring-modules commented out - I've managed after hours
of trial and error, to bootstrap them through the maven invoker plugin.
If you uncomment the module, make sure you comment the invoker so it
doesn't run the modules twice.
> I usually end up exploding wrapped libraries under target/classes
> as it makes Eclipse happy - that's why I don't see this problem.
>
Thanks in advance,
--
Costin
Re: classpath issues with felix-maven-bundle
Posted by Stuart McCulloch <st...@jayway.net>.
Hi Costin,
Is it possible to get access to your modified branch of the build?
would make it easier to find and test possible solutions, instead
of trying to suggest things based on a couple of poms.
I usually end up exploding wrapped libraries under target/classes
as it makes Eclipse happy - that's why I don't see this problem.
--
Cheers, Stuart
On 08/05/07, Costin Leau <co...@gmail.com> wrote:
> Alin Dreghiciu wrote:
> > A solution will be indeed to separate the build of spring-modules,
> > including
> > required libraries from building of the rest. As with spring 2.1 anyway the
> > artifacts will be osgi bundles anyway.
>
> Until they will, we have to deal with this.
>
> >
> > P.S. if you are doing this refactoring isn't now also the moment to get rid
> > of some of the required libraries build and use those from felix commons?
>
> If I find time, I'll see if I can remove some of the libraries.
> >
> > Alin
> >
> > On 5/8/07, Costin Leau <co...@gmail.com> wrote:
> >>
> >> ...
> >> Since maven for some reason, uses <module>/target/classes instead of the
> >> published jar and target/classes is empty, I really can't see any nice
> >> alternative here.
> >
> >
> > I caould not find a clear reference about but I'm suspecting that this is
> > done as you are not always installing the builded artifacts into the
> > repository hence if the resolution would be based on the repository
> > artifacts you would not be able to compile.
> > E.g. mvn clean package that is supposed to just generate the artifacts and
> > not install them into the local repo. (strange is that this will fail on
> > building spring osgi with a artifacts resolution on the spring-core that is
> > quite strange in my view)
> >
> > Am I the only one with this problem?
> >
> >
> > I just google for some moments and I saw some references but nothing
> > relevant.
> >
>
>
> --
> Costin
>
Re: classpath issues with felix-maven-bundle
Posted by Costin Leau <co...@gmail.com>.
Alin Dreghiciu wrote:
> A solution will be indeed to separate the build of spring-modules,
> including
> required libraries from building of the rest. As with spring 2.1 anyway the
> artifacts will be osgi bundles anyway.
Until they will, we have to deal with this.
>
> P.S. if you are doing this refactoring isn't now also the moment to get rid
> of some of the required libraries build and use those from felix commons?
If I find time, I'll see if I can remove some of the libraries.
>
> Alin
>
> On 5/8/07, Costin Leau <co...@gmail.com> wrote:
>>
>> ...
>> Since maven for some reason, uses <module>/target/classes instead of the
>> published jar and target/classes is empty, I really can't see any nice
>> alternative here.
>
>
> I caould not find a clear reference about but I'm suspecting that this is
> done as you are not always installing the builded artifacts into the
> repository hence if the resolution would be based on the repository
> artifacts you would not be able to compile.
> E.g. mvn clean package that is supposed to just generate the artifacts and
> not install them into the local repo. (strange is that this will fail on
> building spring osgi with a artifacts resolution on the spring-core that is
> quite strange in my view)
>
> Am I the only one with this problem?
>
>
> I just google for some moments and I saw some references but nothing
> relevant.
>
--
Costin
Re: classpath issues with felix-maven-bundle
Posted by Alin Dreghiciu <ad...@gmail.com>.
A solution will be indeed to separate the build of spring-modules, including
required libraries from building of the rest. As with spring 2.1 anyway the
artifacts will be osgi bundles anyway.
P.S. if you are doing this refactoring isn't now also the moment to get rid
of some of the required libraries build and use those from felix commons?
Alin
On 5/8/07, Costin Leau <co...@gmail.com> wrote:
>
> ...
> Since maven for some reason, uses <module>/target/classes instead of the
> published jar and target/classes is empty, I really can't see any nice
> alternative here.
I caould not find a clear reference about but I'm suspecting that this is
done as you are not always installing the builded artifacts into the
repository hence if the resolution would be based on the repository
artifacts you would not be able to compile.
E.g. mvn clean package that is supposed to just generate the artifacts and
not install them into the local repo. (strange is that this will fail on
building spring osgi with a artifacts resolution on the spring-core that is
quite strange in my view)
Am I the only one with this problem?
I just google for some moments and I saw some references but nothing
relevant.
Re: classpath issues with felix-maven-bundle
Posted by Costin Leau <co...@gmail.com>.
Alin Dreghiciu wrote:
> Hi Costin,
>
> Here are my empirical observations about maven behavior.
>
> First of all the problem you have is not related to the the new plugin. It
> was the same also with the old plugin but the difference then was that
> before packaging as a bundle the content of spring-core was extracted first
> in the target/classes folder hence there were no problems because even if
> the classpath was set the the spring-core/target/classes, the necessary
> classes were there. With the bnd based plugin this is not true anymore, the
> classes being extracted and included "under the water".
>
> And the observation:
> In a multi project build case (as with spring osgi) maven will use compose
> the classpath for the dependency on artifacts from the same structure using
> the local structure not the installed repository artifacts.
I recall seeing something about that in the logs.
>
> Why does not fail when done separately?
> I suppose you meant separately as starting the build from within the io
> folder meaning the spring-modules will not be taken in consideration so the
> dependency resolution will use the ones installed in the repository.
>
> I do not see a solution right now but I will look further.
Thanks. One work around is to run the modules individually which AFAIK,
can't be done directly from maven.
Since maven for some reason, uses <module>/target/classes instead of the
published jar and target/classes is empty, I really can't see any nice
alternative here.
Am I the only one with this problem?
Cheers,
>
> Alin Dreghiciu
>
> On 5/7/07, Costin Leau <co...@gmail.com> wrote:
>>
>> Hello,
>>
>> I've upgraded today from the 'old' plugin to the new one and I got
>> blocked by a classpath problem.
>>
>> Basically I have two modules which both use the 'bundle' package:
>>
>> spring-core (which osgifies the original spring-core maven jar).
>> and
>> spring-osgi-io which depends on the osgi bundle of the bundle above.
>> (see the attached poms)
>>
>> If ran individually, each module works fine. If I ran them together (as
>> part of a bigger project), the second doesn't compile and throws weird
>> errors.
>>
>> I've ran maven -X and it seems that the problem is caused by the
>> classpath which doesn't get updated:
>>
>> [DEBUG] Source directories: [D:\work\i21\spring-osgi-sf\io\src\main\java]
>> [DEBUG] Classpath: [D:\work\i21\spring-osgi-sf\io\target\classes
>> C:\Documents and
>> Settings\User\.m2\repository\org\slf4j\slf4j-api\1.3.1\slf4j-api-1.3.1.jar
>>
>> C:\Documents and
>> Settings\User\.m2\repository\org\slf4j\jcl104-over-slf4j\1.3.1\jcl104-
>> over-slf4j-1.3.1.jar
>> C:\Documents and
>> Settings\User\.m2\repository\org\osgi\org.osgi.core\4.0\org.osgi.core-
>> 4.0.jar
>> **********
>> D:\work\i21\spring-osgi-sf\spring-modules\spring-core\target\classes
>> **********
>> C:\Documents and
>> Settings\User\.m2\repository\org\slf4j\slf4j-log4j12\1.3.1\slf4j-
>> log4j12-1.3.1.jar
>> C:\Documents and
>>
>> Settings\User\.m2\repository\org\eclipse\osgi\org.eclipse.osgi\3.2.2\org.eclipse.osgi-
>>
>> 3.2.2.jar
>> C:\Documents and
>> Settings\User\.m2\repository\log4j\log4j\1.2.13\log4j-1.2.13.jar]
>> [DEBUG] Output directory: D:\work\i21\spring-osgi-sf\io\target\classes
>>
>> Basically, it seems that the spring-core dependency is replaced with a
>> target/classes folder which is empty.
>> When ran by itself, the classpath is the one expected:
>>
>> C:\Documents and
>>
>> Settings\User\.m2\repository\org\springframework\osgi\spring-core\2.1-m2-SNAPSHOT\spring-
>>
>> core-2.1-m2-SNAPSHOT.jar
>>
>> From what I can see, it seems that the bundle plugin keeps the old
>> classpath between runs.
>>
>> Any ideas or workarounds are welcomed. This is a blocking issue before a
>> release ...
>>
>> P.S. I'm using the latest 0.9.0 SNAPSHOT.
>>
>>
>> Thanks,
>> --
>> Costin
>>
>>
>
--
Costin
Re: classpath issues with felix-maven-bundle
Posted by Alin Dreghiciu <ad...@gmail.com>.
Hi Costin,
Here are my empirical observations about maven behavior.
First of all the problem you have is not related to the the new plugin. It
was the same also with the old plugin but the difference then was that
before packaging as a bundle the content of spring-core was extracted first
in the target/classes folder hence there were no problems because even if
the classpath was set the the spring-core/target/classes, the necessary
classes were there. With the bnd based plugin this is not true anymore, the
classes being extracted and included "under the water".
And the observation:
In a multi project build case (as with spring osgi) maven will use compose
the classpath for the dependency on artifacts from the same structure using
the local structure not the installed repository artifacts.
Why does not fail when done separately?
I suppose you meant separately as starting the build from within the io
folder meaning the spring-modules will not be taken in consideration so the
dependency resolution will use the ones installed in the repository.
I do not see a solution right now but I will look further.
Alin Dreghiciu
On 5/7/07, Costin Leau <co...@gmail.com> wrote:
>
> Hello,
>
> I've upgraded today from the 'old' plugin to the new one and I got
> blocked by a classpath problem.
>
> Basically I have two modules which both use the 'bundle' package:
>
> spring-core (which osgifies the original spring-core maven jar).
> and
> spring-osgi-io which depends on the osgi bundle of the bundle above.
> (see the attached poms)
>
> If ran individually, each module works fine. If I ran them together (as
> part of a bigger project), the second doesn't compile and throws weird
> errors.
>
> I've ran maven -X and it seems that the problem is caused by the
> classpath which doesn't get updated:
>
> [DEBUG] Source directories: [D:\work\i21\spring-osgi-sf\io\src\main\java]
> [DEBUG] Classpath: [D:\work\i21\spring-osgi-sf\io\target\classes
> C:\Documents and
> Settings\User\.m2\repository\org\slf4j\slf4j-api\1.3.1\slf4j-api-1.3.1.jar
> C:\Documents and
> Settings\User\.m2\repository\org\slf4j\jcl104-over-slf4j\1.3.1\jcl104-
> over-slf4j-1.3.1.jar
> C:\Documents and
> Settings\User\.m2\repository\org\osgi\org.osgi.core\4.0\org.osgi.core-
> 4.0.jar
> **********
> D:\work\i21\spring-osgi-sf\spring-modules\spring-core\target\classes
> **********
> C:\Documents and
> Settings\User\.m2\repository\org\slf4j\slf4j-log4j12\1.3.1\slf4j-
> log4j12-1.3.1.jar
> C:\Documents and
>
> Settings\User\.m2\repository\org\eclipse\osgi\org.eclipse.osgi\3.2.2\org.eclipse.osgi-
> 3.2.2.jar
> C:\Documents and
> Settings\User\.m2\repository\log4j\log4j\1.2.13\log4j-1.2.13.jar]
> [DEBUG] Output directory: D:\work\i21\spring-osgi-sf\io\target\classes
>
> Basically, it seems that the spring-core dependency is replaced with a
> target/classes folder which is empty.
> When ran by itself, the classpath is the one expected:
>
> C:\Documents and
>
> Settings\User\.m2\repository\org\springframework\osgi\spring-core\2.1-m2-SNAPSHOT\spring-
> core-2.1-m2-SNAPSHOT.jar
>
> From what I can see, it seems that the bundle plugin keeps the old
> classpath between runs.
>
> Any ideas or workarounds are welcomed. This is a blocking issue before a
> release ...
>
> P.S. I'm using the latest 0.9.0 SNAPSHOT.
>
>
> Thanks,
> --
> Costin
>
>