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 <[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 >> >> > -- Costin
