At 08:51 21/2/01 -0500, Geir Magnusson Jr. wrote:
>Peter Donald wrote:
>>
>> Hi,
>>
>> As the process seems to have slowed and every one seems to be talking about
>> different approach maybe we should look at exactly what we want. There is
>> three different things that people are talking about
>>
>> 1. component repository (ie ToolForge+CJAN)
>> 2. vetted/tested/approved components (ie Avalon+CJAN)
>> 3. base util (Something similar to AUT - Apache Utility Toolkit).
>
>I have a little trouble seeing the distinction between 2 and 3.
well the size/applicability I guess is where the difference is.
3 would contain elements such as
* CascadingThrowable/Exception support that every project has
* IOUtil that almost every project has
* FileUtil
* Exception util
* Stack introspector stuff
* Command line parameter parser
etc
ie All the basic stuff that any large project aquires overtime and are
relatively stable.
(2) would contain stuff like a DB pool/connection manager/action
router/action interface/etc
>> I am happy to work on (3) and are familiar enough with both Turbine and
>> Avalon bases that I could help extract the code from them that was
>> necessary. I already work on (2) ;)
>
>That would be avalon? :)
yaah ;)
>I am happy to join in on Avalon, as long as I was sure that that the
>charter allowed for the things I want to do. Specifically, I am looking
>to make mini-projects out of common software elements (like a conneciton
>pool, XML config utilities, etc) that aren't required to live in a
>framework (but can easily be used by any framework), is identifiable and
>buildable as a separate unit (like being able to build/download a
>Jakarta DBConn Pool w/o dragging endless amounts of unrelated stuff
>with it), etc. Given the recent changes I saw regarding the maillists
>and all the sublists, my understanding of Avalon is still a bit vague.
>I am following it trying to figure it out, though :)
You may want to hold off till end of week as we are still in progress with
the move ;)
>> So if there is enough supporters from other projects do you think it would
>> be useful to start AUT now using the standard apache model? For (1) I think
>> there needs to be a few issues resolved. Thoughts?
>
>What would 'AUT' be?
Apache Utility Toolkit
>
>>
>> Another model no one has mentioned is the "gatherer" style. ie Code remains
>> in whatever CVS it is in now but there is another process to gather
>> components from all the different places and publishes them?
>>
>> So you would have an XML descriptor for each project that lists all
>> sub-products. So if you wanted digester from struts, the connection pool
>> from turbine and the feedReader from jetspeed you just write your own
>> script. This script would indicate your dependencies. During build these
>> dependencies are sucked from CJAN/whatever and placed in lib directory. In
>> many ways this can draw on and complement gump. Thoughts?
>
>This sounds like a great thing for use within Jakarta projects, but I
>still don't think it solves the problem of making things easily
>available, identifiable, documented, etc to outside users, like all
>other jakarta projects have a deliverable available for outside users.
true - that would require a bit more work ;)
>The other issue is that it wouldn't be unexpected if those sub-products
>you mentioned changed over time as the needs of the owning project
>changed, greatly screwing up life for anyone that use it. The only way
>to avoid that is for the project to 'declare' as sub-projects parts of
>the project code it is willing to support as such, and maintain on an
>ongoing basis.
right. And declare specific versions as well - so you can retrieve version
3.2.1 or 1.2.3 or perhaps 2.1.2 etc.
>That would work if you could get projects to do it, but given that we
>have duplicated functionality among the Jakarta projects, I think it
>might be better if we consolodated some of that code, giving each
>project the freedom to use it. (If projects don't use it, we screwed
>up...)
right - the consolidation etc is what Avalon tried to do but it requires
supporters within each project to work.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
