On 13.12.2007 12:06:18 Vincent Hennebert wrote: > Hi, > > I’m all for moving the new image loading package to XML Graphics > Commons. Nothing more to say! Your arguments are convincing. > > Other comments inline. > > Jeremias Maerki wrote: > > On 13.12.2007 07:46:14 The Web Maestro wrote: > > <snip/> > >> In fact, I'm wondering if we don't put more emphasis on the Graphics > >> part of 'Apache XML Graphics Project' in our mission: > >> > >> The Apache XML Graphics Project is responsible for software > >> licensed to the Apache Software Foundation intended for the > >> creation & maintenance of: > >> > >> * the conversion of XML formats to graphical output > >> * related software components > > > > Graphics are an important part of what we do here. I realize that XML > > Graphics Commons has not much to do with XML (except for the XMP part). > > This is a topic that has been raised before and with the move of font > > and PDF code to Commons, this will probably be reinforced. So it's > > absolutely valid to think about different routes. However, that would > > again generate more work and the factorization of the common parts into > > a Commons alone creates enough work. At any rate, we're still operating > > within the limits of the project charter, but if anyone from the outside > > comes and proposes to move certain components to another, to-be-created > > Apache project, I wouldn't have a problem with that. At the moment, it's > > just us caring for the code so I don't see a need to do anything. I'd > > say: let's concentrate on a clean dependency tree first. > > I fully agree. Why not explaining the name like this: the “XML Graphics” > in “XML Graphics Commons” does not so much refers to code inside this > project that deals with XML, as to the two graphical XML formats > implemented by the projects that depend on it (Batik and FOP). We could > have named it “SVG & XSL-FO Commons” as well, but it’s just more elegant > that way (and extensible, we won’t have to rename it one day into > “MathML & SVG & XSL-FO Commons”...). > It happens that both those graphical XML formats needs components like > image or font loading, which themselves have little to do with XML. > Isn’t that the way it should have always been interpreted? O:-)
Sure. But naming something is always tricky. > <snip/> > >> On the logging front, isn't it possible to code the Logging > >> dependencies such that you only load the Logging functionality if it's > >> needed/called? > > > > Source code pre-processing. Shudder. Byte code magic. Hmm. :-/ Still, > > I'm glad Java doesn't have "features" like C or ObjectPascal to > > include/exclude code parts at compile time. > > If the Batik side is really reluctant to introduce a dependency over > Commons Logging, and now that we use Java 1.4 as a minimal requirement, > there’s the option of converting the Commons Logging statements into the > Java logging framework, right? Hmmmm. What with the people who prefer Log4J and want everything logged there? Commons Logging at least provides a switching central to route the log traffic where you want it. I don't think that's so easy (and readily available) with java.util.logging as with Commons Logging. Jeremias Maerki --------------------------------------------------------------------- Apache XML Graphics Project URL: http://xmlgraphics.apache.org/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
