Maybe I'm too far into the "Maven community", but I don't see a problem here. You say:
> 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. But nothing in Maven prevents you from depending upon different versions of the same artifact from different projects in a reactor build. While it is true that you can only have one version of commons in the reactor at a time, this doesn't have anything to do with using commons as a dependency. Within the same reactor, you can have: app1 -> commons 1.0 app2 -> commons 2.0 commons (could be version 1.0, version 2.0 or anything else) You seem to be wanting to have the entire transitive closure defined in a single build, which is just unnecessary and seems at odds with the idea of doing modular development. Justin On 5/12/10 12:34 PM, Chris Blunck wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
