> I find your pronouncement that it won't be here very troubling since you only > have a single vote just as every other committer does. >
Knowing you in person, I'll take the above with a grain of salt that maybe it's not exactly what you meant. However my first reading of this was alarming. People have a right to produce and publish code anywhere they choose. What we have purview over as a Maven project is only the code that comes in here. So you could choose to say you don't like Maven depending upon this external dependency, but that should be rationalized with the fact that the current resolution logic is flawed and unmaintainable. No one in the years I've been around has significantly stepped up to try and fix it (I may be the last one besides Benjamin that really dove in and fixed bugs and that was years ago). Continuing to think the current resolution code will magically improve while externally people are inventing and reinventing the same pieces of code is not a good idea. > I'm going to have to give serious consideration as to whether I could accept > this dependency without the code also residing at Apache. > The key question here is why is this different than ANY other dependency we choose to use that's not at Apache? Maven is a consumer of this api, which is separate than the fact that Maven specific bits are the things Aether is attempting to make generic at the moment. It's a grey line sure about what is core to maven and what is needed by all consumers of this api. I'm sure Ivy, Gradle etc have written code to read Maven specific bits. Should that code also be located here? Are you upset that they didn't? These are obviously facetious question because I know you don't actually think that, but asking them illustrates the distinctions a bit. I for one would love if anyone consuming and producing artifacts for Maven repos could use the same code easily. Having all these permutations makes a mess of the repos when files and metadata aren't updated correctly. It's obvious that projects other than Maven won't use the code in Maven to do it, evidenced by the fact that they don't today. Having this api code in a neutral location makes that hurdle, even if it's a mental one, non-existent. Projects that "compete" won't use each other's code, but everyone uses the same external dependencies already. (think about logging...everyone uses log4j, slf4j etc. If we made log4m and dropped it in maven's scm, would Gradle, Ivy, Buildr use it? Doubtful... at the same time, would the Maven project start depending upon the code in gradle for resolution? Also doubtful.) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
