Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 368596 - Tycho does not honor the classifier element
Summary: Tycho does not honor the classifier element
Status: RESOLVED FIXED
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: Tycho (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P2 normal (vote)
Target Milestone: ---   Edit
Assignee: Jan Sievers CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 373117 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-01-13 17:35 EST by Yves Langisch CLA
Modified: 2021-04-28 16:54 EDT (History)
5 users (show)

See Also:

Attachments
demo-project (26.64 KB, application/zip)
2012-01-13 17:36 EST, Yves Langisch CLA 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Yves Langisch CLA 2012-01-13 17:35:32 EST 
Build Identifier: 

I have an eclipse-test-plugin with POM-dependencies (pomDependencies consider) as follows:

...
<dependency>
	<groupId>ch.dummy</groupId>
	<artifactId>common</artifactId>
</dependency>
<dependency>
	<groupId>ch.dummy</groupId>
	<artifactId>common</artifactId>
	<classifier>tests</classifier>
</dependency>
...

It looks like tycho does not honor the classifier element as the latter dependency overrides the first one. This leads to compilation errors as the first dependency is not on the classpath. A workaround was to define the first dependency as extraClasspathElement for the tycho-compiler-plugin. But as soon as it gets to the tycho-surefire-plugin the dependency is missing from the test runtime.

I'm attaching a test project:

1) mvn install -Pcommon
2) mvn install -Pclient

Reproducible: Always
Comment 1 Yves Langisch CLA 2012-01-13 17:36:42 EST 
Created attachment 209485 [details]
demo-project

Steps to reproduce:

1) mvn install -Pcommon
2) mvn install -Pclient
Comment 2 Igor Fedorenko CLA 2012-01-13 20:21:47 EST 
no, no workaround I can think of
Comment 3 Matthias Sohn CLA 2012-05-21 07:36:54 EDT 
we have seen the same problem with pomDependency=consider on an eclipse-repository project.

instead of assembling the sources jar, the bundle jar is assembled, probably because the classifier is ignored.

more interestingly, switching back to eclipse-update-site works around the problem so this seems to be eclipse-repository specific

sample sources:

http://git.eclipse.org/c/jgit/jgit.git/tree/org.eclipse.jgit.packaging/org.eclipse.jgit.repository/pom.xml
Comment 4 Jan Sievers CLA 2012-05-22 05:05:34 EDT 
(In reply to comment #1)
> Created attachment 209485 [details]
> demo-project
> 
> Steps to reproduce:
> 
> 1) mvn install -Pcommon
> 2) mvn install -Pclient

the attached example is invalid.

module common produces two bundle jars with the same Bundle-SymbolicName: common
Also, both bundles export the same package "ch.dummy" (split package)

Thus Require-Bundle: common is ambiguous and will resolve to whatever wins first.
Also, Import-Package: ch.dummy would be ambiguous in this example and resolution would be indeterministic as well.

however there is a real issue with pomDependencies and classifiers which is demonstrated by the Egit example in comment#3

I am preparing a patch for this issue.
Comment 6 Jan Sievers CLA 2012-05-22 07:10:26 EDT 
*** Bug 373117 has been marked as a duplicate of this bug. ***