This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
See the attached project below. The project is cut version of a real project. Open the project and BSF.xsd schema inside. There is the only complex type BDSMeterDataNotification and its structure isn't shown in the Schema view. I can see only Transaction as a leaf element. But it has not a simple type. Validation doesn't indicate any errors. I think it's a problem of Schema model because the same problem appears in the BPEL mapper, which uses the model directly to show the structure.
Created attachment 61260 [details] test project
Sam, would you please provide quick analysis what is the root cause of the problem. This is request from one of our potential customers and quick evaluation is very nice to have.
*** Issue 134860 has been marked as a duplicate of this issue. ***
I do see the issue, however, I do not agree with the priority (read guidelines). The workaround is to declare components inside aseXML_r17.xsd. I'm not sure whether the schema model doesn't resolve recursively or this particular use-case is broken. I'm working on it and will get back.
Samaresh, unfortunately, the suggested workaround is not applicable for us. Most of our customers work with industry-defined standard XML schemes which, obviously, are created elsewhere and should be used "as is". Pumping up back to P1.
ksorokin, you made it a P1, but didn't justify why though? Clearly from priority stand-point, this is not a P1. I'll leave it to the i-team to decide.
Errr.. I thought that stating that the suggested workaround is not applicable, is a good enough justification. :) Sorry if it is not. What else would you like to see? Yes, this is a critical issue for most corporate/enterprise users of SOA functionality in NetBeans.
There is a recursive algorithm in schema model that resolves external components. See SchemaModelImpl::resolve(). The algorithm resolves components recursively for "include"s but for "import"s it stops at the first import, which is good, except this use-case. In fact I'm not sure what should be the correct behavior. I'll have to investigate further. Please stay tuned.
I have a fix that might work, but am cautious about it. There could be some implications to it, I'll review it with former owners before committing. In the mean while, you may want to use the jar.
Created attachment 61418 [details] schema model
Fix integrated: http://hg.netbeans.org/main/rev/ddbb1cef8948.
It works!