Pierre van Rooden <[EMAIL PROTECTED]> wrote: > Remco van 't Veer wrote: > >After porting to 1.4, neither of the above jars files should be a > >problem when I provide a precompiled jar-file on the xmlbs site. I am > >not sure where mmbase stand now on the 1.4 issue, can anybody enlighten > >me? > > For MMBase 1.7 you already need JDK 1.4, IIRC. So that would not be a > problem. > > >I don't like to add mmbase centric code to this codebase since it will > >add undesired build dependencies. A precompiled jar-file should be easy > >to work with from an mmbase point of view and the wordhtmlfilter should > >probably be moved from the speeltuin to the modules or util or whatever > >package. > > Well, it's trying to find what package to drop it into that may be a bit > of a search. We are talking one class, a bit overkill for a full > application tree perhaps, but not suitabel fro a generic 'tools' package > as it depends on an external lib. > The suggestion was not so much to make it part of the code base, but > make it a separate class/jar that you could, for instance, download from > the xmlbs site, as an extension. > Maybe someone else has a better idea, or people find the idea of a > separate application now so bad?
I think it is not such a big problem if a 'tools' package depends on an external lib, or even the mmbase.jar itself for that matter. It is only a problem an compile time, and we are used to that (mmbase is depending on a good handful of external things already). Of course, if you are actually using the html-filter then you need to have the xmlbs jar at runtime too, but that would be true in any case. Now, most 'tranformations' tools are in org.mmbase.util.transformers, so I'd put an html-filter there too. xmlbs could be an 'optional' lib like informix and oracle or could be one of the 'automatic' libs like xerces, depending on how 'optional' you find that html-filtering is. One could argue that the org.mmbase.util class have no place in mmbase.jar and should be in mmbase-tools.jar or so, but that is another matter. I think such a filter should be located based on its functionality, not so much based on its dependencies, and the ratio for not being suitable for a generic tool package because of that, I don't see. Michiel -- Michiel Meeuwissen | Mediapark C101 Hilversum | +31 (0)35 6772979 | I hate computers nl_NL eo_XX en_US | mihxil' | [] () |
