I primarily deal with 2 open source organizations, Apache and Eclipse. To a lesser degree, I also interact with tigris.org for subversion and subclipse, springframework.org for more and more each week it seems and a few other ".org" organizations. I like to think I grok open source software and how the communities functions. I know no one owes me anything and that if I find a bug or realize a good enhancement then its part of my community commitment to create a reproducible bug report or even better a well thought out patch to the current code. In the long run, this will benefit me as well as others, leading to a win-win for everyone involved. To a large extent the ASF helped start the open source community gig. You're like original band members, but it hurts to say that you all are getting your asses handed to you by orgs like Spring and Eclipse. There just doing a far better job on the dcomentation and website. This all my opinion, with the collective opinions of a few others thrown in, but the truth is that it is becoming flat out painful to deal with some ASF projects, Log4j and Maven in particular. Log4j has been circle jerking on how to releae the 1.3 version of the code and maintain backwards compatibility. It may be impractical to impossible to do so, then rev the version to 2.0, jump to java 5 as a minimum and completely do away with backwards compatibility. But that's a logging project issue now a maven one. To paraphrase, the problem with Maven is that there are "lies, damn lies and the maven documentation".
Take toady's latest example, say you want to remove an ant build file and do things the maven way, so you decide to use the dependency plugin. The web site examples have the group and artifactId being <groupId>org.apache.maven.plugin</groupId> <artifactId>dependency-maven-plugin</artifactId> That doesn't look right because most maven plugins are in the " org.apache.maven.plugins" groupId. You decide to follow the source repo link and it takes you to the maven-dependency-plugin project. Looking at the project's pom confirms that the groupId is "org.apache.maven.plugins" and that the artifactId is really "maven-dependency-plugin". Well we solved that, let's try and use it. Unfortunately it is not available from any repo I currently know of. Damn this is inconvenient, but we'll just have to build it from source. Oh, wait after checking the project out it won't build because it requires an unreleased org.apache.maven.plugins:maven-plugins:pom:2-SNAPSHOT, SON OF A [EMAIL PROTECTED] I just about wanted to bloody slot myself to stop the pain. Now some things that I think would improve things is the adoption of some of the things that I think make the Eclipse Foundation great. 1.) Publish a project plan and commit to periodic milestones. A lot of plugins still are attached to beta APIs even when there are 2 or more released versions of the artifact available. For each milestone release all code should be compiled with the latest as the rule rather than the exception. The plan will let the community know what's coming and when we can expect every milestone build between now and the release. The plan is not static as you can updated whenever you want. 2.) Produce nightly and weekly integration builds. For eclipse, devs have to move up to integration builds and if the builds fail then work is done to fix and verify before moving on. It should be simple for us (the community) to download a build at anytime from a standard location. We should also be able to view a report on the tests so that we can detrmine if it is worth our time to pick it up or not. Maybe this is happening, but how would I know? Both the Maven 2 and Continuum websites have a dead link to the Continuous Integration server, http://maven.zones.apache.org:8080/continuum.<http://maven.zones.apache.org:8080/continuum> 3. Update the website regularly. Just split the thing down the middle into released info (doc, tutorials, examples, etc) and development current info which at a minimum would be the last stable milestone. I realize that there my be bylaw rules, etc. differences between the ASF and EF. Take voting for example. I'm on the mailing list and there are votes called for this plugin and that one from time to time. However, could it not be more efficient to release them in mass, especially if they have been continuously updated to current API's/fixes. Just call for a vote now that in weeks time we will release all core maven plugins for Maven 2.1 M3. This has 2 immediate effects, 1.) the community knows exactly (give or take a day or two for last minute issues) when the next milestone is and 2.) other maven community plugin devs can plan their releases to sync with yours. Now I don't get to bitch, hit send and walk away, so what areas of the website/documentation are available for a person who has some free time. I'm hesitant to signup for something big due to day job and night time commitments, but I do have some time and I'd like guidance on what areas I can invest it with respect to making maven better. I just want the pain to stop. Maven's a great tool and we receive a lot of benefits from its use. However, we likely could do more, faster if some serious sharp edges were child proofed. Wb
