Mailing-List: contact ant-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Users List" <ant-user@jakarta.apache.org>
Message-ID: <072001c27561$d22dce50$6401a8c0@croltn1.tx.home.com>
From: "M Damon Hill" <mdhill2@attbi.com>
To: <ant-user@jakarta.apache.org>
Subject: REPOST-- Very important issue, any input appreciated
Date: Wed, 16 Oct 2002 17:17:28 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Thanks!!


> Good day!
>
> Really peculiar exception I am getting here. Just thought I would share
> it with the group and see if anyone had
> seen it before or knew of a possible solution to the error I am
> experiencing.
>
> Ok, to summarize my project setup in brief:
>           Ant 1.5.1
>           JDK 1.3
>           Solaris
>
> I have a hierarchical directory structure similiar to
>
> turbo1/build.xml
> turbo1/util/build.xml
> turbo1/util/classes
> turbo1/domain/build.xml
> turbo1/domain/classes
> turbo1/persistence/build.xml
> turbo1/persistence/classes
> turbo1/common/build.xml
> turbo1/common/classes
> ......
> turbo1/targets
>
> Now, we compile code and build jar files with the appropriate class
> files from each subproject and place those
> JAR files into the turbo1/targets directory. Now, here is where we run
> into a problem. Let's say I want to clean up the
> class files under each subdirectory before I begin a build. We have a
> 'clean' target that does that. Now, let's say I
> then want to recompile, rebuild jar files, and place those jar files
> under the turbo1/targets directory again with the newer
> versions. Ok, so, we have a target that does that. Only problem is,
> when it executes and we get down to the turbo1/persistence
> package we through the following exception when we try to begin
> compilation:
>
> BUILD FAILED
> file:/vobs/TURBO_source/turbo1/persistence/build.xml:51: Could not
> launch java: java.io.IOException: Resource temporarily unavailable
>
> Now, the kicker is this. Let's say we repeat the process, but this time
> we REMOVE all of the jar files that were in the targets
> directory from the previous build. Now when we run the command to
> recompile, rebuild the jar file and place them under the
> turbo1/targets directory with the newer versions, everything works like
> a charm.
>
> When we go into a subdirectory and before we begin to compile we set up
> the classpath for compilation the following way:
>    we include all the .jar and .zip files in that turbo1/targets
> directory as well as all of the .jar and .zip files from our commonlib
> directory
>
> Now, my question is this: is there a possibility that the setting of
> the classpath before executing java is causing a resource conflict
> because it is setting the OLD .jar file we built into the classpath and
> now we are going to rebuild it with the newer versions of the code.
> Does this even make sense?? It is a hard problem to describe, but very
> easy to demonstrate.
>
> Hopefully someone has an idea.
>
> thanks,
>
> M Damon Hill
> Integrator : TURBO/Jets
> Valtech Technoloies, Inc.
> "Science is built up of facts, as a house is built of stones; but
> an accumulation of facts is no more a science than a heap of stones
> is a house." - Henri Poincare
>
> --
> To unsubscribe, e-mail:   <mailto:ant-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:ant-user-help@jakarta.apache.org>
>


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