Mailing-List: contact user-help@ant.apache.org; run by ezmlm
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Ant lib vs. Classpath
Date: Tue, 27 May 2003 10:32:11 -0500
Message-ID: <1AA6971F96FADB4A96CF73E4729B05F1DCAEBB@USEVS012.leinternal.com>
Thread-Topic: Ant lib vs. Classpath
Thread-Index: AcMkY5HN0tZec9B/TIGFW4qsWL+hRgAASHOA
From: "Chappell, Simon P" <Simon.Chappell@landsend.com>
To: "Ant Users List" <user@ant.apache.org>

I feared that that was what you were going to say. That is not going to =
be awfully workable in our corporate locked-down environment. I need =
everything either in the standard ant install or in the project files =
that I check out of my SCM. Hence my two levels of division: =
cross-project or project-only.

Each "standard" workstation will have the exact same version of ant and =
the exact same version of junit.jar (and the j2ee.jar for compilation =
outside of the IDE reasons). Everything else HAS to be in the project.

Simon

>-----Original Message-----
>From: Erik Hatcher [mailto:jakarta-ant@ehatchersolutions.com]
>Sent: Tuesday, May 27, 2003 10:20 AM
>To: Ant Users List
>Subject: Re: Ant lib vs. Classpath
>
>
>We end up with two checkouts, one for the common stuff (including Ant=20
>and common libs) and the actual project.
>
>	Erik
>
>
>On Tuesday, May 27, 2003, at 11:09  AM, Chappell, Simon P wrote:
>> Erik,
>>
>> That's interesting but while I like your definition of things=20
>> "Integral for all Ant usage" I have a problem figuring out=20
>how to mash=20
>> the other two categories into something that will work with my SCM=20
>> system, so that on any Ant configured machine, I can check out a=20
>> project and "just build it" to mangle the Nike phrase.
>>
>> Thoughts?
>>
>> Simon
>>
>>> -----Original Message-----
>>> From: Erik Hatcher [mailto:jakarta-ant@ehatchersolutions.com]
>>> Sent: Tuesday, May 27, 2003 9:52 AM
>>> To: Ant Users List
>>> Subject: Re: Ant lib vs. Classpath
>>>
>>>
>>> I take a slightly different approach than even this.  junit.jar is
>>> special, and thus lives in ANT_HOME/lib (and Ant is in our CVS
>>> repository too).
>>>
>>> I divide things into three buckets:
>>>
>>> - Integral for all Ant usage, with JAR's in ANT_HOME/lib.  This
>>> includes junit.jar, NetComponents.jar, and a few others.
>>> - Specific to each project - in a project lib directory=20
>(although not
>>> just a big bucket of JAR files - its still highly hierarchical under
>>> this directory)
>>> - Common to all projects but not something needed in Ant's classpath
>>> (Struts, and others) - these live in a common directory above all
>>> projects.
>>>
>>> Erik
>>>
>>> On Tuesday, May 27, 2003, at 10:39  AM, Chappell, Simon P wrote:
>>>> I agree with Erik here. We're coming to the end of a workstation
>>>> standardisation project and I have insisted that the correct
>>> place for
>>>> the junit.jar is in the ANT_HOME/lib because of both classloader
>>>> issues and it's cross-project utilisation.
>>>>
>>>> The heuristic that I use is that there are two places where
>>> a JAR file
>>>> can live: the project's lib directory or ANT_HOME/lib. If
>>> the file can
>>>> vary between projects, then it goes in the project's lib
>>> directory. If
>>>> the file does not vary between projects or is cross-project then it
>>>> lives in ANT_HOME/lib.
>>>>
>>>> This has stopped a lot of problems from even being able to occur.
>>>>
>>>> Simon
>>>>
>>>> -----------------------------------------------------------------
>>>> Simon P. Chappell                     simon.chappell@landsend.com
>>>> Java Programming Specialist                      www.landsend.com
>>>> Lands' End, Inc.                                   (608) 935-4526
>>>>
>>>> "Never give in - never, never, never, never, in nothing great or
>>>> small, large or petty, never give in except to convictions of
>>>> honor and good sense." - Sir Winston Churchill
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Erik Hatcher [mailto:jakarta-ant@ehatchersolutions.com]
>>>>> Sent: Tuesday, May 27, 2003 9:25 AM
>>>>> To: Ant Users List
>>>>> Subject: Re: Ant lib vs. Classpath
>>>>>
>>>>>
>>>>> junit.jar is a special case here.  It must be in the same
>>> classloader
>>>>> as the <junit> task itself.  The recommended solution for
>>> junit.jar is
>>>>> to place it in ANT_HOME/lib.  I view junit.jar as such an
>>>>> integral part
>>>>> of all my development needs, that its *home* location is just in
>>>>> ANT_HOME/lib - I don't maintain it anywhere else.
>>>>>
>>>>> 	Erik
>>>>>
>>>>>
>>>>>
>>>>> On Tuesday, May 27, 2003, at 10:07  AM, Matthias P. wrote:
>>>>>> Hi,
>>>>>>
>>>>>> my question is a conceptual one.
>>>>>>
>>>>>> Erik and Steve suggest in their (great) book (thanks for
>>> it!) not to
>>>>>> use the
>>>>>> classpath variable instead of placing libs in the Ant lib
>>>>> directory. I
>>>>>> try
>>>>>> to follow their advice where ever possible, but now i am not
>>>>> sure how
>>>>>> to do
>>>>>> it.
>>>>>>
>>>>>> I am using the ant-contrib and the junit libs. The junit
>>> lib is also
>>>>>> used by
>>>>>> our developers to test local. Both libs are under version
>>> control in
>>>>>> PVCS in
>>>>>> a special libary project. I dont want the both libaries to
>>> be stored
>>>>>> local
>>>>>> in the ant lib directory. They should be identically to=20
>the version
>>>>>> under
>>>>>> source control.
>>>>>>
>>>>>> Is it a good solution to use the classpath here and point to the
>>>>>> directory
>>>>>> where ant is saving the libs after retriving it from PVCS.
>>>>>> Or is it better to retrieve it from PVCS ans store them in
>>>>> the Ant lib
>>>>>> directory?
>>>>>> Or should i store them local on our build mashine and
>>> additonally in
>>>>>> PVCS
>>>>>> and synchronize it manually?
>>>>>>
>>>>>> Thanks,
>>>>>> Matthias
>>>>>>
>>>>>> --=20
>>>>>> +++ GMX - Mail, Messaging & more  http://www.gmx.net +++
>>>>>> Bitte l=E4cheln! Fotogalerie online mit GMX ohne eigene Homepage!
>>>>>>
>>>>>>
>>>>>>
>>>=20
>---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
>>>>>> For additional commands, e-mail: user-help@ant.apache.org
>>>>>>
>>>>>
>>>>>
>>>>>
>>>=20
>---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
>>>>> For additional commands, e-mail: user-help@ant.apache.org
>>>>>
>>>>>
>>>>
>>>>=20
>---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
>>>> For additional commands, e-mail: user-help@ant.apache.org
>>>>
>>>
>>>
>>>=20
>---------------------------------------------------------------------
>>> 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
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
>For additional commands, e-mail: user-help@ant.apache.org
>
>