On Sep 7, 2009, at 9:52 PM, Ralph Goers wrote:
At one point the pom was going to be "redone" so that it wasn't
going to be completely compatible. Later, I think the decision was
made to keep it compatible. At one point there was support for
having different pom formats but I'm not really sure what the state
of that is.
I asked if we could have yaml poms, and some of the committers said
"no." ;-)
Not exactly that simple, but the usual arguments about standardization
vs. flexibility in the tool were levied.
On that point, perhaps one way to handle this is to do something like
this:
1. Require all maven poms released in an organization inherit the
global metadata.
2. Any pom (of any type) would load this metadata
3. Run would fail because of a restriction in the parent pom on
available formats (for organizational standardization).
The argument about maven-wide standardization is, I believe, the
developers imposing a style based on a preference. If my whole
organization wants to roll yaml poms, I can't see why we shouldn't.
Having to do a second translation layer outside of maven means that
for us to standardize on something that makes us more productive and
less prone to error, we have to use a more brittle approach because of
an unnecessary design decision of the tool. Pick a canonical format,
sure, but for source... Heck, Maven builds that concept into its java
lifecycle, with generated code. Imagine if the build tool determined
that I could only use JACC, and that ANTLR wasn't part of the "maven"
set.
Go for standardization, pick sane, well documented defaults, but don't
bake in design decisions that don't conflict with those principles (if
possible).
Anyway - that's just a recap of my position. Focus on standardization
and not breaking existing anything came up (though I think spuriously,
since a canonical format would take care of that). Heck, we allow
maven-antrun-plugin executions for arbitrary crap, so at least if
we're going to script, we do it consistently in the lifecycle. Just
make this a pre-processing step.
cheers,
Christian.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
