There is also an issue on windows of a classpath size. I know i have
been burnt by this before.
David Van Couvering wrote:
Good points, although I am very wary of a huge long set of jars in the
classpath, an invitation to confusion and difficulty for our users.
Couldn't we have a "third-party.jar" that has all the third-party
classes?
Thinking about this further, there is also the issue of avoiding
version mismatch and jar-file-stomping when Derby is installed into a
larger milieu of software, and a lot of this common stuff like JMX is
in use by other projects? I know how we deal with this at Sun, but
how is this managed in the open source world? Or is this why you need
open source integrator companies?
David
Jeremy Boynes wrote:
David Van Couvering wrote:
I like code reuse rather than having to write and maintain our own
work. That's a big pull of open source is building from what others
have done. I vote for including the libraries in derby.jar, rather
than having jar-file explosion.
The reuse aspect is really why I want to explore this.
Re-implementing everything in Derby may be OK for simple stuff like
command line parsing but will be problematic for more complex things
like JMX.
The open community aspect should not be underestimated - a project
that refuses to even consider other open source solutions will very
rapidly become isolated.
I would not recommend bundling things inside derby.jar as that leads
to classes being loaded from unexpected places (e.g. I would not
expect org.apache.commons.cli.Something to come from derby.jar).
One concern is making sure we include third-party stuff with
compatible licensing. What is the process for making we don't get
into some legal tangle?
The ASF has strict policies on what can be used by ASF projects to
ensure that the final distribution is compatible with the Apache
License. This basically comes down to only being able to use other
software if its license is no more restrictive than the Apache License.
--
Jeremy
