Community
Participate
Working Groups
I ran wtpbuilded on Windows XP. The build failed because the scripts were generating paths that are too long for Windows. I'll attach my build.properties. Here is the Ant console message: [build-wtp-wst-sdk] C:\dev\build-home\build-wtp-I\workdir\plugins\org.eclipse.wst.common_core.feature.source\build.xml:52: IO error canning directory C:\dev\build-home\build-wtp-I\workdir\plugins\org.eclipse.wst.common_core.feature.source\temp.folder\org.eclipse.wst.common_core.feature.source_1.5.0.v200604022030--AXrVWXW6kGj-uJ\src\org.eclipse.wst.common.emfworkbench.integration_1.0.0.v200604131335\schema [build-wtp-wst-sdk] Total time: 9 minutes 2 seconds When I try to look at the folder in Windows Explorer, I get the error message: Can't access this folder. Path is too long.
Created attachment 38796 [details] build.properties
I need to do a local build to test the DITA-OT integration. The build fails when it generates the source features. Can I avoid generating the source features?
Arthur, there's probably a couple of bugs your are running in to here (I suspect some of that source is not getting zipped up as it should), but ... to "get you running", you can limit what's built by editing your local copy of build.xml in releng.wtpbuilder/distribution/wtp.build Just comment out the "sdk" parts such as <ant antfile="${buildTargets}" > <property name="component" value="jst-sdk" /> </ant> Then, to keep your locally edited copy from being replaced, there's some place else you might have to modify so that releng.wtpbuilder is not downloaded each time.
See also bug 134187. I am going to try to temporarily remove all that "SDK Source" contributed by ws explorer. Its not criticial for running ... just being a good citizen and providing all source in an SDK. And, easier for me to remove it temporarily, and let ant experts improve the "cusom script" that can just zip it all up ... instead of trying to copy if to various places.
FYI ... the "trick" I tried as described in comment #4 didn't quite work ... just ran into another directory where it was "too long", (emf integration ... /shema) and it is, I believe, all legitamately too long. This is partially a change with the new .qualifiers added to versions ... makes some paths much longer. Also, there is a spot in the generated build.xml files, that, during cleanup, have something like <delete ${temp.folder}> This might be better using file or directory sets ... I think then the subdirectories are deleted "recursively", so no one of them is too long.
Core team doesn't have resources to fix/test Windows for builds ... well integrated and tested contributions would be welcome.
*** This bug has been marked as a duplicate of bug 242287 ***
