So - 2 points.
1. Who's saying you have to actually have YAML poms IN the maven
project - as long as I can find a way to (through autodiscovery of
some mechanism) not have to do crazy wrappers. You said these
extension points would be there, so I'm happy. (do note the smiley)
2. Who's saying you ahve to change the internals of the maven pom in
a way that would screw with integrations like m2eclipse, etc. Not I.
Note, I said canonical format, and someone else (can't remember who)
pointed out that the object model is the truly canonical metadata
model. That's fine with me. I'm talking about pre-generating in a
way that's transparent from the CLI. If that's by extensions, fine.
I just would rather not have mvn wrapper scripts to do it.
Christian.
On Sep 8, 2009, at 3:35 AM, Jason van Zyl wrote:
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: [email protected]
For additional commands, e-mail: [email protected]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
---------------------------------------------------------------------
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]
