Community
Participate
Working Groups
Build Identifier: 2.1.0.RELEASE I built a PAR which included slf4j-api-1.5.8.jar (since that was a transitive dependency of tiles-servlet-2.2.2.jar, via jcl-over-slf4j-1.5.8.jar) When I installed it into Virgo, I got this message: package 'org.slf4j_1.6.1' in bundle 'com.springsource.slf4j.api_1.6.1' used by 'org.slf4j.impl_1.6.1' in bundle 'com.springsource.slf4j.nop_1.6.1' conflicts with 'org.slf4j_1.5.8' in bundle 'com.example.par-1.0.0.SNAPSHOT-slf4j .api_1.5.8' I get that it's a different version number, but why couldn't the PAR be installed, and have those bundles be upgraded to run against 1.6.1 instead of 1.5.8? None of the imports had a closed range. Reproducible: Always Steps to Reproduce: Create a PAR with the following Maven dependency: <dependency> <groupId>org.apache.tiles</groupId> <artifactId>tiles-servlet</artifactId> <version>2.2.2</version> </dependency> This will create a PAR containing slf4j-1.5.8, which conflicts. You need: <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-dependency-plugin</artifactId> <executions> <execution> <id>copy-dependencies</id> <phase>prepare-package</phase> <goals> <goal>copy-dependencies</goal> </goals> <configuration> <outputDirectory>${project.build.directory}/classes</outputDirectory> <overWriteIfNewer>true</overWriteIfNewer> <excludeArtifactIds>slf4j-api</excludeArtifactIds> </configuration> </execution> </executions> (You may need commons-collections-3.2.1 as well) <dependency> <groupId>commons-collections</groupId> <artifactId>commons-collections</artifactId> <version>3.2.1</version> </dependency>
This is the expected scoping behaviour of a PAR, which also applies to scoped plans. When satisfying imports of bundles in a scope, exports from bundles in the scope take precedence over exports from bundles outside the scope. Under the covers this is implemented by metadata rewriting which adds matching attributes to tie the imports in a scope to the corresponding exports in the scope. A PAR which needs to wire to different exporters depending on the available bundles must omit these exporters from the PAR to avoid the above scoping behaviour. This is pretty routine: the (varying) external dependencies of a PAR go in repository/usr (if not already provided by Virgo) and the PAR is then deployed.
