Sorry for the delay. On 07.05.2004 12:37:52 Abey Mullassery wrote: > > Thanks a lot for the detailed mail and very useful suggestions. > > > I agree with Martin that Apache Commons would be a better place. Another > > place could be the shared code base in the upcoming XML Graphics project > > but I think Apache Commons is still preferred. I'd rather not have such > > a package outside the ASF if possible. There are enough potential customers > > here that we can justify a shared ASF-homed API adapter for images. > > > > That was my understanding as well eventhough upcoming XML Graphics > project was news to me. I personally would love to share this code with > ASF than anywhere else. > Since many of you say that its better fit to be an Apche commons > project, I will send this proposal to the Apache-commons list. Is the procedure > same for Apache Commons as well?
I think so. Since you're an Apache committer already, it might not be so difficult to bring the code in. But if it's not grown within the ASF it might have to go through the incubator. > But I think it is best to propose the package to Apache commons after > we redefine the scope based on the feedback that we have got here. I > started writing this library for myself :-) and hence I designed it in > such as way that was easy for me to use (for Image Taglib and Image ANT > Tasks). However it is just in a preliminary stage to be an apache > commons package. If this is to succeed I think this needs to be more than a one-man-show. As I said before my priorities currently don't allow me to participate enough to make a difference. I can only lend moral support. <snip what="scope definition"/> I agree with your analysis. If you had to support the code all by yourself (i.e. without the help of others) it might be best if you kept the code or include it with the rest of the taglib code. Only if you get additional help will make the transition to Apache Commons make sense. It's probably best to ping FOP-land to see if anyone (with resources) is interested to help out. I'll drop a note on [EMAIL PROTECTED] so they know what's on the table. > > Could you elaborate what you mean by "SVG operations"? > > All I meant was a simpe interface with methods that take SVG > string/file/stream as input, does some manipulation on it and returns > SVG. That sounds to me as it would really belong into Batik. > Let me know your thoughts, I'm sorry that I cannot be more of a help but I sympathize with your goal. Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
