ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Visher" <tim.vis...@gmail.com>
Subject Re: Storing all libs in SCM?
Date Tue, 03 Jun 2008 21:54:48 GMT
Thanks Gabor.

So essentially you're saying that depending on the location of the
build file relative to the location of the lib directory (say 2
directories up the tree), I could in theory put '../..' for the build
location and Ant's smart enough to resolve that on whatever system
it's on?  That's great if that's the case.

On Tue, Jun 3, 2008 at 5:19 PM, Gabor Maghera <gmaghera@gmail.com> wrote:
> As far as slashes go (and colon or semicolon for classpaths), use the
> path syntax that you are comfortable with.  Ant will do the platform
> specific translation for you.  But I'd stick with relative paths, as
> Ant will not translate something like C: from Windows into / on UNIX.
>
> Cheers,
> Gabor
>
> On Tue, Jun 3, 2008 at 10:32 AM, Tim Visher <tim.visher@gmail.com> wrote:
>> Also, terribly sorry for this incredibly n00b question, but I'm
>> wondering what you would set the ubiquitous ${basedir} property to,
>> since you want it to be cross platform.  Would that be some sort of
>> relative path?  In my build script currently I have basedir (in the
>> project tag) set to '.'.  This is great, but if I want to store the
>> external libs outside of all of the projects they support, I can't
>> even really imagine a good way to do that...  Thoughts there?  Thanks
>> again!
>>
>> On Mon, Jun 2, 2008 at 4:37 PM, David Weintraub <qazwart@gmail.com> wrote:
>>> The standard is to put your JAR files in a single directory like
>>> $PROJ_DIR/lib or $PROJ_DIR/extern. Some people will divide up their
>>> jars into various directories that might be needed for special types
>>> of builds. For example: extern/lib for all standard libraries,
>>> extern/server for JARs that are needed for the server, and
>>> extern/client for all JARS that are needed for the client.
>>>
>>> You can then use the javac task to specify your CLASSPATH for
>>> compilation. You can do something like this:
>>>
>>> <property name="common.classpath.dir" value="${basedir}/extern/lib"/>
>>> <property name="server.classpath.dir" value=${basedir}/extern/server"/>
>>> <property name="client.classpath.dir" value="${basedir}/extern/client"/>
>>>
>>> <!-- Client Build -->
>>> <javac
>>>    srcdir="${src.dir}"
>>>    destdir="${dest.dir}"
>>>    <classpath>
>>>        <fileset dir="${common.classpath.dir}"/>
>>>        <fileset dir="${client.classpath.dir}">
>>>             <include name="*.jar"/>
>>>        </fileset>
>>>    </classpath>
>>> </java>
>>>
>>> The advantage is that your JAR files will automatically be included in
>>> your classpath as you add JAR files into the correct extern
>>> directories. And, since the JARS are versioned with the SCM system,
>>> you checkout the correct version of the JAR files whenever you
>>> checkout your project for development. In most SCM systems, the
>>> directory is somewhat versioned with the files, so that if you add a
>>> new JAR to REL_1.2 that was not in REL_1.0, you will see the new JAR
>>> when you checkout REL_1.2, but not REL_1.0.
>>>
>>> The disadvantage is that you cannot select the ordering of the JAR
>>> files. If two JARS contain the same classname, the class that is used
>>> is the one that is in the first JAR file in the classpath. Officially,
>>> you don't know the exact classpath, so you can't specify which JAR
>>> file should be first. To me, this is an extremely minor issue. You
>>> shouldn't have two distinct JARs which contain duplicate class names.
>>>
>>> By the way, I highly recommend you rename your JAR files to include
>>> the revision in the name. For example, if you're using ftp.jar, rename
>>> it to the correct version like ftp.2.3.jar or ftp.1.2.jar. This may
>>> mean deleting the old JAR from the source archive (using "svn delete
>>> ftp.1.2.jar" or
>>> "cvs delete -f ftp.1.2.jar") and adding a new version back in (using
>>> "svn add ftp.2.3.jar" or "cvs add ftp.2.3.jar").
>>>
>>> This is a bit more work than just updating the JAR and committing the
>>> latest version. But, this will help you know the exact revisions of
>>> each third party JAR in your build. Developers can easily see what
>>> defects are in a particular JAR. What that JAR supports, and what
>>> could happen if they want to upgrade that JAR file.
>>>
>>> Since JAR files are binary, you don't really gain anything by simply
>>> updating the JAR file with the latest revision. You can't do a diff
>>> between two binary revisions, and you don't save any room in your
>>> source archive because binary files aren't saved in delta format.
>>>
>>> On Mon, Jun 2, 2008 at 3:45 PM, Tim Visher <tim.visher@gmail.com> wrote:
>>>> Hello Everyone,
>>>>
>>>> I've been working on setting up an automated build environment using
>>>> Ant for a few days while I try to move towards the Continuous
>>>> Integration benchmark and I've run into a major snag that I can't seem
>>>> to get past.  I've been doing a lot of reading about Agile Processes
>>>> and Continuous Integration and one of the major things that keeps
>>>> getting brought up is that you should have every component needed to
>>>> build your software stored centrally via SCM in order to ensure that
>>>> you are always able to reproduce any build.  I'm probably going to
>>>> stop short of throwing the OS and DB software in there, but I would
>>>> like to store all necessary lib jars (such as javaee.jar and mail.jar)
>>>> in there so that when a vanilla box checks out the software, it has a
>>>> constant place to look for all necessary library components.  So far,
>>>> I've gotten things to work by putting the necessary lib files in
>>>> ANT_HOME/lib and by using the -lib flag to specify an alternate
>>>> location that also has the necessary lib files, but I can't figure out
>>>> how to pass something like the -lib option internally to the build.xml
>>>> file.  I've tried specifying the classpath property in the javac task
>>>> but that did not work either, even though when I ran ant in -verbose
>>>> mode the classpath option that was apparently being passed to javac
>>>> did have the correct folder on it.
>>>>
>>>> I'm not sure where the break down in my understanding is but hopefully
>>>> the above is more than enough info for someone to help me.  If it's
>>>> not, please just ask as I've wasted too much time trouncing through
>>>> the documentation.
>>>>
>>>> Thanks in advance for your help!
>>>>
>>>> --
>>>>
>>>> In Christ,
>>>>
>>>> Timmy V.
>>>>
>>>> http://burningones.com/
>>>> http://five.sentenc.es/ - Spend less time on e-mail
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
>>>> For additional commands, e-mail: user-help@ant.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> --
>>> David Weintraub
>>> qazwart@gmail.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
>>> For additional commands, e-mail: user-help@ant.apache.org
>>>
>>>
>>
>>
>>
>> --
>>
>> In Christ,
>>
>> Timmy V.
>>
>> http://burningones.com/
>> http://five.sentenc.es/ - Spend less time on e-mail
>>
>> ---------------------------------------------------------------------
>> 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
>
>



-- 

In Christ,

Timmy V.

http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail

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


Mime
View raw message