- This topic has 6 replies, 2 voices, and was last updated 18 years, 2 months ago by
.
-
Posts
-
Our development teams are working on a new JSF based web project. We have split out our faces-config.xml file into multiple config files. So now we have multiple param-values set for javax.faces.CONFIG_FILES setting within the web.xml.
This causes the managed beans defined in those config files to be unresolved, therefore displaying a warning every time we reference a bean using expression language in the jsp’s, and also preventing us from using autocomplete with the managed bean references.
This is something that seems to be present with most eclipse-based IDE’s. But some IDE’s (i.e. IBM’s RAD) has fixed this issue with it’s latest version.
This is something important enough to us that would prevent us (75+ developers) from continuing forward with the use of the MyEclipse platform.
Can somebody please let me know when the MyEclipse team plans on resolving this issue? Otherwise, does anyone know of a workaround (feasible one) to this?
thanks!
jjOk, I took a look at this and couldn’t reproduce the issue using an internal build of our GA release. Can you download this project, import it and clean it and see if you get errors? And if autocomplete works correctly in your TestJSFPage.jsp file?
I just imported your test project and also was not able to reproduce the problem. So I looked into the differences between your test project and our project. The difference was that we don’t have the JSF nature enabled within our IDE. We have been trying our best to be IDE “agnostic” with our development approach, and therefore we refrained from enabling MyEclipse specific natures.
When I added the JSF nature attribute in the .project file, I was then able use autocomplete and there were no more undefined bean references in the JSP’s.
So the question is, why do we need to enable the JSF nature of myeclipse in order for this to work? With the JSF nature NOT installed, we were still able to use autocomplete so long as we only used 1 faces-config.xml file. The assumed answer is that this is an underlying eclipse bug and myeclipse fixes it by enabling the jsf nature. Could you provide further explanation?
Thank you very much for spending time on this issue!!!
ejohnjones,
I know the fight trying to be ‘agnostic’, and instead of fighting that battle at the IDE level (you will loose. Meaning every IDE does it different, and you end up cutting your nose off despite your face) fight it at the source-repository level. Meaning you just don’t check in the IDE files, like dot-files in Eclipse, project files in IntelliJ/JBuilder/etc and custom build files in NetBeans.I’ve been on a team that was almost split in thirds between Eclipse/IntelliJ and JBuilder, and we *had* to do this to keep the other purists in the group happy and not go crazy. It ended up working great and we just checked source-only into the repo.
As for our nature, there are some default assumptions that our code make which is why it likely worked, but the nature is a collection of meta-data that we collect during the wizard to let MyEclipse *know* about the project.
It’s possible to automate this further, but enabling better JSF support in non-JSF projects is not high on our list of priorities and I doubt management would give it priority either over further enhancement work at this particular time.
So I think the temporary solution of keeping IDE-specific files out of source control might be a more agreeable way to go for you and your team at the moment. Then it doesn’t matter what nature/etc. is on the project, because none of those files get checked in.
