[snip]
Venkata Krishnan wrote:
Hi Sebastien, thanks. I've figured out all of this already :) Just
the one hanging thing - the definitions.xml is an artifact that might
have to be picked up by the contribution service. While processors
for all other documents could be found by their unique extensions such
as .composte or .constrainingType its a bit of a trouble with
definitions.xml, the extension .xml being generic.
Could we extend the logic in ExtensibleURLArtifactProcessor.read to
first look at extensions and if not found try with the name of the
file ? So the principle is - search for processors either by
extensions or by the file name for specific kind of documents. I sort
of feel a bit clumsy about this approach - whats an alternative that
could be cleaner ?
Thanks
Here's a simple change to make this cleaner:
Instead of URLArtifactProcessor.getType() returning
.composite for *.composite files
definition.xml for definition.xml files
URLArtifactProcessor.getType() could return
*.composite for *.composites files
definitions.xml for definition.xml
Thoughts?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
