Le samedi 23 juin 2007, Brett Porter a écrit : > We shouldn't permit relative entities in the POM - it would cause > grief when deployed to the repository. > > - Brett ok, then the target API is read(InputStream) I won't add read(URL).
regards, Hervé > > On 23/06/2007, at 5:29 AM, Hervé BOUTEMY wrote: > > Le vendredi 22 juin 2007, Arnaud HERITIER a écrit : > >> Be careful, because when you read an xml file with a reader (or an > >> inputstream) instead of a path (or an url) you can't use relative > >> entities > >> in xml (because the parser can't know where the main doc is). > > > > yes, read(InputStream) is better than read(Reader) for encoding, > > but does not > > help for relative entities. > > Do you want that I add read(URL) at the same time, and document it > > as the > > preferred way of getting the model read? At the first time, for > > compatibility > > reasons, it would call read(InputStream) then read(Reader), but in > > the long > > term, it could be coded to permit relative entities. > > WDYT? > > > > Hervé > > > >> This is not a problem because we discourage the usage of xml > >> entities in > >> our xml documents, but we have to continue to say it !!! > >> > >> Arnaud > >> > >> On 22/06/07, Hervé BOUTEMY <[EMAIL PROTECTED]> wrote: > >>> Le vendredi 22 juin 2007, Kenney Westerhof a écrit : > >>>> Hi, > >>> > >>> Hi, > >>> > >>>> indeed, it's a case of doing new XXXInputstream( something, > >>>> "encoding" > >>> > >>> ), > >>> > >>>> or a reader. Some work has been done on this, IIRC. > >>>> > >>>> The problem is that you need to prescan the xml declaration, so you > >>> > >>> start > >>> > >>>> parsing until you get the first xml language element that is not a > >>> > >>> comment, > >>> > >>>> (an xml element, in which case encoding is utf8, or > >>>> a doctype declaration, encoding is utf8, or > >>>> a processing instruction, and if it's the xml processing > >>>> instruction > >>> > >>> parse > >>> > >>>> the encoding attribute and use that, otherwise it's utf8). > >>>> > >>>> This isn't too hard to do, except you need to restart reading > >>>> the xml > >>> > >>> file > >>> > >>>> from start, if the encoding is not utf-8. The real problem is in > >>>> the > >>> > >>> API's; > >>> > >>>> you cannot take a reader and restart that, since you cannot > >>>> change the > >>>> encoding on an instantiated reader, and you certainly don't want to > >>>> wrap it. You'd need access to a raw inputstream that doesn't apply > >>>> encoding transformations to the bytes, and wrap that in a Pushback > >>>> something and then rewrap it if you found the encoding. > >>> > >>> exactly, this is the job done by XmlReader in Rome: > >>> > >>> https://rome.dev.java.net/apidocs/0_5/com/sun/syndication/io/ > >>> XmlReader.ht > >>> ml > >>> > >>> I have the class, well written and tested by Rome developers. My > >>> first > >>> question is then: where to put it, to be able to use it in a lot of > >>> places where there are Readers instanciated for XML streams? > >>> plexus-utils? or make a dependency on Rome? or another place? > >>> > >>>> I'm a bit fuzzy on all the java.io api's, so we'll have to find the > >>> > >>> proper > >>> > >>>> class to use in the API so we can do this; a File would work. > >>>> > >>>> Anyway, I once tried to fix this issue but the api had to be > >>>> changed > >>>> and there were just too many changes across plexus and maven at the > >>>> time to push this through. > >>> > >>> With this class available, the change to Maven model can be backward > >>> compatible: > >>> - the old read(Reader) API remains for compatibility, but is > >>> deprecated > >>> - a new read(InputStream) API is added, which calls read(new > >>> XmlReader(in)) > >>> The whole Maven code can then slowly migrate from deprecated > >>> Reader API > >>> to the > >>> new InputStream one, or use XmlReader if it is too hard to switch to > >>> InputStream. > >>> The only change is that there is a new dependency to this XmlReader > >>> class: I > >>> don't know if it is a real problem or not. > >>> > >>> I searched a little bit, this new API addition could be done > >>> individually > >>> in > >>> each .mdo file. But of course integrating it the code generation > >>> mechanism of > >>> Modello would be a lot better: Jason, if your proposal to have > >>> access to > >>> Modello is still valid, I'm interested. > >>> > >>> Regards > >>> > >>> Hervé > >>> > >>>> -- Kenney > >>>> > >>>> Hervé BOUTEMY wrote: > >>>>> Le jeudi 21 juin 2007, Jason van Zyl a écrit : > >>>>>> It seems like there are many problems with encoding that could be > >>>>>> easily solved with a couple tweaks to modello, specifically the > >>>>>> reader and writing so I've scheduled these for 2.0.8. There some > >>>>>> patches for these and hopefully Herve will work his magic with > >>>>>> his > >>>>>> suggested fix. I like the idea of borrowing the idea from the > >>>>>> Rome > >>>>>> IO utils to find the right encoding by default. That could > >>>>>> easily be > >>>>>> integrated into modello. Herve if you need access to Modello > >>>>>> we can > >>>>>> set you up. > >>>>> > >>>>> I'm interested at working on that. Do I need Modello access, or > >>>>> other > >>>>> components? I don't really know, these Modello things are the > >>>>> parts I > >>>>> didn't really dive into for the moment. > >>>>> The magic of the idea is that the encoding handling is not done by > >>>>> the parser, but by the reader. Then, the code that has to > >>>>> change is > >>>>> the > >>> > >>> code > >>> > >>>>> creating the Reader from a File: it must be changed from "new > >>>>> FileReader(file)" to "new XmlReader(file)". > >>>>> > >>>>> We need to: > >>>>> 1. choose where we put the XmlReader so that any code can use > >>>>> it when > >>>>> necessary. Or have a dependency on Rome: but all Rome for only 1 > >>>>> class (even if this class is really great)... > >>>>> 2. change every code that creates a Reader for XML parsing > >>>>> > >>>>> WDYT? > >>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> Jason > >>>>>> > >>>>>> ---------------------------------------------------------- > >>>>>> Jason van Zyl > >>>>>> Founder and PMC Chair, Apache Maven > >>>>>> jason at sonatype dot com > >>>>>> ---------------------------------------------------------- > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> ----------------------------------------------------------------- > >>>>>> --- > >>>>>> - 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] > >>>> > >>>> ------------------------------------------------------------------- > >>>> -- > >>>> 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] > > > > --------------------------------------------------------------------- > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
