I very much second Kalle here. Stay away from profiles as much as possible - most often they are used in the wrong way. Also, if you're migrating a large system I would very much recommend that you get someone with good Maven knowledge to help you get things right. I very often come to projects where some senior developer has created a Maven build setup which is just completely wrong. Having to refactor that costs possibly two-three times more than doing it right from the beginning. It often also upsets the developers as they often have to change the way they work.
/Anders On Fri, Dec 10, 2010 at 18:57, Kalle Korhonen <[email protected]>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] > >
