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