We are planning on changing the pom format when we move to modelVersion 5.0.0 (which currently looks like a Maven 4.0 goal)
Our current plan is to get 3.2.x stabilised and perhaps roll a 3.3 line with new features until we are in agreement over what a modelVersion 5.0.0 pom should look like. One of the current suggestions that may be gaining traction is to separate the consumer pom from the build pom. The consumer pom would be designed with machine parsing as the priority... there would actually be two of them both generated from the build pom. The first consumer pom would be a modelVersion 4.0.0 regular pom so that older clients can still make some sense of the artifacts. The second consumer pom would allow the new features we want to add and hopefully be a format where we can extend without fear of breaking future existing clients... in other words Maven is not the only consumer of pom files, so we need a format that can evolve going forward without risking breaking the other parsers out there... and since some of these parsers are not even JVM based we cannot force them to use our JVM based parser. The builder pom, since it is only used by Maven when building a project, can actually have a much simpler set of format restrictions... such as you cannot depend on a parent builder pom that uses a newer modelVersion than yours. On 25 February 2014 05:16, William Ferguson <[email protected]>wrote: > One of the common complaints I hear about Maven is that the config is too > verbose, especially when compared to the attribute based dependency config > used by Ivy. Personally it doesn't worry me overly, but if the config for > dependencies/plugins where to become attribute based instead of element > based it could really condense a pom and improve readability. > > Are there any plans to move to an attribute based config post 3.2? > > William >
