Community
Participate
Working Groups
Build ID: M20080221-1800 Steps To Reproduce: Defining sourcepaths for libraries is a really useful feature. Being able to define them based on a classpath variable would be even more useful. In my build I keep the libraries sources and javadoc archives external to the project. This makes it easier to ensure that these files do not get shipped with my distribution build. In order to support multiple platform development in my build it is necessary to define classpath variables for external locations - windows and nix have different paths. Currently the sourcepath does not support classpath variable extensions so I need two .classpath files. I also need to repeat the external path in the sourcepath for all my files over and over again, making a change to the location much more difficult. More information: Great product. I am a long time user and have logged many bugs some of which were fixed =) Thank you for the consideration.
I think this refers to development time source attachement - which belongs to JDT UI/Core, rather then debug.
The workaround to this is to base the libraries on a variable that points to the project src directory. You can then use a different variable that points to the your external source and docs and extend that to locate the source. The only issue is that the javadoc location doesn't allow use of a variable even in this case so unfortunately that doesn't work very well. The solution that I've found is to create a linked resource folder to my external source/docs directory and then use that in the source and javadoc location. This isn't ideal though as it makes the source and docs more coupled to my project - the thing I was trying to avoid in the first place. Fortunately the eclipse build and my ant distribution build are seperate and having a link in the eclipse build is transparent in the directory structure to ant and much safer than having an actual directory within the source tree. I'll log the javadoc location not accepting a variable as a seperate bug.
Actually I wish it should work in totally another way - remove sourcepath from project based sourcepath, because two identical JAR file from two projects should share same setting, move the config to a workspace setting. Currently the sourcepaths for libraries are saved in .classpath file, which is usually checked in to source control. I don't want to fight my team-mate if anyone disagree a standardized external zip file path. If I were able to standardize the team, a common user libraries or simple shared project will help. Another issue of the current way is, there are some library setup from plugins and some other plugin do dynamic updates. e.g. GROOVY_DSL_SUPPORT / maven. The idea is to use MD5 hash/filename name pattern. when the sourcepath in .classpath is absent or file not found. 1. hash a md5sum the enclosing JAR file contains the .class. 2. lookup the sourcepath from a user defined mapping table by the md5sum. 3. a new config UI in Preferences/Java/Build Path/Source Libraries to update that. I can found XML/XML Catalog is doing thing some how similar. In XML Validator/Editor, User/Plugin Specified Entries override the actual URL written. The idea of using md5sum, not the filename/path is because some 3rd party JAR usually share same JAR file name in different version.
