On 10/12/2010 1:24 PM, KARR, DAVID (ATTSI) wrote:
-----Original Message-----
From: Kalle Korhonen [mailto:kalle.o.korho...@gmail.com]
Sent: Friday, December 10, 2010 9:58 AM
To: Maven Users List
Subject: Re: Reasonable use of profiles?
On Fri, Dec 10, 2010 at 9:20 AM, KARR, DAVID (ATTSI)<dk0...@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.
To clarify the use case I'm talking about here, let's say the EAR requires 20 principal artifacts to
construct the EAR (not to mention the numerous third-party dependencies). These have a 1-1 correspondence to
modules. Some developers will work on one set of those modules (one or more), and other developers will work
on other sets. No developers will work on all of the modules, but all developers need all of the produced
artifacts in order to produce an EAR. So, if I only do work on one module, I could produce a build project
that just has two modules, the module I work on, and the "EAR" module. I would get the other
artifacts from the Nexus repo. Other developers would have to use a different build project, with a
different set of modules, including the "EAR" module. Other developers would have a build project
with a still different set of modules, including the "EAR" module.
> From what I can tell, my only option is to create these numerous very similar
"build" projects, all with different permutations of the available modules.
Release management would never use these, these are just for developers.
I'm simply looking for a better way to manage this. I envision if I somehow had a "list" property,
consisting of module names, defined in "settings.xml", a developer could easily add or subtract
from this list, and a single "build" project would use that property. I just don't know how to get
something like this to work with Maven.
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.
What I have the leeway to produce is a structure that is compatible with Maven, but will
still work with the Ant build. I can't bring down the entire development process while I
single-handedly construct the Maven infrastructure. It was hard enough to get permission
to even examine Maven. Each of our individual projects will produce a single artifact,
whether from Ant or Maven, and the responsibility for assembling the EAR is now separated
into a separate "build" project. That will allow me to integrate Maven with
less pain after the slightly transformed Ant build is working.
I am still trying to figure out how your development process is so
abnormal that the normal Maven way will not work out-of-the-box.
We have over 70 projects that build our portal application that includes
standalone batch jobs, web services, servlets and portlets.
We use no profiles and have very simple POM files.
I can not see any reason in what I get from reading your description of
your environment that makes me think you are doing anything so far
outside normal development projects.
I would suggest that you start with Mavenizing your utilities and then
convert each project.
I am not sure why this is something that would take very long to do.
Keep it simple.
Stay away from fancy or custom plugins.
Avoid profiles until you have your basic build converted and then see if
profiles can optimize anything.
Get your Nexus working well.
If your are using Eclipse, move to Eclipse/STS to get their really nice
integration with Maven.
Keep asking questions but start them at the strategy level before
getting into details.
Ron
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
