0

Is there a way to prioritize fragment dependencies? I have the case that one of the maven plugins that is used at compile time does not use the hierarchical OSGi Classloading, but instead uses a "flat" classpath. Now there is a version conflict between (transitive) dependencies of the host plugin and the fragment. Everything would work fine in a hierarchical scneario, but fails for the "flat" classpath.

Is there a way to prioritize the fragments dependencies? Logically, i mean that the dependencies of the fragment should be resolved before the dependencies of the host.

kutschkem
  • 7,826
  • 3
  • 21
  • 56
  • So, you have a maven plug-in configured in your build which works on the approximation of the OSGi class path injected by Tycho into the Maven model? – oberlies Dec 19 '13 at 13:33
  • @oberlies if i parse your sentence correctly, i assume so, yes. – kutschkem Dec 19 '13 at 15:15
  • So you want to manipulate the class path that Tycho injects into the Maven model. Unfortunately, this is not possible. – oberlies Dec 20 '13 at 11:37

1 Answers1

0

No, dependencies of the host and fragment are resolved at the same time. Besides, I'm struggling to imagine why you think it would ever help to resolve the fragment first.

I think you are jumping ahead of yourself. It seems you have decided that the solution must be based on resolution order, so that's the question you have chosen to ask. It would be much more helpful to go back a step (or several) and describe the actual error and why it's happening. All you've said so far is that something "fails"... in what sense? Is there an error message? Did something unexpected happen? Maybe your expectation is wrong, so please describe what you expected to happen vs what actually happened.

I'm also confused about your use of the terms "hierarchical" vs "flat" classpaths. OSGi classloading is neither strictly hierarchical nor flat.

Neil Bartlett
  • 23,743
  • 4
  • 44
  • 77
  • "flat" seems clear to me, what is the proper term you would use for OSGi classloading? Also, if you are interested in the, let's say, "original" question, it is here http://stackoverflow.com/questions/19998211/how-do-i-diagnose-and-fix-classpath-problems . Now the actual problem is a little more complicated than described, my test bundle "Project A" is not just dependent on "Project B" but is a fragment of "Project B", and "Project B" is not directly dependent on JUnit, but is dependent on a bundle that ships its own JUnit version along. The problem is that i want/have to use JUnit 4.11 API – kutschkem Dec 18 '13 at 08:27
  • ... but at (xtend) compile time only get to see JUnit 4.8 classes – kutschkem Dec 18 '13 at 08:27
  • Hold on are you talking about compile-time dependencies?? In which case the question is not about OSGi or class loading at all... – Neil Bartlett Dec 18 '13 at 13:10
  • No the question is about compiling xtend as part of a tycho-based build. I explicitely said in my question that the problem appears at compile time. Maybe talking about class-loading is wrong, is the proper term dependency resolution? Or rather compile-time class path?? My suggested solution, however, is an OSGi one. Just in this instant i managed to solve the issue by making my host plugin depend on the right JUnit version, and declare the dependency before the one that introduces the rogue JUnit. If there was a way to do what i describe in my question, then i can avoid that dependency... – kutschkem Dec 18 '13 at 13:31
  • ...and keep my host plugin agnostic of the fact that some fragment wants to use JUnit and needs the dependency declared in a certain fashion. – kutschkem Dec 18 '13 at 13:32
  • Okay so I got confused. The solution will have nothing to do with OSGi since OSGi is a runtime technology. It'll be something to do with how Maven/Tycho handles transitive dependencies, probably. Better to tag the question with "tycho" and "maven" so that people who know about your build system will see it. – Neil Bartlett Dec 18 '13 at 13:41