On Wed, May 12, 2010 at 1:48 PM, Justin Edelson <[email protected]>wrote:
> 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 are correct that this is handled gracefully within Maven. However, it presupposes that both commons-1.0 and commons-2.0 have been previously built and installed into a maven repository that is accessible to app1 and app2. What should be done if that assumption is not valid? In other words ... a new developer svn co's the codebase and wants to do a full-build so they can deploy the app. If the artifacts for commons-1.0 and commons-2.0 are not in a maven repository then how does that new developer build them? Since they are artifacts of the project it seems logical (to me) that a new developer on the project should be able to build them without much hassle. Where I'm going with all of this is: I'd like to prepare an RPM for a maven repository that contains all the artifacts from my project. Ideally the build instructions in the spec are as simple as: - svn co <mycode> - cd <mycode> && mvn install Unfortunately I'm in the predicament where app1 and app2 depend on different versions of commons. That's just fine in the OSGi world because the 2 bundles for commons are kept separate by the container. However, since I can't build BOTH versions in the reactor at the same time I'm wedged into a position where I may need to modify the build instructions in my RPM spec. I'm trying to avoid that if possible because I'd prefer for application developers to not be responsible for modifying spec files when they add or introduce a new dependency within our project. > 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. > Perhaps you can steer me in another direction after considering what I've described above? -c
