Community
Participate
Working Groups
I need to have a container return an external classfolder in addition to jars that it can now return. It needs to be a classfolder and the container allows it to be dynamically found and not hard-coded. That way I supply a plugin to someone and they just add the container. The container will then find the correct class folder in the system to use.
Sorry Rich, we cannot allow this scenario since we would not be notified of changes in this external folder. Note that for external jar files, we keep the timestamp of the jar and thus we know when the jar file changes. But this would not work for external folders as the file systems usually don't change the timestamp of a folder if the change is inside this folder. You should first create a linked folder to the external folder, then return the path to this linked in your container. OK to close ?
It's not satisfactory, but if you can't do it, you can't do it. :-( The problem is that this guy is dynamic in my case, in which case the linkage can change, so how would the container handle this? It may even go away. So I don't see how I can handle link/change/remove in a dynamic way from the container.
I just ran into this exact case. I have a container which produces both jar and class dir entries. It's not really practical to create linked folders since these entries and folders come and go frequently. It seems to me that if JDT requires change notification and that's only available through linked folders, then JDT should auto-setup a linked folder in this situation. Making the container be responsible for this exposes an implementation detail that should stay hidden (in my opinion).
I agree that users should not be made aware of linked folders, but I don't quite see how the container provider cannot be held responsible for doing it. It is the one knowing which artifacts are required on the classpath, and that can figure what is no longer necessary. We could imagine a way for classpath entries to be created and requesting some linking under the cover, but this would need to be something brand new. Also, it wouldn't be obvious as to deciding when a linked folder is no longer necessary and should be discarded. Also, a linked classfolder entry would need to provide both a link name path ('lib/') and an actual OS location corresponding to it ('C:/myLibs/blah/classes/'). But again, the classpath initializer should be able to drive the linked folder creation directly.
I don't think the writer of classpath container should need to be aware of this limitation. It is inconsistent and confusing that it's perfectly ok to add a jar from an external location, but it's not ok to add a class folder. The explanation given shows this to be an implementation limitation. As such, any "fix" for this problem should be taken care of by the implementation (JDT). It's clear that there is already logic inside the JDT that detects this condition. It seems pretty straight-forward to add auto-linking at that point instead of requiring every container writer to duplicate this code. As an additional point, when the container is expanded in the package explorer, the paths are shown. It would be confusing for the user to see the actual physical location for the jars and some random linked location for the classes dirs, while they may be physically co-located. If it's the JDT that's tracking this auto-linking, it could easily display the physical location for auto- linked folders. As far as implementation is concerned... I don't think any extra info is needed in the classpath entry. The container api already provides for a way to tell the JDT what should be on the classpath and the JDT can detect when an external folder is given. If an external folder is not included in the returned list when the container is refereshed, then it's no longer needed. Note that the choice of the actual link target is not important. In the ideal world, the user is never made aware of it. The only thing that's needed for tracking this is a map of auto-linked paths to their auto-generated target names. When classpath is refreshed, the extraneous entries can be detected and links removed.
Deferring post 3.1
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
