Return-Path: Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 64828 invoked from network); 31 May 2000 16:16:54 -0000 Received: from mail.activcard.com (HELO hub1.hub.activcard.com) (207.93.240.18) by locus.apache.org with SMTP; 31 May 2000 16:16:54 -0000 Received: from usexchg1.activcard.com (USEXCHG1 [192.168.133.9]) by hub1.hub.activcard.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id KKPMGN1Q; Wed, 31 May 2000 09:17:23 -0700 Received: by USEXCHG1 with Internet Mail Service (5.5.2448.0) id ; Wed, 31 May 2000 09:13:52 -0700 Message-ID: From: Jean-Noel Gadreau To: "'ant-dev@jakarta.apache.org'" Subject: RE: Platform independend classpath in build.xml? Date: Wed, 31 May 2000 09:13:49 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFCB1B.35F5F8F2" X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFCB1B.35F5F8F2 Content-Type: text/plain; charset="windows-1252" I am still new to Ant, so I did not know about these classes. Sounds good. I will try to have a look at it when I have some more time. Thanks Jean-Noel -----Original Message----- From: Stefan Bodewig [mailto:bodewig@bost.de] Sent: Wednesday, May 31, 2000 6:11 AM To: ant-dev@jakarta.apache.org Subject: Re: Platform independend classpath in build.xml? >>>>> "JG" == Jean-Noel Gadreau writes: JG> Moreover, I think the same problem will arise for other path JG> (like for .DLL or .so needed by some JNI classes for JG> instance). How about defining a task that is able to add path to JG> a list in a crossplatform way, which would not be limited just to JG> CLASSPATH. This way, if you need to specify PATH (to find a tool JG> or something), we could use the same class. Please let's not reinvent the wheel. Thomas Haas has built what you're describing and has sent it as part of our JUnit task. The current implementation consists of two classes Path and PathElement. Citing from his javadocs - deHTMLed for readability: /** * This object represents a path as used by CLASSPATH or PATH * environment variable. * * It consists of a list of PathElement and Path * objects. It is used to represent a classpath or path like nested parameters * in task definitions: * * *
* * * * * * *
* * * The object implemention sometask must provide a method called * createSomepath which returns an instance of Path. * Nested path definitions are handled by the Path object and must be labeled * path.

* * The path element takes a parameter path which will be parsed * and split into PathElement objects. It will usually be used * to define a path from an environment variable. * * @author Thomas.Haas@softwired-inc.com */ This class takes care of all the platform dependent stuff. using this and nested elements wherever path like structures are needed should suffice. Thomas is on vacation AFAIK but I hope he will get back to this soon. Thomas is a commiter so he can make these changes quicker than I could put together the necessary patch. Stefan ------_=_NextPart_001_01BFCB1B.35F5F8F2 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable RE: Platform independend classpath in build.xml?

I am still new to Ant, so I did not know about these = classes. Sounds good. I will try to have a look at it when I have some = more time.

Thanks
Jean-Noel

-----Original Message-----
From: Stefan Bodewig [mailto:bodewig@bost.de]
Sent: Wednesday, May 31, 2000 6:11 AM
To: ant-dev@jakarta.apache.org
Subject: Re: Platform independend classpath in = build.xml?


>>>>> "JG" =3D=3D Jean-Noel = Gadreau <jngadreau@activcard.com> writes:

 JG> Moreover, I think the same problem will = arise for other path
 JG> (like for .DLL or .so needed by some = JNI classes for
 JG> instance). How about defining a task = that is able to add path to
 JG> a list in a crossplatform way, which = would not be limited just to
 JG> CLASSPATH. This way, if you need to = specify PATH (to find a tool
 JG> or something), we could use the same = class.

Please let's not reinvent the wheel. Thomas Haas has = built what you're
describing and has sent it as part of our JUnit = task.

The current implementation consists of two classes = Path and
PathElement. Citing from his javadocs - deHTMLed for = readability:

/**
 * This object represents a path as used by = CLASSPATH or PATH
 * environment variable.
 *
 * It consists of a list of = <code>PathElement</code> and = <code>Path</code>
 * objects. It is used to represent a classpath = or path like nested parameters
 * in task definitions:
 *
 * <code>
 * <sometask><br>
 *   <somepath>
 *     <element = location=3D"/path/to/file.jar" />
 *     <element = path=3D"/path/to/file2.jar:/path/to/class2;/path/to/class3" = />
 *     <element = location=3D"/path/to/file3.jar" />
 *     <element = location=3D"/path/to/file4.jar" />
 *   </somepath>
 * </sometask><br>
 * </code>
 *
 * The object implemention = <code>sometask</code> must provide a method called
 * <code>createSomepath</code> = which returns an instance of <code>Path</code>.
 * Nested path definitions are handled by the = Path object and must be labeled
 * = <code>path</code>.<p>
 *
 * The path element takes a parameter = <code>path</code> which will be parsed
 * and split into = <code>PathElement</code> objects. It will usually be = used
 * to define a path from an environment = variable.
 *
 * @author Thomas.Haas@softwired-inc.com
 */

This class takes care of all the platform dependent = stuff.

using this and nested elements wherever path like = structures are
needed should suffice.

Thomas is on vacation AFAIK but I hope he will get = back to this
soon. Thomas is a commiter so he can make these = changes quicker than I
could put together the necessary patch.

Stefan

------_=_NextPart_001_01BFCB1B.35F5F8F2--