> The shareable thingies that I care the most about are typically smaller
> than a framework. In fact, dependency on a particular framework (of any
> nature) is probably detrimental to reuse.
>
> Example 1: the connection pool in Struts is 2 classes, with
> dependencies only on the JDK and the JDBC 2.0 Optional Package APIs. It
> uses JavaBeans property setters for configuration, so you'd write your
> own mechanism for initialization (using whatever approach your framework
> favors), but the pool itself doesn't mandate anything.
I think that is the ideal case for shared components :
- support existing standards, if that is applicable (javax.sql.DataSource
for a DB pool)
- no dependency on a larger framework
The Struts db pool looks like it's the best one overall.
I would be willing to contribute (if someone is interested, of course) the
Slide HTTP client library core to the library / agora project if there are
some very strict publicized guidelines about API and behavior changes (I
have quite a bit of code which depends on the library). I would suggest
asking for a vote with no -1 prior to any change which would break source
compatibility.
I didn't follow the whole discussion so this may have been discussed already
(Costin just convinced me I should join the effort).
I would vote +1 for the Agora name.
> +1 on fine-grained JAR files -- this is one of the better parts of the
> CPAN approach.
+1 too.
> When we get down to process details, I'm going to recommend that we
> record dependencies in the MANIFEST.MF file of our JAR files, in the
> manner recommended in the JDK 1.3 documentation describing "system
> extensions". In suitable environments (for instance, any servlet
> container that implements 2.3), the container will even do this checking
> for you.
Sure, but let's not seal the JARs ;-)
> > The Library project should specifically steer clear of
> > developing grand frameworks. That kind of development
> > is much more appropriate for full-blown subprojects
> > like Turbine, Struts, and Avalon.
+1.
Remy
