I'll try rolling out the MASSEMBLY-155 fix, just to see if that makes a difference. I can't imagine the ClassCastException fix or the file-mode processing chewing up much, though.
Brett: Is it possible that you weren't running out of memory previously *because* of the CCE? -john On 3/30/07, Brian E. Fox <[EMAIL PROTECTED]> wrote:
I imagine the fix for MASSEMBLY-155 might cause the archiver to use a little more memory. I would imagine though that if the excludes weren't used, the fix wouldn't have an impact. -----Original Message----- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Friday, March 30, 2007 1:36 AM To: Maven Developers List Subject: Re: [vote] Attempt 2: Release 2.2-beta-1 of maven-assembly-plugin John, I'm building a >100mb assembly and the build is blowing up with an OOME. I upped the limit to 128m and instead of that problem it completely hangs down the track (kill -9). I'm trying again with 256m now. If I build with 2.1 again, there are no problems. I am able to switch back and forth and get consistent results: dead with 2.2, fine with 2.1. Oddly, though, I had no such problems with 2.2 yesterday. Did anything change overnight that might leak memory? - Brett On 30/03/2007, at 3:50 AM, John Casey wrote: > This is the second attempt, after fixing: > > * http://jira.codehaus.org/browse/MASSEMBLY-155 > * http://jira.codehaus.org/browse/MASSEMBLY-192 > * [file and directory mode parsing] > > WRT mode parsing, everything is now parsed using Integer.parseInt > ( mode, 8 > ). If this results in a NumberFormatException, that is wrapped in an > AssemblyFormattingException that indicates that it was a file/dir > mode that > failed to parse. If the parse succeeds, the resulting mode int is > checked > for sanity. That is, cases where group|world have perms that the user > doesn't, or cases where world has perms that the group doesn't (as in, > user:rx, group:rwx, world: rx). This could still break builds where > a mode > is specified in decimal, but at least there should be some > indication of > what went wrong...and now they'll know that we're trying to do the > right > thing. Also, all of the mode parsing has been consolidated into > TypeConversionUtils, with a TypeConversionUtilsTest to check my work. > Finally, for MASSEMBLY-155, there is a new integration test that > verifies > its behavior. > > > So, let's try this again: > > I wanted to call a vote to release a beta version of the new assembly > plugin. There are still some outstanding issues (though not as many > as jira > would have you believe; they just need tests), but I think we're at > around > 95-99% backward compatibility and the new features seem to be > working well. > It's been just sitting in SVN for quite awhile now, and many people > are > using it directly from there. I'd like to provide better support > for those > people, and start getting more feedback on exactly what's still > broken. > > The change list is pretty large, but is mainly concerned with > refactoring > the plugin away from the old monolithic approach to one that uses > phases to > handle the different descriptor sections, along with common task > classes to > handle behavior shared between phases. > > Road Map: > > http://jira.codehaus.org/secure/ReleaseNote.jspa? > projectId=11126&styleName=Html&version=12617 > > > Tag: > > http://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly- > plugin-2.2-beta-1 > > Staging repository: > > http://people.apache.org/~jdcasey/stage/repo<http:// > people.apache.org/%7Ejdcasey/stage/repo> > > So, let's try 72h +1/+0/-1. Please cast your votes! > > Here's my +1. > > -john --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
