For help with installation, bugs reports or feature requests, please head over to our new forums.
Genuitec Community on GitHub
- This topic has 14 replies, 3 voices, and was last updated 20 years, 4 months ago by
.
-
Posts
-
I get unknown tag warnings in the jsp editor whenever I have the sun reference implementation of jsf specified in the classpath even though the tlds are in the jars on the classpath. When I point to the myfaces jars I don’t get the warnings (and annoying yellow squiggly lines) and everything seems happy. I don’t have any references to the tlds in web.xml in either case. Why the different behavior?
Here’s the config info (nothing in the log):
*** Date: Tue Nov 01 10:33:53 PST 2005
*** System properties:
OS=WindowsXP
OS version=5.1
Java version=1.4.2_06*** MyEclipse details:
MyEclipse Enterprise WorkbenchVersion: 4.0.3 GA
Build id: 20051025-4.0.3-GA*** Eclipse details:
Eclipse SDKVersion: 3.1.0
Build id: I20050627-1435Eclipse Project SDK
Version: 3.1.0
Build id: I20050627-1435Eclipse Platform
Version: 3.1.0
Build id: I20050627-1435Eclipse Java Development Tools
Version: 3.1.0
Build id: I20050627-1435Eclipse Graphical Editing Framework
Version: 3.1
Build id: 200509301327Eclipse RCP
Version: 3.1.0
Build id: I20050627-1435Eclipse Plug-in Development Environment
Version: 3.1.0
Build id: I20050627-1435Eclipse startup command=-os
win32
-ws
win32
-arch
x86
-launcher
C:\eclipse3.1\eclipse\eclipse.exe
-name
Eclipse
-showsplash
600
-exitdata
a24_68
-vm
C:\WINDOWS\system32\javaw.exeThere shouldn’t be any. If you add the Sun RI back, restart MyEclipse and then rebuild the project (clean it) do the errors stay? What specifcally are the errors (please copy-paste one of them)
Doing a clean doesn’t help. This isn’t an error but a warning – when editing the jsp I get the squiggly yellow lines with a yellow box in the right margin. If I hover over the box, the message is something like “Unknown tag (f:view)”. Autocomplete and code help obviously doesn’t work at this point within these tags. I said previously that this seemed to work OK for myfaces libs, but now I can’t even get the taglibs recognized when changing the jars in the classpath to myfaces.
After you change out the taglibs on the project, can you try rebuilding the project by selecting Project > Clean…
How did you create your project? Did you create a MyEclipse Web Project and then add JSF capabilities to it? Can you try that and see if the new project gives you the same problems?I did the clean via the project menu and that didn’t help. When creating a new project it works fine, but I’m trying to use myeclipse to work on an existing jsf project that’s structured slightly differently than the myeclipse web project so that’s not much help.
I don’t see a way to remove the jsf capability from a project once added, since I was going to try to readd jsf. Is that possible? Is there any kind of logging I can turn one to see why it can’t find the taglib?
jkirby,
the layout of the project can have a lot to do with why the editor can/can’t resolve resources, so that’s not just a minor detail. How is your project laid out? Are the myfaces libs and Sun RI libs in different directories from eachother.Wait a minute, myeclipse is not actually using the java classpath to find the jars is it. It’s only looking in the WEB-INF/lib directory. I just looked at the test project I created and when I remove the RI jars from WEB-INF/lib and only have them in the eclipse project java classpath I get the same behavior I’m seeing on my project.
It’d be nice if there was a way to get myeclipse to actually use the project java classpath as well as looking at WEB-INF/lib or provide a myeclipse configuration where I could specify the path to use for resolving taglibs. At the very least, you need to document what is required for the editor to work properly…
For the project I’m working on the dependent third party libs aren’t actually copied into the deployment location until build time. This is mostly because of a need to manage the libs for licensing purposes so we can readily identify what is ours and what comes from elsewhere. In other words we have a staging area where the project files we create actually reside which only nominally resembles a webapp and a deployment directory where the final webapp is assembled before adding to a WAR by the ant build. Myeclipse is configured to point to the staging area which has an empty WEB-INF/lib, but maybe it should point to the deployment directory instead…
Wait a minute, myeclipse is not actually using the java classpath to find the jars is it. It’s only looking in the WEB-INF/lib directory. I just looked at the test project I created and when I remove the RI jars from WEB-INF/lib and only have them in the eclipse project java classpath I get the same behavior I’m seeing on my project.
It is using the classpath, however JARs external to your workspace, because of an Eclipse platform design, are not parsed for TLDs.
That’s good to know… It’s pretty common to have libs outside the workspace (particularly if you’re using maven) so this is a pretty big gotcha that should be highlighted.
Is there a way to change the web-root folder for the project on the MyEclipse-Web properties page? If I point to my build location instead of the source location the correct files will be in WEB-INF/lib. Don’t see any way to reset this on an existing project though…
We are going to make that field editable again in the near future, for the time being you can edit the .mymetadata file and change it manually there, then close and reopen your project (and optionally rebuild it).
One other question on paths while we’re on the topic. Is there a similar constraint on finding xsd’s for validating xml files. I have the same xml file in two places in my workspace, one in a directory web/myapp and a second in a directory build/web/myapp (the later is where the build drops it). The build location validates fine, but the other one gives an error in the problems tab:
Severity Description Resource In Folder Location Creation Time
2 cvc-elt.1: Cannot find the declaration of element ‘view’. navModel.xml dcApplication/web/myapp line 36 November 4, 2005 1:43:23 PMI have the xsd referenced on the XML catalog preferences tab. Also, is there a way to locate xsd’s on a project by project basis?
The format of your schemaLocation attribute in your XML file has the format of: URI URL, while I’m not an expert, I know if the XSD hasn’t been registered in the XML catalog, your URL portion will need to be a literal path to the XSD file, locally or remotely. If you have registered your XSD file with our XML catalog, using the URI should be sufficient for resolving it.
If you are having problems with this, please paste your full XML catalog entry (all 3 fields) as well as the top of your XML file for us to see.
An no there are not per-project settings for XSD resolution, the catalog is workspace-scoped.
The odd thing is that it works on one file, but not the other even though they are identical:
Here’s the xml file header:
<?xml version=”1.0″?>
<view label=”label” canDelete=”false” canPaste=”false” id=”root” tip=”This be the root” class=”menufolder” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xsi:schemaLocation=”http://peregrine.com/shared/cwc navmodel.xsd” xmlns=”http://peregrine.com/shared/cwc”>Here’s the XML Catalog settings:
URI: platform:/resource/dcApplication/etc/navModel.xsd
Key Type: Namespace Name
Key: http://peregrine.com/shared/cwcDo you have the navmodel.xsd file anywhere in your project? Does it happen to be in the same folder as the XML file that does validate correctly?
Try changing your schemaLocation to this:
http://peregrine.com/shared/cwc(Just the URI), then revalidate the file, does that work?
XML is a tricky beast…
The xsd is in a different directory than the xml.
Actually, I was able to get a better set of error messages by using the right-click “myeclipse>remove validation markers” and “run validation” commands. Turned out I didn’t have the latest version of the xsd referenced (there was a difference in the xsd’s target namespace declaration). The normal eclipse build error message wasn’t very helpful, particularly when one of the two files validated fine and the code help worked fine in that one.
Oh well, it’s working now… thanks for all the help…
