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:[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]>
