Cocoon, Turbine, duplication of efforts

["Diethelm Guallar, Gonzalo" <Go...@sonda.com>]

Another innocent question (believe me, I'm not trying
to start a flame war or anything like that).

I have seen how Cocoon recently has incorporated the
Turbine-based DB connection pool. Rather than taking
this functionality off Turbine, I would think, from a
software engineering point of view, that it would make
more sense to place this component at a lower-level
library, available for use to anything that needs it.

In this sense, could Cocoon (or parts of it) be implemented
on top of Turbine? Or maybe could Turbine (or parts of
it) be implemented on top of Cocoon? Maybe the pool
should be moved to Avalon, and have Turbine use it
from there? Maybe I'm just crazy?

On the other hand, maybe the history of how Turbine and
Cocoon were developed explains the duplication in effort?
I'm just trying to understand where every piece fits in
the large picture.

BTW, when I first started looking into Java and the Apache
project, I made a list of all the projects that I found
on the Apache site(s). The list has 30 (yes, thirty!)
different projects. This doesn't make it easy for a beginner
to get their feet wet into the Java waters... Just for your
entertainment, here is the list (compiled two months ago;
some, but not many, of the products listed here may not have
anything to do with Apache):

Jyve
JMeter
Alexandria
JSSI
Ant
Regexp
Xerces
Slide
Xalan
Struts
Turbine
Taglibs
ECS
Watchdog
Village
SPFC
Jetspeed
JBoss
Tomcat
Enhydra
FreeMarker
Xang
Cocoon
FOP
PicoServer
James
Avalon
OpenEJB
JServ

and, of course, the Jakarta project, which is an umbrella for
some of the projects mentioned above... I understand much better
now what each of these is, but it IS a daunting proposition for
a beginner looking for Java-based development tools and
architecture to stare at this list.

Anyway, thanks in advance for any comments.


-- 
Gonzalo A. Diethelm
gonzalo.diethelm@sonda.com
If this mail is in HTML format, blame Exchange Server: Q222508

Re: Cocoon, Turbine, duplication of efforts

[Stefano Mazzocchi <st...@apache.org>]

> "Diethelm Guallar, Gonzalo" wrote:
> 
> Another innocent question (believe me, I'm not trying
> to start a flame war or anything like that).

No problem.
 
> I have seen how Cocoon recently has incorporated the
> Turbine-based DB connection pool. 

Yes.

> Rather than taking
> this functionality off Turbine, I would think, from a
> software engineering point of view, that it would make
> more sense to place this component at a lower-level
> library, available for use to anything that needs it.

You are totally right.
 
> In this sense, could Cocoon (or parts of it) be implemented
> on top of Turbine? Or maybe could Turbine (or parts of
> it) be implemented on top of Cocoon? Maybe the pool
> should be moved to Avalon, and have Turbine use it
> from there? Maybe I'm just crazy?

No, you're not.

In a perfect world, you would have all projects based on the component
model created by Avalon and working together smoothly without having one
project to be placed on top of parts of another.

But refactoring is something that takes time.

Anyway, don't worry: we are fully aware of this :)                       
 
> On the other hand, maybe the history of how Turbine and
> Cocoon were developed explains the duplication in effort?

Yep.

> I'm just trying to understand where every piece fits in
> the large picture.

Avalon is should be below everything.
 
> BTW, when I first started looking into Java and the Apache
> project, I made a list of all the projects that I found
> on the Apache site(s). The list has 30 (yes, thirty!)
> different projects. This doesn't make it easy for a beginner
> to get their feet wet into the Java waters... Just for your
> entertainment, here is the list (compiled two months ago;
> some, but not many, of the products listed here may not have
> anything to do with Apache):

let me explain
 
> Jyve -> Turbine web-app
> JMeter -> GUI application (standalone)
> Alexandria -> commang line application (partially based on Cocoon)
> JSSI -> servlet (standalone)
> Ant -> command line application (standalone)
> Regexp -> library (standalone)
> Xerces -> library (standalone)
> Slide -> servlet (standalone)
> Xalan -> library (standalone)
> Struts -> servlet library (standalone)
> Turbine -> servlet (standalone)
> Taglibs -> JSP library (standalone)
> ECS -> library (standalone)
> Watchdog -> command line application (standalone)
> SPFC -> servlet library (standalone)
> Jetspeed -> based on *both* Turbine and Cocoon
> Tomcat -> server application (standalone)
> Xang -> servlet (standalone)
> Cocoon -> servlet and command line (based on Xerces, Xalan, Fop, Turbine-pool)
> FOP -> command line application / library (standalone)
> PicoServer -> server (will be based on Avalon)
> James -> server (based on Avalon)
> Avalon -> server framework (standalone)
> JServ -> server application (standalone)

And these are *not* ASF projects

> JBoss (not an ASF project)
> Enhydra (not an ASF project)
> FreeMarker (not an ASF project)
> Village (not an ASF project)
> OpenEJB (not an ASF project)

and we have no absolute control over them.
 
> and, of course, the Jakarta project, which is an umbrella for
> some of the projects mentioned above... I understand much better
> now what each of these is, but it IS a daunting proposition for
> a beginner looking for Java-based development tools and
> architecture to stare at this list.

:)

I'll try to give you a better picture:

             Avalon <- Xerces
               |
               v
         James, Tomcat
               |
               v
 Xerces, Xalan, FOP, Turbine, Cocoon 
               |
               v
         JetSpeed, Jyve
                       
> Anyway, thanks in advance for any comments.

You are welcome.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------