Community
Participate
Working Groups
When you attach JavaDoc and/or Source to a library that is automagically populated by Web App Libraries (because it's in the WEB-INF/lib directory) the association is stored in a file called classpath.decorations.xml. This file is located in your eclipse workspace, not your project .settings, and there's no way to change it. Thus, there is no way to check this file into scm for example, so that it must be maintained from machine to machine. The information in classpath.decorations.xml should be captured in a more standard manner. An extension of the solution provided by JDT (keep this info in the .classpath) seems to make sense, instead of creating an altogether different solution. Most importantly, this information should be associated with the project so it can be checked in to scm and shared between developers. Regards, Christian
Yes, this is a problem here and also with the jars picked up by the EAR Libraries classpath containter. I haven't been able to figure out any workaround.
Why can't that information be stored in the .settings directory instead? Also, when one upgrades a jar the source/javadoc association is lost. I opened a ticket against core for this (see #159843) which has been resolved. It would be fantastic is there was a way to ease the management of web app libraries' attachments as well.
mass update to remove target for all those targeted to 1.5.3 that were "normal" severity and "priority 3" (on the surface those dont' seem serious enough to fix in a maintenance release). If I have made an error pleasae reset target and set priority appropriately.
Hey Kosta, wonder if you had any thoughts on this bug and also bug 160163 which is essentially the same thing except for the EAR Libraries classpath container.
Storing in the workspace metadata is required because these attachments are absolute paths that will vary from machine to machine and should not be placed into project metadata. The JDT does not provide any mechanism for a classpath container to store this information. Storing it in the workspace metadata is typical (see the java runtime classpath container).
On second thought, the difference between the JRE Container and the Web App Libraries container is that the Web App Libraries container contains jars that are in the project vs. external. Therefore it is not unreasonable to assume that src / javadoc might be available in the project as well. Might be possible to relativize the paths we get from the JDT and store them in the project or at least give user a switch to let them control it. Making this an enhancement and removing the 1.5.3 target as this change would not be appropriate for a service pack release.
(In reply to comment #6) > On second thought, the difference between the JRE Container and the Web App > Libraries container is that the Web App Libraries container contains jars that > are in the project vs. external. Therefore it is not unreasonable to assume > that src / javadoc might be available in the project as well. Might be possible > to relativize the paths we get from the JDT and store them in the project or at > least give user a switch to let them control it. > Making this an enhancement and removing the 1.5.3 target as this change would > not be appropriate for a service pack release. Exactly. The way our team develops, we always include the libraries that we are developing in the WEB-INF/lib folder, because our library versions tend to change, but we don't want to have to go through every single application every time we want to use a new library version. So in this case, we use a different workspace to develop each project - to be able to keep the javadocs with the libs. If this is still in planning, what would be great is if the way you add Web Application libraries worked like the User Library mechanism. Be able to select the information from a directory of libraries - like the the User Library - and add them directly to the WEB-INF/lib folder, complete with the associated Javadocs. Being able to version control the javadoc / web application library configurations would be _awesome_.
any progress on this?
wow 4 years and still no progress? In my case I am using a workspace jar, so as long as people have checkedout a library project, they should be able to reuse this setting (if it were in svn) <classpath> <container id="xxx-web!org.eclipse.jst.j2ee.internal.web.container"> <entry id="C:/workspaces/eclipse/xxx/library/apache/log4j/log4j-1.2.15.jar"> <source-attachment-path>/library/apache/log4j/log4j-1.2.15-sources.jar</source-attachment-path> </entry> </container> </classpath> This goes along with <dependent-module deploy-path="/WEB-INF/lib" handle="module:/classpath/lib/library/apache/log4j/log4j-1.2.15.jar"> <dependency-type>uses</dependency-type> </dependent-module> in org.eclipse.wst.common.component file
does not work at all! this is terrible! come on, i'm not going to add each and every jar to a directory and then assign sources just to make sure the settings get stored in the .classpath file. Please fix it ASAP, this really makes my job, as well as my teammates, a pain in the lower part of the body. i just updated to the newest versions of eclipse and wtp so i guess i didn't miss any important fix here. Or is it coming in Indigo?
+1 Our team uses Eclipse and I thought I'd make life easier by checking the Javadoc locations into VCS. After some experimentation and googling I found that it is not possible. A concrete example - we use the Apache commons-lang jar as part of the web app libraries. Eclipse very nicely supports URLs for online Javadoc (no need to check the Javadocs into our repo). I added the Javadoc URL to the appropriate web app library: http://commons.apache.org/lang/api-2.6/ THis works fine but when I came to commit the change to the .project, .classpath or .settings file I found it was not persisted. I eventually found it tucked away in "<workspace>/.metadata/.plugins/org.eclipse.jst.common.frameworks/classpath.decorations.xml": <classpath> <container id="b20120910_ne_a!org.eclipse.jst.j2ee.internal.web.container"> <entry id="/home/sam/neal_charts/htrak/code/java/hmshow/WEB-INF/lib/commons-lang-2.2.jar"> <attribute name="javadoc_location">http://commons.apache.org/lang/api-2.6/</attribute> </entry> </container> I was expecting to see a change in .project, .classpath or .settings file that I could commit to VCS e.g. <classpathentry kind="con" path="org.eclipse.jst.j2ee.internal.web.container"/> <entry id="commons-lang-2.2.jar"> <attribute name="javadoc_location">http://commons.apache.org/lang/api-2.6/</attribute> </entry> Would be very handy to have access to Javadoc automatically upon checking out from VCS
+1 I maintain some custom virtual folder inside the pre defined WEB-INF\classes folder which contains links to src folders of other projects within the same Eclipse workspace. In the "Web App Libraries" tab of the build path config one can attach a source folder for the WEB-INF\classes folder itself and there I specify my custom virtual sub folder and that way Eclipse can easily resolve all sources for compiled classes I'm interested in. That would easily work for all useres checking out the project, if those refernces would be stored per project as well. Example: > /some_project/WebContent/WEB-INF/classes > [...]/some_pkg1/... > [...]/some_pkg2/... > [...]/some_pkg3/... > [...]/eclipseSrcLinks/some_pkg1 -> some_pkg1/src > [...]/eclipseSrcLinks/some_pkg2 -> some_pkg2/src > [...]/eclipseSrcLinks/some_pkg2 -> some_pkg2/src The attached source for [...]/WEB-INF/classes then is: > /some_project/WebContent/WEB-INF/classes/eclipseSrcLinks
