> -----Original Message-----
> From: Brian Topping [mailto:[email protected]]
> Sent: Friday, December 10, 2010 10:13 AM
> To: Maven Users List
> Subject: Re: Reasonable use of profiles?
> 
> 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>

Interesting.  This could go into the "build" project POM, but if a
developer needed a custom list of modules, they could define that in
their settings.xml.  I guess that could work for what I'm looking for.
 
> 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]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to