Re: The good ol' JUnit problem

[Mark Lybarger <ml...@gmail.com>]

Jon,

This is a similar issue with the xalan classes in the 1.4 jdk. 
they're exposed directly by sun (and other jvm's) as org.apache.*. 
basically they just imported xalan and possibly other apache classes
into the jvm.  this gives your entire application (jvm) one chance to
override the version used by using the extensions folder.  not very
good when you have multiple web applications that each need a specific
version of xalan or what not.  i believe sun has fixed this issue in
1.5 jdk's with a method similar to what i did to get optional ant
tasks work w/o modifying the target environment.

here's what i did when i needed the scp task and found out the only
way to use ant's tasks was to modify the target environment to use
them (ie, ant/lib folder, user's ~/.lib folder, ant_opts env var,
etc).  i grabbed the ant source, and basically refactored the classes
for the tasks i needed to be in a different name space (different
package structure).  i believe i used external.org.apache.ant.* as the
base package structure.  next, the actual task names had to be
slightly modified.   i think this is in a .properties file or some
such.  i used m_scp i believe.  there's probably some magic you can do
with xml that will allow your builds to still use <scp>, but i chose
to explicitly indicate that the tasks were slightly modified from ant
distributed tasks.    thus, in my build.xml, i would have <m_scp> with
the same syntax as the <scp> task.  it's a bit if work, but it allows
you to have junit and others defined completely outside of a core ant
distribution.

it's nice that ant provides tasks for things they can't or won't
bundle with their distribution, but i would really like to see ant
distributed at least with the same tasks able to be defined
externally.  i'd be more than willing to help with this.  what i would
envision is ant providing in addition to it's ant/lib folder, a
ant/lib/external folder or perhaps an ant/external/lib folder that
contains the same tasks in an external.org.apache name space.  this
external lib folder would not be loaded by the default ant
classloader, but would be available for users to include libs as
needed.    i don't like much the <scp> .vs. <m_scp> issue, and it
would be very nice if both taskdefs could define a <scp> or <junit>
task w/o any collision.  i'm not sure how that would work.

good luck Jon!
~mark

On 10/28/05, Jon Skeet <Jo...@clearswift.com> wrote:
> Currently, our build uses a modified distribution of Ant - all the
> optional libraries we need are bundled into the lib directory. We use a
> similarly modified version of Eclipse (i.e. the Ant part has the same
> changes made).
>
> Needless to say, this is somewhat suboptimal. I want to move to a system
> where we can change versions of Ant and Eclipse easily, without having
> to perform the modifications again. With imports, this isn't too hard
> (because I can have our own "lib" directory with a taskdefs.xml project
> which can be imported from any build which needs them). I believe this
> should solve our problems for everything *except* for Junit.
>
> None of the solutions in the FAQ seem very satisfactory to me,
> unfortunately - they're not upgrade-friendly. Here are my ideas:
>
> 1) Copy the JUnit jar file into ant/lib if it's not there already, and
> document the fact that tests won't work first time.
> 2) Remove ant-junit.jar from ant/lib if it's there, and document the
> fact that tests won't work the first time.
> 3) Tell everyone to have an ANT_OPTS environment variable of "-lib xxx"
>
> Again, none of these are terribly appealing, but at least they don't
> require changing stock installations beyond what is possible within a
> build file itself. Of course, they *do* require knowing where the
> ant/lib directory is - is there a recommended way of knowing that?
>
> Possibly modifying the stock Ant just to remove ant-junit.jar is the way
> forward. (I prefer this to adding the junit jar file to ant/lib, as that
> makes it harder to change versions of Junit.)
>
> For Eclipse, I can modify our "template workspace" to give Ant an extra
> global entry to the JUnit jar file. That shouldn't be too bad.
>
> Jon Skeet
> Senior Software Engineer
> CLEARSWIFT
> The MIMEsweeper Company
>
> DDI:               +44 (0) 1189  038  109
> Mobile:           +44 (0) 7970 158 865
> Switchboard:   +44 (0) 1189  038  903
> Fax:               +44 (0) 1189  039  000
> Web: www.clearswift.com
>
>
> Clearswift monitors, controls and protects all its messaging traffic in compliance with its corporate email policy using Clearswift products.
> Find out more about Clearswift, its solutions and services at http://www.clearswift.com
>
> This communication is confidential and may contain privileged information intended solely for the named addressee(s). It may not be used or disclosed except for the purpose for which it has been sent. If you are not the intended recipient, you must not copy, distribute or take any action in reliance on it. Unless expressly stated, opinions in this message are those of the individual sender and not of Clearswift. If you have received this communication in error, please notify Clearswift by emailing support@clearswift.com quoting the sender and delete the message and any attached documents. Clearswift accepts no liability or responsibility for any onward transmission or use of emails and attachments having left the Clearswift domain.
>
> This footnote confirms that this email message has been swept by MIMEsweeper for Content Security threats, including computer viruses.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org