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 <[EMAIL PROTECTED]> 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
