Community
Participate
Working Groups
WTP build uses a number of Linux/Unix specific scripts and command that makes it difficult, if not impossible, to run build on Windows. Since there are a good number of WTP committers and contributors who use Windows (don't know whether it's a majority or not), this limitation creates a situation where few committers ever do local builds even when the scope of changes really makes a local build advisable. This is related to Bug 242285 which is another reason that few people run local builds.
Can you be more specific about what's needed or not needed as an end-result? For example, I guess you are not expecting jars to be signed. I'd guess you are expecting jars to be conditioned for packing. I'm wondering what limit's you've ran into (with those two things turned off). I'd prefer specific bugs be open if/when you encounter problems ... otherwise, sounds more like a feature request. (And, that doesn't make it any less important for someone to tackle.)
assigning to myself so it's obvious it's been triaged. As you might guess, high quality patches are welcome.
Ideally, the build is fully reproducible on Windows. It has been a while since I tried this last, some my memory is a bit hazy, but the problems I hit were at the very start of the build rather than at the end, so I don't think the items you've identified are the problem here. Perhaps a lot of the issues can be bypassed when Bug 242285 is resolved.
*** Bug 137232 has been marked as a duplicate of this bug. ***
Dave, thanks for volunteering to tackle this long desired bug.
I'll see what I can do to get it non-server specific. Basically if I can get it to run from within a Workspace, then it should be able to run regardless of server. Same build should then run on a build server, a developer's work space, or another OS.
I was unable to run a complete build on Windows back around WTP 1.5. The problem I hit was that the directory paths and file names got too long. The limit on Windows is smaller than Linux. Parts of the build did work. I don't recall where it failed.
I just checked my old bug 137232 which describes the path length problem on Windows. I see that is marked as a duplicate of this. I find this odd. Normally when someone reports a bug that has been previously reported, the new bug is marked as a duplicate of the old bug. Why are you doing the opposite now? I've also noticed this in some old Web service bugs I reported. Thx.
Okay, here is one suggestion I'm going to make, but in order for it to work, all of the WTP build.xml files will need to be updated. I would suggest getting rid of the environment variables all together as everything that is being handled by environment variables can be handled via a property file just as well. I managed to get at least to the point where it checks the files out, but after that it just seems to skip the actual build. Here is what I have included in a property file called commonVariations.properties: JAVA_4_HOME= JAVA_5_HOME=/home/dcarver/jrockit-jdk1.5.0_12 LOCAL_BUILD_PROPERTIES=davesProperties BUILD_CVS_WRITE_PROTOCOL=pserver BUILD_CVS_WRITE_USER=anonymous BUILD_CVS_SERVER=dev.eclipse.org SKIPUSER=true BUILD_UPLOAD=false RELENG_CONTROL=${BUILD_HOME}/releng.control PROJECT_BUILDERS=${BUILD_HOME}/projectBuilders BASEOS=linux BASEWS=GTK BASEARCH=ppc USE_LOGGER=true USE_QUIET=true USE_DEBUG=false CVS_QUIET=false CVS_REALLY_QUIET=false BUILD_CVS_ROOT=/cvsroot/webtools DOWNLOAD_ROOT=${BUILD_HOME}/download.eclipse.org SKIP_JAR_SIGNING=true REMOTE_SSH_COMMAND= RELENG=webtools.maps/releng RELENG_BUILDER=webtools.releng/releng.wtpbuilder build.distribution=distribution/xsl.build buildType=I PROJECT_PROJECTS=project/ Now in the cc_project_build we need to add the BUILD_HOME property name, as: <property name="BUILD_HOME" location="."/> This will set by default the BUILD_HOME to be the CWD that the ant build is executed. If you are executing the build from your workspace it uses that workspace and project that it was executed from as the BUILD_HOME...it can be overriden and passed as a BUILD_HOME directory or we could include it in the properties file above. The next thing that needs to be added as well is a statement to read the above properties file: <!-- Read Properties from a standard properties file --> <property file="commonVariations.properties"/> That will load ant with the values in the properties file and make then available as ANT variables. The last thing to do is to comment out the property statement that retrieves property files from the environment variables. The above would be the first change I would do, in order to eliminate the need for the environment variables at all.
Since this bug has had no activity for over a year, I'm closing as "wontfix". It _might_ deserve to stay open as a feature request. But not as a "major" bug. See http://wiki.eclipse.org/WTP/Conventions_of_bug_priority_and_severity And, IMHO, building on windows will be more difficult than the benefit would merit. Time and resource better spent on more important issues. Thanks though, for raising the issue.
(In reply to comment #10) > Since this bug has had no activity for over a year, I'm closing as "wontfix". > > It _might_ deserve to stay open as a feature request. But not as a "major" bug. > See http://wiki.eclipse.org/WTP/Conventions_of_bug_priority_and_severity > > > And, IMHO, building on windows will be more difficult than the benefit would > merit. Time and resource better spent on more important issues. > > Thanks though, for raising the issue. Honestly, it might be best to look at Athena Common Builder. It runs on multiple platforms, and just needs a build.properties update for the various platforms that it needs to run. It can handle the WTP projects. Just a suggestion.
