I'd second the very good points that Kalle made. To add some practical experience from this end, I just last night learned the power of using the <module> element within a <profile> element...
> <profiles> > <profile> > <id>all</id> > <modules> > <module>web</module> > <module>core</module> > <module>messaging</module> > <module>security</module> > </modules> > </profile> > <profile> > <id>web</id> > <modules> > <module>web</module> > <module>messaging</module> > <module>security</module> > </modules> > </profile> > <profile> > <id>core</id> > <modules> > <module>core</module> > <module>messaging</module> > <module>security</module> > </modules> > </profile> > </profiles> I use Spring for the IoC container on my projects, and in an optional project for core, have a stubbed command bean that is defined once in the web project, then with a full implementation again in the core project, but with the "primary" attribute on the bean definition set to true. This transparently overrides the central command message interface with a real implementation, connecting the two projects together at runtime. The messaging and security projects are obviously needed by either project, whether they run separately or together. The messaging project contains the message classes that are sent to the stub or the core depending on what gets loaded, and the core project accepts those messages, thus creating a dependency from both. Brian On Dec 10, 2010, at 12:57 PM, Kalle Korhonen wrote: > On Fri, Dec 10, 2010 at 9:20 AM, KARR, DAVID (ATTSI) <[email protected]> wrote: >> Another desire I have is to allow for developers not even building most >> of the modules, and just letting the "ear" project pull snapshot >> artifacts from the Nexus repo (built by the release team or continuous >> integration). I could do this with multiple "build" projects, including >> different sets of "module" elements. That seems messy, however. I wish >> I had different options for setting that up, perhaps in a profile, but I >> don't see how that could work. > > Overall, I'd say this sounds better than trying to (mis-)use profiles. > Nothing you said indicates to me that the EARs are functionally > equivalent, and therefore I'd create different modules for different > EARs. One of the Maven ground rules is one artifact per module. > Typically you deviate from that plan only if you need to build > different versions of the same module (packaged differently, for > different OSes/JVMs etc.) and often you use profiles for the desired > effect. I'd further say using profiles should never be your first > option. Reserve profiles for the time you really need them. > > Since you are going to re-work the build, I'd mercilessly refactor it > into a modular build now. Since Maven is so good at versioning things, > your build doesn't have to be monolithic. Snapshots are ok, but it's > far better if you can identify common, stable areas of the codebase > and simply release them separately. Then your top-level builds are > mostly assembling things together rather than compiling/building them. > Personally, I'd put my efforts on making the build modular, automating > version migration and doing more continuous integration & testing > rather than trying to force Maven the same logic as your Ant build. > Depending on the size of the project and your team, it would likely be > beneficial to pay somebody who really knows Maven to assist you in the > migration at this point (if you can get it approved, I know how it > is). It would save you from a lot of grief later. > > Kalle > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
