commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <si...@ecnetwork.co.nz>
Subject Re: [digester][PROPOSAL] optional dependencies
Date Mon, 29 Sep 2003 22:17:59 GMT
On Mon, 2003-09-29 at 23:18, robert burrell donkin wrote:
> i think that it's important that digester retains the smallest possible 
> set of core dependencies. but i'd like to be able to supply users (who 
> need this functionality) with more exotic toys such as regular expression 
> based pattern matchers based on ORO or regexp. i think that the best way 
> to go forward would be adopt the strategy that ant uses and separate out 
> core dependencies from optional ones. the basic, default configuration 
> should run with only the core dependencies.
> 
> i'd like to concentrate these optional dependencies under the 
> org.apache.commons.digester.optional package. i'd also like to structure 
> the build so that no class in core can depend on any in optional. i'd also 
> like to put these classes into a src/optional-java directory (rather than 
> src/java).

Sounds like a fine idea to me.

Of course the optionals module will end up with dependencies like:
  optional-feature-a requires alibs.jar
  optional-feature-b requires blibs.jar

So someone who wants optional-feature-a has to either put all
dependencies of digester-optional.jar (alibs.jar AND blibs.jar) in their
path, or try to figure out whether using just alibs.jar is sufficient.

Still, I guess this is how ant's optional package works anyway, and it
seems to be workable.

> i'm not sure whether it would be best to distribute a single digester jar 
> or whether we should ship two jars.

+1 to two jars. 

It would be reassuring to know that when using features from "core"
Digester, that no unexpected libs will be required.

Once someone starts using optional.jar, then they are "deliberately"
entering dependency hell, where they need to figure out which libs to
include based upon which optional features they intend to use. Or just
include *all* dependencies of optional.

I guess if each optional feature is in its own package, eg
  org.apache.commons.digester.optional.ororules
then the package.html for that module can document the libs required for
that feature. A user of feature "ororules" can therefore check the
package description for that feature to find the dependencies.

Once concern: if "core" and "optional" are separated, then:
(a) 
There can't be any factory methods on Digester for optional rule
classes. This is unfortunate, as most users won't know that a Rule
exists if it doesn't have a factory method on Digester.
(b)
If the javadoc for "core" and "optional" are separated, then it will be
even more difficule for users to discover what optional features exist.

I don't know how Ant resolves this; their javadocs aren't available
online as far as I can see. They *have* written a manual which describes
both the core and optional features so that users can see what is
available in optional. I don't think we want to go to that length for
Digester though :-)

Regards,

Simon



Mime
View raw message