Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <4DF8A819.705@oracle.com>
Date: Wed, 15 Jun 2011 14:39:53 +0200
From: Kristian Waagan <kristian.waagan@oracle.com>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US;
 rv:1.9.2.15) Gecko/20110412 Thunderbird/3.1.9
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: Refactoring ant junit target to automatically set classpath
References: <4DF0BCED.7000700@oracle.com>
In-Reply-To: <4DF0BCED.7000700@oracle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.


-- 
Kristian

> --> 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
>
>
> --> WHO WILL BE AFFECTED
> 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.
>
>