No, as long as there is the correct xmlns defined. For example, this:
<switchyard xmlns="urn:switchyard-config:switchyard:1.0" xmlns:sca="http://docs.oasis-open.org/ns/opencsa/sca/200912">
is the same thing as this:
(I used the composite element instead of the component element in my example, but xml and namespaces work the same way no matter.)
Thank you very much. That makes sense.
Your answer is intriguing. Then perhaps I have an interesting observation. The scanner does not not seem to conform to whatever is set up as a namespace if a file pre-exists. If, for instance, in a project, you start with the visual tool and later create services via the annotation route, a conflict arises. The visual tool appears to prepend sca: by default, and the scanner does not.
You can mix and match xml, some with the namespace prefix, and some with locally defined namespaces. It doesn't matter, as long as it's all copesetic.
I will say that the Best Practice is to use the Eclipse tooling. The java annotations which exist to generate switchyard.xml were an early innovation which might not last long-term as a supported configuration method.
That said, if you find that there is a bug, where something doesn't work, please file an issue in JIRA.
Thanks David. It is too early to file a bug yet ... I need to gather more information.
But don't get rid of the annotations. They were a very happy spot in the tooling and a welcome relief/alternative from/to the visual tool. Certainly for me.
Is it correct that the scanner is tied to the compile lifecycle event? When I compile from the command line in maven it looks like the file is not getting updated in the target directory. Am I missing something?
The "configure" goal (which runs the scanners) is backed by the ConfigureMojo, whose default lifecycle phase is "process-classes". If you've overridden this in your pom.xml, I could see that being a problem.