When you canceled the patch, it seemed to be because you didn't like the degree of complexity I placed in the ant script.
Yes. The build scripts are already awkward to maintain, and what little maintenance occurs happens as in this issue: enough to fix the immediate problem. I don't think this imposes a high maintenance burden, as the eclipse build is hardly high-traffic, but I don't think we disagree that the current patch is an indirect fix. If that's all there is, then fine, but I'd like to be sure that this does not incur undue technical debt.
I implemented conditional logic in our buildfile to check the platform, and inject the correct jar dependency into the Eclipse project classpath file if it's being constructed in a platform which requires this jar.
More precisely, the patch injects XML comment characters into the Eclipse project classpath file to exclude a non-existent jar. Unless the eclipse-files target were rewritten to generate- rather than inject paths into- the classpath file, I agree, it's not clear how to effect what the current patch achieves.
this isn't related to "Eclipse arcana." The requirements imposed by Eclipse are straightforward: we need to create a classpath file containing a list of exactly the jars necessary to compile the project.
I suggested the eclipse dev list because this can't be the first time someone has thought about this issue. Before settling on injecting XML into an eclipse configuration file using ant properties, it's not unreasonable to ask if there's a better way.