Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 330008

Summary: Uses constraint violation
Product: [RT] Virgo Reporter: Alex Blewitt <alex.blewitt>
Component: unknownAssignee: Project Inbox <virgo-inbox>
Status: CLOSED WONTFIX QA Contact:
Severity: normal    
Priority: P3 CC: glyn.normington
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:

Description Alex Blewitt CLA 2010-11-11 10:42:04 EST
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>
Comment 1 Glyn Normington CLA 2010-11-12 07:15:07 EST
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.