David Crossley wrote: > David Crossley wrote: > > David Crossley wrote: > > > David Crossley wrote: > > > > > > > > I notice that there is a different size with the jar > > > > that gets packed for the release ... > > > > > > > > [forrest-trunk-release]$ ls -l build/xml-forrest.jar > > > > build/dist/shbat/build/xml-forrest.jar > > > > 67164 Apr 10 22:34 build/dist/shbat/build/xml-forrest.jar > > > > 66577 Apr 10 22:33 build/xml-forrest.jar > > > > > > This is very strange. All that happened in the "dist-shbat" > > > target is that the Ant "copy" task copied the build/xml-forrest.jar > > > to that dist location. > > > > Ah, i made the "dist-shbat" target pause with an "input" > > task, copied the jar over by hand, then let it proceed > > after the copy. > > > > Something mangles the jar later in the process. > > > > Looking ... > > Found it. > > I had added "fixcrlf" tasks so that we didn't need > to build the release on two different operating systems. > > It was wrecking the jar file. > > Doing 'forrest run' works for me now. > > However, there are some images that are mangled too. > > I thought that "fixcrlf" would only touch text files, > but no. > > So i think that we need to go back to how we built > the packages in the past. > > Would a committer on Windows (preferably have a well-connected > PGP key) please get ready to build the release. > > Get a fresh trunk checkout and have Java 1.4 > > I will help you with the next steps.
Actually hold that. There is a reasonably small set of binary filename extensions. I could try excluding them too from the fixcrlf task. Surely other projects don't need to jump through such hoops. Do they worry about line-endings? I am tempted to just build the first release candidate without the fixcrlf and see what happens. Does anyone have an opinion on that? Need to make a decision quickly. -David
