maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Topping <topp...@codehaus.org>
Subject Re: Reasonable use of profiles?
Date Fri, 10 Dec 2010 18:13:13 GMT
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) <dk068x@att.com> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message