db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <kristian.waa...@oracle.com>
Subject Re: Refactoring ant junit target to automatically set classpath
Date Wed, 15 Jun 2011 12:39:53 GMT
On 09.06.11 14:30, Kristian Waagan wrote:
> Hi all,
> I just uploaded patch with a possible solution for the issue DERBY-4089
> [1], where it is suggested that it should be possible to run the junit
> targets without manually setting the classpath after 'ant all' has been
> run. This suggestion got some pushback by a claim that it would be more
> reasonable to run against the production jars instead of the
> classes-directory.
> Since the patch may affect some people using the junit targets, I'd like
> to get some feedback before I make any changes.

I committed the change on trunk with revision 1136011.


> --> CHANGE
> The classpath for the junit targets will be set automatically, with the
> following preferences:
> o if derby.junit.classpath is specified by the user, don't do anything
> o if derby.junit.classpath is unspecified
> o look for insane jars
> o look for sane jars
> o if either of them are found, set derby.junit.classpath to the empty
> string
> o if no jars are located [2], set derby.junit.classpath to the
> classes-directory
> o additionally, ant will append the user's CLASSPATH environment
> variable to the junit classpath
> Users who have set the CLASSPATH environment variable when running the
> junit-tasks.
> With the changes mentioned, it is likely that what's on the CLASSPATH
> variable will be shadowed by either the jars or the classes-directory.
> To get the same behavior as earlier, you would have to set
> derby.junit.classpath="" when invoking ant.
> --> PROBLEM?
> ant clobber doesn't clean the jars directory ([2])
> If a developer has built the jars, then runs 'ant clobber', modifies the
> code, runs 'ant all', followed by for instance 'ant junit-all', the bits
> tested will be the now outdated jar files.
> I did find this from Dan:
> "I think some of it is history with the product. The Cloudscape jars,
> when it was a closed source product, took a long time to build and the
> process needed a machine with a lot of memeory. This was due to the
> obfuscation process. Thus developers typically did not build the jars,
> only the classes, and the build scripts were set up to reflect that."
> Are there other reasons why 'ant clobber' doesn't delete the jars?
> Can we make 'ant clobber' delete the jars?
> Finally, if the patch is committed, the following targets are basically
> rendered redundant:
> junit-all-codeline-jars
> junit-system-codeline-jars
> junit-single-codeline-jars
> Is anyone using these?
> If not, I'd say we remove them.

View raw message