Eric Kolotyluk wrote: > What I do is have a top-level POM like (see below), and then I have my > top level project POMs reference that (see further below). This may not > be the best example, as I am still in the process of building the > infrastructure, but > > 1. I put the Parent POM in its own place in source control and I > manually deploy it with Maven when I make changes. > 2. You need to do this before creating any Project POMs that reference > it because they should reference it via Maven and not the file > system - if you work in a large company you will soon discover why. > 3. There is of course a bootstrapping issue because now the project > POMs need to know how to find your Repository Manager, which is why > I include that information in the top level (Corporate) POM so > people can use it as a reference. > 4. As you may gather I am using Sonatype's Nexus as a Repository Manager. > 5. We are still developing our corporate repository infrastructure so > the content of the Corporate POM will evolve over time as our > corporate governance and policies are better codified. > > Does that help?
[snip] > <modules> > <module>platform.Java</module> > <module>platform.NET</module> > </modules> [snip] It's a bad idea to declare modules in a global (resp. corporate POM). Such a POM should be a project on its own with no submodules. Or do you think the Apache parent POM references all projects at Apache that use Maven directly (or indirectly)? A project POM may now refer the global parent either using a specific version (to pin down a specific set of versions and dependencies) or a SNAPSHOT to use the latest entries/updates of the global POM. - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
