Community
Participate
Working Groups
A library by definition is something that many can share. Being unable to create a shareable user library is a severe limitation of this functionality. There definately needs to be a way to use a CLASSPATH_VARIABLE for jars within a library so that many users can share the same library definition by defining a variable which abstracts out the local machine paths. I'm attaching a patch which (mostly) accomplishes this except for 2 issues that I need help in resolving: 1) After defining a user library based on a variable, if I then change the variable, I need some way to force java build path updates of projects that depend on user library. May be some other strangeness associated with this too (i.e needs more testing =) 2) If I define a user library that uses a variable, the preference page shows the variable nature of the library for the lifetime of that eclipse process. However, if I then restart eclipse, the preference page no longer shows the variable nature even thow it is present in the underlying object. Has something to do with CPUserLibraryElement.UpdatedClasspathContainer being there before the restart, and UserLibraryClasspathContainer being there after. Note that I had to redefine UserLibraryClasspathContainer.getClasspathEntries to hide variable nature as needed by the IClasspathContainer spec (to get user lib working in a java projects build path)
Created attachment 20434 [details] patch to jdtcore to enable this functionality Also need to patch jdtui
Created attachment 20435 [details] patch to jdtui for this functionality also need to patch jdtcore
The jdtcore patch was against HEAD, the jdtui against v20050401-1200 as head would not compile in M6.
1) jdt.core is missing an notification mechanism for classpath variable changes 2) the problem is here that the preference page communicates with the store with the normal classpath container protocols: JavaCore.getClasspathContainer(..) to get a container initializer.requestClasspathContainerUpdate() to set entries in a container Both of these API do not allow the classpath entries to be variable entries. I don't really see how you could trick that. The clean way would be that jdt.core allows classpath variable entries. moving to jdt.core for comments
I've gotten this fully working, but as martin said its not clean =) The UI code needs to be able to access the unresolved classpath entries, and the easiest way to do this was for me to add a ctor to UserLibraryClasspathContainer to be constructed with resolution disabled, and construct that instance in UserLibraryPreferencePage instead of using the container from JavaCore. Of course this breaks the access rule for internal packages between jdt.ui and jdt.core. Allowing ClasspathContainer to contain variables would be a better solution.
Ok, I have a naive solution to allow Variables in containers. I'm attaching new patches. Eveything seems to work for my simple test cases, but there is probably some underlying reason for not allowing variables in containers that I did not exercise. If someone could run these patches through the eclipse test cases and/or explain to me why variables are not allowed in containers, maybe I can come up with a solution, and we can possibly get this into the 3.1 release =)
Created attachment 20529 [details] patch to jdtcore with container/variable changes
Created attachment 20530 [details] patch to jdtui with container/variable changes
An alternative implementation that should allow me to do what I want would be to add an IClasspathContainer2 extending IClasspathContainer with a method getUnresolvedClasspathEntries(). This might (?) have less of a chance of breaking something that changing the behavior to allow getClasspathEntries() to return Variables.
*** Bug 98465 has been marked as a duplicate of this bug. ***
*** Bug 97752 has been marked as a duplicate of this bug. ***
What is the current state of this bug? Is it going to be included in the 3.2 release. I've looked at the New and Noteworthy for M1 and M2 and don't see any mention of it. Are source and javadoc attachment locations being considered as included in this bug? i.e Can one add source and javadoc attachments to a lib using a defined classpath variable. This would be a great help to a team as all jars/source and javadoc can be shared between the whole team very easily. This has some great side effects. 1. Content assist works for all external libs without any timewasting configuraion. 2. Source code for open source projects can be inspected to know exactly what is being done intead of additional timewasting in the form of a developer having to go to a browser, download the source, attach it to the jar [with an absolute path because classpath variables are not supported] and then have to make sure not to commit the changes to the .classpath file or .userlibraries file so that he/she won't disturb other team members with absoulute paths that won't work on their machines. It also means a team can have one libs folder in their content repository with all libs/javadocs and source instead of commiting many different jars many times one only commits a .userlibraries files which point to all of this stuff dynamically.
No planned for 3.2, worth reconsidering in next release.
setting resolution to later as stated by comment 13
Reopening to consider for 3.3
Bug 70417 is more general than this bug. *** This bug has been marked as a duplicate of 70417 ***
