Venkata Krishnan wrote:
Not sure I understand this. I guess its to do with the
ExtensibleURLArtifactProcessor that strips off the extension and
searches for processors only by those extensions. So even if the
URLArtifactProcessor.getArtifactType() returned 'definitions.xml' we'd
still have a problem. I guess we have to designate some files as
configuration files that have specific designated processors. When
the contribution service picks up these files it must invoke the
corresponding artifact processors and in all other cases - for
application artifacts it could go by what its going currently. Makes
sense ?
- Venkat
On 8/8/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
[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
I didn't say that this didn't require any changes in any classes. I'm
just proposing a change to how URLArtifactProcessors indicate what they
support:
*.foo for all files with extension .foo
foo.bar for file foo.bar
Then, yeah sure, some classes will have to change to accomodate this new
way of declaring URLArtifactProcessors.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
