Community
Participate
Working Groups
The existing code and solution for handling multiple roots only works for .tld and .jar *files*, not *folders* as is required when working with tag files. +++ This bug was initially created as a clone of Bug #329750 +++ Comment 12 David Mansfield 2011-03-02 15:45:48 EST i have a test case that isn't working. it's a tar.gz of a workspace I just created with a project not working. there are two "deployment assemblies" /web and /built/web /built/web/WEB-INF/tags contains foo.tag /web/departmentGroup/addEdit/addEditForm.jsp contains a reference to the tag which cannot be resolved (in fact the directory /WEB-INF/tags is red). There's also a Test.java for good measure ;-) I'll attach in a sec... Comment 13 David Mansfield 2011-03-02 15:47:53 EST Created attachment 190201 [details] project demonstrating failure to resolve jsp tag files i tried to attach a workspace but it's too large. i believe this project can be imported into a fresh workspace and it'll show the problem.
Created attachment 190216 [details] proposed patch (HEAD)
i'm not an expert on compiling eclipse. is there a jar file you could link/post/send me so I could test this?
Looks good.
Created attachment 190657 [details] feature patch This is a feature patch that contains this fix against Helios SR2. You should be able to unzip it into your eclipse install directory and just restart Eclipse. To verify check the Installation details (Help > About Eclipse then click Installation Details) and look for org.eclipse.jst.jsp.core. The version should be 1.2.304.v201103080933.
Committed to 3.2.4.
I'm having problems with this in Indigo SR1 - it seems to work for a fresh project, but after some time, the editor can no longer resolve the tagdir and shows red. I'd open a new bug, but the subject is exactly the same as this one which I opened 9 months ago.
(In reply to comment #6) > I'm having problems with this in Indigo SR1 - it seems to work for a fresh > project, but after some time, the editor can no longer resolve the tagdir and > shows red. > > I'd open a new bug, but the subject is exactly the same as this one which I > opened 9 months ago. Is it a Maven project?
no. not a maven project. I had thought this fixed but realized it wasn't working. I re-imported my project into a new workspace last Friday, and it was working, now it's not again (Monday). Is it possible this has to do with having multiple projects in the workspace? I think it stopped working after I imported some of my other projects into the new workspace. Is there some ambiguity to the paths in the org.eclipse.wst.common.component file? Should they (and can they) be qualified to a specific project? Right now I have, e.g.: <wb-resource deploy-path="/" source-path="/built/web"/> Where "/built/web" is a relative path inside the project itself.
(In reply to comment #8) > no. not a maven project. > > I had thought this fixed but realized it wasn't working. I re-imported my > project into a new workspace last Friday, and it was working, now it's not > again (Monday). Is it possible this has to do with having multiple projects in > the workspace? I think it stopped working after I imported some of my other > projects into the new workspace. > > Is there some ambiguity to the paths in the org.eclipse.wst.common.component > file? Should they (and can they) be qualified to a specific project? > > Right now I have, e.g.: > > <wb-resource deploy-path="/" source-path="/built/web"/> > > Where "/built/web" is a relative path inside the project itself. No, it's supposed to be project-relative. Are any of your projects referring to each other? Can you attach a failing one along with the contents of your workspace's .metadata\.plugins\org.eclipse.jst.jsp.core\taglibindex\ directory?
Yes. Lots of project dependencies. I have the dependencies set in the "java build path" and in the "project references" settings. Strangely, I just looked at the taglibindex source code, and saw that it deletes the generated index files when the project is closed. So I closed all of the projects. Then I re-opened them and the indices have not been rebuilt... There are no files in the .metadata/.plugins/org.eclipse.jst.jsp.core/taglibindex/ directory. Is there a builder that is missing? If I grep through the workspace for taglibindex I see only this line (which was split by bugzilla): ./.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jst.jsp.core.prefs:org.eclipse.jst.jsp.core.taglib.TaglibIndex=DIRTY
(In reply to comment #10) > Yes. Lots of project dependencies. I have the dependencies set in the "java > build path" and in the "project references" settings. > > Strangely, I just looked at the taglibindex source code, and saw that it > deletes the generated index files when the project is closed. So I closed all > of the projects. Then I re-opened them and the indices have not been > rebuilt... There are no files in the > > .metadata/.plugins/org.eclipse.jst.jsp.core/taglibindex/ > > directory. Is there a builder that is missing? > > If I grep through the workspace for taglibindex I see only this line (which was > split by bugzilla): > > ./.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jst.jsp.core.prefs:org.eclipse.jst.jsp.core.taglib.TaglibIndex=DIRTY It's not a builder, otherwise we'd be forcing you to build when you didn't want to just to make validation and content assist work. It won't be reindexed, and the index files recreated, until another piece of code actually asks for that information. The value you found is a precaution, warning the taglibindex not to trust its saved files in case the workbench crashed.
I figured it out. The directory /built/web is marked as a "derived" resource (which it is!). Setting this prevents the taglibindex from indexing these files even though they are part of the deployment assembly. Any chance to workaround/fix ? Is this desired behavior?
(In reply to comment #12) > I figured it out. The directory /built/web is marked as a "derived" resource > (which it is!). Setting this prevents the taglibindex from indexing these > files even though they are part of the deployment assembly. > > Any chance to workaround/fix ? Is this desired behavior? Yes, it is desired. http://help.eclipse.org/helios/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Fguide%2FresAdv_derived.htm "Derived resources are resources that are not original data, and can be recreated from their source files. It is common for derived files to be excluded from certain kinds of processing....A common use is to mark a subfolder of the project as derived when an "output" folder (such as the "bin" folder in Java projects) is created by the plug-in." Where's the not-built copy of those tag files? That path is what I'd expect to see in the org.eclipse.wst.common.component file.
Unfortunately, the web artifacts come from another project, and as far as i know, there is no way to build a deployment with web artifacts from another project, so we have a custom build system which creates a final "built" directory with all kinds of stuff (images ,css etc) copied (linked actually) from other projects. Not only that, but for legacy reasons (i.e. stupid developers), in the "source" projects, the directory structure is not the same as in the final deployment. Thanks for your help. I guess we can put this one to rest.
One other thing, though. It seems impossible for me to believe that in real use-cases people are able to commit many of the xml files necessary for a web-application (web.xml, struts, Spring etc) without any templating. Once you use templating, the files become derived, and the indexer cannot use them. It seems a major limitation.
Having found myself brought back to this exact bug over 2 years later by google search on the same problem :-(, I thought I'd post my "solution" (so I can find it in two years). Mark the directory with the derived tag files as not derived. (uncheck 'Derived' in folder properties). Close the project. Open the project Right click project -> validate Mark the directory with the derived tag files as derived.
(In reply to David Mansfield from comment #16) > Having found myself brought back to this exact bug over 2 years later by > google search on the same problem :-(, I thought I'd post my "solution" (so > I can find it in two years). > > Mark the directory with the derived tag files as not derived. (uncheck > 'Derived' in folder properties). > > Close the project. > > Open the project > > Right click project -> validate > > Mark the directory with the derived tag files as derived. February 2017. Still. Effin. Happening. This was driving me batty. This "fixed" it, thanks. I was getting this before I even created my first tag. I had to create a tag before the tags directory was marked as "derived." After that, I could do the uncheck-close-open-validate-check steps.
(In reply to Craig Prall from comment #17) > (In reply to David Mansfield from comment #16) > > Having found myself brought back to this exact bug over 2 years later by > > google search on the same problem :-(, I thought I'd post my "solution" (so > > I can find it in two years). > > > > Mark the directory with the derived tag files as not derived. (uncheck > > 'Derived' in folder properties). > > > > Close the project. > > > > Open the project > > > > Right click project -> validate > > > > Mark the directory with the derived tag files as derived. > > February 2017. > > Still. Effin. Happening. > > This was driving me batty. This "fixed" it, thanks. > > I was getting this before I even created my first tag. I had to create a tag > before the tags directory was marked as "derived." After that, I could do > the uncheck-close-open-validate-check steps. Or 2018, even.
