Opinion poll: Additional utility jars

[Jeremias Maerki <de...@greenmail.ch>]

I'm stumbling over code blocks every now and then that could/should be
reused or even used from a common library. Examples of that are stream
copying code, little/big endian conversions etc. This is mostly little
stuff but these things wouldn't need to be in our codebase. Sometimes
there's code around that could simply be written much more cleanly. I've
recently changed FontFileReader which had a very strange way of loading
a file using buffers. I've added a copyStream method which could easily
replaced by code from Commons IO, for example. Well, ok, I've introduced
a bug when I did that, but after fixing the bug the code is now a lot
clearer. Also, gradually introducing more of Avalon in the redesign will
lead to additional jars that we will need.

So, what I want to have opinions for is the following:

How could we handle the usage of additional libraries such as Jakarta Commons
packages or stuff from Avalon Excalibur?

Right now, we have avalon-framework.jar in our lib directory. I still
remember the somewhat negative feedback from users when we introduced
that one (!) new jar file as a dependency. Ok, we've also had LogKit,
but we were able to make that one optional.

Excalibur is a collection of small packages which all provide little
jars, one or more jar per package/sub-sub-subproject. Of course, there's
also a big one, but that would mean that you'd obviously have to use a
big jar from which you may well be using less than 20%. Same for Jakarta
Commons.

So what comes to my mind is two things:

1. Provide a big fop-complete.jar which contains among the fop classes all
the utility packages with an Apache home (Commons, Avalon stuff). That's
for easy use and involves repackaging of the utility jars during build.

2. Provide the same fop.jar as before but we'll have some more jars in
out lib directory over time. This obviously means that the classpath
will get some longer.

IMO both has to be done, especially to service those who don't like a
lot of jars in their classpath.

I'm looking forward to your comments and ideas.

Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: Opinion poll: Additional utility jars

[Oleg Tkachenko <ol...@multiconn.com>]

Ralph LaChance wrote:

>> Extensions to the original proposal:
>> - Modularize FOP a bit better: build separate jars for the core, CLI,
>>   AWTViewer and the servlet (and move the servlet from contrib to the
>>   main src tree)
> 
> 
> gee, last I checked, the AWTViewer is fewer than a dozen classes,
> and I'd guess it ~doesn't~ use a at most 2 or 3 dozen class files from
> the fully-loaded jar (i.e., classes for the PDF and other renderers.)
> Is it really worth factoring fop into separate jars that differ so little ?

I think it should. First of all it's clearly distinct component, which 
can be superfluous sometimes, e.g. when FOP is running on a server. 
Secondly, you forgot about GUI and L10n resources, which are going to 
get bigger. And last, there are some enhancement requests and plans 
about this stuff, so I'm sure it'll grow.

-- 
Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: Opinion poll: Additional utility jars

[Ralph LaChance <Ra...@compuserve.com>]

At 02:11 PM 12/1/02, you wrote:
>Extensions to the original proposal:
>- Modularize FOP a bit better: build separate jars for the core, CLI,
>   AWTViewer and the servlet (and move the servlet from contrib to the
>   main src tree)

gee, last I checked, the AWTViewer is fewer than a dozen classes,
and I'd guess it ~doesn't~ use a at most 2 or 3 dozen class files from
the fully-loaded jar (i.e., classes for the PDF and other renderers.)
Is it really worth factoring fop into separate jars that differ so little ?



         ' Best,
         -Ralph LaChance



         In theory, there is no difference between
         theory and practice, but in practice there is.

                 (Someone wrote that, but I don't know who.)




---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: Opinion poll: Additional utility jars

[Oleg Tkachenko <ol...@multiconn.com>]

Jeremias Maerki wrote:

> 1. Provide a big fop-complete.jar which contains among the fop classes all
> the utility packages with an Apache home (Commons, Avalon stuff). That's
> for easy use and involves repackaging of the utility jars during build.
> 
> 2. Provide the same fop.jar as before but we'll have some more jars in
> out lib directory over time. This obviously means that the classpath
> will get some longer.
> 
> IMO both has to be done, especially to service those who don't like a
> lot of jars in their classpath.
Sounds reasonable. +1

-- 
Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: Opinion poll: Additional utility jars

[Oleg Tkachenko <ol...@multiconn.com>]

J.Pietschmann wrote:

> Extensions to the original proposal:
> - Modularize FOP a bit better: build separate jars for the core, CLI,
>   AWTViewer and the servlet (and move the servlet from contrib to the
>   main src tree)
+1 We need a bit of COP here. What about a little brainstorm on 
decomposing FOP in avalon sense?

> - Check what can be shared with Batik. Some parts of font handling comes
>   to mind. BIDI handling too. Unify approaches in the API perhaps.
Good idea. +1

-- 
Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: Opinion poll: Additional utility jars

["J.Pietschmann" <j3...@yahoo.de>]

Jeremias Maerki wrote:
> I'm stumbling over code blocks every now and then that could/should be
> reused or even used from a common library.

Extensions to the original proposal:
- Modularize FOP a bit better: build separate jars for the core, CLI,
   AWTViewer and the servlet (and move the servlet from contrib to the
   main src tree)
- Check what can be shared with Batik. Some parts of font handling comes
   to mind. BIDI handling too. Unify approaches in the API perhaps.

> 2. Provide the same fop.jar as before but we'll have some more jars in
> out lib directory over time. This obviously means that the classpath
> will get some longer.
> 
> IMO both has to be done, especially to service those who don't like a
> lot of jars in their classpath.

Batik has a batik-all.jar and a huge bunch of smaller jars for people
who want only a part of the functionality.

While I like the idea of factoring out utilities and commonly used
funktionality to projects like xml-commons, this increases the potential
for version clashes. An example is the trouble in Cocoon because the
Batik version needed by FOP was not the same as the one used by the
Cocoon serializers. Auxilary libraries need a very stable API and a
very careful design. If this is met, I'm +1, otherwise -0.

J.Pietschmann


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org