You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@xmlgraphics.apache.org by Jeremias Maerki <de...@greenmail.ch> on 2005/08/05 21:44:02 UTC
XML Graphics Commons: last call
People, I want to finally get through with this. I've put it up for much
too long. This is the last call for comments and suggestions on my XML
Graphics Commons proposal on the Wiki:
http://wiki.apache.org/xmlgraphics/XmlGraphicsCommonComponents
I'm sending this also to both subproject dev lists only so I'm sure
everybody has seen it. The discussion will be exclusively on
general@xmlgraphics.apache.org. Everyone how responds to one of the
project dev list must donate 5$ to the ASF for further cross-posting. :-)
Not a bad idea anyway to donate something to the ASF. *grin*
I'll cast a vote for the formal creation of the XML Graphics Commons
subproject next week, provided there are no objections or outstanding
points. I hope I didn't leave anything unanswered last time we discussed.
Now is the time to remind me.
Jeremias Maerki
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: XML Graphics Commons: last call
Posted by Jeremias Maerki <de...@greenmail.ch>.
Now I get it, thanks. Well, it was not so much a decision by the
community than my extreme pushing into the direction that we should call
the AWTRenderer the Java2DRenderer. :-) Anyway, the naming problem IMO
only applies to the AWTRenderer itself and that remains within FOP where
I agree we need to be careful about the renaming. The components we
extract are purely technical I don't think there is a reason for the
Graphic2D implementations to bear any note of "AWT". It's even more
wrong to talk about AWT in this context, since this part has absolutely
nothing to do with the "Advanced Windowing Toolkit".
On 09.08.2005 19:52:25 The Web Maestro wrote:
> Sorry to be unclear... At some point, the decision was made to stop
> referring to AWT when talking about FOP's 2-dimensional screen & print
> renderer. Instead we started referring to it as "Java2D" which I agree
> is much more concise & descriptive. However, there may be some who
> think of it as AWT, and I think at the top level, we should refer to it
> as Java2D (formerly FOP's AWT renderer). I don't think we should go
> CRAZY with this, and *always* reference it that way, but there needs to
> be somewhere on the site (and in the code?) that relates the two.
>
> On Aug 8, 2005, at 2:10 PM, Jeremias Maerki wrote:
> > Sorry, Clay, but I don't understand what you mean. I'm feeling stupid.
> >
> > On 08.08.2005 18:31:10 The Web Maestro wrote:
> >> The only thing that strikes me, is that Java2D doesn't say (make
> >> reference or include any info to help searchers find it--e.g.,
> >> formerly
> >> AWT). Apolgies for the delay, I'm moving the house, office, and
> >> servers
> >> this month...
Jeremias Maerki
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: XML Graphics Commons: last call
Posted by The Web Maestro <th...@gmail.com>.
Sorry to be unclear... At some point, the decision was made to stop
referring to AWT when talking about FOP's 2-dimensional screen & print
renderer. Instead we started referring to it as "Java2D" which I agree
is much more concise & descriptive. However, there may be some who
think of it as AWT, and I think at the top level, we should refer to it
as Java2D (formerly FOP's AWT renderer). I don't think we should go
CRAZY with this, and *always* reference it that way, but there needs to
be somewhere on the site (and in the code?) that relates the two.
On Aug 8, 2005, at 2:10 PM, Jeremias Maerki wrote:
> Sorry, Clay, but I don't understand what you mean. I'm feeling stupid.
>
> On 08.08.2005 18:31:10 The Web Maestro wrote:
>> The only thing that strikes me, is that Java2D doesn't say (make
>> reference or include any info to help searchers find it--e.g.,
>> formerly
>> AWT). Apolgies for the delay, I'm moving the house, office, and
>> servers
>> this month...
Regards,
Web Maestro Clay
--
<th...@gmail.com> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: XML Graphics Commons: last call
Posted by Jeremias Maerki <de...@greenmail.ch>.
Sorry, Clay, but I don't understand what you mean. I'm feeling stupid.
On 08.08.2005 18:31:10 The Web Maestro wrote:
> The only thing that strikes me, is that Java2D doesn't say (make
> reference or include any info to help searchers find it--e.g., formerly
> AWT). Apolgies for the delay, I'm moving the house, office, and servers
> this month...
Jeremias Maerki
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: XML Graphics Commons: last call
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 11.08.2005 22:40:25 J.Pietschmann wrote:
> Jeremias Maerki wrote:
> > I can check in the excalibur-framework variant, if you like? :-)
>
> Better, but still not perfect. You know, bad karma burns and all that.
> Claiming to be a framework solving big problems just doesn't match
> with still being a fringe product after putting heroic effort in it
> for quite a few years.
I know. That was tongue-in-cheek.
> > Would talking to the Excalibur
> > people about extracting the configuration package into a separate JAR be
> > an acceptable solution?
>
> Nice idea. Perhaps republishing as "jakarta commons configuration
> light" might help in getting out of the collateral damage radius of
> Avalon. :-/ :-\ :-/
Hehe. I wonder how much the guys from Commons Configuration would like
that name. Ok so, if there are additional voices that I should pursue
this I can. I've got enough other things on my task list to be happy not
to have to do this. After all, I don't really want this. It's just a
possible way out of this. So if anybody wants to take the lead here, I'd
be VERY VERY thankful.
Jeremias Maerki
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: XML Graphics Commons: last call
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Jeremias Maerki wrote:
> I can check in the excalibur-framework variant, if you like? :-)
Better, but still not perfect. You know, bad karma burns and all that.
Claiming to be a framework solving big problems just doesn't match
with still being a fringe product after putting heroic effort in it
for quite a few years.
> Would talking to the Excalibur
> people about extracting the configuration package into a separate JAR be
> an acceptable solution?
Nice idea. Perhaps republishing as "jakarta commons configuration
light" might help in getting out of the collateral damage radius of
Avalon. :-/ :-\ :-/
J.Pietschmann
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: XML Graphics Commons: last call
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 10.08.2005 23:04:37 J.Pietschmann wrote:
> Jeremias Maerki wrote:
> > BTW, what's a "tool"?
>
> Anything which is not generally used by the average end user.
> I'd like to add "reusable" to the definition, but this might be
> too restricting.
> Ant tasks and other plugin-type stuff should qualify in addition
> to standalone apps.
Would you mind adding that directly to the Wiki?
> > Everybody always complains about that little library. What's the problem?
>
> Bad name. Unpleasant associations. Flamewars. Uncontrolled playground.
> Small but extremely annoying design bugs. Endless debug sessions due to
> misleading error messages. Microsoft Avalon.
I can check in the excalibur-framework variant, if you like? :-)
http://www.apache.org/dist/excalibur/excalibur-framework/binaries/
Do you have an alternative to Avalon, oops, Excalibur Framework?
Design bugs in the configuration stuff? Would talking to the Excalibur
people about extracting the configuration package into a separate JAR be
an acceptable solution?
Jeremias Maerki
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: XML Graphics Commons: last call
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 11.08.2005 13:44:35 Thomas DeWeese wrote:
> > On 11.08.2005 02:34:35 Thomas DeWeese wrote:
>
> >> Ok so I took some time and I really don't like this model.
> >>This is exactly the sort of thing that belongs at the application
> >>layer not at the library layer. The idea of 'passing data' around
> >>the application through a config file seems really bad to me.
> >>(it's an excellent example of a programmers hack, look at all the
> >>cool stuff I can do, so I can also break things in really odd
> >>unpredictable ways - that's a small price to pay for tweakability).
>
> Jeremias Maerki wrote:
>
> > Ok, we disagree then. It probably doesn't help either to say that
> > certain things in Batik similar to that topic make my head spin, too.
>
> It's not a matter of making my head spin, I just don't like it.
> I understand the attraction it has, I just don't like it's model,
> this only makes it harder to accept as a dependency.
>
> Also it's worth noting that the oddities of Batik don't add external
> dependencies.
But possibly to the internal complexity and code base size. So be it. I
understand your argument a lot better now.
> > Fact is that both Batik and FOP are stable products, having lost their
> > hype-factor, and they are too small or too specialized to attract many
> > corporate supporters. We have to fight to make us attractive.
>
> Well, my personal suspicion for Batik is that there aren't
> enough itches. It basically does it's job too well, SVG isn't
> people's main interest and it does all the basic stuff really
> well so for 99% of users they just drop it in and it works.
Yep, my big problem with Barcode4J. It's almost perfect. :-(
> > It must be as easy as possible for newbies to jump in. So we have to
> > find solutions for that. Somehow. Both FOP and Batik IMHO suffer
> > from the "big blob of code" problem. I don't know the ideal solution
> > to that problem, yet. Good ideas are always welcome.
>
> >>I think this is really trying to do an end run
> >>around this. There is no clear description of the data that passes
> >>across this interface - that's really ugly IMO.
> >
> > That's mostly because nobody's done the documentation, yet.
>
> The code/interfaces should provide most of the documentation.
>
> >> The problem is that I don't care how big or small a dependency is
> >>once the dependency is there it causes problems.
> >
> > Dependency: The great FUD-word. Sorry for being sarcastic.
>
> Why is it FUD?
Exactly because of your generalization that any dependency automatically
causes problems. That's pure FUD. Sure, there may be problems but that's
normal in software development and hopefully, a dependency is only
introduced when it brings considerable benefit. Even there you agree as
I can see further down.
> I'm a bit annoyed that you are accusing me of
> spreading FUD.
I'm sorry. But it was, IMO. Just reproducing and debugging tons of
functionality again and again even though established and stable
solutions are available doesn't go well with me. But I'm sure we can do
something about your truly valid concerns. My goal: I want results now.
I still have to have some energy left to actually move (or rather copy
at the beginning) those components once we've agreed on the plan.
> Batik has had quite a bit of trouble with dependencies
> requiring our developers to drop everything to sort out an issue.
> It is quite disruptive, often the fix isn't very good because the
> developer is racing to resolve an issue and hasn't planned the
> update/change and doesn't have the time to understand what changes
> have taken place in the other library.
With this argument you'd have to implement your own operating system and
your own JVM and restrict it to one platform alone. Not all problems can
be avoided, can they? It's simply part of the game and it's partly what
makes our jobs interesting. Nobody said "software developer" (or rather
"problem solver") was an easy job. I may be weird, but I like it that
way. :-)
> > pdf-transcoder.jar contains commons-logging, commons-io and
> > avalon-framework repackaged in the JAR. Batik didn't seem to have a
> > problem with that until now.
>
> Actually that's not true, I was really annoyed when those popped up
> and I did much of the initial work to bury them in the PDF transcoder
> Jar. I'll also say that as long as the dependency stays limited to that
> I'll be satisfied. What I don't want is that the codecs and the
> Graphics2D implementations (core components of Batik) start acquiring
> these dependencies. This is a serious concern since most people will
> view these classes as a common dependency of xmlgraphics-commons.
Ok. But you realize this might even result into an argument for
splitting the individual components? :-) Seriously, I understand that.
Let's try to remove those dependencies as much as possible.
> > And that's the whole point: People who have
> > problems with additional JARs (and that's probably the main problem) can
> > get a repackaged JAR if need be. That's what I've done for
> > pdf-transcoder.jar. That's what Xalan-J did in their latest release,
> > they repackaged Apache BCEL and Apache Regexp in their xalan.jar.
> > Dependencies are nothing more than Java classes that are not directly
> > coming from the same project.
>
> They are more. First because of Ruby, second because a client
> may already be using an incompatible version of the library, forcing
> the person using the 'older' version to make an unplanned/unwanted
> upgrade to the component. If Fop/Batik was the only one using the
> dependency then I would agree, but this isn't the case.
Good point. A good example in this context: Some FOP users complained
that they can't use Batik 1.6 with FOP 0.20.5. :-( The nice thing about
Avalon Framework and, so far, Commons Logging is that the changes were
always backwards-compatible.
> > Like we in FOP depend on Batik and have been bitten a number of times
> > by interface changes. Things like that happen. That's why people and
> > projects should talk to each other.
>
> So you closely track development of Excalaber and Commons logging
> and I/O? Do you want to? I know that I don't.
Yes, I do, and yes, I want to. Not so much for Excalibur since Avalon
Framework is dead stable, but I'm a committer in Commons IO. All that's
part of the dependency deal. Same problem inside one project. Does every
committer have a good idea about every little part in a project? No,
surely not.
> > That is also one of the reasons behind XML Graphics Commons.
> > FOP could have continued with its own SVG implementation. But that would
> > have made no sense. FOP is extremely happy for the dependency on Batik
> > because of the benefits!
>
> Sure but Batik provides _loads_ of functionality. It's a
> balancing act: How much do I gain by adding this dependency?
> Is the dependency stable? Am I going to have to/want to rip it
> out in a year or two to move to something else?
Exactly.
Commons Logging:
Interface: absolutely stable (almost the same as the ubiquitous Log4J),
doesn't force the actual choice of logging framework to the user, it's
easy to add custom backends without changing the calling app.
Implementation: under revision mostly because of some weird class loader
problems in very special environments.
Avalon Framework:
Interface: absolutely stable, Implementation: absolutely stable. Every
release was fully backwards-compatible.
Commons IO:
Interface: stable now that 1.0 is available. Backwards-compatibility is
a high concern in this project.
These dependencies were not added out of the blue. There were and are
good reasons for them. But again, we can revise them for the parts we
move. Too bad I'm probably going to be the only one doing all the work
from the FOP-side. Prove me wrong, guys!
> >>>I don't see how logging disturbs operation in interactive contexts.
> >>
> >> It doesn't necessarily disturb it but it doesn't help either.
> >
> > It can help the developer. Logging is easily turned off entirely for an
> > interactive application. Almost no performance penalty for logging if a
> > few very simple rules are followed.
>
> Like wrapping every call to log with a runtime check? :(
> You can do that for System.err as well ;)
Sure you can. And then you have to start building a non-intrusive
configuration mechanism to switch on and off certain groups. Again. :-)
Just keep in mind, those who run server-side apps hate System.out/err!
And FOP is mostly used in this area.
So we really need to understand that all we build here must hold for
both extremes: applet-embedding and server-side service.
> > But adding and removing System.err/outs all the time is not really a good
> > solution. There are a few things you can't do with them:
> > - You can't turn on logging through a configuration file in a production
> > environment to investigate strange behaviour in a server application.
> > - You can't just tell people with a problem to specify "-d" on the
> > command-line do we get more helpful information on what is probably
> > going on inside the code. This makes helping people a lot easier.
> > - Switching on a certain group of logging statements for a special task
> > at hand while developing. It makes me so much more productive.
>
> I didn't try and say that logging was bad, I just don't think
> it's worth an external dependency.
>
> In my experience I have usually had to first look at the code
> to figure out what logging I needed to turn on, and second
> almost always had to add additional logging to track the problem.
> Then at least for graphics (which I suspect tend to be called
> several orders of magnitude more than most things) I have to
> really remove the extra logging or put it in a totally separate
> log category/subcategory (and a separate conditional) since
> it would make it impossible to track other issues and/or impact
> performance. By which time just adding/removing the // on System.err is
> looking pretty good to me (especially if you need to pass or gain
> access to a log object, as opposed to having global loggers, I'm not
> 100% certain which FOP uses).
We've moved from a mix of global logging (MessageHandler which is
similar to your UserAgent) and logger passing (Avalon) to static logging
(Commons Logging). The latter emphasizes the fact that logging is mainly
for the developer and a different mechanism is needed for end-user
communication, especially in multi-threaded environments. The latter is
missing ATM. FOPpers, do you hear me? :-)
> >>Now there are potentially non-interactive applications
> >>for Batik components (the transcoders mostly) but right now they
> >>handle logging/notification through the UserAgent classes.
> >
> > Yes, but the name "UserAgent" implies that this is used for interaction
> > with the user. Who interacts with the developer, giving him the
> > information he needs?
>
> The UserAgent, it is the embodiment of the user in the software.
> Some users just want more/different information than others.
> A developer is just a very detail oriented user ;)
Doesn't mean that it has to be squeezed through the same channel. The
problem is that passing the user agent all through the system isn't the
best thing to do. We've experienced something similar with Avalon
Logging and it didn't turn out well.
> IMO there can just be a 'log' method on the UserAgent the
> application can forward this to a logging implementation that
> does 'smart things' or it can print it with System.err or it
> can just eat it, or it can forward it to the current applications
> logging system.
But given the libary character of the new components you'd have to
define various levels of UserAgents (dependency management and all).
That doesn't sound very promising.
Anyway, let's hope that is moot and we can do without logging in these
basic libs.
> ---
>
> > So. Do we all agree that I should change the suggested directory tree to
> > show a combined package structure, not a separate one?
>
> This is my preference.
Ok, let's start with that.
> > Another thing I can do (if noone objects) while moving code from FOP to
> > Commons is to remove Commons Logging from certain library parts (PDF lib,
> > for example) which are not crucial. Maybe even all of it. That should be
> > possible without too much backfire. I'd kill everybody who'd want to
> > deprive me of the use of a logging facility in FOP's layout engine,
> > though. :-) I'd like to keep the dependency on Commons IO. I can offer
> > to do the repackaging work in the Ant builds.
>
> This also works for me.
Thanks.
Sorry, Thomas, for being hard on you. I just want you to see our side,
too. We have two different philosophies here. I hope we can find a good
middle way. And I naively thought the "last call" would be easily waved
through after the previous discussions. Ha.
Jeremias Maerki
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: XML Graphics Commons: last call
Posted by Thomas DeWeese <Th...@Kodak.com>.
> On 11.08.2005 02:34:35 Thomas DeWeese wrote:
>> Ok so I took some time and I really don't like this model.
>>This is exactly the sort of thing that belongs at the application
>>layer not at the library layer. The idea of 'passing data' around
>>the application through a config file seems really bad to me.
>>(it's an excellent example of a programmers hack, look at all the
>>cool stuff I can do, so I can also break things in really odd
>>unpredictable ways - that's a small price to pay for tweakability).
Jeremias Maerki wrote:
> Ok, we disagree then. It probably doesn't help either to say that
> certain things in Batik similar to that topic make my head spin, too.
It's not a matter of making my head spin, I just don't like it.
I understand the attraction it has, I just don't like it's model,
this only makes it harder to accept as a dependency.
Also it's worth noting that the oddities of Batik don't add external
dependencies.
> Fact is that both Batik and FOP are stable products, having lost their
> hype-factor, and they are too small or too specialized to attract many
> corporate supporters. We have to fight to make us attractive.
Well, my personal suspicion for Batik is that there aren't
enough itches. It basically does it's job too well, SVG isn't
people's main interest and it does all the basic stuff really
well so for 99% of users they just drop it in and it works.
> It must be as easy as possible for newbies to jump in. So we have to
> find solutions for that. Somehow. Both FOP and Batik IMHO suffer
> from the "big blob of code" problem. I don't know the ideal solution
> to that problem, yet. Good ideas are always welcome.
>>I think this is really trying to do an end run
>>around this. There is no clear description of the data that passes
>>across this interface - that's really ugly IMO.
>
> That's mostly because nobody's done the documentation, yet.
The code/interfaces should provide most of the documentation.
>> The problem is that I don't care how big or small a dependency is
>>once the dependency is there it causes problems.
>
> Dependency: The great FUD-word. Sorry for being sarcastic.
Why is it FUD? I'm a bit annoyed that you are accusing me of
spreading FUD. Batik has had quite a bit of trouble with dependencies
requiring our developers to drop everything to sort out an issue.
It is quite disruptive, often the fix isn't very good because the
developer is racing to resolve an issue and hasn't planned the
update/change and doesn't have the time to understand what changes
have taken place in the other library.
> pdf-transcoder.jar contains commons-logging, commons-io and
> avalon-framework repackaged in the JAR. Batik didn't seem to have a
> problem with that until now.
Actually that's not true, I was really annoyed when those popped up
and I did much of the initial work to bury them in the PDF transcoder
Jar. I'll also say that as long as the dependency stays limited to that
I'll be satisfied. What I don't want is that the codecs and the
Graphics2D implementations (core components of Batik) start acquiring
these dependencies. This is a serious concern since most people will
view these classes as a common dependency of xmlgraphics-commons.
> And that's the whole point: People who have
> problems with additional JARs (and that's probably the main problem) can
> get a repackaged JAR if need be. That's what I've done for
> pdf-transcoder.jar. That's what Xalan-J did in their latest release,
> they repackaged Apache BCEL and Apache Regexp in their xalan.jar.
> Dependencies are nothing more than Java classes that are not directly
> coming from the same project.
They are more. First because of Ruby, second because a client
may already be using an incompatible version of the library, forcing
the person using the 'older' version to make an unplanned/unwanted
upgrade to the component. If Fop/Batik was the only one using the
dependency then I would agree, but this isn't the case.
> Like we in FOP depend on Batik and have been bitten a number of times
> by interface changes. Things like that happen. That's why people and
> projects should talk to each other.
So you closely track development of Excalaber and Commons logging
and I/O? Do you want to? I know that I don't.
> That is also one of the reasons behind XML Graphics Commons.
> FOP could have continued with its own SVG implementation. But that would
> have made no sense. FOP is extremely happy for the dependency on Batik
> because of the benefits!
Sure but Batik provides _loads_ of functionality. It's a
balancing act: How much do I gain by adding this dependency?
Is the dependency stable? Am I going to have to/want to rip it
out in a year or two to move to something else?
>>>I don't see how logging disturbs operation in interactive contexts.
>>
>> It doesn't necessarily disturb it but it doesn't help either.
>
> It can help the developer. Logging is easily turned off entirely for an
> interactive application. Almost no performance penalty for logging if a
> few very simple rules are followed.
Like wrapping every call to log with a runtime check? :(
You can do that for System.err as well ;)
> But adding and removing System.err/outs all the time is not really a good
> solution. There are a few things you can't do with them:
> - You can't turn on logging through a configuration file in a production
> environment to investigate strange behaviour in a server application.
> - You can't just tell people with a problem to specify "-d" on the
> command-line do we get more helpful information on what is probably
> going on inside the code. This makes helping people a lot easier.
> - Switching on a certain group of logging statements for a special task
> at hand while developing. It makes me so much more productive.
I didn't try and say that logging was bad, I just don't think
it's worth an external dependency.
In my experience I have usually had to first look at the code
to figure out what logging I needed to turn on, and second
almost always had to add additional logging to track the problem.
Then at least for graphics (which I suspect tend to be called
several orders of magnitude more than most things) I have to
really remove the extra logging or put it in a totally separate
log category/subcategory (and a separate conditional) since
it would make it impossible to track other issues and/or impact
performance. By which time just adding/removing the // on System.err is
looking pretty good to me (especially if you need to pass or gain
access to a log object, as opposed to having global loggers, I'm not
100% certain which FOP uses).
>>Now there are potentially non-interactive applications
>>for Batik components (the transcoders mostly) but right now they
>>handle logging/notification through the UserAgent classes.
>
> Yes, but the name "UserAgent" implies that this is used for interaction
> with the user. Who interacts with the developer, giving him the
> information he needs?
The UserAgent, it is the embodiment of the user in the software.
Some users just want more/different information than others.
A developer is just a very detail oriented user ;)
IMO there can just be a 'log' method on the UserAgent the
application can forward this to a logging implementation that
does 'smart things' or it can print it with System.err or it
can just eat it, or it can forward it to the current applications
logging system.
---
> So. Do we all agree that I should change the suggested directory tree to
> show a combined package structure, not a separate one?
This is my preference.
> Another thing I can do (if noone objects) while moving code from FOP to
> Commons is to remove Commons Logging from certain library parts (PDF lib,
> for example) which are not crucial. Maybe even all of it. That should be
> possible without too much backfire. I'd kill everybody who'd want to
> deprive me of the use of a logging facility in FOP's layout engine,
> though. :-) I'd like to keep the dependency on Commons IO. I can offer
> to do the repackaging work in the Ant builds.
This also works for me.
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: XML Graphics Commons: last call
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 11.08.2005 02:34:35 Thomas DeWeese wrote:
> Jeremias Maerki wrote:
> > On 09.08.2005 13:12:18 Thomas DeWeese wrote:
>
>
> >>>On 08.08.2005 22:31:09 J.Pietschmann wrote:
> >>
> >>>>2. Seeing Avalon as dependency makes me uneasy. I'd prefer
> >>>>commons code to be refactored to not using Avalon and to
> >>>>provide raw functionality only.
> >>
> >> So I am a bit concerned about the addition of three new
> >>external dependencies for Batik. I realize that some of it is
> >>already there but hidden in the PDF transcoder.
> >>
> >>Jeremias Maerki wrote:
> >>
> >>>Everybody always complains about that little library. What's the problem?
> >>>We're not going to do Avalonization anymore. But the configuration
> >>>subpackage in A-F is a perfect (!) little tool and a LOT smaller than
> >>>Jakarta Commons Configuration.
> >>
> >> What are we configuring?
> >
> > Fonts and optional PDF-fine-tuning, mostly. Not everything that could
> > also be configured in FOP 0.20.5 is already implemented in the trunk.
>
> Ok so I took some time and I really don't like this model.
> This is exactly the sort of thing that belongs at the application
> layer not at the library layer. The idea of 'passing data' around
> the application through a config file seems really bad to me.
> (it's an excellent example of a programmers hack, look at all the
> cool stuff I can do, so I can also break things in really odd
> unpredictable ways - that's a small price to pay for tweakability).
Ok, we disagree then. It probably doesn't help either to say that
certain things in Batik similar to that topic make my head spin, too.
> The problem is that I'm sure this is exactly the sort of
> thing that sparked the flame wars. I also am not going to even
> come close to have the time or interest to provide a replacement.
There you got it wrong. It was actually exactly the sort of thing we do
here as a whole: Componentizing a complex system. People mostly didn't
understand Avalon at the time I introduced it but as far as I can
remember we didn't have major flamewars because of that. I even got most
of the people convinced that the Avalonization was a good thing.
Fact is that both Batik and FOP are stable products, having lost their
hype-factor, and they are too small or too specialized to attract many
corporate supporters. We have to fight to make us attractive. It must be
as easy as possible for newbies to jump in. So we have to find solutions
for that. Somehow. Both FOP and Batik IMHO suffer from the "big blob of
code" problem. I don't know the ideal solution to that problem, yet.
Good ideas are always welcome.
> >>>If anything, those who have a problem
> >>>with A-F should propose a viable alternative (I haven't seen one, yet)
> >>>or work with the Excalibur guys to extract the configuration subpackage
> >>>into a stand-alone lib.
> >>
> >> Since I have no idea what the library is and/or what you
> >>plan to use it for I can't really provide alternatives.
>
> This should be done the old fashioned way, the library should export
> interfaces to support configuration and the _application_ should
> provide the configuration data to the library as appropriate for
> the application.
That's exactly what's being done, just with the help of an existing and
stable little library instead of having to come up with yet a new way of
configuring a system (userconfig.xml with SAX handler in FOP 0.20.5,
key-controlled property system in Trancoders in Batik, etc. etc.).
> I think this is really trying to do an end run
> around this. There is no clear description of the data that passes
> across this interface - that's really ugly IMO.
That's mostly because nobody's done the documentation, yet.
> > But A-F contains a configuration subpackage [2] which is very small,
> > very easy to use and provides exactly what is necessary to load a
> > configuration tree from an XML file and to access values in a type-safe
> > and fail-safe manner while not having to deal with the deficiencies of a
> > DOM.
>
> The problem is that I don't care how big or small a dependency is
> once the dependency is there it causes problems.
Dependency: The great FUD-word. Sorry for being sarcastic.
pdf-transcoder.jar contains commons-logging, commons-io and
avalon-framework repackaged in the JAR. Batik didn't seem to have a
problem with that until now. And that's the whole point: People who have
problems with additional JARs (and that's probably the main problem) can
get a repackaged JAR if need be. That's what I've done for
pdf-transcoder.jar. That's what Xalan-J did in their latest release,
they repackaged Apache BCEL and Apache Regexp in their xalan.jar.
Dependencies are nothing more than Java classes that are not directly
coming from the same project. Like we in FOP depend on Batik and have
been bitten a number of times by interface changes. Things like that
happen. That's why people and projects should talk to each other. That's
partly why I suggested FOP and Batik to go together under a common
umbrella, so we can be closer together. So far, this seems to work well. But
the whole thing is also about reusing code. It's a big possibility to
avoid bugs and to speed up development, not having to reinvent the wheel
each time. That is also one of the reasons behind XML Graphics Commons.
FOP could have continued with its own SVG implementation. But that would
have made no sense. FOP is extremely happy for the dependency on Batik
because of the benefits!
Granted, Avalon Framework obviously faces too much resistance and in the
light of that needs to be taken out, at least out of certain code parts.
I can do that if need be. Reluctantly, but I can do it. I don't think
anybody else is ready to volunteer for that ATM, or am I wrong?
> >> I'm also not thrilled with adding lots of logging dependencies.
> >>Logging makes sense for 'non-interactive' contexts but is not really
> >>what you want for most interactive contexts.
> >
> > AFAICS there is exactly one dependency on Commons Logging. Avalon
> > Logging is not used anymore.
>
> Once again it doesn't matter how big or small the dependency is
> a dependency is a dependency. Also the lots of logging dependencies
> come from the pervasiveness of logging. Once you are in it's hard
> to change.
We've changed from Avalon-style logging to Commons Logging and it wasn't
that hard. It's much less of a problem than constantly running after
stray System.outs. It's simply important to know how logging should be
used. It took us a little time in FOP to find that out, but we should be
fine, now.
> So what is common's I/O used for? I assumed it was used for
> Logging.
No. Commons IO is a small library containing low-level helpers for
recurring tasks such as copying stream (which everybody otherwise have
to reinvent each time, with bugs, of course), loading streams into byte
arrays, dealing with file names. It contains helpful Stream and Reader
implementations, for example, a memory-optimized version of
ByteArrayOutputStream. Javadocs here to get an idea:
http://jakarta.apache.org/commons/io/apidocs/index.html
Here's a list of Apache projects using Commons IO (scroll to "Dependees"):
http://vmgump.apache.org/gump/public/jakarta-commons/commons-io/details.html
(The dependecy of Commons IO on Commons Lang in the Gump descriptor is
bogus BTW. Commons IO has no runtime dependencies.)
Want to see the dependees list for Commons Logging? :-)
http://vmgump.apache.org/gump/public/jakarta-commons/commons-logging/details.html
> > I don't see how logging disturbs operation in interactive contexts.
>
> It doesn't necessarily disturb it but it doesn't help either.
It can help the developer. Logging is easily turned off entirely for an
interactive application. Almost no performance penalty for logging if a
few very simple rules are followed.
> > Do you prefer logging by System.out? Or can you do without logging?
>
> I add/uncomment system.err messages (and often make use
> of 'new Error("blah").printStackTrace()') as needed to track problems.
> In the past I've developed elaborate logging systems (mostly C/C++)
> and they can be useful for situations where build times are long
> or you need to support remote clients. But Java build times are tiny
> and end users can access our source.
Yes, in C/C++ you can use macros and all that ugly stuff to filter out
logging code at build time if you don't want it. No go for Java. But
adding and removing System.err/outs all the time is not really a good
solution. There are a few things you can't do with them:
- You can't turn on logging through a configuration file in a production
environment to investigate strange behaviour in a server application.
- You can't just tell people with a problem to specify "-d" on the
command-line do we get more helpful information on what is probably
going on inside the code. This makes helping people a lot easier.
- Switching on a certain group of logging statements for a special task
at hand while developing. It makes me so much more productive.
> > I learned that I can't. Logging is a very powerful means while
> > debugging (dev- and deployment-time).
>
> As I said logging can be useful in non-interactive circumstances,
> but in interactive situations you need to provide feedback through
> the GUI. In my experience logging is useless for this - the type
> and style of messages that goes into logs is very different from
> the GUI.
Exactly. That's a point that is on my task list for FOP. Logging is for
developers, end-users in an interactive environment need different
feedback. So we finally agree on something. I'm a little happier now.
> Now there are potentially non-interactive applications
> for Batik components (the transcoders mostly) but right now they
> handle logging/notification through the UserAgent classes.
Yes, but the name "UserAgent" implies that this is used for interaction
with the user. Who interacts with the developer, giving him the
information he needs?
> >>---
> >>
> >>Other comments:
> >>
> >> You should probably add 'SVGGraphics2D' to the java2D tree,
> >>and possible components coming from Batik.
> >
> >
> > Done. Remember, it's a Wiki! And we get change logs on
> > commits@xmlgraphics.apache.org. :-)
> >
> >
> >> I'm not sure what the intent of the code structure is. It
> >>looks like each of the 'parts' is intended to be an independent
> >>'project' (i.e. separate source tree's). Would it make more
> >>sense to just have one source tree and separate based on
> >>packages (this is what batik does to build it's sub jars)?
> >
> > That's one possibility but people have a hard time understanding what is
> > in which of the batik JARs.
>
> I'm not sure that splitting the code up helps here. I think it
> makes the problem worse (which tree is the stuff I need in?).
Ok, as I said, I'm not too sure about the benefits, but I don't think
it makes the problem worse, either. I'd appreciate additional opinions
here. But then, no opposition from me putting this in a combined directory
structure. I like the separation because it forces you to think a little
more about the dependencies (package dependencies here, not JAR
dependencies) while coding. It makes for more reusable and more cleanly
designed components.
> > Like FOP, Batik is a big blob of code. What I intend with the
> > split is to make it easier and (more importantly) less overwhelming
> > for newbies to start working on certain parts. FOP is scary
> > and so is Batik. Experience shows that despite a clean package structure,
> > people still don't find their way. I don't say that my proposal will
> > definitely solve that problem but I suspect it might help. At any rate,
> > this is an aspect that we need to take very seriously. Batik (even more
> > than FOP) needs to attract new contributors. What happens if you and/or
> > Cameron suddenly go inactive? There's no one left. Project dies. (Sorry,
> > my PMC hat shows here)
>
> I'm happy to split out independent pieces but in my opinion they
> are either completely separate project (independent releases possible)
> or they should be one code base. I think the 1/2 way solution is
> just annoying for everyone.
Ok, so let's start from the combined directory structure, see how it
turns out and decide later if it makes sense to split in any way. It
doesn't really fix the "big blob of code" problem but if we can move
forward, then I'm fine with it. At least moving these code parts to the
Commons area is already a good step in the right direction.
> > Is that plausible?
> >
> >
> >> The current system seems like a lot of extra build nonsense
> >>since each jar has to be built in turn so it can be used to
> >>compile the next project, right?
> >
> > Not necessarily. I don't think a separate build for each package is
> > necessary. I think it's simply helpful to more clearly show to
> > interested people what the individual parts are.
>
> Isn't this better done in the documentation? I fail to see how
> introducing a bunch of extra empty directories does anything to
> help comprehension. And as long as you have one big build you
> don't even get enforcement of unidirectional dependencies.
Again, same arguments as above. But you're right documentation is a big
step towards this already. But it's not about the empty directories
which are the problem, it's the number of outer branches (directories)
if the tree. People don't find out what parts are hidden in the tree.
Better have a forest, each tree representing a component/tool. But again,
no problem taking a small step first. Documentation will help.
> > This also favors a cleaner design which is an additional benefit.
> > I think Victor Mote could tell you a good tale how he alone
> > already profited from dividing FOray (a FOP fork) into digestable
> > chunks.
>
> My point is that it doesn't do anything for good design. There
> is no advantage to this split from a design point of view.
Ok, so we disagree again. Can't be helped. Let's move forward.
So. Do we all agree that I should change the suggested directory tree to
show a combined package structure, not a separate one?
Another thing I can do (if noone objects) while moving code from FOP to
Commons is to remove Commons Logging from certain library parts (PDF lib,
for example) which are not crucial. Maybe even all of it. That should be
possible without too much backfire. I'd kill everybody who'd want to
deprive me of the use of a logging facility in FOP's layout engine,
though. :-) I'd like to keep the dependency on Commons IO. I can offer
to do the repackaging work in the Ant builds.
Jeremias Maerki
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: XML Graphics Commons: last call
Posted by Chris Bowditch <bo...@hotmail.com>.
Hi Thomas,
thanks for clearing up the points I raised. What you are saying is now a
lot clearer to me.
Thomas DeWeese wrote:
<snip/>
> AFAIKS there is no explicit documentation of what the
> configuration object's interface is. It's what ever the file
> happens to contain and the library happens to want to pull out.
> This interface is totally free to change at any point in time.
I understand your objection now. You mean you don't like the generic
nature of the configuration classes.
>
> This is bad, IMO it's akin to global variables. They are really
> easy to manipulate 'outside' of the published interfaces can be
> extremely useful, and make it impossible for the application to
> have a sane view, enforce and/or lockdown he application state.
>
>> If you can't/won't suggest an alternative then you seem to be on weak
>> ground when arguing against something.
>
>
> So I did suggest an alternative (it's right below), publish an
> honest to goodness configuration object with a real interface. Then
> have the application layer populate that through what ever means it
> chooses. I also admitted that I was in a weak position because there
> was no way I was going to rewrite the 'problem' code.
Ok. That wasn't clear before.
>
> But please keep in mind why we are having this discussion. It
> is because we are in the final stages of deciding how Fop and
> Batik can merge development in common areas. You will note that
> in this discussion there is no issue around Batik external dependencies
> because there are none. All of our external dependencies are
> pay as you go (Xalan, rhino, pdf-transcoder,...). Batik hasn't
> inflicted other projects our users without strong justification.
I seem to remember some pain relating to licensing of Rhino recently. So
I don't completely agree here. The fact is that both projects need to
use third party software. It's all about code re-use, ease of
development etc.
>
>>> The problem is that I don't care how big or small a dependency is
>>> once the dependency is there it causes problems.
>>
>>
>> I understand the concern about adding a new dependency and agree size
>> is somewhat irrelevant. The alternative is to rewrite everything
>> yourself which isn't very good either.
>
>
> So I'm happy to use libraries that provide significant functionality
> but I don't like adding a dependency for something as silly as
> configuration. I understand that it 'makes it easy' on the programmer
> to provide a broad configuration interface, but I'm fairly convinced
> that this is often not a good thing.
Ok. I don't disagree with you now that you've explained your point better.
>
>>>> I don't see how logging disturbs operation in interactive contexts.
>>>
>>>
>>> It doesn't necessarily disturb it but it doesn't help either.
>>
>>
>> Not true. Logging is extremely helpful when debugging problems raised
>> by a remote user. And since all our users are remote and supported by
>> the mailing list logging is vital to supporting our users.
>
>
> Come on, the way we support remote users is almost always:
> Please send us a reproducible test case
Sometimes yes, but often too we ask them to specify -d at the command
line to figure out why they have just "null" appearing on stdout.
>
> If they have integrated the application into a larger app then
> they are Java savy and they can be asked to modify source. Look
> I'm not trying to say that Logging is useless just that it is
> another example of something I would rather not introduce an
> external dependency to provide.
This is a fair argument against the configuration classes, but not
against the logging classes. There is a strong justification for logging
in supporting users and as a development aid.
We would prefer not to remove configuration as a dependency, but I think
we could do it as a compromise if you are prepared to accept logging as
a dependency.
<snip/>
> As I said that is currently done through the UserAgent class.
> The basic point I was making is that in order to support the GUI we
> need something a bit higher level than logging, as long as Batik
> needs that to support interactive contexts we can use it where
> FOP uses logging.
So you can simply turn off logging for the interactive use case and use
something else, which is specific to Batik and therefore won't need to
live in xml-commons.
>> You may be right here, but your earlier arguments are not related IMO.
>
>
> No they weren't intended to be. This is a separate piece of
> commentary on the proposal.
OK.
>
>>>> I think it's simply helpful to more clearly show to
>>>> interested people what the individual parts are.
>>>
>>>
>>> Isn't this better done in the documentation? I fail to see how
>>> introducing a bunch of extra empty directories does anything to
>>> help comprehension. And as long as you have one big build you
>>> don't even get enforcement of unidirectional dependencies.
>>
>>
>> Who said anything about creating empty directories? Empty ones won't
>> be helpful, but breaking up big packages into smaller ones makes the
>> code easier to get to grips with.
>
>
> So what are you going to be putting in all the extra copies of?
>
> <blah>/source/java/org/apache/xmlgraphics
>
> I consider those to be 'empty directories', you need one copy
> of them but you don't need 7-8 copies of them.
I think I misunderstood this part of the debate. Sorry for any confusion.
<snip/>
>
> What helps understanding is good documentation.
Agreed.
Chris
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: XML Graphics Commons: last call
Posted by Thomas DeWeese <Th...@Kodak.com>.
Chris Bowditch wrote:
> Thomas DeWeese wrote:
>
> <snip/>
>
>> Ok so I took some time and I really don't like this model.
>> This is exactly the sort of thing that belongs at the application
>> layer not at the library layer. The idea of 'passing data' around
>> the application through a config file seems really bad to me.
>> (it's an excellent example of a programmers hack, look at all the
>> cool stuff I can do, so I can also break things in really odd
>> unpredictable ways - that's a small price to pay for tweakability).
>
> I don't understand why passing a configuration object around an
> application should be considered a programmer hack. It's common and well
> accepted practise. Can you elaborate a bit on why you think it's a hack?
AFAIKS there is no explicit documentation of what the
configuration object's interface is. It's what ever the file
happens to contain and the library happens to want to pull out.
This interface is totally free to change at any point in time.
This is bad, IMO it's akin to global variables. They are really
easy to manipulate 'outside' of the published interfaces can be
extremely useful, and make it impossible for the application to
have a sane view, enforce and/or lockdown he application state.
> If you can't/won't suggest an alternative then you seem to be on
> weak ground when arguing against something.
So I did suggest an alternative (it's right below), publish an
honest to goodness configuration object with a real interface. Then
have the application layer populate that through what ever means it
chooses. I also admitted that I was in a weak position because there
was no way I was going to rewrite the 'problem' code.
But please keep in mind why we are having this discussion. It
is because we are in the final stages of deciding how Fop and
Batik can merge development in common areas. You will note that
in this discussion there is no issue around Batik external dependencies
because there are none. All of our external dependencies are
pay as you go (Xalan, rhino, pdf-transcoder,...). Batik hasn't
inflicted other projects our users without strong justification.
>> The problem is that I don't care how big or small a dependency is
>> once the dependency is there it causes problems.
>
> I understand the concern about adding a new dependency and agree size is
> somewhat irrelevant. The alternative is to rewrite everything yourself
> which isn't very good either.
So I'm happy to use libraries that provide significant functionality
but I don't like adding a dependency for something as silly as
configuration. I understand that it 'makes it easy' on the programmer
to provide a broad configuration interface, but I'm fairly convinced
that this is often not a good thing.
>>> I don't see how logging disturbs operation in interactive contexts.
>>
>> It doesn't necessarily disturb it but it doesn't help either.
>
> Not true. Logging is extremely helpful when debugging problems raised by
> a remote user. And since all our users are remote and supported by the
> mailing list logging is vital to supporting our users.
Come on, the way we support remote users is almost always:
Please send us a reproducible test case
If they have integrated the application into a larger app then
they are Java savy and they can be asked to modify source. Look
I'm not trying to say that Logging is useless just that it is
another example of something I would rather not introduce an
external dependency to provide.
>> As I said logging can be useful in non-interactive circumstances,
>> but in interactive situations you need to provide feedback through
>> the GUI. In my experience logging is useless for this - the type
>> and style of messages that goes into logs is very different from
>> the GUI. Now there are potentially non-interactive applications
>> for Batik components (the transcoders mostly) but right now they
>> handle logging/notification through the UserAgent classes.
>
> FOP doesn't have a GUI and whilst Batik may have a GUI in some
> circumstances - there are other use cases - such as transcoders (that
> you already mentioned) and embedded use of Batik where logging is
> necessary to provide feedback of what Batik is doing.
As I said that is currently done through the UserAgent class.
The basic point I was making is that in order to support the GUI we
need something a bit higher level than logging, as long as Batik
needs that to support interactive contexts we can use it where
FOP uses logging.
>> I'm happy to split out independent pieces but in my opinion they
>> are either completely separate project (independent releases possible)
>> or they should be one code base. I think the 1/2 way solution is
>> just annoying for everyone.
>
> You may be right here, but your earlier arguments are not related IMO.
No they weren't intended to be. This is a separate piece of
commentary on the proposal.
>>> I think it's simply helpful to more clearly show to
>>> interested people what the individual parts are.
>>
>> Isn't this better done in the documentation? I fail to see how
>> introducing a bunch of extra empty directories does anything to
>> help comprehension. And as long as you have one big build you
>> don't even get enforcement of unidirectional dependencies.
>
> Who said anything about creating empty directories? Empty ones won't be
> helpful, but breaking up big packages into smaller ones makes the code
> easier to get to grips with.
So what are you going to be putting in all the extra copies of?
<blah>/source/java/org/apache/xmlgraphics
I consider those to be 'empty directories', you need one copy
of them but you don't need 7-8 copies of them.
Can't you see that we would be kidding our selves if we
really believe that the above is more 'understandable' than:
source/java/org/apache/xmlgraphics/<blah>
Can't you see how unless each project is built and released
independently (at least potentially) all this does is introduce
8 copies of the root of the source tree?
> I guess you have a point here. Splitting up large packages into small
> ones helps understanding not the design.
What helps understanding is good documentation.
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: XML Graphics Commons: last call
Posted by Chris Bowditch <bo...@hotmail.com>.
Thomas DeWeese wrote:
<snip/>
> Ok so I took some time and I really don't like this model.
> This is exactly the sort of thing that belongs at the application
> layer not at the library layer. The idea of 'passing data' around
> the application through a config file seems really bad to me.
> (it's an excellent example of a programmers hack, look at all the
> cool stuff I can do, so I can also break things in really odd
> unpredictable ways - that's a small price to pay for tweakability).
I don't understand why passing a configuration object around an
application should be considered a programmer hack. It's common and well
accepted practise. Can you elaborate a bit on why you think it's a hack?
>
> The problem is that I'm sure this is exactly the sort of
> thing that sparked the flame wars. I also am not going to even
> come close to have the time or interest to provide a replacement.
Your reason why a flame war should result is not clear to me. If you
can't/won't suggest an alternative then you seem to be on weak ground
when arguing against something.
>
>>>> If anything, those who have a problem
>>>> with A-F should propose a viable alternative (I haven't seen one, yet)
>>>> or work with the Excalibur guys to extract the configuration subpackage
>>>> into a stand-alone lib.
>>>
>>>
>>> Since I have no idea what the library is and/or what you
>>> plan to use it for I can't really provide alternatives.
>
>
> This should be done the old fashioned way, the library should export
> interfaces to support configuration and the _application_ should
> provide the configuration data to the library as appropriate for
> the application. I think this is really trying to do an end run
> around this. There is no clear description of the data that passes
> across this interface - that's really ugly IMO.
Agreed that the application may need to provide implementations of
anything specific - but the classes we are talking about are deemed to
be generic.
>
>> But A-F contains a configuration subpackage [2] which is very small,
>> very easy to use and provides exactly what is necessary to load a
>> configuration tree from an XML file and to access values in a type-safe
>> and fail-safe manner while not having to deal with the deficiencies of a
>> DOM.
>
>
> The problem is that I don't care how big or small a dependency is
> once the dependency is there it causes problems.
I understand the concern about adding a new dependency and agree size is
somewhat irrelevant. The alternative is to rewrite everything yourself
which isn't very good either.
<snip/>
>> I don't see how logging disturbs operation in interactive contexts.
>
>
> It doesn't necessarily disturb it but it doesn't help either.
Not true. Logging is extremely helpful when debugging problems raised by
a remote user. And since all our users are remote and supported by the
mailing list logging is vital to supporting our users.
>
>> Do you prefer logging by System.out? Or can you do without logging?
>
>
> I add/uncomment system.err messages (and often make use
> of 'new Error("blah").printStackTrace()') as needed to track problems.
> In the past I've developed elaborate logging systems (mostly C/C++)
> and they can be useful for situations where build times are long
> or you need to support remote clients. But Java build times are tiny
> and end users can access our source.
Well thats fine for development, but no help for supporting remote
users. To tell a user where the source code is and they should figure it
out themselves is not acceptable. A small percentage of users may be
happy to do this, but most will not be java savy and will expect help
from the developers.
>
>> I learned that I can't. Logging is a very powerful means while
>> debugging (dev- and deployment-time).
>
>
> As I said logging can be useful in non-interactive circumstances,
> but in interactive situations you need to provide feedback through
> the GUI. In my experience logging is useless for this - the type
> and style of messages that goes into logs is very different from
> the GUI. Now there are potentially non-interactive applications
> for Batik components (the transcoders mostly) but right now they
> handle logging/notification through the UserAgent classes.
FOP doesn't have a GUI and whilst Batik may have a GUI in some
circumstances - there are other use cases - such as transcoders (that
you already mentioned) and embedded use of Batik where logging is
necessary to provide feedback of what Batik is doing.
<snip/>
> I'm happy to split out independent pieces but in my opinion they
> are either completely separate project (independent releases possible)
> or they should be one code base. I think the 1/2 way solution is
> just annoying for everyone.
You may be right here, but your earlier arguments are not related IMO.
>
>> Is that plausible?
>>
>>
>>> The current system seems like a lot of extra build nonsense
>>> since each jar has to be built in turn so it can be used to
>>> compile the next project, right?
>>
>>
>> Not necessarily. I don't think a separate build for each package is
>> necessary. I think it's simply helpful to more clearly show to
>> interested people what the individual parts are.
>
>
> Isn't this better done in the documentation? I fail to see how
> introducing a bunch of extra empty directories does anything to
> help comprehension. And as long as you have one big build you
> don't even get enforcement of unidirectional dependencies.
Who said anything about creating empty directories? Empty ones won't be
helpful, but breaking up big packages into smaller ones makes the code
easier to get to grips with.
>
>> This also favors a cleaner design which is an additional benefit. I
>> think Victor Mote could tell you a good tale how he alone already
>> profited from dividing FOray (a FOP fork) into digestable chunks.
>
>
> My point is that it doesn't do anything for good design. There
> is no advantage to this split from a design point of view.
I guess you have a point here. Splitting up large packages into small
ones helps understanding not the design.
Chris
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: XML Graphics Commons: last call
Posted by Thomas DeWeese <Th...@Kodak.com>.
Jeremias Maerki wrote:
> On 09.08.2005 13:12:18 Thomas DeWeese wrote:
>>>On 08.08.2005 22:31:09 J.Pietschmann wrote:
>>
>>>>2. Seeing Avalon as dependency makes me uneasy. I'd prefer
>>>>commons code to be refactored to not using Avalon and to
>>>>provide raw functionality only.
>>
>> So I am a bit concerned about the addition of three new
>>external dependencies for Batik. I realize that some of it is
>>already there but hidden in the PDF transcoder.
>>
>>Jeremias Maerki wrote:
>>
>>>Everybody always complains about that little library. What's the problem?
>>>We're not going to do Avalonization anymore. But the configuration
>>>subpackage in A-F is a perfect (!) little tool and a LOT smaller than
>>>Jakarta Commons Configuration.
>>
>> What are we configuring?
>
> Fonts and optional PDF-fine-tuning, mostly. Not everything that could
> also be configured in FOP 0.20.5 is already implemented in the trunk.
Ok so I took some time and I really don't like this model.
This is exactly the sort of thing that belongs at the application
layer not at the library layer. The idea of 'passing data' around
the application through a config file seems really bad to me.
(it's an excellent example of a programmers hack, look at all the
cool stuff I can do, so I can also break things in really odd
unpredictable ways - that's a small price to pay for tweakability).
The problem is that I'm sure this is exactly the sort of
thing that sparked the flame wars. I also am not going to even
come close to have the time or interest to provide a replacement.
>>>If anything, those who have a problem
>>>with A-F should propose a viable alternative (I haven't seen one, yet)
>>>or work with the Excalibur guys to extract the configuration subpackage
>>>into a stand-alone lib.
>>
>> Since I have no idea what the library is and/or what you
>>plan to use it for I can't really provide alternatives.
This should be done the old fashioned way, the library should export
interfaces to support configuration and the _application_ should
provide the configuration data to the library as appropriate for
the application. I think this is really trying to do an end run
around this. There is no clear description of the data that passes
across this interface - that's really ugly IMO.
> But A-F contains a configuration subpackage [2] which is very small,
> very easy to use and provides exactly what is necessary to load a
> configuration tree from an XML file and to access values in a type-safe
> and fail-safe manner while not having to deal with the deficiencies of a
> DOM.
The problem is that I don't care how big or small a dependency is
once the dependency is there it causes problems.
>> I'm also not thrilled with adding lots of logging dependencies.
>>Logging makes sense for 'non-interactive' contexts but is not really
>>what you want for most interactive contexts.
>
> AFAICS there is exactly one dependency on Commons Logging. Avalon
> Logging is not used anymore.
Once again it doesn't matter how big or small the dependency is
a dependency is a dependency. Also the lots of logging dependencies
come from the pervasiveness of logging. Once you are in it's hard
to change.
So what is common's I/O used for? I assumed it was used for
Logging.
> I don't see how logging disturbs operation in interactive contexts.
It doesn't necessarily disturb it but it doesn't help either.
> Do you prefer logging by System.out? Or can you do without logging?
I add/uncomment system.err messages (and often make use
of 'new Error("blah").printStackTrace()') as needed to track problems.
In the past I've developed elaborate logging systems (mostly C/C++)
and they can be useful for situations where build times are long
or you need to support remote clients. But Java build times are tiny
and end users can access our source.
> I learned that I can't. Logging is a very powerful means while
> debugging (dev- and deployment-time).
As I said logging can be useful in non-interactive circumstances,
but in interactive situations you need to provide feedback through
the GUI. In my experience logging is useless for this - the type
and style of messages that goes into logs is very different from
the GUI. Now there are potentially non-interactive applications
for Batik components (the transcoders mostly) but right now they
handle logging/notification through the UserAgent classes.
>>---
>>
>>Other comments:
>>
>> You should probably add 'SVGGraphics2D' to the java2D tree,
>>and possible components coming from Batik.
>
>
> Done. Remember, it's a Wiki! And we get change logs on
> commits@xmlgraphics.apache.org. :-)
>
>
>> I'm not sure what the intent of the code structure is. It
>>looks like each of the 'parts' is intended to be an independent
>>'project' (i.e. separate source tree's). Would it make more
>>sense to just have one source tree and separate based on
>>packages (this is what batik does to build it's sub jars)?
>
> That's one possibility but people have a hard time understanding what is
> in which of the batik JARs.
I'm not sure that splitting the code up helps here. I think it
makes the problem worse (which tree is the stuff I need in?).
> Like FOP, Batik is a big blob of code. What I intend with the
> split is to make it easier and (more importantly) less overwhelming
> for newbies to start working on certain parts. FOP is scary
> and so is Batik. Experience shows that despite a clean package structure,
> people still don't find their way. I don't say that my proposal will
> definitely solve that problem but I suspect it might help. At any rate,
> this is an aspect that we need to take very seriously. Batik (even more
> than FOP) needs to attract new contributors. What happens if you and/or
> Cameron suddenly go inactive? There's no one left. Project dies. (Sorry,
> my PMC hat shows here)
I'm happy to split out independent pieces but in my opinion they
are either completely separate project (independent releases possible)
or they should be one code base. I think the 1/2 way solution is
just annoying for everyone.
> Is that plausible?
>
>
>> The current system seems like a lot of extra build nonsense
>>since each jar has to be built in turn so it can be used to
>>compile the next project, right?
>
> Not necessarily. I don't think a separate build for each package is
> necessary. I think it's simply helpful to more clearly show to
> interested people what the individual parts are.
Isn't this better done in the documentation? I fail to see how
introducing a bunch of extra empty directories does anything to
help comprehension. And as long as you have one big build you
don't even get enforcement of unidirectional dependencies.
> This also favors a cleaner design which is an additional benefit.
> I think Victor Mote could tell you a good tale how he alone
> already profited from dividing FOray (a FOP fork) into digestable
> chunks.
My point is that it doesn't do anything for good design. There
is no advantage to this split from a design point of view.
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: XML Graphics Commons: last call
Posted by Cameron McCormack <ca...@mcc.id.au>.
Jeremias Maerki:
> That's one possibility but people have a hard time understanding what is
> in which of the batik JARs. Like FOP, Batik is a big blob of code. What
> I intend with the split is to make it easier and (more importantly) less
> overwhelming for newbies to start working on certain parts. FOP is scary
> and so is Batik. Experience shows that despite a clean package structure,
> people still don't find their way. I don't say that my proposal will
> definitely solve that problem but I suspect it might help. At any rate,
> this is an aspect that we need to take very seriously. Batik (even more
> than FOP) needs to attract new contributors. What happens if you and/or
> Cameron suddenly go inactive? There's no one left. Project dies. (Sorry,
> my PMC hat shows here)
One thing I would like is a detailed description of the structure of
Batik, how all the classes interact and so on. I remember when I was
originally trying to understand how Batik worked, it took me quite a
while. And even when I thought I had understood some of it, there was
still plenty I wasn't exactly clear about. I'd like to write such a
document when I get some time. Perhaps early next year.
--
e-mail : cam (at) mcc.id.au icq : 26955922
web : http://mcc.id.au/ msn : cam-msn (at) aka.mcc.id.au
office : +61399055779 jabber : heycam (at) jabber.org
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: XML Graphics Commons: last call
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 09.08.2005 13:12:18 Thomas DeWeese wrote:
> Hi all,
>
> > On 08.08.2005 22:31:09 J.Pietschmann wrote:
>
> >>2. Seeing Avalon as dependency makes me uneasy. I'd prefer
> >>commons code to be refactored to not using Avalon and to
> >>provide raw functionality only.
>
> So I am a bit concerned about the addition of three new
> external dependencies for Batik. I realize that some of it is
> already there but hidden in the PDF transcoder.
>
> Jeremias Maerki wrote:
>
> > Everybody always complains about that little library. What's the problem?
> > We're not going to do Avalonization anymore. But the configuration
> > subpackage in A-F is a perfect (!) little tool and a LOT smaller than
> > Jakarta Commons Configuration.
>
> What are we configuring?
Fonts and optional PDF-fine-tuning, mostly. Not everything that could
also be configured in FOP 0.20.5 is already implemented in the trunk.
FontSetup.buildFontListFromConfiguration():
http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/FontSetup.java
PDFFilterList.buildFilterMapFromConfiguration();
http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/src/java/org/apache/fop/pdf/PDFFilterList.java
PDF- and AbstractPSTrancoder implement the Avalon Configurable interface
to receive the configuration for fonts and PDF ATM:
http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/src/java/org/apache/fop/svg/PDFTranscoder.java
http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/src/java/org/apache/fop/svg/PDFDocumentGraphics2D.java
http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/src/java/org/apache/fop/render/ps/AbstractPSTranscoder.java
(For PS this is only prepared but not implemented, yet)
The following Wiki page shows how this is currently used:
http://wiki.apache.org/xmlgraphics-fop/SvgNotes/PdfTranscoderTrueTypeEmbedding
> > If anything, those who have a problem
> > with A-F should propose a viable alternative (I haven't seen one, yet)
> > or work with the Excalibur guys to extract the configuration subpackage
> > into a stand-alone lib.
>
> Since I have no idea what the library is and/or what you
> plan to use it for I can't really provide alternatives.
Avalon Framework [1] defined a special programming model promoting
Inversion of Control and Separation of Concerns. We had plans to use
these patterns in FOP but it never really came to that. Now that the
Avalon project has been closed (mostly due to community wars),
maintenance of A-F has moved to Excalibur and Cocoon is currently moving
slowly away from Avalon to OSGi, this is no issue anymore.
But A-F contains a configuration subpackage [2] which is very small,
very easy to use and provides exactly what is necessary to load a
configuration tree from an XML file and to access values in a type-safe
and fail-safe manner while not having to deal with the deficiencies of a
DOM. I've also used it exactly for that in Barcode4J (my open source
barcode library) with great success.
[1] http://excalibur.apache.org/framework/index.html
[2] http://excalibur.apache.org/apidocs/org/apache/avalon/framework/configuration/package-summary.html
> I'm also not thrilled with adding lots of logging dependencies.
> Logging makes sense for 'non-interactive' contexts but is not really
> what you want for most interactive contexts.
AFAICS there is exactly one dependency on Commons Logging. Avalon
Logging is not used anymore.
I don't see how logging disturbs operation in interactive contexts. Do
you prefer logging by System.out? Or can you do without logging? I
learned that I can't. Logging is a very powerful means while debugging
(dev- and deployment-time).
> ---
>
> Other comments:
>
> You should probably add 'SVGGraphics2D' to the java2D tree,
> and possible components coming from Batik.
Done. Remember, it's a Wiki! And we get change logs on
commits@xmlgraphics.apache.org. :-)
> I'm not sure what the intent of the code structure is. It
> looks like each of the 'parts' is intended to be an independent
> 'project' (i.e. separate source tree's). Would it make more
> sense to just have one source tree and separate based on
> packages (this is what batik does to build it's sub jars)?
That's one possibility but people have a hard time understanding what is
in which of the batik JARs. Like FOP, Batik is a big blob of code. What
I intend with the split is to make it easier and (more importantly) less
overwhelming for newbies to start working on certain parts. FOP is scary
and so is Batik. Experience shows that despite a clean package structure,
people still don't find their way. I don't say that my proposal will
definitely solve that problem but I suspect it might help. At any rate,
this is an aspect that we need to take very seriously. Batik (even more
than FOP) needs to attract new contributors. What happens if you and/or
Cameron suddenly go inactive? There's no one left. Project dies. (Sorry,
my PMC hat shows here)
Is that plausible?
> The current system seems like a lot of extra build nonsense
> since each jar has to be built in turn so it can be used to
> compile the next project, right?
Not necessarily. I don't think a separate build for each package is
necessary. I think it's simply helpful to more clearly show to
interested people what the individual parts are. This also favors a
cleaner design which is an additional benefit. I think Victor Mote could
tell you a good tale how he alone already profited from dividing FOray
(a FOP fork) into digestable chunks.
> Also you keep mentioning 'pattern' classes which might not be able
> to be transfered (depends on GVT tree), I think you probably mean the
> 'gradient' classes which should be able to be moved (we will try to
> move the pattern stuff but it isn't a slam dunk).
Could be. I probably messed that up.
Thanks for the feedback.
Jeremias Maerki
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: XML Graphics Commons: last call
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi all,
> On 08.08.2005 22:31:09 J.Pietschmann wrote:
>>2. Seeing Avalon as dependency makes me uneasy. I'd prefer
>>commons code to be refactored to not using Avalon and to
>>provide raw functionality only.
So I am a bit concerned about the addition of three new
external dependencies for Batik. I realize that some of it is
already there but hidden in the PDF transcoder.
Jeremias Maerki wrote:
> Everybody always complains about that little library. What's the problem?
> We're not going to do Avalonization anymore. But the configuration
> subpackage in A-F is a perfect (!) little tool and a LOT smaller than
> Jakarta Commons Configuration.
What are we configuring?
> If anything, those who have a problem
> with A-F should propose a viable alternative (I haven't seen one, yet)
> or work with the Excalibur guys to extract the configuration subpackage
> into a stand-alone lib.
Since I have no idea what the library is and/or what you
plan to use it for I can't really provide alternatives.
I'm also not thrilled with adding lots of logging dependencies.
Logging makes sense for 'non-interactive' contexts but is not really
what you want for most interactive contexts.
---
Other comments:
You should probably add 'SVGGraphics2D' to the java2D tree,
and possible components coming from Batik.
I'm not sure what the intent of the code structure is. It
looks like each of the 'parts' is intended to be an independent
'project' (i.e. separate source tree's). Would it make more
sense to just have one source tree and separate based on
packages (this is what batik does to build it's sub jars)?
The current system seems like a lot of extra build nonsense
since each jar has to be built in turn so it can be used to
compile the next project, right?
Also you keep mentioning 'pattern' classes which might not be able
to be transfered (depends on GVT tree), I think you probably mean the
'gradient' classes which should be able to be moved (we will try to
move the pattern stuff but it isn't a slam dunk).
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: XML Graphics Commons: last call
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Jeremias Maerki wrote:
> BTW, what's a "tool"?
Anything which is not generally used by the average end user.
I'd like to add "reusable" to the definition, but this might be
too restricting.
Ant tasks and other plugin-type stuff should qualify in addition
to standalone apps.
> Everybody always complains about that little library. What's the problem?
Bad name. Unpleasant associations. Flamewars. Uncontrolled playground.
Small but extremely annoying design bugs. Endless debug sessions due to
misleading error messages. Microsoft Avalon.
J.Pietschmann
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: XML Graphics Commons: last call
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 08.08.2005 22:31:09 J.Pietschmann wrote:
> The Web Maestro wrote:
> ...
>
> Thanks for providing me with a hook into the thread!
>
> My 2c to the proposal:
> 1. Its not all that clear to me whether xmlgraphics
> commons is for commonly used tool, libraries or both.
Primarily, it should be a set of libraries. PFMReader and TTFReader will
be inevitable tools at the beginning but I don't think it should be a
place for tools. Tools should get their own subproject. I've updated the
Wiki page to try to make that clearer. BTW, what's a "tool"? Is that a
class with a main() method?
> 2. Seeing Avalon as dependency makes me uneasy. I'd prefer
> commons code to be refactored to not using Avalon and to
> provide raw functionality only.
Everybody always complains about that little library. What's the problem?
We're not going to do Avalonization anymore. But the configuration
subpackage in A-F is a perfect (!) little tool and a LOT smaller than
Jakarta Commons Configuration. If anything, those who have a problem
with A-F should propose a viable alternative (I haven't seen one, yet)
or work with the Excalibur guys to extract the configuration subpackage
into a stand-alone lib.
Jeremias Maerki
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: XML Graphics Commons: last call
Posted by "J.Pietschmann" <j3...@yahoo.de>.
The Web Maestro wrote:
...
Thanks for providing me with a hook into the thread!
My 2c to the proposal:
1. Its not all that clear to me whether xmlgraphics
commons is for commonly used tool, libraries or both.
2. Seeing Avalon as dependency makes me uneasy. I'd prefer
commons code to be refactored to not using Avalon and to
provide raw functionality only.
J.Pietschmann
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: XML Graphics Commons: last call
Posted by The Web Maestro <th...@gmail.com>.
The only thing that strikes me, is that Java2D doesn't say (make
reference or include any info to help searchers find it--e.g., formerly
AWT). Apolgies for the delay, I'm moving the house, office, and servers
this month...
Regards,
Web Maestro Clay
--
<th...@gmail.com> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: XML Graphics Commons: last call
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Jeremias Maerki wrote:
> The discussion will be exclusively on
> general@xmlgraphics.apache.org.
I've just detected I'm not subscribed to general@xmlgraphics
Duh!
J.Pietschmann
Re: XML Graphics Commons: last call
Posted by Jeremias Maerki <de...@greenmail.ch>.
Thanks, Thomas, for getting back to me. There's only the one dependency
on Commons IO left. I'm sorry if this somehow wasn't clear enough. As I
said we can see to it that we can get rid of the other two. If it really
becomes unbearable I'm sure we can talk about Commons IO, too. But I
really think that's a good and useful one.
So I think we can proceed to the vote now. I'll prepare it right away.
On 24.08.2005 02:18:44 Thomas DeWeese wrote:
> Hi Jeremias,
>
> Jeremias Maerki wrote:
> > Is there anything to add? I'd like to proceed to the formal vote if
> > possible.
> >
> > Thomas, are you ok with the plan as it stands right now or are you
> > still upset by my remarks in this thread and having reservations?
>
> I'm still not thrilled with the added dependencies, but I
> think we have a reasonable understanding for now.
Jeremias Maerki
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: XML Graphics Commons: last call
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Jeremias,
Jeremias Maerki wrote:
> Is there anything to add? I'd like to proceed to the formal vote if
> possible.
>
> Thomas, are you ok with the plan as it stands right now or are you
> still upset by my remarks in this thread and having reservations?
I'm still not thrilled with the added dependencies, but I
think we have a reasonable understanding for now.
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: XML Graphics Commons: last call
Posted by Jeremias Maerki <de...@greenmail.ch>.
Is there anything to add? I'd like to proceed to the formal vote if
possible.
Thomas, are you ok with the plan as it stands right now or are you
still upset by my remarks in this thread and having reservations?
Thanks,
Jeremias Maerki
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org