You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Steven Noels <st...@outerthought.org> on 2002/12/08 23:29:47 UTC
Apache Trove
Hi all,
due to the recent and upcoming reorgs in terms of the
'federation'/project/subproject structure and the assumed increased
difficulty for people finding their way around ASF projects, I have been
playing around with a draft 'trove' application, which isn't much more
than some XML & XSLT glued together, running on top of Cocoon.
http://cocoon.cocoondev.org/mount/trove/ (warning: data entry hasn't
been completed yet)
This 'app' runs on top of a very free-formed XML document currently:
<trove>
<federation name="XML">
<keyword name="XML"/>
<site uri="http://xml.apache.org/"/>
<description>[...]</description>
<project name="FOP">
<keyword name="XSL-FO"/>
<keyword name="Java"/>
<site uri="http://xml.apache.org/fop/"/>
</project>
</federation>
<project name="BCEL">
<site uri="http://jakarta.apache.org/bcel/"/>
<description>[...]</description>
<federation name="Jakarta"/>
<keyword name="Java"/>
</project>
[...]
and should be maintained by the respective project communities. I
already went searching what Gump could offer me in terms of available
data, but Gump is for obvious reasons limited to Jakarta and XML (Java)
projects. Adding the Gump people to add a 'keyword' element to their
descriptors wouldn't cause too much harm, but the problem is that I also
store the project hierarchy in my data file, and this is slightly
orthogonal to Gump's structure. So adding extra data to Gump's
descriptors would help, but not enough and not for everybody (including
perl/php/...)
Another approach might be to store a small trove file per project in the
committers cvs module, where assumably everybody has access too, and me
aggregating those.
The (XML) structure being required would be something like:
<project name="">
<site uri=""/>
<description></description>
<keyword name=""/>
(<federation name=""/>)
</project>
Projects can contain projects, and can be grouped into 'federations',
aka httpd, xml, jakarta and others. I tried to set up the stylesheets to
do something meaningful without many strict requirements on the
hierarchy of the datafile.
Anyway, this is just a heads-up. I don't know where I could move it too
since it falls a bit in-between projects. The presentation is by no
means finished, but should be easy to tweak. I can nurture this thing on
my own on my own server, but if other people would be interested in
playing along, just gimme a yell.
Cheers,
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0103539/
stevenn at outerthought.org stevenn at apache.org
Re: Apache Trove
Posted by Stefano Mazzocchi <st...@apache.org>.
Steven Noels wrote:
> Hi all,
>
> due to the recent and upcoming reorgs in terms of the
> 'federation'/project/subproject structure and the assumed increased
> difficulty for people finding their way around ASF projects, I have been
> playing around with a draft 'trove' application, which isn't much more
> than some XML & XSLT glued together, running on top of Cocoon.
>
> http://cocoon.cocoondev.org/mount/trove/ (warning: data entry hasn't
> been completed yet)
>
> This 'app' runs on top of a very free-formed XML document currently:
>
> <trove>
> <federation name="XML">
> <keyword name="XML"/>
> <site uri="http://xml.apache.org/"/>
> <description>[...]</description>
> <project name="FOP">
> <keyword name="XSL-FO"/>
> <keyword name="Java"/>
> <site uri="http://xml.apache.org/fop/"/>
> </project>
> </federation>
> <project name="BCEL">
> <site uri="http://jakarta.apache.org/bcel/"/>
> <description>[...]</description>
> <federation name="Jakarta"/>
> <keyword name="Java"/>
> </project>
>
> [...]
>
> and should be maintained by the respective project communities. I
> already went searching what Gump could offer me in terms of available
> data, but Gump is for obvious reasons limited to Jakarta and XML (Java)
> projects. Adding the Gump people to add a 'keyword' element to their
> descriptors wouldn't cause too much harm, but the problem is that I also
> store the project hierarchy in my data file, and this is slightly
> orthogonal to Gump's structure. So adding extra data to Gump's
> descriptors would help, but not enough and not for everybody (including
> perl/php/...)
>
> Another approach might be to store a small trove file per project in the
> committers cvs module, where assumably everybody has access too, and me
> aggregating those.
>
> The (XML) structure being required would be something like:
>
> <project name="">
> <site uri=""/>
> <description></description>
> <keyword name=""/>
> (<federation name=""/>)
> </project>
>
> Projects can contain projects, and can be grouped into 'federations',
> aka httpd, xml, jakarta and others. I tried to set up the stylesheets to
> do something meaningful without many strict requirements on the
> hierarchy of the datafile.
>
> Anyway, this is just a heads-up. I don't know where I could move it too
> since it falls a bit in-between projects. The presentation is by no
> means finished, but should be easy to tweak. I can nurture this thing on
> my own on my own server, but if other people would be interested in
> playing along, just gimme a yell.
>
> Cheers,
>
> </Steven>
I like it!! what about moving the sources over to the community CVS
module so that maybe others can play with it and enhance it? Just a
random suggestion.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
Re: Apache Trove
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Steven Noels wrote:
> Nicola Ken Barozzi wrote:
>
>> I'm looking into making these published via Gump, taking a parallel
>> route to the one Steven has taken. We'll soon see the solution and
>> work together on it.
>
>
> I have been background talking with Sam and moved towards using Gump as
> a datasource, too - but not running inside Gump since I have some Cocoon
> tricks in mind. Nothing committable yet, though. Do we need to work in
> parallel?
Not necessarily.
I was thinking of changing the stylesheets so that the Gump build
outputs to the xdocs11 format. Actually all Gump does in this regard is
aggregate the descriptors and xslt them.
What are your ideas?
Let's move this to the Forrest list where there are also the major Gump
devs, and see what we can do.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Apache Trove
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Steven Noels wrote:
> Nicola Ken Barozzi wrote:
>
>> I'm looking into making these published via Gump, taking a parallel
>> route to the one Steven has taken. We'll soon see the solution and
>> work together on it.
>
>
> I have been background talking with Sam and moved towards using Gump as
> a datasource, too - but not running inside Gump since I have some Cocoon
> tricks in mind. Nothing committable yet, though. Do we need to work in
> parallel?
Not necessarily.
I was thinking of changing the stylesheets so that the Gump build
outputs to the xdocs11 format. Actually all Gump does in this regard is
aggregate the descriptors and xslt them.
What are your ideas?
Let's move this to the Forrest list where there are also the major Gump
devs, and see what we can do.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Apache Trove
Posted by Steven Noels <st...@outerthought.org>.
Nicola Ken Barozzi wrote:
> I'm looking into making these published via Gump, taking a parallel
> route to the one Steven has taken. We'll soon see the solution and work
> together on it.
I have been background talking with Sam and moved towards using Gump as
a datasource, too - but not running inside Gump since I have some Cocoon
tricks in mind. Nothing committable yet, though. Do we need to work in
parallel?
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0103539/
stevenn at outerthought.org stevenn at apache.org
Re: Apache Trove
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sam Ruby wrote:
> Steven Noels wrote:
>
>> Sam Ruby wrote:
>>
>>> It would really be nice if the Maven/Gump/Forrest/Trove/etc.
>>> descriptors could be converged. With a base vocabulary that all can
>>> share, and an ability to have namespace qualified tool extensions.
>>
>>
>> Yup - so what do you think: should/could this be something to be added
>> to/triggered by Gump? Or do you prefer it to live outside, and only
>> trying to define that convergence w.r.t. descriptors...?
>
>
> I'm only focused on convergence of the descriptors. It really doesn't
> make much sense for a project to maintain a separate set of largely
> overlapping metadata, one for each tool.
Krysalis Centipede decided to use the Gump descriptor and enhance it
where needed. Jakarta POI for example uses it.
>> Areas were being part of Gump might help are existing buy-in by a lot
>> of projects (even non-Apache ones!), and the description and uri
>> already being there. Problem is that Gump only maintains a linear
>> 'classification' of projects, whereas I want some hierarchy, and the
>> notion of keywords that needs to be added.
>>
>> I don't know enough about the Gump machinery to start extending it
>> (but I'm downloading it ATM), so any guidance is welcome.
>
>
> Gump ignores tags it doesn't understand. But if we can get more tools
> to share metadata, we probably need to make this more formal via
> namespaces.
>
> FYI: Forrest is going down the route of adding tags to gump descriptors.
Yup, and Centipede too.
Also, on Forrest we are testing an xml version of the status file, that
is complementary to the project descriptor as a container of community info.
> Maven invented their own descriptors, with the idea of eventually
> generating gump descriptors from this format. To date, this has not
> worked out as well as I would have liked, for example:
>
> http://marc.theaimsgroup.com/?l=alexandria-dev&m=103936130220759&w=2
>
> - Sam Ruby
>
> P.S. An example of the types of report that Gump produces:
>
> http://cvs.apache.org/builds/gump/latest/xref.html
I'm looking into making these published via Gump, taking a parallel
route to the one Steven has taken. We'll soon see the solution and work
together on it.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Apache Trove
Posted by Sam Ruby <ru...@apache.org>.
Steven Noels wrote:
> Sam Ruby wrote:
>
>> It would really be nice if the Maven/Gump/Forrest/Trove/etc.
>> descriptors could be converged. With a base vocabulary that all can
>> share, and an ability to have namespace qualified tool extensions.
>
> Yup - so what do you think: should/could this be something to be added
> to/triggered by Gump? Or do you prefer it to live outside, and only
> trying to define that convergence w.r.t. descriptors...?
I'm only focused on convergence of the descriptors. It really doesn't
make much sense for a project to maintain a separate set of largely
overlapping metadata, one for each tool.
> Areas were being part of Gump might help are existing buy-in by a lot of
> projects (even non-Apache ones!), and the description and uri already
> being there. Problem is that Gump only maintains a linear
> 'classification' of projects, whereas I want some hierarchy, and the
> notion of keywords that needs to be added.
>
> I don't know enough about the Gump machinery to start extending it (but
> I'm downloading it ATM), so any guidance is welcome.
Gump ignores tags it doesn't understand. But if we can get more tools
to share metadata, we probably need to make this more formal via namespaces.
FYI: Forrest is going down the route of adding tags to gump descriptors.
Maven invented their own descriptors, with the idea of eventually
generating gump descriptors from this format. To date, this has not
worked out as well as I would have liked, for example:
http://marc.theaimsgroup.com/?l=alexandria-dev&m=103936130220759&w=2
- Sam Ruby
P.S. An example of the types of report that Gump produces:
http://cvs.apache.org/builds/gump/latest/xref.html
Re: Apache Trove
Posted by Steven Noels <st...@outerthought.org>.
Sam Ruby wrote:
> It would really be nice if the Maven/Gump/Forrest/Trove/etc. descriptors
> could be converged. With a base vocabulary that all can share, and an
> ability to have namespace qualified tool extensions.
Yup - so what do you think: should/could this be something to be added
to/triggered by Gump? Or do you prefer it to live outside, and only
trying to define that convergence w.r.t. descriptors...?
Areas were being part of Gump might help are existing buy-in by a lot of
projects (even non-Apache ones!), and the description and uri already
being there. Problem is that Gump only maintains a linear
'classification' of projects, whereas I want some hierarchy, and the
notion of keywords that needs to be added.
I don't know enough about the Gump machinery to start extending it (but
I'm downloading it ATM), so any guidance is welcome.
> P.S. Gump is capable of running anything that can be run via the
> command line and produces output to stdout/stderr.
Duly noted :)
As of know, Trove is nothing more than 2 XSLT stylesheets, it doesn't
make use (yet) of any Cocoon-specific component.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0103539/
stevenn at outerthought.org stevenn at apache.org
Re: Apache Trove
Posted by Steven Noels <st...@outerthought.org>.
Sam Ruby wrote:
> It would really be nice if the Maven/Gump/Forrest/Trove/etc. descriptors
> could be converged. With a base vocabulary that all can share, and an
> ability to have namespace qualified tool extensions.
Yup - so what do you think: should/could this be something to be added
to/triggered by Gump? Or do you prefer it to live outside, and only
trying to define that convergence w.r.t. descriptors...?
Areas were being part of Gump might help are existing buy-in by a lot of
projects (even non-Apache ones!), and the description and uri already
being there. Problem is that Gump only maintains a linear
'classification' of projects, whereas I want some hierarchy, and the
notion of keywords that needs to be added.
I don't know enough about the Gump machinery to start extending it (but
I'm downloading it ATM), so any guidance is welcome.
> P.S. Gump is capable of running anything that can be run via the
> command line and produces output to stdout/stderr.
Duly noted :)
As of know, Trove is nothing more than 2 XSLT stylesheets, it doesn't
make use (yet) of any Cocoon-specific component.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0103539/
stevenn at outerthought.org stevenn at apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Apache Trove
Posted by Sam Ruby <ru...@apache.org>.
Steven Noels wrote:
>
> and should be maintained by the respective project communities. I
> already went searching what Gump could offer me in terms of available
> data, but Gump is for obvious reasons limited to Jakarta and XML (Java)
> projects. Adding the Gump people to add a 'keyword' element to their
> descriptors wouldn't cause too much harm, but the problem is that I also
> store the project hierarchy in my data file, and this is slightly
> orthogonal to Gump's structure. So adding extra data to Gump's
> descriptors would help, but not enough and not for everybody (including
> perl/php/...)
It would really be nice if the Maven/Gump/Forrest/Trove/etc. descriptors
could be converged. With a base vocabulary that all can share, and an
ability to have namespace qualified tool extensions.
- Sam Ruby
P.S. Gump is capable of running anything that can be run via the
command line and produces output to stdout/stderr.
Re: Apache Trove
Posted by Steven Noels <st...@outerthought.org>.
Jeff Turner wrote:
<snip/>
Scary: yet another guy mindreading me :)
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0103539/
stevenn at outerthought.org stevenn at apache.org
Re: Apache Trove
Posted by Jeff Turner <je...@apache.org>.
On Sun, Dec 08, 2002 at 03:36:41PM -0800, Robert Koberg wrote:
> Hi Steven,
>
> interesting choice of the word 'trove'
> --- something valuable discovered or found
> --- a collection of valuable objects
>
> ----- but nothing is discovered - it is already known, of course it is a
> collection of valuable objects. The history of the word is from the french verb
> 'trover = "to find".' But there is nothing to find. It is already known.
Not to people looking :) The relationship between the various Apache
projects is far from clear. Eg, Struts, Turbine and Cocoon all are
'frameworks' of sorts, but that info isn't made clear anywhere.
Likewise, Struts, Webwork and Maverick are all MVC 'Controllers', JSP,
Velocity, WebMacro, Tea, are MVC 'Views', Castor, OBJ, Torque, Hibernate
are all object/relational whatsits.. wouldn't it be nice if someone
classified all this stuff. Or rather, if the individual projects could
classify _themselves_, and then a harvester works out the relations..
While it is possible Steven was musing on French verbs, I think its more
likely he stole the meaning from Sourceforge's classification system:
http://sourceforge.net/softwaremap/trove_list.php
That might be related to the Trove on ESR's page,
http://www.tuxedo.org/~esr/trove/
> but if it is a list of all projects, why not use 'grove'
> -- my dictionary says grove = a small wood or stand of trees without dense
> undergrowth
I think some SGML people got there first:
http://www.xml.com/pub/a/2000/04/19/groves/
--Jeff
> ----- a clean forrest?
>
> semantic pedantics :)
> -Rob
>
> > -----Original Message-----
> > From: Steven Noels [mailto:stevenn@outerthought.org]
> > Sent: Sunday, December 08, 2002 2:30 PM
> > To: community@apache.org
> > Cc: alexandria-dev@jakarta.apache.org; forrest-dev@xml.apache.org
> > Subject: Apache Trove
...
Re: Apache Trove
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Steven Noels wrote:
> Bert Van Kets wrote:
>
>> Steven,
>> Where do you want to get with this information? I can see the link
>> between this "trove" document and Forrest, but please elaborate.
>
>
> There isn't much of a link right now, but this can come.
>
>> From what I read between the lines it would be a great opportunity to
>> use the restructuring to get people into Forrest, or to adapt Forrest
>> to reflect the structure and make the transition for the projects to
>> Forrest as easy as 123.
>
>
> I'm not nearly as ambitious as that. I just have troubles finding out
> what projects exist in the Apache hemisphere, and given the recent
> turbulence, I thought such a resource might be helpful.
>
> I was thinking of Forrest as a skinning system - but would like to focus
> on data collection first. I've been talking to Sam Ruby and am trying to
> find some common ground between all these descriptors.
Easy, the common ground is the Gump descriptor.
At centipede we have enhanced it with extra data, and Forrest is using
part of that version. Maven is able to generate it automatically.
Gump already makes a cross-linked site on these descriptors, if you want
to give me a hand in Forrestizing the output...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Apache Trove
Posted by Steven Noels <st...@outerthought.org>.
Bert Van Kets wrote:
> Steven,
> Where do you want to get with this information? I can see the link
> between this "trove" document and Forrest, but please elaborate.
There isn't much of a link right now, but this can come.
> From what I read between the lines it would be a great opportunity to
> use the restructuring to get people into Forrest, or to adapt Forrest to
> reflect the structure and make the transition for the projects to
> Forrest as easy as 123.
I'm not nearly as ambitious as that. I just have troubles finding out
what projects exist in the Apache hemisphere, and given the recent
turbulence, I thought such a resource might be helpful.
I was thinking of Forrest as a skinning system - but would like to focus
on data collection first. I've been talking to Sam Ruby and am trying to
find some common ground between all these descriptors.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0103539/
stevenn at outerthought.org stevenn at apache.org
Re: Apache Trove
Posted by Bert Van Kets <be...@apache.org>.
Steven,
Where do you want to get with this information? I can see the link between
this "trove" document and Forrest, but please elaborate.
From what I read between the lines it would be a great opportunity to use
the restructuring to get people into Forrest, or to adapt Forrest to
reflect the structure and make the transition for the projects to Forrest
as easy as 123.
Do I read you correctly?
Bert
At 23:29 8/12/2002 +0100, you wrote:
>Hi all,
>
>due to the recent and upcoming reorgs in terms of the
>'federation'/project/subproject structure and the assumed increased
>difficulty for people finding their way around ASF projects, I have been
>playing around with a draft 'trove' application, which isn't much more
>than some XML & XSLT glued together, running on top of Cocoon.
>
>http://cocoon.cocoondev.org/mount/trove/ (warning: data entry hasn't been
>completed yet)
>
>This 'app' runs on top of a very free-formed XML document currently:
>
><trove>
> <federation name="XML">
> <keyword name="XML"/>
> <site uri="http://xml.apache.org/"/>
> <description>[...]</description>
> <project name="FOP">
> <keyword name="XSL-FO"/>
> <keyword name="Java"/>
> <site uri="http://xml.apache.org/fop/"/>
> </project>
> </federation>
> <project name="BCEL">
> <site uri="http://jakarta.apache.org/bcel/"/>
> <description>[...]</description>
> <federation name="Jakarta"/>
> <keyword name="Java"/>
> </project>
>
> [...]
>
>and should be maintained by the respective project communities. I already
>went searching what Gump could offer me in terms of available data, but
>Gump is for obvious reasons limited to Jakarta and XML (Java) projects.
>Adding the Gump people to add a 'keyword' element to their descriptors
>wouldn't cause too much harm, but the problem is that I also store the
>project hierarchy in my data file, and this is slightly orthogonal to
>Gump's structure. So adding extra data to Gump's descriptors would help,
>but not enough and not for everybody (including perl/php/...)
>
>Another approach might be to store a small trove file per project in the
>committers cvs module, where assumably everybody has access too, and me
>aggregating those.
>
>The (XML) structure being required would be something like:
>
><project name="">
> <site uri=""/>
> <description></description>
> <keyword name=""/>
> (<federation name=""/>)
></project>
>
>Projects can contain projects, and can be grouped into 'federations', aka
>httpd, xml, jakarta and others. I tried to set up the stylesheets to do
>something meaningful without many strict requirements on the hierarchy of
>the datafile.
>
>Anyway, this is just a heads-up. I don't know where I could move it too
>since it falls a bit in-between projects. The presentation is by no means
>finished, but should be easy to tweak. I can nurture this thing on my own
>on my own server, but if other people would be interested in playing
>along, just gimme a yell.
>
>Cheers,
>
></Steven>
>--
>Steven Noels http://outerthought.org/
>Outerthought - Open Source, Java & XML Competence Support Center
>Read my weblog at http://radio.weblogs.com/0103539/
>stevenn at outerthought.org stevenn at apache.org
Re: Apache Trove
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
Nice. Very interesting.
Dw.
On Sun, 8 Dec 2002, Steven Noels wrote:
> Hi all,
>
> due to the recent and upcoming reorgs in terms of the
> 'federation'/project/subproject structure and the assumed increased
> difficulty for people finding their way around ASF projects, I have been
> playing around with a draft 'trove' application, which isn't much more
> than some XML & XSLT glued together, running on top of Cocoon.
>
> http://cocoon.cocoondev.org/mount/trove/ (warning: data entry hasn't
> been completed yet)
>
> This 'app' runs on top of a very free-formed XML document currently:
>
> <trove>
> <federation name="XML">
> <keyword name="XML"/>
> <site uri="http://xml.apache.org/"/>
> <description>[...]</description>
> <project name="FOP">
> <keyword name="XSL-FO"/>
> <keyword name="Java"/>
> <site uri="http://xml.apache.org/fop/"/>
> </project>
> </federation>
> <project name="BCEL">
> <site uri="http://jakarta.apache.org/bcel/"/>
> <description>[...]</description>
> <federation name="Jakarta"/>
> <keyword name="Java"/>
> </project>
>
> [...]
>
> and should be maintained by the respective project communities. I
> already went searching what Gump could offer me in terms of available
> data, but Gump is for obvious reasons limited to Jakarta and XML (Java)
> projects. Adding the Gump people to add a 'keyword' element to their
> descriptors wouldn't cause too much harm, but the problem is that I also
> store the project hierarchy in my data file, and this is slightly
> orthogonal to Gump's structure. So adding extra data to Gump's
> descriptors would help, but not enough and not for everybody (including
> perl/php/...)
>
> Another approach might be to store a small trove file per project in the
> committers cvs module, where assumably everybody has access too, and me
> aggregating those.
>
> The (XML) structure being required would be something like:
>
> <project name="">
> <site uri=""/>
> <description></description>
> <keyword name=""/>
> (<federation name=""/>)
> </project>
>
> Projects can contain projects, and can be grouped into 'federations',
> aka httpd, xml, jakarta and others. I tried to set up the stylesheets to
> do something meaningful without many strict requirements on the
> hierarchy of the datafile.
>
> Anyway, this is just a heads-up. I don't know where I could move it too
> since it falls a bit in-between projects. The presentation is by no
> means finished, but should be easy to tweak. I can nurture this thing on
> my own on my own server, but if other people would be interested in
> playing along, just gimme a yell.
>
> Cheers,
>
> </Steven>
>
Re: Apache Trove
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
Nice. Very interesting.
Dw.
On Sun, 8 Dec 2002, Steven Noels wrote:
> Hi all,
>
> due to the recent and upcoming reorgs in terms of the
> 'federation'/project/subproject structure and the assumed increased
> difficulty for people finding their way around ASF projects, I have been
> playing around with a draft 'trove' application, which isn't much more
> than some XML & XSLT glued together, running on top of Cocoon.
>
> http://cocoon.cocoondev.org/mount/trove/ (warning: data entry hasn't
> been completed yet)
>
> This 'app' runs on top of a very free-formed XML document currently:
>
> <trove>
> <federation name="XML">
> <keyword name="XML"/>
> <site uri="http://xml.apache.org/"/>
> <description>[...]</description>
> <project name="FOP">
> <keyword name="XSL-FO"/>
> <keyword name="Java"/>
> <site uri="http://xml.apache.org/fop/"/>
> </project>
> </federation>
> <project name="BCEL">
> <site uri="http://jakarta.apache.org/bcel/"/>
> <description>[...]</description>
> <federation name="Jakarta"/>
> <keyword name="Java"/>
> </project>
>
> [...]
>
> and should be maintained by the respective project communities. I
> already went searching what Gump could offer me in terms of available
> data, but Gump is for obvious reasons limited to Jakarta and XML (Java)
> projects. Adding the Gump people to add a 'keyword' element to their
> descriptors wouldn't cause too much harm, but the problem is that I also
> store the project hierarchy in my data file, and this is slightly
> orthogonal to Gump's structure. So adding extra data to Gump's
> descriptors would help, but not enough and not for everybody (including
> perl/php/...)
>
> Another approach might be to store a small trove file per project in the
> committers cvs module, where assumably everybody has access too, and me
> aggregating those.
>
> The (XML) structure being required would be something like:
>
> <project name="">
> <site uri=""/>
> <description></description>
> <keyword name=""/>
> (<federation name=""/>)
> </project>
>
> Projects can contain projects, and can be grouped into 'federations',
> aka httpd, xml, jakarta and others. I tried to set up the stylesheets to
> do something meaningful without many strict requirements on the
> hierarchy of the datafile.
>
> Anyway, this is just a heads-up. I don't know where I could move it too
> since it falls a bit in-between projects. The presentation is by no
> means finished, but should be easy to tweak. I can nurture this thing on
> my own on my own server, but if other people would be interested in
> playing along, just gimme a yell.
>
> Cheers,
>
> </Steven>
>
RE: Apache Trove
Posted by Robert Koberg <ro...@koberg.com>.
Hi Steven,
interesting choice of the word 'trove'
--- something valuable discovered or found
--- a collection of valuable objects
----- but nothing is discovered - it is already known, of course it is a
collection of valuable objects. The history of the word is from the french verb
'trover = "to find".' But there is nothing to find. It is already known.
but if it is a list of all projects, why not use 'grove'
-- my dictionary says grove = a small wood or stand of trees without dense
undergrowth
----- a clean forrest?
semantic pedantics :)
-Rob
> -----Original Message-----
> From: Steven Noels [mailto:stevenn@outerthought.org]
> Sent: Sunday, December 08, 2002 2:30 PM
> To: community@apache.org
> Cc: alexandria-dev@jakarta.apache.org; forrest-dev@xml.apache.org
> Subject: Apache Trove
>
>
> Hi all,
>
> due to the recent and upcoming reorgs in terms of the
> 'federation'/project/subproject structure and the assumed increased
> difficulty for people finding their way around ASF projects, I have been
> playing around with a draft 'trove' application, which isn't much more
> than some XML & XSLT glued together, running on top of Cocoon.
>
> http://cocoon.cocoondev.org/mount/trove/ (warning: data entry hasn't
> been completed yet)
>
> This 'app' runs on top of a very free-formed XML document currently:
>
> <trove>
> <federation name="XML">
> <keyword name="XML"/>
> <site uri="http://xml.apache.org/"/>
> <description>[...]</description>
> <project name="FOP">
> <keyword name="XSL-FO"/>
> <keyword name="Java"/>
> <site uri="http://xml.apache.org/fop/"/>
> </project>
> </federation>
> <project name="BCEL">
> <site uri="http://jakarta.apache.org/bcel/"/>
> <description>[...]</description>
> <federation name="Jakarta"/>
> <keyword name="Java"/>
> </project>
>
> [...]
>
> and should be maintained by the respective project communities. I
> already went searching what Gump could offer me in terms of available
> data, but Gump is for obvious reasons limited to Jakarta and XML (Java)
> projects. Adding the Gump people to add a 'keyword' element to their
> descriptors wouldn't cause too much harm, but the problem is that I also
> store the project hierarchy in my data file, and this is slightly
> orthogonal to Gump's structure. So adding extra data to Gump's
> descriptors would help, but not enough and not for everybody (including
> perl/php/...)
>
> Another approach might be to store a small trove file per project in the
> committers cvs module, where assumably everybody has access too, and me
> aggregating those.
>
> The (XML) structure being required would be something like:
>
> <project name="">
> <site uri=""/>
> <description></description>
> <keyword name=""/>
> (<federation name=""/>)
> </project>
>
> Projects can contain projects, and can be grouped into 'federations',
> aka httpd, xml, jakarta and others. I tried to set up the stylesheets to
> do something meaningful without many strict requirements on the
> hierarchy of the datafile.
>
> Anyway, this is just a heads-up. I don't know where I could move it too
> since it falls a bit in-between projects. The presentation is by no
> means finished, but should be easy to tweak. I can nurture this thing on
> my own on my own server, but if other people would be interested in
> playing along, just gimme a yell.
>
> Cheers,
>
> </Steven>
> --
> Steven Noels http://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> Read my weblog at http://radio.weblogs.com/0103539/
> stevenn at outerthought.org stevenn at apache.org
>