:) thanks. That makes sense to me. - Venkat
On 8/9/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
