db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Re: Modular build, was: VOTE: Approach for sharing code
Date Thu, 15 Sep 2005 23:12:38 GMT
Daniel John Debrunner wrote:
> But as an aside, I once downloaded an open source project, which then
> instructed me to fetch a further five or six common Apache libraries,
> either at a specific version numbers or higher than a given version. I
> followed all this correctly, set up the classpath and immediately got an
> abstract method error.
> That's an example of badly managed common versions, and I do not wish
> Derby to fall into the same trap.
> 1) The ease to download goes away in that case where I had to spend time
> finding and downloading N additional jars.
> 2) The ease to use goes away when I have to modify the classpath to add
> six or seven jars.
> 3) The desire to use goes away completely when having followed the
> instructions the product fails.
> This e-mail isn't to solict ideas on how specifics can be solved, but to
>  understand that Derby's ease of use in all aspects is one of its
> greatest strengths, we cannot forget that, or lose it.

And how many open source projects have you downloaded or used without 
such issues? Please don't taint this from one bad experience.

For build-time dependencies, many of these issues are addressed by Maven 
which automatically downloads the dependencies specified in the project. 
  This would be an immediate solution to the problem raised on the 
recent junit thread.

For run-time dependencies, these can be addressed with solutions like 
1) for Derby as a standalone server, we can have one executable jar that
    loads all dependencies from an internal classloader (no classpath
    issues at all)
2) for Derby as a library, the application embedding us should be using
    the same type of solution and we would fit in there just like
    clogging. With it controlling the classpath there is nothing for the
    user to (mis-)configure

All of these lead to a simple end-user experience - whether they are 
trying to build from source, use a standalone server, or embed inside 
another application.


View raw message