On 5/12/10 2:19 PM, Chris Blunck wrote: > On Wed, May 12, 2010 at 1:48 PM, Justin Edelson <[email protected] > <mailto:[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? Make it so... Maven isn't really usable without artifacts in repositories.
> > 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. A) the release artifacts should be in a Maven repository. B) developers shouldn't be building releases C) If a developer needs to build a module, they should check it out of version control and build it. > > 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 I'm really not clear what you are trying to accomplish here, but I'm not that well-versed with RPMs. > > 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 might want to ask on the mojo mailing list about advice on building RPMs with Maven. > > > > > 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? > Mostly it seems to me you're trying to avoid having a repository. I would steer you away from this. If you are doing non-trivial development with Maven (or, arguably, with anything), you need an artifact repository. Justin > > > -c --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
