xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc Portier" <...@outerthought.org>
Subject [Leonidas] an invitation (was RE: [PROPOSAL] Centaven and Friends (was Re: You make the decision (was Re: Quick! convert all your projects to maven!)))
Date Thu, 02 May 2002 06:02:04 GMT
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: costinm@covalent.net [mailto:costinm@covalent.net]
>
> +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.


---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org


Mime
View raw message