Hello, This may be OT for the thread but I figured the Felix community is the community most likely impacted by this behavior in Maven. I'm hopeful that somebody has a workaround or can provide some guidance on how they approached this problem.
My project is partitioned into smaller efforts. Each individual smaller effort can be considered a subproject. When reusable logic is identified we often place it into a "commons" module that is shared between the smaller efforts. Each smaller effort is described by a feature XML file that uses the mvn protocol. From a directory perspective you can think of our project like this: ProjectX: - commons/trunk - commons/tags/1.0.0 - commons/tags/2.0.0 - app1/trunk - app1/tags/1.0.0 - app1/tags/2.0.0 - app2/trunk - app2/tags/1.0.0 - app2/tags/2.0.0 At the ProjectX directory we have a pom.xml that references submodules commons/trunk, app1/trunk, and app2/trunk. The problem I have arises when app1 and app2 use different versions of the commons module. If app1 references commons/1.0.0 as a dependency and app2 references commons/2.0.0 as a dependency I'm in trouble because my top level pom.xml can't build both versions of commons in the same reactor. The Maven community doesn't view this as limiting. They ask: why would you ever have different sub-projects that use different versions of a common module? In the pluggable OSGi world this is very natural - app1 can safely use version 1.0.0 of commons while app2 can safely use version 2.0.0. So my question to the Felix community is: how do you approach this problem? One approach is to mangle the artifactId at the commons level and append the version (e.g. commons-1.0.0). That would certainly work but ... Another approach might involve the use of Maven profiles to determine which version of commons to build (e.g. if I'm the app2 profile I should build version 2.0.0 of commons but if I'm the app1 profile I should build version 1.0.0). Or yet another approach might be to create entirely separate pom.xml files at the ProjectX level for app1 and app2. That seems kinda scary though. Does anyone have any ideas? Or does anyone have another way of looking at this problem that might shed some light on a decent solution? Thanks for your time, -Chris
