Community
Participate
Working Groups
I have a need to determine the mapping from resolved to raw classpath entries and am currently obtaining that information via the internal field JavaModelManager.PerProjectInfo.rootPathToRawEntries. If an acceptable public API currently exists that I can leverage to access these mappings, that would be ideal, otherwise, I would like to request that this information be exposed via the JDT API.
IPackageFragmentRoot#getRawClasspathEntry() provides you with this information, assuming you have root in your hands. I suspect we could have a more flexible API which would only consider a root path, and thus could be used with path from roots or CP entries.
Sthg like: IJavaProject#getRawClasspathEntry(IPath) IJavaProject#getResolvedClasspathEntry(IPath) may need the kind as well.
thanks for the info; that more flexible API would be great - I'll try out the IPackageFragmentRoot#getRawClasspathEntry() route now
I was able to get things working using IPackageFragmentRoot but it was a bit awkward and involved calls that bypass the resolved cp cache: I made calls to IJavaProject.findPackageFragmentRoots() for desired raw IClasspathEntry objects (findPackageFragmentRoots() like it skips the PerProjectInfo cache when resolving entries); since I ultimately need resolved IClasspathEntry objects, I then then had to map the paths contained in the resolved IPackageFragmentRoots back to resolved IClasspathEntry objects. Let me explain my use case and you can may be able to suggest a better public API approach (that leverages the resolved cp cache): -I want to retrieve all resolved IClasspathEntry objects whose corresponding raw entries have a specific attribute I had been doing this as follows: -get the raw classpath and find all raw entries that have the attribute (return if no raw entries have the attribute) -call IJavaProject.getResolvedClasspath() (which will use the cache if possible) -iterate through the resolved entries: -use PerProjectInfo.rootPathToRawEntries to find the associated raw entry (looks like this is exactly how IPackageFragmentRoot.getRawClasspathEntry() locates the raw cp entry) -if the associated raw cp entry had the attribute, then add the resolved cp entry to the list to return (some other checks are done as well)
ignore the resolved cp cache issue; still have the issue with mapping back from resolved IPackageFragmentRoots to resolved IClasspathEntries so would be nice to eventually have an API like you suggested: IJavaProject#getRawClasspathEntry(IPath)
Targeting for 3.4
Not sure if this is related, or the best place for the comment, but this is the only ticket matching "resolvedPathToRawEntries" I can find, and the comments seem relevant. Using 3.3RC1 with WST, I'm getting the following error with libraries added to the "J2EE Module Dependency" project properties panel. !ENTRY org.eclipse.wst.validation 4 0 2007-05-21 17:15:23.825 !MESSAGE !STACK 0 java.lang.NoSuchFieldError: resolvedPathToRawEntries at org.eclipse.jst.j2ee.classpathdep.ClasspathDependencyUtil.getComponentClasspathDependencies(ClasspathDependencyUtil.java:187) at org.eclipse.jst.j2ee.classpathdep.ClasspathDependencyUtil.getComponentClasspathDependencies(ClasspathDependencyUtil.java:146) at org.eclipse.jst.j2ee.internal.classpathdep.ClasspathDependencyValidator.validateInJob(ClasspathDependencyValidator.java:133) at org.eclipse.wst.validation.internal.operations.ValidatorJob.run(ValidatorJob.java:65) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) I've determined this is caused when a library is added to the build path, and the checkbox next to the library, in the J2EE panel, is ticked (to export to the server). Unchecking the library stops the error. My testing to determine the behaviour was using JUnit4. UI issues created as a result of this include the "Add/Remove Projects" dialog not appearing when the error-ing state is in place. Adding an external jar to the J2EE dependency panel appears to be OK. Mac OSX 10.4.9 Eclipse 3.3RC1 Apache Tomcat 6.0.10
Hi Paul, you must have an old WTP build and incompatible platform version (we never had an official build with that break since that set of components won't compile); the bug you were looking for is WTP bugzilla https://bugs.eclipse.org/bugs/show_bug.cgi?id=183894 If you grab any of the official WTP builds (with the corresponding Eclipse platform version), you'll be OK: e.g. WTP RC0: http://download.eclipse.org/webtools/downloads/drops/R2.0/S-2.0RC0-200705171455/
Unfortunately we ran out of time and the API is now frozen for 3.4. Deferring post 3.4
