On Aug 4, 2010, at 7:04 AM, Brian Fox wrote: >> 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.
There is no good way to explain exactly what I meant, but I'll try. I realize Jason started this project but: 1. "The Maven Company" thing has bugged me for a long time. It is in clear violation of an ASF trademark but Jason says tough shit. We on the PMC let it go because in the whole scheme of things it isn't that big of a deal. 2. Periodically I am in meeetings with folks at my company with people who start a sentence with "Jason said"... and then go on to say something that has never been discussed on these lists. That ticks me off because they believe he is the BDFL of Maven when Apache doesn't allow for such a title. 3. I see posts like the one I responded to on a regular basis that imply the decision has already been made and the rest of the community doesn't have a voice. My response would not have included the above had the email started with something like "I think hosting Aether at Eclipse is a great choice and would like consensus for that" vs "Aether will be at Eclipse. Let me know if you have any objections". The first is about team building while the second is the BDFL model. I realize the above is not going to sit well with Jason. Individually none of the above are a big deal, but when added up they make me very concerned about this project. > > 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 don't work for Sonatype. I don't work on Maven full time. I've started to look at new code previously only to have it pulled out making my effort a waste of time. You know very well what problems I want to address - I've mentioned them several times and attempted to fix one of them, ending with you and me reviewing the code. Since then I've been told on this list that those issues cannot be addressed until after 3.0. Who knew that 3.0 was still going to be in development years later. > > >> 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? The difference is in how critical the component is to the overall project. Maven and the repository go hand in hand. Maven cannot run without it. From an external point of view when people think of Maven they think of poms and the repository. > > 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.) I agree with all of the above except: a. No one uses the code in Maven because it wasn't designed to do it. Providing Aether as a separate jar solves that problem no matter where it resides. b. Saying Ivy or Gradle won't use code produced by Maven because we compete is sheer conjecture. c. I haven't seen anyone say that the code has to be bundled as part of Maven. As a Maven subproject or an independent ASF project it can be packaged separately. So really, I just don't buy the argument that moving this to a separate foundation is required so that other projects will use it. I do buy into the argument that this code needs to be completely separate and even have its own build lifecycle. Ralph --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
