Hi all, Just following up on this. I note there are a couple of suggested solutions. I am happy to try them out over the next couple of days and see if any are suitable. To be honest, I think this is a hiccup and can be easily resolved.
Re. conflicts with the testing framework - actually the use of the build.properties file for filtering is similar to the route that had already been taken with the use of testEnvironment.properties so they have become more aligned. The build.properties file should not interfere with the testing framework as it doesn't filter any files in the testing environment, they are filtered by testEnvironment.properties. As a general comment I would note that we have a problem in that you can currently filter in a number of different ways, including in the Ant 'update_webapps' step. I would argue that we should not be editing web.xml files as part of deployment but that is just my opinion. The result is that lots of people have developed lots of different procedures for filtering during build and deployment. Inevitably some are going to have to change if rationalisation takes place, whatever the solution implemented. I note the reservations voiced regarding this particular solution after last nights meeting. Obviously its right and proper that developers should be able to revise their positions with regards to code changes at any time even to the extent that they may request a change to be backed out, but personally I still think this change is a step in the right direction, albeit it may need tweaked a little before release. Cheers, Robin. On 28/08/12 21:17, helix84 wrote: > Hello everyone, > > in recent days I've noticed that building the DSpace master branch can > sometimes take a very long time. I think I now found the cause of > that. > > Once my build crashed (and kept crashing) because it ran out of JVM > heap space, I investigated the reason. It boiled down to a recursive > ls command called from maven-assembly-plugin. Now why would a ls > command crash? I noticed a strange repetition in the target directory > structure that probably shouldn't be there: > ...classes/target/classes/target/classes/... (repeated several times). > I checked out a clean repository and it was built without a hitch. I > suspected the reason might be multiple build cycles, so I ran a few > and found the following: > > * I found out that running the maven "clean" target removes these > patterns and brings build times down to normal > * In my environment, I managed to get 3 consecutive builds without > cleaning, the 4th one failed from memory starvation during creation of > jars. > * I tried to assess the severity of this problem by counting the > 'target/classes/target' patterns using "find . -path > '*target/classes/target*' | wc -l" > dspace 1.8.2 count (for reference): 0 patterns > master after 1 build: 42 patterns; 4 minutes 45 seconds > master after 2 builds: 2934 patterns; 5 minutes 9 seconds > master after 3 builds: 19446 patterns; 14 minutes 24 seconds > master after 4th failed build: ~40 minutes > > I'm attaching the results of "find . -path '*target/classes/target*'" > after 1 build and after 3 builds. > > I'm now going to bisect master to find the commit that caused this. > But it will likely be some maven refactoring, so if you have any > suspicions, you may speed up the process by pointing it out. > > Regards, > ~~helix84 -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Dspace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
