You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by Tim Visher <ti...@gmail.com> on 2008/06/02 21:45:20 UTC
Storing all libs in SCM?
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
Re: Storing all libs in SCM?
Posted by Tim Visher <ti...@gmail.com>.
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 <gm...@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 <ti...@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 <qa...@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 <ti...@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
Re: Storing all libs in SCM?
Posted by Gabor Maghera <gm...@gmail.com>.
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 <ti...@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 <qa...@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 <ti...@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
Re: Storing all libs in SCM?
Posted by Tim Visher <ti...@gmail.com>.
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 <qa...@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 <ti...@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
Re: Storing all libs in SCM?
Posted by Tim Visher <ti...@gmail.com>.
Thanks David.
Clearly my misunderstanding was in the use of the classpath tag. I
tried to use that but was unable to get it work. I'll try sometime
soon.
Do I understand that you're not a fan of dependency management from
the likes of Ivy or Maven then? Gilles recommended that I look into
Ivy and I hadn't yet so I went and did that this morning and it looks
pretty intriguing. One thing I noticed right off the bat was that it
did not have javaee.jar (at least not that I could find) available.
However, it did have junit.jar. The 4 dependencies that I have at the
moment which are not in the jdk are javaee.jar, mail.jar,
derbyclient.jar, and junit.jar. I think there's a breakdown somewhere
in my understanding about how to make the 'standard' jars available to
ant. What started me down this whole path was that I could not use
any of the JEE classes in the System. Right now I have no CLASSPATH
variable but I can still use all of the standard JDK libs, javac just
seems to know about them. Is there a way to do this with the JEE
classes as well?
Beyond that, the other question I would have about dependency
management (with something like Ivy vs. Manually) is how you would go
about SCMing that. It seems like a 'dangerous' thing to allow an
outside entity to manage all of your dependencies for you. You're not
guaranteed that a particular jar will always be there, you need an
internet connection to get to it (at least at first), etc. etc. Is
there something I'm missing there? Or is that the major downfall of
using a dependency management tool?
Thanks so much for your help!
On Mon, Jun 2, 2008 at 4:37 PM, David Weintraub <qa...@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 <ti...@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
Re: Storing all libs in SCM?
Posted by David Weintraub <qa...@gmail.com>.
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 <ti...@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
Re: Storing all libs in SCM?
Posted by Mike Spross <mg...@gmail.com>.
On Mon, Jun 2, 2008 at 3:45 PM, Tim Visher <ti...@gmail.com> wrote:
> 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.
You can tell Eclipse to run a custom Ant build script by creating a
custom builder task: go to the project's properties, select Builders,
click New, and select Ant Builder. You can point Eclipse to an Ant
script to run and specify additional command-line arguments to pass to
Ant. The builder will run whenever you build the parent project in
Eclipse. However, I already tried this, and it appears that Eclipse's
built-in Ant doesn't support the -lib flag anyway; you have to add
explicitly add every JAR you need in the Classpath tab, or dynamically
build the classpath in the Ant script that you are running. I'm not
sure if there is a cleaner way to handle all this, but off the top of
my head here are some possible workarounds (haven't tested any of
these ideas), that are all basically the same concept, but slightly
different variations:
1) Make a stub launch-build.xml file that only Eclipse uses. This file
would invoke the standalone version of ant, passing it the real
build.xml file and the correct lib path, since the standalone version
of Ant can handle the -lib flag properly.
2) Have a single build.xml file that dynamically builds the classpath
by scanning some path that we could define in an Ant variable.
3) Create a new Builder in Eclipse using the Program option, instead
of the Ant Builder option. The builder invokes the standalone version
of Ant, passing in the correct lib path via the -lib flag. Like option
2, we would only need one build.xml file.
In any case, I'm not sure how we can get around the problem of
duplicating classpath information. That is, the Eclipse projects have
their own classpath settings, but then so will the Ant build scripts
that we create. Unless there is some way to keep the two in sync
without manually having to edit one when the other changes.
> 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 created a HelloWorld class that uses the javax.persistence package,
which is in javaee.jar, and a build.xml that just runs javac with the
classpath pointing to javee.jar on my system. The classpath setting
worked fine for me, so I have to ask the obvious question here: did
you remember to put the full path to the .jar file(s) in classpath, as
opposed to just the folder path? Here are HelloWorld.java and
build.xml:
~/HelloWorld/src/HelloWorld.java:
import javax.persistence.*;
@Entity //just to use something in javaee.jar...
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello world!");
}
}
~/HelloWorld/build.xml:
<project>
<javac
srcdir="src"
destdir="build"
classpath="/opt/jee_sdk/lib/javaee.jar"
debug="on"
/>
</project>
--
Mike Spross
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: Storing all libs in SCM?
Posted by Gilles Scokart <gs...@gmail.com>.
You should look at http://ant.apache.org/ivy/
2008/6/2 Tim Visher <ti...@gmail.com>:
> 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
>
>
--
Gilles Scokart
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org