On 28 Jul 07, at 8:56 AM 28 Jul 07, Jason Dillon wrote:
Folks, I think this may have come up before, though I've not gone
digging in the jira or mailing list trenches for it...
I would be *really, really useful* if a pom could include other
poms into its effective pom *in addition to* the parent pom. The
parent pom and tree structure is very useful for defining projects
and scoped configuration muck for a single project, but when
wanting to share more pom elements with many projects, the
inheritance model breaks down significantly and ends up causing
projects to duplicate elements to control common build scenarios,
which then causes more maintenance... and in the end ultimately
ends up in a rather big mess :-(
Composition versus inheritance. The same problem has arisen with the
POM.
For something like a release profile, or release tool chain and
import or mixin approach would be far more convenient.
The problem is how and where to get the information to mixin. I think
it should come from the repository, so something like the release
profile becomes a mixin taken from a reliable source like the
repository. Otherwise being able to mixin anything potentially leads
to build portability problems. In order to do this we also have a not
to trivial task of figuring out what takes precedence, merging versus
aggregation ... and we really don't have solid rules for much of this
behavior at the moment.
So general mixins I agree would be highly useful, but the devil is in
the details. It would be quite easy to pull a chunk of XML, we could
either do it at the modello level or the project builder level, but
what to ultimately do with the information is the problem.
The rest of the system is a little fragile for this to be turned on
IMO as useful as it would be.
If you want to start looking at it that would be cool, but I don't
think it's a weekend project. The impact of turning on a feature like
that is widespread.
I would really like to define a simple pom module, that defines
some common pom elements, maybe in a profile, maybe not. And then
configure my projects root pom (er the top-level pom that is) to
*include* the pom modules to get that poms elements overlaid into
the current effective pom. In the same way that works for the
parent really. Maybe first apply includes/imports (whatever you
call them) then parent, and then local overrides take precedence or
something like that.
Of course reference the poms to be included in the same way that
the parent is defined, yada, yada, yada.
IMO, this would be a *HUGE* benefit to the entire Maven community,
as then at this point folks can start to develop and share common
build configurations and let projects consume them easily.
It doesn't seem like rocket science... though I've not dug into the
depths of the plexus, modelo and other bits that made the pom
inheritance bits work.
Just for clarification, I'm not for tossing out the parent/child
bits, those are also important, but I think we need a kinda mixin
for pom configuration too.
Any thoughts?
--jason
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
