On 2009-09-08, at 9:49 AM, Christian Edward Gruber wrote:
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)
These are not going to be discovered. You are going to have to support
hooking in your format. Autodiscovery implies support on our side and
that's not going to happen. That's not a trivial system to make work
properly. I've tried and it's exactly the can of worms I'm talking
about. It's a few lines of code on your side. So again, the onus is
going to be on you to support your version of Maven that works with a
given POM format. There will be no autodiscovery mechanism in 3.x.
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.
Neither did I, you misread. M2Eclipse won't even be able to read the
POM. These tools use their own parsers which integrate into the given
platform. In M2Eclipse we actually use EMF, not Maven's internal
parser. I'm sure Netbeans and IDEA have similar mechanisms. So there
isn't parity in the tooling either. The autodiscovery happening in the
core and then being magically picked up in tooling is a pipe dream.
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.
Ultimately in 3.x you'll be able to write your own front-end parser,
extend or overwrite a Guice wiring to put in what you like and then
you're ready to go. Or you could also make the autodiscovery mechanism
you talked about and wire that in.
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]
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]
