Community
Participate
Working Groups
I'm not sure if this is a bug, or an intended feature, but it used to be possible (in early 3.0 milestone builds) to add a variable (which points to an external directory) to the Libraries tab of the Java Build Path in the project properties. This was handy as it meant any run configurations created on that project then had that directory in their runtime classpath, rather than having to add the variable to each run config. However, if you add a directory pointing variable to the Java Build Path it now results in a build error: "Required library cannot denote external folder: 'C:\...' for project ..."
This is important to me too. I'm constantly running into where I need a class folder, but the folder is not in the project. It is somewhere else. It is a real pain to have to create a linked folder in the project just so I can get to the classfolder. Could you please make class folders prime-time accessible? Both from the build path AND from a container. I have some dynamic containers that need to supply class folders instead of jars and I can't do that.
At the Core level, all the pieces are there. JDT UI (and implementors of the containers like PDE UI) should create the link for you if the folder is external. Moving to JDT UI for comment
This is definitely one area where our UI should be more intuitive. You currently need to go 'advanced' to enable linked folders, but this should be transparently performed when selecting a folder which happens to be located externally from workspace.
I didn't want to create a "linked" folder. That doesn't really work for my purposes. I want to be able to use an external class folder in the build path. Especially from a container. I want to dynamically contribute the external classfolder from the container because it can change depending on the installation. I'm opend bug 81402 as an explicit request for classfolder support from a container.
Martin, any comments.
Creating a linked folder does a bit more than an external class folder, e.g. you would get all the resources in it, would see them in the package explorer and unfortunatly be able to modify them. Linked resources are also not so handy when sharing, you would see a name on the .classpath file which doesn't even have to be the name of the external folder (links can have any name you give them). Can't classpath variable entries point to external folders?
No. They only did at some point, by mistake. Again the main reason for not allowing these is the updating story. Given they are not resources, the incremental updates are busted. We would need to keep individual timestamps of all the files, and reconstruct deltas to behave ok in model or builder. I could imagine the user requiring to force a refresh of the library when changing, and this would be considered as a major change (i.e. like a classpath change triggering full build). If that would be a workable approach, then maybe we could reconsider our decision. Though it is getting too late for 3.1 I am afraid.
Is this now a candidate for 3.2?
You don't want a link to an external folder, but a classpath variable entry that can point to an external folder, right? Moving to JDT core
Could we get a disposition on this request for 3.2: ability to add a classpath variable entry that points to an external folder. Thanks.
Referring to an external classfolder, either directly, or indirectly through a classpath variable, or a classpath container is not planned for 3.2. The problem is not so much about making it available on the buildpath; but rather about: how do we incrementally compile against it in a satisfactory fashion. We need to find modified classfiles, and recompile dependants. We do this for external JAR/ZIP files, but not for individual classfiles. Doing it would require visiting classfolder, searching for different classfiles on a per file basis, and treat these as structurally changed in our incremental compilation loop. Bookkeeping all these data is going to slow down every single small compile action (think changing one line in an editor); and requires to duplicate the logic which is inside the platform/resource support currently. This is why using a linked folder is the best answer. It is going to have these external classfolders become managed resources from now on, and we will be able to compile incrementally against these.
JohnA - couldn't we imagine a mode where the platform could be told to track file changes outside the workspace ? (future) This way, it could broadcast such resource deltas, without requiring clients to use linked folders. As a result, we could enable external folders on the buildpath, and benefit from resource change tracking. Plus all external tools (ant scripts) would run unmodified, as opposed to getting burnt today from not able to understand what a linked folder is mapping to...
Why is this any harder than "When the variable points at something outside the workspace, we under the covers create a linked folder that points at it?"
Hi, can someone please confirm that this will or will not be addressed for 3.2. Thanks.
Jay - I confirm that no action is planned for 3.2. Re:comment 13 - Mike: is your question aimed at JohnA or me ? In case you asked me, then creating a linked folder under the cover is not an option since it will not match what the user told us (he meant external folder, and we would show him some other pseudo folder (the linked one) everywhere); also linked folders are not shareable, i.e. if it appears on a buildpath, then it is not going to be recreated on a teammate's install and will give him no clue as to what the folder is supposed to map to). I believe my proposal for supporting arbitrary resource mounting, and leaving them at their original locations is more powerful since it will also allow seamless integration with all script-based tools, which isn't the case with linked folders.
This sounds like a rather significant enhancement request and not really a bug. Should the severity be set to enhancement. I ask because I hear people asking about this one for 3.2.2. So far, I am saying no because it would be too big of a change and is really new function, but I want to make sure I am reading this correctly.
*** Bug 93135 has been marked as a duplicate of this bug. ***
May be a duplicate of or depends on bug 182537...
We've received customer complaint about this issue, when they tried to migrate from RAD6 (which is eclipse 3.0) to RAD7 (eclipse 3.2). They used to define path variables, and added them to the build path in RAD6, so that their xml files (contained inside those folder) can be found during runtime. They can no longer do that. Currently they have tried putting all the xml files into a JAR, and then add the JAR to the build path. That seems to work around the issue. But it is painful to do so, stated the customer. Any idea when this bug will be fixed?
(In reply to comment #19) > We've received customer complaint about this issue, when they tried to migrate > from RAD6 (which is eclipse 3.0) to RAD7 (eclipse 3.2). > > They used to define path variables, and added them to the build path in RAD6, > so that their xml files (contained inside those folder) can be found during > runtime. They can no longer do that. > > Currently they have tried putting all the xml files into a JAR, and then add > the JAR to the build path. That seems to work around the issue. But it is > painful to do so, stated the customer. > > Any idea when this bug will be fixed? > This is currently not on the 3.4 plan. Other possible workarounds for your customer: 1. add the external library folder to the runtime classpath (instead of the build path) if they are running a Java launch configuration 2. add a link folder to the external library folder, and add this folder as a library on the build path Would either of this workaround work for your customer ?
Currently, the customer putting all his xml file inside a JAR, and used that as a workaround. I mentioned to him the 2nd workaround, haven't received any feedback yet. The 1st workaround will not be applicable, as the customer's project is web project.
what-if: We introduced a new kind of classpath entry (or enhance existing class folder entry) to recognize external folder. Then when resolving the classpath, we create a link folder automatically. In package explorer, we do not show the link folder name, but instead its actual location (so it would only look odd in the navigator). We recommend using relative path in CP entry; so we can share these entries in source control.
I've also got a customer with this need; in his case, he's got a bunch of XML files sitting in a directory, that he needs to access at run-time. The XML files are part of a 3-rd party piece of s/w, so he's quite reluctant to simply JAR them up and access them that way. He, too, wishes he could use a variable to point to a directory as part of the build path.
Will be fixed as part of fix for bug 182537 *** This bug has been marked as a duplicate of bug 182537 ***
Verified for 3.4M6
Re: comment #20, suggestion 2: How can one linked folder added as a library to the project's class path?? The dialog offers only the known options - JSF Libraries, User libraries, etc etc. No possibility to add a whole folder at once.
(In reply to comment #26) > Re: comment #20, suggestion 2: > How can one linked folder added as a library to the project's class path?? The > dialog offers only the known options - JSF Libraries, User libraries, etc etc. > No possibility to add a whole folder at once. > Pre Eclipse 3.4, press Add Class Folder, then New Folder, then Advanced. You can then create a link to an external class folder. With Eclipse 3.4, simply press Add External Class Folder
... that doesn't always work: "The type javax.xml.soap.MimeHeaders cannot be resolved. It is indirectly referenced from required .class files" I am runnign the latest Eclipse 2021-03.
