But, how do you do a development build on your machine without affecting
the team of, say, Struts 1.1b2 when the main project in your ${jars}
directory is Struts 1.0?
Here's my scheme...
lib.properties (typed from memory, Struts path details may not be accurate):
struts.version=1.0
struts.dir=${lib.dir}/jakarta-struts-1.0
struts.jar=${struts.dir}/struts.jar
Then in my classpaths, I use very specific <pathelement
location="${struts.jar}"/> for all my project JAR's and carefully craft
classpaths to *only* the JAR's that are needed. This can cause extra
build file maintenance when a new JAR is needed, but in my opinion that
makes sense to have to change the build to incorporate a new dependency.
Now, to build with Struts 1.1b2:
ant -Dstruts.version=1.1b2
Voila! Or, I could override struts.dir if it was not under my
${lib.dir}, or override struts.jar property directly. And using one
large lib directory with different versions of different libraries
present, a project could pick and choose its own versions separately
from other projects, yet share the same library directory in the SCM.
I make one exception, though, admittedly, and that is with XDoclet (from
CVS HEAD). There are a dozen or so JAR files. It would be worth me
refactoring to only include the specific modules I use, though.
Erik
Dominique Devienne wrote:
> Usually your plugs are more subtle ;-)
>
> Personally, I don't have a problem with using:
>
> <path id="classpath">
> <fileset dir="${jars}" includes="*.jar" />
> </path>
>
> when ${jars} evaluates to a directory under CM control. I think it's safe
> (because you only get the JARs checked in in there), and also because you
> don't need to change the build.xml when you had a new dependency.
>
> I haven't chap9 of JDwA to look at to comment on it though... --DD
>
> -----Original Message-----
> From: Erik Hatcher [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, September 05, 2002 10:09 AM
> To: Ant Users List
> Subject: Re: Adding a directory of jars to the classpath
>
> I highly discourage the **/*.jar inclusion of JAR's into a classpath.
> This leaves it too open-ended to have the build broken later by someone
> introducing a conflicting JAR at a later time and this can be time
> consuming and painful to track down.
>
> Alternatively, there is an approach that I've evolved over time using a
> lib.properties to contain properties for library version numbers,
> directory mappings, and JAR location mappings that can allow great
> flexibility and control classpaths and overriding what version of
> library is used.
>
> This is documented chapter 9 of Java Development with Ant
> (Loughran/Hatcher).
>
> Erik
>
>
> Kervin, Stephen wrote:
>
>>Cant think of a better way off hand. Looks good.
>>
>>Stephen
>>
>>-----Original Message-----
>>From: Joe Tomcat [mailto:[EMAIL PROTECTED]]
>>Sent: 05 September 2002 10:16
>>To: Ant Users List
>>Subject: RE: Adding a directory of jars to the classpath
>>
>>
>>On Wed, 2002-09-04 at 23:02, Kervin, Stephen wrote:
>>
>>
>>>We use a "lib" folder. But unfortunatly you still need to specify each jar
>>>seperataly on the class path, I have not seen a way to java to recursive a
>>>directory looking for jars. I tend to use a classpath from a
>>>paths.properties file this way it is easily configurable and updateable.
>>
>>
>>This is what I'm using for now:
>>
>> <target name="compile" depends="prepare" description="Compiles all
>>source code.">
>> <javac srcdir="${src.dir}" destdir="${build.classes}"
>>excludes="**/old/*">
>> <classpath>
>> <fileset dir="${applibs}">
>> <include name="**/*.jar"/>
>> </fileset>
>> </classpath>
>> </javarc>
>> </target>
>>
>>It grabs all the jars in ${applibs}. I can then set up my deploy target
>>to copy those jars over to webapps/ROOT/WEB-INF/libs if they change and
>>I should be set, right? Is this the best way to do this?
>>
>>
>>--
>>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
>>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>>
>>--
>>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
>>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>>
>>
>>
>
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
