Community
Participate
Working Groups
Build ID: M20071023-1652 This is an expansion of issue# 70417. I request an integration of the following. - external tools variables - classpath variables - linked resources variables. There should be one single variable basis in eclipse used (as well as completely usable for substitution) throughout all of the eclipse IDE. It is very annoying when I could refer to ${workspace_loc:whatever-path} at external tools and then when I try to define classpath variables with ${workspace_loc:blah}, eclipse ide is non-responsive (rather, it is responsive with error msg). They should also share the same format - rather than ${var:xxx} in one place and then $var/xxx in another. According to Eclipse help on Linked Resources Path Variables: "By using a path variable, you can share projects containing linked resources with team members without requiring the exact same directory structure as on your file system." Which is not true - because the moment you move your workspace from C:\projects.cvs\mybotserver to C:\projects.svn\mybotserver all the variables (classpath and linked resources) break. Therefore, I recommend Eclipse team removing this untrue and misleading paragraph until it becomes true: "By using a path variable, you can share projects containing linked resources with team members without requiring the exact same directory structure as on your file system."
Variables should grounded on workspace as I suggested earlier - but they should be scoped on project sets. Which means, 1. A path variable is always relative to the workspace location. 2. The path separator of a path based on a path variable should always be forward slashes. 3. Since a workspace may have multiple project sets, the path variables should be local to a project set. Therefore, a variable "tomcat" defined in a.psf would not be visible to b.psf. 4. For people not using PSFs, they will always be using default.psf. Alternatively, We could have - workspace variables which would be visible to every project in a particular workspace; - project set variables which would be visible only to members within a project set. And if we wanted to carry this to extremes, we could have project level variables so that we have a hierarchy of variables: workspace -> project set-> project. And ... since we might wish to carry this variable integration that far, why not bring it to object-oriented extreme - we should call them resource objects rather than variables. So that a tomcat server could also be defined and exploited: ${servers[my tomcat 5.5].syspath:/commons/lib} ${connectors.jdbc[manufacturing mysql db].url}
Then, pursuant to an earlier issue I had entered (but I cannot remember which), variables/resources should be accessible to an external tool running independent of Eclipse. We need to integrate the programmer's realm with the build manager's realm. The build manager uses a megalomaniac ant script that runs every night to trigger a build without eclipse. Within the perspective of the build manager, there is no point for programmers to define any variables which the megalomaniacal build process is unable to access. There should be an export-resources-to-xml function which could be run by the programmer from eclipse for the benefit of the build manager's ant script.
Marking assigned for consideration post 3.4
