You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by robert burrell donkin <ro...@blueyonder.co.uk> on 2003/09/29 13:18:46 UTC
[digester][PROPOSAL] optional dependencies
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).
i'm not sure whether it would be best to distribute a single digester jar
or whether we should ship two jars.
your comments please :)
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester][PROPOSAL] optional dependencies
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Monday, September 29, 2003, at 11:17 PM, Simon Kitching wrote:
<snip>
> 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.
maybe we could group together on the basis of the dependency. certainly,
we'd need to make the dependencies very clear in the javadocs.
> 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.
that's life :)
it's usually possible to factor the abstraction so that the optional
dependency is simply one implementation. if this is done then it's
possible to include hooks in the core without adding the dependencies
(which remain in the adapter classes which can be plugged in). for example,
see RegexRules and RegexMatcher.
> (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'd prefer a single set of javadocs even if we ship two jars.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester][PROPOSAL] optional dependencies
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Monday, September 29, 2003, at 11:17 PM, Simon Kitching wrote:
<snip>
> 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.
maybe we could group together on the basis of the dependency. certainly,
we'd need to make the dependencies very clear in the javadocs.
> 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.
that's life :)
it's usually possible to factor the abstraction so that the optional
dependency is simply one implementation. if this is done then it's
possible to include hooks in the core without adding the dependencies
(which remain in the adapter classes which can be plugged in). for example,
see RegexRules and RegexMatcher.
> (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'd prefer a single set of javadocs even if we ship two jars.
- robert
Re: [digester][PROPOSAL] optional dependencies
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [digester][PROPOSAL] optional dependencies
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
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
Re: [digester][PROPOSAL] optional dependencies
Posted by "Craig R. McClanahan" <cr...@apache.org>.
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.
+1.
The core is currently dependent on beanutils, collections, and logging.
That's a list I would prefer not to extend.
>
> 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).
+1, parallel to the new examples directory.
>
> i'm not sure whether it would be best to distribute a single digester
> jar or whether we should ship two jars.
Ant ended up with two jars in the same situation, and I think that's
probably a reasonable approach.
>
> your comments please :)
>
> - robert
Craig
Re: [digester][PROPOSAL] optional dependencies
Posted by "Craig R. McClanahan" <cr...@apache.org>.
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.
+1.
The core is currently dependent on beanutils, collections, and logging.
That's a list I would prefer not to extend.
>
> 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).
+1, parallel to the new examples directory.
>
> i'm not sure whether it would be best to distribute a single digester
> jar or whether we should ship two jars.
Ant ended up with two jars in the same situation, and I think that's
probably a reasonable approach.
>
> your comments please :)
>
> - robert
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org