Community
Participate
Working Groups
Build Identifier: Build id: 20100617-1415 I'm trying to use a catalog file to define the locations of XSDs that are generated on a CI server for namespaces used in project XML files. If I use a namespace, say "test://dummy.namespace", and then specify the real location of the XSD in a catalog file, configured as a Delegate for "test://" (or as Next catalog), content assist does not offer any suggestions, etc. for the elements in that namespace. I will attach a simple example. Reproducible: Always Steps to Reproduce: 1. Create a new project, test 2. Add the two xml files to the project (to be attached) 3. Add a user-specified Delegate XML Catalog for start string "test://" to catalog file test/test-catalog.xml 4. In test.xml try to use content assist with and without xsd: namespace - both should present the same set of tags, but only xsd: is resolved.
Created attachment 179371 [details] Test xml file
Created attachment 179372 [details] Test catalog file
Created attachment 182954 [details] patch Our catalog resolver is resolving "test://this.is.a.catalog.test.uri" to "http://www.w3.org/2001/XMLSchema", which is correct for given catalog.So it goes to internet cache to get result and content assist fails. If we use "http://www.w3.org/2001/XMLSchema" directly in test.xml , then it will be resolved to a jar file locally which contains all schemas etc , and content assist works. If resolved uri is in http protocol, we should try to resolve it again in hope to find it in local jar file.
Created attachment 182965 [details] new patch removed change in URIHelper, which is not in our plugin.
(In reply to comment #3) > If we use "http://www.w3.org/2001/XMLSchema" directly in test.xml , then it > will be resolved to a jar file locally which contains all schemas etc , and > content assist works. > If resolved uri is in http protocol, we should try to resolve it again in hope > to find it in local jar file. Perhaps XMLSchema was a bad example for the simple test case if it is resolved to a jar file - I find this bug to exist for other XSDs that only exist at the end of the http location.
Looks like CacheURIResolverExtension is resolving 'http://www.w3.org/2001/XMLSchema' to a wrong cached element.It is not a xsd at all.Maybe it is getting confused with this particluar url.Could you add another example for us? Valentin, is there anything specific we should be aware of while trying to fetch an xsd from internet?
Comment on attachment 182965 [details] new patch It sounds like this patch is obsolete based on the last two comments.
This won't be making it into Luna, unless someone wants to pick it up.
