I'd suggest you take a look at how we build Sling. In short, although we have a multi-module build, it is purely for aggregation. We cut releases of individual modules when they are ready and then produce an application which is an assembly of released module. That application is embodied in multiple forms, including a Karaf feature.xml file. Although we don't package (in the case of the JAR/WAR distributions) or reference (in the case of the Karaf feature.xml file) multiple versions of the same bundle, there's nothing stopping us from doing that. Within the multi-module build, we different versions of a variety of bundles being used.
I'm happy to talk about build theory for hours on end, but I fear this really is off-topic for felix-users. If you have specific questions about the Sling build, feel free to ask on the sling users list. Justin On 5/12/10 2:51 PM, Chris Blunck wrote: > On Wed, May 12, 2010 at 2:30 PM, Justin Edelson <[email protected] > <mailto:[email protected]>> wrote: > > 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]> > > <mailto:[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. > > > I agree. I think the question is: how do you populate the repository? > > > > 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. > > > I agree with all those statements. What I'm searching for is the > handoff between A and B. Developers shouldn't build releases but they > do play a role in the process in that developers possess the knowledge > of what ingredients should be blended together to create a release. > Maven has been very effective as an expression of that recipe (e.g. my > app depends on these other modules and this is how they all go together). > > I think we're somewhat in agreement here. > > If developers "shouldn't be building releases" as you point out then > that suggests that the release engineers need to build the software that > will be released. Ideally they would use the same recipes the > developers used: the various pom.xml files. > > > > >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. > > > Each of my project's "applications" are described in separate feature > files. Those feature files use the mvn protocol that reference bundles > that are needed in order to install and start the feature. I can set a > property in the org.ops4j.pax.url.mvn configuration that specifies the > location of a maven repository. This makes deployment very natural... > > The activity of creating an RPM based on "any maven repository" is a > one-time task. I do it once and I shouldn't have to modify it in the > future. > > As long as my project's pom.xml files build all the different versions > of the artifacts that they need my deployment becomes much easier. It > consists of: > 1.) deploy "the maven repository" > 2.) deploy felix-karaf > 3.) deploy several feature files > > > > > > > > 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. > > > I've built RPMs with maven several times using the rpm-maven-plugin. > What I'm trying to do is larger than what rpm-maven-plugin provides... > > > > > 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. > > > Not quite... I very much want a repository chock full of multiple > versions of artifacts. But I also want to be able to build that > repository up from scratch (when I'm building from within a .spec file) > so that I can distribute it as an RPM. > > > -c > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
