Sorry, I did walk away there for a little bit. On 8/27/06, Brett Porter <[EMAIL PROTECTED] > wrote:
On 28/08/2006, at 7:14 AM, Wendell Beckwith wrote: > 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> The dependency plugin was accepted to this project, but hasn't yet been released here. IMO, we should remove it from the plugin list or put it in a separate section as it shouldn't be considered ready for use here yet. Still, please do file bugs against it where there are documentation issues.
Done. http://jira.codehaus.org/browse/MDEP-34
> 1.) Publish a project plan and commit to periodic milestones. Yes, we need a roadmap. Development on the Maven core has been on the backkburner as we fix peoples pressing issues and work on the plugins and, funnily enough, the documentation. As you'll have seen on this list recently, John has been putting a lot of topics together for discussion and they come up from time to time and get recorded. At some point in the near future we'll have a roadmap for 2.1 out. > A lot of plugins still are attached to beta APIs even when there > are 2 or > more released versions of the artifact available. Specific examples? I don't see this in any plugins that aren't themselves beta plugins. > For each milestone > release all code should be compiled with the latest as the rule > rather than > the exception. I'm not really sure what this achieves for the end user, and whether you are talking about just maven, or all its plugins too. I assume you are referring to us learning from Callisto here, which I've already ranted about on my blog, but I'd be interested to hear from someone who is closer to that community that knows the tangible benefits it brough.
I suppose this depends on where you draw the line between maven core (whatever that is) and its plugins. In all honesty I don't know where that line lies. So some of what I see may be related to the plugins and not maven itsself. At present I can't think of where I saw a maven plugin using a beta api but I do remember that while tracking something done in the repo I noticed that there were 2 full versions ( x.0 and x.0.1) already available and that the code was calling for an 2.0-beta version. I recently wiped and rebuild my local repo, and ran a search across all poms in the org.apache.maven group and didn't turn up anything, so perhaps it's all better now. Until I can produce some reliable evidence I would mark this as unreproducible.
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. Yes, that's a good idea.
For my team, I have been using, with minor adaptations, the eclipse dev process and in general I think it has the right amount of "agility". We post our plan early with our commited, proposed, deferred and rejected items for the next release and we revise it through out the release process. We use confluence for posting so that people interested in it can subscribe just to that page to cut down on unwanted emails. Therefore, when we make updated everyone who wants to be notified is notified and they can either comment on the issues we have attached to each plan item or start a forum discussion. I've create a template that maybe of use to you all if you wanted to go this way.
> 2.) Produce nightly and weekly integration builds. We already do. We could do it better. I've brought this topic up a couple of times on the Continuum list.
I'm not on that list but I guess I will have to be to get a better picture of what's going on.
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 > This seems to be the problem. Our nightly builds are produced from an old system that we were intending to move to Continuum so hadn't published links to. On the Continuum side, we had to move the server "temporarily" due to resource constraints and the links haven't been updated yet. Please file an issue for these.
Done. http://jira.codehaus.org/browse/MNG-2535
> 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. There's been significant discussion on this on the list already which I can give you pointers to if you need them, but I'm not rehashing them again. I'm happy with the plan we have. Unfortunately, when people have put forward proposals recently they've been met with silence. We need more participation to get this moving. > However, could it > not be more efficient to release them in mass, especially if they > have been > continuously updated to current API's/fixes. Our experience is the opposite. We did this in Maven 1 and plugin releases were always stuck behind a core release. It takes a lot more effort to release every plugin at once.
I'm not asking that you abandon releases when you think there is merit or for critical fixes. Instead I'm suggesting that you publish ahead of time that you are going to roll a milestone/release at a certain periodic time in the future. For the most part, no one on any eclipse list requests a build/release because we (community and devs) know from reviewing the plan when they will be. Because the community knows, the community waits. Because the devs know the community is going to pounce on the milestone like the slowest Zebra ,they work to get it in shape slightyl ahead of time. In no way should this prevent you from release maven-foo-plugin between milestones/releases. The APIs are not a moving target. I like that we can push out a
single plugin when it has fixes, and that old plugins continue to work with new releases of Maven. On the other hand, it means we need a greater eye over everything to make sure plugins do get released regularly. This needs work. > 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. I'm happy to guide you into any area where you are interested to help out. So, is it documentation that you want to help with? We have a list of outstanding tasks which I can put in one place. Or would you like to help pull together the roadmap for external consumption?
I'm open to working with either or both. I do believe that production of the roadmap can help guide how to prioritize what documentation will be needed and when though. - Brett
Wb
