I ran another clean build but this time with the MAVEN_OPTS settings
John mentioned below. I'm not sure yet if it's indicative of a general
solution (since it didn't always fail) but it didn't fail with the out
of memory error this time.
However, this time it did fail with the fileIO exception (actually, it's
a java.io.FileNotFoundException).
assemble:package-assembly:
[echo] Preparing CRLF line endings in text based files for zip
distribution
[zip] Building zip:
C:\geronimo\assemblies\j2ee-tomcat-server\target\geronimo-tomcat-j2ee-1.2-SNAPSHOT.zip
[echo] Preparing LF line endings in text based files for tar.gz
distribution
BUILD FAILED
File...... C:\geronimo\maven.xml
Element... maven:reactor
Line...... 227
Column.... -1
Unable to obtain goal [multiproject:install-callback] -- C:\Documents
and
Settings\Administrator\.maven\cache\geronimo-assembly-plugin-1.2.0-8\plugin.jelly:352:
-1: <ant:fixcrlf> java.io.FileNotFoundException:
C:\geronimo\assemblies\j2ee-tomcat-server\target\geronimo-1.2-SNAPSHOT\config-store\30\geronimo-console-standar
d-1.2-SNAPSHOT.war\WEB-INF\work\org\apache\jsp\WEB_002dINF\view\certmanager\generateCSRNormal_jsp.java
(Access is denied)
Total time : 36 minutes 34 seconds
15:58:36,934 INFO [App] Total time : 36 minutes 34 seconds
The referenced file (generateCSRNormal_jsp.java) does not exist in this
work location (just as the exception indicated). It's the only jsp that
doesn't have both the java and class files in that work location.
However, it makes me wonder if we need to be processing these work files
anyway in the plugin. Do we really need to touch the line endings on
these files (if in fact that is what we're doing at this point in time)?
As a side note: After the build %temp% included about the same number
of test* files as my earlier post (47), only 9 geronimo-deploymentUtil*
files and 11 package*.tmpdir directories.
John Sisson wrote:
Joe Bohn wrote:
I've been encountering a number of problems building on Windows which
seem to be steadily getting worse and I was wondering if anybody else
is experiencing this (and hopefully has some work-arounds).
- Out of Memory Errors. These seem to be related to two different
things:
1) Long file names. If I remember correctly Windows has issues if
the file names exceed 256 bytes. I've been working with multiple
levels of geronimo concurrently and so have had to name the root
something other than simply geronimo. It seems like if I start to get
longer than 12 characters or so I begin to hit these problems. I
think we may be getting into trouble here with the depth of our
packages and embedded classes.
Yes, it is concerning..
http://mail-archives.apache.org/mod_mbox/geronimo-dev/200601.mbox/[EMAIL PROTECTED]
I also have had to shorten my directory path I am building in. The long
file name issue should go way when we move to JDK 1.5_06 but a number of
other programs on Windows that deal with files also have the issue (e.g.
Windows File Explorer, WinZip, Visual SourceSafe) so this issue could
bite us with users complaining that other tools they are using can't
work with Geronimo's long directory paths.
Do we have a JIRA for this issue?
2) Extra garbage hanging around in %temp% from previous builds. The
geronimo build leaves a lot of trash in %temp% and when that seems to
cause problems with out of memory errors and subsequent builds.
See http://issues.apache.org/jira/browse/GERONIMO-777
Are you seeing these problems on trunk, 1.0 or 1.1 branches or all?
What JDK are you using?
For a long time I have been using the following (from memory I think
there was something in maven or one of the libraries it uses that had a
leak - not sure if this still exists)
SET MAVEN_OPTS=-Xmx512m -XX:MaxPermSize=128m
What command are you using to build? (this could possibly affect what
code gets invoked and how much memory is used). Do you have MAVEN_OPTS
environment variables set?
I will try to reproduce with the same JDK level and commands once you
provide the info.
- File IO errors when running the CRLF plugin. These may be related to
the %temp% storage but I seem to get them at times even when I've just
cleaned out my %temp%. Running back to back I get different results.
One thing to try is disabling XP's file indexing (which I have done).
It looks like this has caused problems for Java elsewhere (see the
workaround in this bug)..
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5006328
I also found that
http://www.sysinternals.com/Utilities/ProcessExplorer.html utility is
good for tracking down processes that have file handles open. Use the
Find-->Find Handle menu option and specify the file name.
I had some similar problems for a while and ended up tracking it down my
incorrectly configured Diskeeper disk defragmenter that had paused
defragmentation and held file handles open.
Have you tried with real-time virus checking disabled to check it isn't
a virus checker causing issues?
What files are you getting the IO errors on? Can you include the error
output?
It makes me wonder if we need to have some kind of retry logic for file
operations if we are possibly competing with file indexers etc so we can
run on a Windows box without problems. I noticed some of the Ant tasks
have retry logic for some file operations:
http://svn.apache.org/viewcvs.cgi/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Mkdir.java?view=markup
http://svn.apache.org/viewcvs.cgi/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Delete.java?view=markup
Regards,
John
Thanks for the help,
Joe
--
Joe Bohn
joe.bohn at earthlink.net
"He is no fool who gives what he cannot keep, to gain what he cannot
lose." -- Jim Elliot
