Community
Participate
Working Groups
Using Eclipse 3.5M2 When using the Service Component wizard to generate a component XML document the wizard automatically populates the Name field (under the "Service Component Definition Information" section) with the chosen filename for the XML document, less the extension. When you consider that the <component> element's name attribute "must be globally unique" (see Section 112.4.3 of the OSGi spec), a better generated name might be the symbolic name of the containing bundle. Of course, this is complicated by the fact that a bundle can contain multiple components. The bottom line here is that we don't want to teach people that something simple, such as "component" is appropriate for a <component> element's name attribute.
What do you recommend here Simon? Should we try to qualify the names to make it more unique? com.my.package.component?
My preference would be to see the BundleSymbolic-Name used as the default <component> name. Most bundles will have just one <component>, and we know that the BundleSymbolic-Name is unique, or at least should be. While the spec says that the <component> name must be globally unique, pragmatically the only case where the <component> name absolutely needs to be unique is when you are also using Configuration Admin to configure the component's properties.
OK, so I got around to testing the rule that a component's name must be unique, and it seems that Equinox's DS implementation actually enforces the rule. Here's what you get when you try and slip a component with a duplicate name past the SCR: >Error [4] [SCR] Found components with duplicated names inside their bundle! This component will not be processed: ... Ouch! This only adds weight to my suggestion that the tooling should suggest a component name based upon the Bundle-SymbolicName. When a component name collision is detected by the tooling it would likely be enough to append a numeric id to force it to be unique. Not only should the tooling suggest a unique name for the component, but it should, as far as is possible, check that at runtime we're not going be have component names collisions. While checking the target platform would be nice it probably would be too costly in terms of time and memory, not to mention that it won't be particularly scalable, so maybe it's enough for the tooling to check that all components in the workspace have unique names.
Created attachment 117124 [details] DSFileWizardPage updates File Name="component.xml" Component Name=<Bundle's Symbolic Name>
That sounds great! Regarding the "File Name:" field, this is discussed in bug 253635: 5. The "File name:" field needs to be automatically populated, and I suggest that we use "component.xml". In most cases there will only be a single XML document, so this name works perfectly. The value of this field should be persisted (using either dialog settings or plug-in preferences) so that the user does not have to enter their preferred name every time. Persisting the chosen filename would be nice too, since not everyone will agree with the default.
Done. Thanks Rafael! > 20091105 Can you open another bug for the issue you mentioned about dialog settings Simon?
The dialog settings are mentioned in bug 253635.
