Community
Participate
Working Groups
the build.xml file for ecf.provider (is missing in the component list) has fix path setup in target "provider.jar". e.g. <pathelement path="../../plugins/org.eclipse.core.runtime_3.1.0/runtime.jar"/> This path work only if the workspace is in eclipse folder and not somewere else. Proposed Solution: use ${user.dir} or an environment variable.
Fixed in checked in build.xml. Absolute path replaced with '.' (only appears in eclipse.refresh task), and changed erroneous '@dot' with '.'. Both of these problems due to bugs in the Eclipse build.xml generator. Need to make sure that bugs are entered into bug tracking for platform (if not already there).
I think this was an missunderstanding. I was talking about the "provider.jar" jar target not the "refresh" target. In the new version 1.3 I still get compiler errors because he can not find the e.g. runtime.jar My workspace is in a complete different directory, so you can not navigate by "../../plugins" into the plugin path.
(In reply to comment #2) > I think this was an missunderstanding. I was talking about the "provider.jar" > jar target not the "refresh" target. > > In the new version 1.3 I still get compiler errors because he can not find the > e.g. runtime.jar > > My workspace is in a complete different directory, so you can not navigate by > "../../plugins" into the plugin path. This build.xml was generated via the PDE, so I think that the general fix for this problem lies with a fix for the PDE build.xml generation code (i.e. it should generate paths that require the default workspace location). Have you submitted this as a bug report to the PDE bug lists? We will try to put in a workaround to our build.xml file, but we hope to remove this build.xml file totally and just use the dynamically generated build.xml from the PDE...the only reason we have a checked-in build.xml for the provider project at all is that we discovered another bug in the PDE build.xml generator that was preventing automatic build from happening properly! In any event, let me know if you've reported this to the PDE bugs list (I haven't looked through the avaiable projects so I don't know which one would be appropriate). Thanks.
No i didn't report this to PDE
Steven, Is this fixed in a more recent version of the PDE? (i.e. 3.1M6)? If not, you should report it to PDE (or I will) immediately so it can get into the final 3.1 release. We on the ECF team cannot fix this directly. (In reply to comment #4) > No i didn't report this to PDE
The build.xml scripts generated are not meant to be reused. They are generated according to a specific setup (workspace location, eclipse install location, etc).
(In reply to comment #6) > The build.xml scripts generated are not meant to be reused. > They are generated according to a specific setup (workspace location, eclipse > install location, etc). Pascal...the reason we used build.xml at all was that the PDE would not complete a build successfully without a hand-tweaked build.xml. That's the bug. As I recall the generated build.xml had some property like ${dots} where the 'dots' property didn't exist and so the generated build.xml file crashed with path elements that looked like this: <pathelement path="${dots}/${dots}/plugins/etc with no substitution for the ${dots} Stephan used our hand-tweaked build.xml and reported this bug to us. We've since removed the hand-tweaked build.xml completely from the ECF build as 3.1M6 seems to generate build.xml files that work (for us, anyway).
