Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: domain of paulmcmahan@gmail.com designates
 66.249.92.169 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=OfODUDtrWe6aRjew0xMdROFb1rfHinBez88DXU8jSnUg/WPvG0R3IINAT94NBjFXSQJhrqDj7QsYL9XeDWZFMUBx+9h5mbdU5SDL5k+ewTMtCMZoqS5NKe4xl6YY16dqpj28L0PH8p79AvY4XMnGqgiThbHNORscmXer2mc3Zn8=
Message-ID: <21df75940608301330k712a4ab7u666141ba46dfa14c@mail.gmail.com>
Date: Wed, 30 Aug 2006 16:30:18 -0400
From: "Paul McMahan" <paulmcmahan@gmail.com>
To: dev@geronimo.apache.org
Subject: Re: windows build hell
In-Reply-To: <44F5F41C.70106@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <44F5B08C.6010701@earthlink.net> <44F5EF58.7000300@gmail.com>
	 <C87E11AF-5D15-474C-9ED0-B611E76B7B85@apache.org>
	 <44F5F41C.70106@gmail.com>

You can create a filename starting with "." from a command window.

Paul

On 8/30/06, Hernan Cunico <hcunico@gmail.com> wrote:
> Windows wont let you create a file with "." as the initial character,
> that's why I'm trying to force it in the command line.
>
> Is there any other alternative in windows?
>
> Cheers!
> Hernan
>
> Bill Dudney wrote:
> > I got rid of the OOME by putting
> >
> > MAVEN_OPTS=-Xmx512m
> >
> > into my ~/.mavenrc file
> >
> > TTFN,
> >
> > -bd-
> >
> > On Aug 30, 2006, at 2:04 PM, Hernan Cunico wrote:
> >
> >> I had experienced all these errors, in addition, the one I get the
> >> most is an annoying out of mem error
> >>
> >> ...
> >> [DEBUG] Trace
> >> java.lang.OutOfMemoryError
> >> [INFO] ------------------------------------------
> >> [INFO] Total time: 38 seconds
> >> [INFO] Finished at: Wed Aug 30 15:50:06 EDT 2006
> >> [INFO] Final Memory: 43M/63M
> >> [INFO] ------------------------------------------
> >>
> >> I tried to increase the mvn heap sz by adding to the command
> >> -DMAVEN_OPTS=-Xmx512m. It does not seem to work, any suggestions?
> >>
> >> Cheers!
> >> Hernan
> >>
> >> Joe Bohn wrote:
> >>> We've been struggling with build problems on windows for some time
> >>> now and things just keep on getting worse.
> >>> I'm composing this note to summarize the problems that I'm aware of
> >>> with work-arounds and possible solutions.   I'm also fishing to see
> >>> if anybody else has some ideas on how to resolve these issues.
> >>> 1)  Windows pathlength problem.
> >>> Problem:
> >>> There are miscellaneous failures that can typically be tracked down
> >>> to the windows pathlength problem.  The nature of our repository
> >>> structure and deployment make this a big problem.   It also seems
> >>> like we're continuing to add more intermediate elements in path names
> >>> as we try to get things more organized and conform to Maven 2
> >>> conventions.
> >>> Work-around:
> >>> The work-around is to keep the windows root path as small as
> >>> possible. I now typically build from a root path of c:\g to avoid
> >>> these problems.
> >>> Possible Solution:
> >>> For a longer term solution I'm planning to work on a new repository
> >>> implementation in 1.2 that that isn't as redundant or verbose.
> >>> 2)  JSP compilation errors
> >>> Problem:
> >>> Embedded error: Unable to compile class for JSP
> >>> Strange error message about JAVA_HOME, etc...
> >>> Possible Solution/Work-around:
> >>> Update the pom.xml in the root directory to use version
> >>> 1.4.5-SNAPSHOT (from 1.4.4) for the jspc-maven-plugin.  Not sure if
> >>> Jeff Genender is planning to make 1.4.5 an official release for
> >>> this.  We're not sure why it gets us around the problem so it may be
> >>> a red herring.
> >>> 3)  Openejb2 test failures.
> >>> Problem:
> >>> Caused by: java.lang.NoSuchMethodException:
> >>> org.openejb.deployment.DeploymentTestSuite.getName()
> >>> Work-around:
> >>> After bootstrap failure cd to <root>\target\external\openejb2
> >>> "mvn -Dmaven.test.skip=true"
> >>> cd back to <root>
> >>> "mvn clean install"
> >>> Possible solution:
> >>> Dain suggested adding the "getName" method to the test.  However,
> >>> when I attempted this I hit other errors.
> >>> http://marc.theaimsgroup.com/?l=geronimo-dev&m=115680051431478&w=2
> >>> I think it would be helpful if we could disable the openejb tests
> >>> until this problem is resolved.
> >>> 4)  Blue screen of death (bsod)
> >>> Problem:
> >>> This has been reported by multiple users on various machines.  When
> >>> running an M1 or M2 build the user encounters a bsod due to a memory
> >>> failure.
> >>> PAGE_FAULT_IN_NONPAGED_AREA
> >>>  ***  STOP:  0x00000050 (0xBADDB148, 0x00000000, 0x8056C77B, 0x00000000)
> >>> Dump of physical memory
> >>> Work-around/Possible Solution:
> >>> Haven't found one yet.  I've tried updated drivers, replaced
> >>> hardware, tried various heap size settings, etc....  At times this
> >>> can be fairly frequent (every 3rd build attempt or so).  I'm
> >>> collecting bootstrap.log files from folks when this happens during a
> >>> bootstrap to see if there is a common thread.  So far, with the
> >>> bootstrap logs, it always seems to happen at about the same place:
> >>> Running tests after building a module (usually tomcat.ApplicationTest
> >>> or TomcatModuleBuilderTest) and the final lines in the log are always
> >>> the Creation of an MBeanServer like this:
> >>>  [exec] Running org.apache.geronimo.tomcat.ApplicationTest
> >>>  [exec] Created MBeanServer with ID: 5dcec6:10d5a184aed:-8000:jbohn2:1
> >>> Please respond to this note if you are seeing the bsod failures on
> >>> windows.  At first I thought this was just me and was hardware
> >>> related.  However, the more I talk to folks on windows the more I
> >>> hear of other folks encountering this same problem.  I've updated all
> >>> drivers, replaced my entire system, and several other folks have
> >>> reported seeing this on completely different systems.   I think that
> >>> pretty much rules out a hardware problem.
> >>> ideas welcome!
> >>> Joe
> >
> >
>