On Jul 28, 2007, at 8:52 AM, Jason van Zyl wrote:
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.
Yes, this is really what I'm thinking of. A way to mixin a shared
profile, or to configure a set of dependency and plugin versions
which have been _blessed_, etc.
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.
I'm definitely thinking that the bits to mixin come from the
repository, and I'm even thinking they are just regular old poms...
configured like:
----8<----
<project>
<modelVersion>...
<parent>
...
</parent>
<imports>
<import>
<groupId>foo.bar</groupId>
<artifactId>some-shared-pom-muck</artifactId>
<version>1.0</version>
</import>
</imports>
</project>
---->8----
I know that the precedence thing may be problematic... so I suggest a
simple solution of exposing an additional element in the <import>
bits, which are optional to control how that pom is merged in. Of
course we come up with some reasonable default, say, always overlay
that stuff last after parent is merged in. But maybe the user might
want the imported pom to take precedence, or for the import to take
precedence over the parent, but not other profiles, etc.
I dunno, just kinda thinking out loud...
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.
I agree... but I really think that this is a critical missing part of
Maven to allow build configurations to be shared and re-used. Right
now the best we can do is chuck stuff into a common parent and then
get projects to extend from that parent to share the common
configuration (which is what the genesis project-config module is for
in the geronimo project). but folks rather tend to not like that, as
its got some ugly wrinkles, so more often folks just copy-paste which
ends up with more bits to go flip when that shared configuration
changes, which it does all the time.
Along the same lines, I was thinking that it would be a really good
idea, once this works, to setup some common mixin pom for a basic
project, a maven plugin, a groovy project, etc... that basically
configure the latest supported and working version details for
plugins that might be used for that type of project, as well as a
recommended release profile and probably some integration testing
profile. So that folks can easily quickly start creating complex and
powerful builds with out having to know about all that xml.
I think for each mvn release we'd roll out a new set of these project
genre poms with updated versions, and then make point releases over
time until the next mvn release when supporting plugins are released
and known to be compatible with that version of mvn and the other
plugins and bits configured.
It is possible to do something like this now, but its a PITA due to
the parent/child bits. Like we could create these, maybe have them
extend the ASF poms, but no everyone who wants to use it wants that
ASF stuff in there. If they are root poms, then folks will have to
add that ASF stuff to each of their projects. I think you know what
I'm talking about. So, the mixin pom bits are really important here,
as well as other places, to allow build configuration to trully shared.
The rest of the system is a little fragile for this to be turned on
IMO as useful as it would be.
How can we make it less fragile? I've really been wanting this
functionality for a few years now... I keep making parent poms to put
in config, and I want to keep re-using that config, but it becomes
problematic and messy to manage some of the duplicate information,
and well, projects just tend to get rust slowly overtime. :-(
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.
Heh, ya, no kidding. At this point I'm just trying to start a dialog
with the community to get feedback.... on the concept, potential
impacts, potential roadbumps, as well as maybe a hint or two of like
"if you wanted to try, maybe you could look at X.class and see how
parent merging goes, blah, blah, blah" ;-)
Cheers,
--jason
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
