********************
      WHY KRYSALIS
   ********************

From: "Andrew C. Oliver" <[EMAIL PROTECTED]>

> I've no problem with that if Ken is given committer access, the
> community agrees and comes up with a plan to integrate the two and all.
>  I just figured it made more sense to have a project specifically for it
> rather than a subproject of a subproject that has nothing to do with it
> in general.

This is why Centipede came up on Krysalis instead of Apache.

I followed the discussion we had here on if/how to accept projects at
Apache, and about why Jakarta is not Sourceforge.
Krysalis came up with the goal of pursuing Apache-style projects out of
Apache itself, till they mature to a level at which they can honestly
propose themselves on this list.

Personally, I have already tried to collaborate with Maven on the Alexandria
list, even only at the descriptor level, and unfortunately have miserably
failed (http://marc.theaimsgroup.com/?t=101713408000002&r=1&w=2)

This is why Maven and Centipede have different descriptors.

BTW, the Centipede module.xml descriptor is an enhanced Gump descriptor, and
works OOTB with Gump itself.

   **********************
          CENTAVEN?
   **********************

> But there has to be a sincere effort not just a "squash
> centipede by saying yes to the proposal then -1ing the implemnetation".
>  I just want the "to".

I just want a build system that gives you the possibilities of Centipede,
which Maven still lacks.

That said, I don't care where the project resides. My decision of putting it
on Krysalis was taken to abide as much as possible to Jakarta standards, but
it seems that stretching them to ones needs is more effective.

> Personally I'd like to see the combined Centaven moved to a
> jakarta.org/centaven level.  If this effort is truely undertaken, POI
> will upgrade to a combined centaven.  (I don't care what its named its
> the senitment).. .  Then who wins?  Well everyone.  We get what we need.

I'm +1000 for this, as I have always been.

So, let me throw the stone.


                                         -oOo-


Here is what I think is in the best intrest of ALL on Jakarta, let's see
what the Jakarta Community thinks.

   ***************************
            PROPOSALS
   ***************************
This multi-proposal is an effort to unite forces on the build-system front
and to give a sense to all project build/documentation/site projects on
xml.apache and Jakarta.


        JAKARTA-GUMP
   ***********************
Alexandria started as a multi-project documentation system, and is now dead.
Gump started there by using the Alexandria descriptors but has become a
conyinuous-integration tool.

I propose that it finally becomes a top-level Jakarta project, as it is now
de-facto.

The Vindico proposal will migrate to that project as well and will have the
possibility to challenge the current de-facto Gump codebase with a vote as
permitted by the Jakarta rules.


        JAKARTA-ALEXANDRIA
   *******************************
Alexandria still has an important mission, that of creating beautiful
cross-referenced Java project documentation.
Maven has taken part of the code-base AFAIK and is using it.
Centipede is producing source-code cross reference with javasrc and
umldoclet, and is working on creating SVG UML package charts.

Alexandria can continue with its mission.
Maven can port-back the code it uses.
Javasrc developer Bill Smith has decided to DONATE the code to the
Alexandria project and continue coding there
(http://sourceforge.net/forum/message.php?msg_id=1552505).
Centipede will give all the code it has that generates documentation.

        CENTAVEN
   *******************
Maven and Centipede have similar goals but different approaches.

I would like to see them united, and have a single project description
system.

We have the need, we have the community, we have the code.

Centipede will never be able to make it into Maven and viceversa, because
the approaches are very different.

I think that these can be overcome, and that we can devide a comon system
that solves *all* our  _needs_.


        SUMMARY
   *******************
Here is my +1+1+1 for all three proposals.

This is the best I can do, and what I think is in the best interest for
Apache.

What do you think?

--
Nicola Ken Barozzi                   [EMAIL PROTECTED]
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to