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. I would
assume that whatever is in 3 has been vetted, tested and approved, and I
thought 2 was supposed to be base utility elements for server
development.
> 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? :)
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 :)
> 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?
>
> 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.
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.
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...)
Which brings us back to last week... :)
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
