>>>> I'm not sure I understand. Is the proposal here to deploy non-XML project >>>> descriptors to the repository in addition to the standard pom? If so, >>>> what is the point? >>> >>> In the case of the Clojure dialect there will be two other implementations >>> using the same dialect. Lein, Cake, and Polyglot Maven. Lein and Cake want >>> to >deal with the Clojure format. So it's not skin off my back if we deploy >>> another format, it's not going to harm anyone and help them. Polyglot Maven >>> could deal >with either but there tools might not be able to. Should they >>> use the bits in Polyglot Maven. I'd like that but I can't make them.
If everything gets converted to the standard pom format, what use is there having the alternate forms of their pom in the repo? If I depend on something, I don't care how they built it, just that the pom has the correct dependency information. If you think the native info absolutely must be there for some other reason, then I think it should be in a standard file to avoid an explosion of unmanaged crap polluting the repo. Something like: foo-1.0.pom and foo-1.0.native where native can contain any dialect but is prefaced by a header describing what dialect it is. What I wouldn't want to see is randomly named standards popping up for every new dialect. No one disagrees with the rest of what you said here about leveraging the energy of the communities, I think the concern is simply that it be done in a bounded way to keep the repo contents fairly normalized. BTW this concept of native vs pom could apply to how we manage future maven pom formats. Maven 3.1, 4 ,5 could all be valid native layouts where the dependency info is translated back to the v4 pom we have today. It is a mix of concerns to have both the build info and the dependency info described in the same file in the repo. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
