On Wed, May 12, 2010 at 13:51, Chris Blunck <[email protected]> wrote:
> On Wed, May 12, 2010 at 2:30 PM, Justin Edelson <[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]>> 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? > When you decide to release a component, you should use the maven release plugin that will do all the work for you (creating the svn tag and uploading the release in the repository). That way, your repository will be populated over time with all the versions that will be released. That's how all maven repositories work. In addition to your own repository containing your releases, you'll need a repository containing external libraries (pointing either to central or your own controlled repository containing approved libraries). > > > > 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. > > Once a release has been cut, the artifacts will have been deployed into the repository as part of the release process. So developers should not checkout a tag and build it themselves, they should rely on repositories to grab all their dependencies. > > > > >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 > > Right, that makes sense. But you would still have to build the "repository" from a controlled repository. > > > > > > > > > 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. > > You may want to have a look at the features-maven-plugin from karaf which is used to create the repository from a karaf features. That's what we actaully use to build the karaf distribution. It won't package it for you, but it will grab the dependencies and move them into a fodler that you can zip later. > > -c > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
