Community
Participate
Working Groups
Next to shampoo-and-conditioner 2-in-1, the JDT classpath container is arguably the best invention of the last 100 years. One limitation that exists though is the inability to resolve the container to a classpath entry that directly references a class folder in the file system. see bug 109137 for one such use case that would benefit from this support. There are certainly more that could benefit from it. PDE is not the only client that uses classpath containers (but it is certainly the coolest). To recap comments from bug 109137, some seem to refer to 'linked folders' as the answer to this problem, but linked folders in this case have several problems/limitations: Problem #1: Linked folders cannot be created during a POST_CHANGE event when the resource tree is locked (bug 64340 comment 18) Workaround for problem #1: during a POST_CHANGE event, create a classpath entry and have it reference a non-existent linked folder linking to the class folder on disk. Then during a PRE_BUILD event, right before jdt/core validates the classpath, you get a chance to create the linked folder that you referenced earlier. This would allow the compilation to proceed normally without JDT being aware of the trick that was done. Problem #2: Linked folders dirty shared .project files with non-sharable data. We don't want to relive another episode of bug 46668. This one is a deal breaker. The .project file must not get dirty and must remain true to the dynamic nature of the container. Problem #3: The classpath container client needs to keep track of linked folders since he would have to remove any folders he created should the dependency on the corresponding plug-in goes away. Problem #4: Creating linked folders in every project that needs them may result in a large number of links being created. Is the client expected to create a special place where he can pool/recycle linked folders? These are the problems that have come up so far. Expecting clients of classpath containers to address and/or work around all these issues on their own is a big burden on them. Each will have to come up with their own creative/hackish solution. That's not in our JDT contract, so to speak. We need to come up with a solution that will allow a client to resolve a classpath container to a classpath entry that references an external folder with the same ease that they currently can reference an external JAR. Interestingly, if you read the entertaining bug 46668, you will see a previous crisis that is circumstantially very similar to this one, but with a happy ending. I am confident we can do the same here.
Is there any update on that? I really would love to see that as soon as possible as bug#109137 which seem to block this one really hard!
See also bug 208654.
Hey guys is there any chance to get this fixed some day? According to Wassim this blocks bug 109137 which is on of the bugs with the most votes in the Eclipse bugzilla. Is this something which could be addressed in the 3.4 time-frame? Thanks Bernd
Is there any love from JDT on this that it may now be possible? http://wiki.eclipse.org/Resource_Deltas_for_External_Folders
Note this was not on the plan for 3.4. I will try to find some time to see if we can use http://wiki.eclipse.org/Resource_Deltas_for_External_Folders
Jerome, If there's anything I can do to help, test, or literally whatever just let me know. Solving this problem would be a very big enhancement for EMF's workflow and for pretty much any client who is building a generator framework.
Ed - can you explain the EMF usecase ? Just being curious...
The same is true for me. I'd really like to see this. If I could help out, let me know. Bernd
This wiki document describes the setup steps we follow to bootstrap our development environment. http://wiki.eclipse.org/EMF/Getting_Source Some details are in http://wiki.eclipse.org/EMF/Getting_Source#The_notorious_bug_109137 In http://wiki.eclipse.org/EMF/Getting_Source#Setting_up_the_Eclipse_Workspace there is a script we run in order to build jars. It's really quite painful. The other blocked bugs have details as well.. Anything I can do to help, just say the word!
I am also willing to come out of exile/retirement and do the corresponding work on the PDE side and/or help out in any way. i have been "project-managing" (i.e. not doing anything useful ;) for a few months now and it would be good to get back to coding.
*** Bug 77113 has been marked as a duplicate of this bug. ***
Created attachment 90733 [details] Proposed fix and regression tests
Fix and tests released for 3.4M6
Thanks guys! PDE can support the impossible now.
Just to make sure that people understand the consequences of adding an external library folder on the classpath, I wanted to clarify that the current design doesn't allow the resources in this folder to be edited (or deleted, or moved, etc.) External library folders have been designed to be able to compile (or run) against them, so that you can reference and use types in these folders. The assumption was that changes in these folders were made externally to Eclipse. Will that be an issue for anyone? I.e. 1. Do you usually edit resources in library folders within Eclipse? 2. Do you expect to be able to edit these resources within Eclipse? 3. Will this restriction block you in your work? 4. How bad would you like us to remove this restriction?
Jerome, Here's one of the ways we expect to use this. We'll install a new Eclipse driver and then we'll extract all our source from CVS, which will compile that the source to the bin folders. We'll then exit Eclipse, and use a link to include all the workspace plugins in the main Eclipse and use the same configuration file that Eclipse uses to launch a runtime workspace to relaunch the main workspace. This will redirect the bootstrapped workspace plugins to use their bin folder contents for the runtime. The result will allow us to use our runtime and generator to regenerate the runtime and generator models. Of course changes made within the workspace are likely to change the contents of the bin folder. I wouldn't expect already loaded classes to be affected. Compilation within this bootstrapped workspace doesn't actually need to external folders support. The second way we expect to use this is to be able to launch a runtime workspace and to be able to test our generator in that runtime workspace. The generator will be used to create new projects and those projects will have plugin dependencies on the runtime plugins in the main workspace and hence the generated Java code in the runtime will need to compile against those main workspace plugins' bin folders. Of course going back to the main workspace and changing the plugins will update the bin folder contents. It seems reasonable that such a change would require terminating and relaunching the runtime workspace (just as today a jar that's in use would be locked and couldn't be changed without terminating the runtime workspace). I don't expect in the runtime workspace to be able to modify the external folder (which is a folder in the main workspace). I do expect that such changes might happen externally, as when I go to the main workspace and modify some code. I suppose that's an external change though. Will a refresh in the runtime workspace be sufficient to update it's knowledge of the external folder contents. Obviously I don't expect the running workspace IDE/environment to change except to the extent that it supports hot debug as it does today. Does all this make sense. Will those two scenarios work? It will be a huge improvement to our workflow, both in complexity and turnaround time, to avoid having to create jars...
(In reply to comment #16) Thanks Ed. Yes both scenario will work from JDT/Core standpoint. I guess there is still some work needed on the PDE side (but that's out of my reach :-) ) Just one limitation for now (see bug 219566): if you select a project in the runtime workspace and hit Refresh, it won't refresh the external library folders. You will have to either enable auto-refresh, or deselect the project and hit refresh. This will refresh the entire runtime workspace including the external library folders.
Jerome, Thanks so much for making this improvement! The F5 without a selected project is tricky, but not a big deal. This will be a fantastic improvement to our workflow and for anyone working on generators that produce code which must be compiled against their runtime. Many thanks to the folks who are helping make this happen!!
Jerome, can you please clarify/summarize what this change bring in for the end user and for plugin developers? The classpath containers already supported external jars and maybe even class folders. So what will be different with the new API? Thanks.
Before this change, JDT didn't support external folders on the classpath and hence PDE could not support a classpath container that resolves to an external folder opposed to an external jar. Wassim mentioned that explicitly in his initial description: > One limitation that exists though is the inability to resolve the container to > a classpath entry that directly references a class folder in the file system. So this new support allows external folders to be just as fully supported as external jars both directly by JDT and by classpath containers. The biggest impact for typical users will be that it allows runtime workspace plugins to compile against the plugins made available in the main Eclipse's workspace. I.e., it eliminates the need for a deployment step or some jarring scripts to turn folders into jars. That's my $0.02 view of it anyway...
Ok, if I understand this correctly, it wasn't really been prohibited before, as IClasspathEntry.getPath() could return link to the jar or folder if entry type is CPE_LIBRARY, which is allowed type for IClasspathContainer according to its javadoc. So, this change is basically making it work if IClasspathEntry.getPath() returns path to the folder for container entry? It is correct or there is something else in there?
(In reply to comment #20) Thanks Ed for clarifying. (In reply to comment #21) Yes, that's correct. Before you were able to create a classpath entry pointing to an external folder, but since it was specified that it was not supported, you would not be able to use it: JavaConventions,validateClasspathEntry(...) would fail, and attempting set a classpath with such an entry would result in a classpath marker in the Problems view.
Thanks Jerome
Created attachment 91023 [details] Fix and tests for non-Java resource support in external class folders I missed the support for non-Java resources in external class folders in the first patch. This fixes this issue. This is released in HEAD as well.
Jerome, I wonder if these changes made it any easier to allow source folders in the classpath containers requested on bug 100508 ?
(In reply to comment #25) > Jerome, I wonder if these changes made it any easier to allow source folders in > the classpath containers requested on bug 100508 ? Sorry Eugene, but these changes have nothing to do with supporting source folders in classpath containers.
Created attachment 92901 [details] Fix for refresh problem With this fix, refreshing of external folders is now done asynchronously when the project is refreshed. The fact that it is asynchronous is ok when this happens in the IDE. If other clients want to make it synchronous when they call refresh on the project, they will have to join on the manual fresh familily. E.g. IProject project = ... project.refreshLocal(IResource.DEPTH_INFINITE, null); Job.getJobManager().join(ResourcesPlugin.FAMILY_MANUAL_REFRESH, null);
(In reply to comment #18) > The F5 without a selected project is tricky, but not a big deal. To make it clear, this limitation is now gone with the patch from comment 27. You can now select the project and hit F5 and it will also refresh the external folders referenced on this project.
Verified for 3.4M6 using build I20080324-1300.
*** Bug 208654 has been marked as a duplicate of this bug. ***
This does not fully work for all cases: "The type javax.xml.soap.MimeHeaders cannot be resolved. It is indirectly referenced from required .class files" I am using latest Eclipse 2021-03.
