On 2009-09-08, at 4:12 AM, Christian Edward Gruber wrote:
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." ;-)
The flexibility will be in the Maven framework, not what we expose in
the Maven CLI. The difference being the onus of support is not the
burden of this project but whomever decides to make their variant of
the POM. This is not a small change in behaviour or interoperability.
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.
There would be nothing stopping you at all from doing this. The onus
of support is on you. This is one of the primary goals of the changes
in Maven 3.x is to easily allow extensions. For integrators to provide
extensions and to support them, not for us at the project to support.
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.
This may very well happen in the future. But there are far more
important concerns and mixing in trying to support variants of the POM
in the first release cycle of 3.0 would be a complete and total
disaster. We would have 198 variations because people think they have
something better. Each one of them with a valid arguments as to why
they are better. So instead of debating the merits of format we will
give you the ability to support your format. It's outside the scope of
Maven proper.
I would like people to actually try this as then we'll see what the
outcome is without there being serious damage on the Maven side. The
fact is we don't actually know what would happen and it's not going to
be an experiment in Maven. I don't think people understand the real
impact of changing so fundamental as the POM format:
- All examples in books and existing documentation become invalid
- Maven tooling like M2Eclipse, Netbeans and IDEA become immediately
useless until the tooling catches up
- Interoperability becomes impossible in the short term
These are not insignificant issues and are _extremely_ costly to
support. There is the problem here in the Maven project itself, but
allowing arbitrary POM formats then imposes huge support costs on
people who have invested in Maven tooling.
For all of these reasons it's not going to happen quickly in Maven
itself that we change the format. The extension points will be there
and folks can do as they like but it's just not something I think we
can feasibly support in Maven.
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
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
