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:-) <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? Vincent --------------------------------------------------------------------- Apache XML Graphics Project URL: http://xmlgraphics.apache.org/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
