maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <>
Subject Re: Re : non-xml poms in 3.x
Date Tue, 08 Sep 2009 08:00:09 GMT

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:
>>> For additional commands, e-mail:
>> Thanks,
>> Jason
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder,  Apache Maven
>> ----------------------------------------------------------
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:



Jason van Zyl
Founder,  Apache Maven

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message