Can you verify something for me? Please make sure to disable Honour all XML schema locations in preferences, XML→XML Files→Validation after installation. This will prevent erroneous XML validation errors from appearing on switchyard.xml files.
See if that clears up this issue. The XML validation in Eclipse gets a bit picky sometimes. The configuration that is generated works just fine with the runtime and is quite valid.
Brian, I think you misunderstood me. I don't want to disable the XML validation such that to hide the errors. What I want is to understand how come the Switchyard visual editor generates XML content that itself cannot validate and how to solve this problem. And the solution isn't, of course, to disable the validation. If you think that hiding errors is a solution to any issues, then I think we don't have the same idea about what ans issue is and what a solution is.
What about ignoring the comopiler/build errors and disabling unit tests, this being the panacea solution to all the issue one might have ?
Have you read this installation guide? The official installation guide itself demands disabling the XML validation built-in in Eclipse
And I guess your real issue has nothing to do with the built-in XML validation. So, for the sake of narrowing down the issue, why don't just follow Brian's suggestion at least for the time being?
Where did you see that the installation guide is requiring to disable the XML validation ? I didn't find anything like that in the link you provided.
You guys, you are unbeleivable. You're explaining me that hidding the XML validation erros would be a solution to the fact that the XML produced by the visual editor is not valid. You also explain that the issue doesn't have anything to do with the fact of disabling the XML validation. But you propose that as a solution, even if, as you say, it doesn't have anything to do with the issue. Last but not least, you're saying that, since the XML is okay as far as the runtime is concerned, it doesn't matter much that it doesn't validate in the IDE. Okay, what's the point then to use the IDE ?
First of all, I'm sorry you're having issues with XML validation. Second, there are issues with the built-in validation that Eclipse provides. It's not perfect. This is the best option we have at the moment to work around some of the quirks it involves. No solution is perfect, so we hope you will bear with us.
The tooling does create valid XML configuration files that the runtime happily consumes to do its job. Ultimately, that's our goal here.
I hear your frustration and understand. The validation DOES work for errors and major issues that could be created in the configuration. The validation issues that you are referring to come from Eclipse itself, so I don't have a way to handle that beyond turning off the warning - which is just that, a warning - and of little consequence to the user.
Second, there is a warning near the top of this page - Installing Eclipse Tooling - SwitchYard - Project Documentation Editor about the XML validation. I will have to look at the docs themselves to see if it was included in them.
Hope that helps
Just to highlight Brian's last comment here - the tooling is producing valid XML that conforms to the SCA and SY schema. The issue here is with the built-in Eclipse validator. This problem is annoying, but it has a straightforward workaround and is not indicative of a problem with the XML we are generating or consuming in the runtime.
1 of 1 people found this helpful
I agree that the XML generated by the visual editor is valid as far as the specs and the runtime is concerned. What I'm saying is that JBDS is not able to validate XML code it generates itself. The fact that the issue comes from the Eclipse validator (aka JBDS validator) doesn't change anything to the problem.
The solution is not to disable the validator and, consequently, not to be any more able to validate any XML/XSD in all the workspace, just because this particular tool doesn't work. No, the solution is to fix the issue in the Eclipse validator (aka JBDS validator). If the Eclipse validator has issues, how come you build new features on the top of a foundation that has issues ?
Do you think that concurrent products, like Oracle SOA Suite, generates SCA code which appear as invalid when validated by the same tool which generetd it ? And that the software editor explains to users that, "well, the generated content would be valid from the specifications point of view, it's just that our tool doesn't work properly" ? This is simply ridiculous.
Sorry for you bumping into this issue.
I agree it is annoying and something that should be fixed. We need to work on getting the validation in eclipse fixed.
You asked why we continue to build top of a foundation that has issues ? Well, short answer is that there is no other sensible base to build upon and we are fixing issues in this foundation as we find them and have time to fix them.
We got this on our "need to fix" list. Let me know if you would like to help test/verify whatever fixes we will work on and i'll forward you the jiras when we make/resolve them.