Hi, Carefully trying to step in at a moment where there again was an attempt to being usefull :-) (Ken's [PROPOSAL] seemed to me too honest and willing to hijack it into more flamewars)
[doing the awfull crosspost reflecting the nature of this message-body] > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > +1 > > I would go even further and propose a top level project that will > host all project-management tools, including Gump. > with 'top level' you mean next to jakarta.apache and xml.apache projects? grouping all dev-facilitating-community-infrastructure-project-management related stuff into a common place for the others to start from sounds like a good idea? (IMO) Maybe this could give us all some neutral grounds AND an obvious central forum (lighthouse function) to work on and discuss the features in such system(s). Some of the original forest-dev kick off mailings had wishlists talking about this kind of stuff, only forrest doesn't try to be more then create a browser consumable cockpit view on all aspects of such an infrastructure. Finally: next to having possible competing alternatives (which indeed will solve itself in some survival-of-the-fittest mechanism anyway) one of the bigger drawbacks I'm seeing in the current situation of historicaly randomly self-project-oriented itch-scratching in the dev-infrastructure part: It leads to bad functional partitioning! The best thing I like about general/natural OSS design is that they tend to focus on 1. doing a small and essential part of the job very well and 2. putting up clear interfaces to hook into the others (pretty much like good OO design should focus on a sound split up of responsibility and collaboration, the typical example is the unix pipe-commandline which rules over the one size fits all executable that takes a million options, swithces and command line arguments (well, in unix they combine both of course :-() ) In the current situation, which I would call: "scratching 'the my-infrastructure and my-project management'-itch" tends to glob anything the particular project group sees as out-of-scope-but-essential-for-progress into one subproject... (This is also why this discussion goes on and on if you ask me: we have difficulty to compare maven and centipede because they take up more then one aspect in the show and have both areas in which they do and don't overlap... and if you ask me some of the features both maven and centipede are raving about should be refactored out as different co-operating and plugable subprojects of a bigger new dev-infrastructure strategy) And from this angle I dislike the expressed idea of waiting for more estalished versions of the currently competing (and ever funcitonally growing in an attempt to 'win') subsusbsub- and/or foreign- projects. In one line: The setup of a root level group could facilitate the discussions on sound functional partitioning. (it makes more sense to me then trying to combine jakarta and xml mailinglists, also on this social level some sound functional partitioning is a good idea, people that want to subscribe to all 'generals' can easily do so, perhaps facilitating that into one automated subscription-mail to all groups makes sense but if you're really interested in the topics you shouldn't be that lasy) I think Steven made a nice overview of what is already here and there in that arena: http://marc.theaimsgroup.com/?l=xml-apache-general&m=102028272723903&w=2 (maven, centipede, gump, forest, alexandria,...) probably 'ant' could be considered to move in as well. (having it's comparable grown out of tomcat history sure makes it a good candidate.) > While gump doesn't have a very big community of developers ( I wish > I had more time), it is an essential tool for jakarta, and > I think 'it is the real thing'. it should be an essential tool for xml.apache as well, as would go for all other projects in this new arena. and it would kinda offer a mechanism for offering to the world the best-practice-filled infrastructure tools these communities were able to create cause of their high volume and agility. it will never free us comppletely from itch scratching subprojects, but who would care then? this being the start of at least a no-flame subthread :-) maybe leaving us with some topic oriented questions can invite anyone into constructive participation: . Which are the different aspects of an elaborated development-community? [possibly grouped around the main activities: communication, documentation, participation, status reporting] . Into which features would you translate these aspects? [both server side as well as view-side as maybe IDE integration dreams] . Which of these do we have available in which subprojects? . What is the good or bad experience with it, maybe from commercial products as well? . Can we refactor those out and define interfaces between them? [probably loads of XML] . Can we find a name for this that does not try to combine 'centipede' nor 'maven' ? [admitting to some forrest/gump (as the movie, not the projects :-)) bias I propose (at least as a working name): 'Leonidas', the brand on the box of belgian chocolates, since I honnestly don't know what I'm going to get :-)] damn, so much work already, we could use the separate mailing list :-) more detailed questions welcome as we go allong... regards, and feel free... -marc= > > There are many solutions for the same problem - and it seems > Centipede is based on Cocoon and XSLT, which would make it > my preference ( if I would need such a tool ). > I know other people dislike xslt - and I think it's fair to > have a choice. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
