On Feb 8, 2004, at 3:37 AM, J.Pietschmann wrote:
If we are involved in such considerations, we need to decide how we
propose to support our 1.3 user base. The most recent discussions
showed that a number of users face steep costs to upgrade to 1.4.
As for the 1.4 discussion: The jakarta commons
Clay Leeds wrote:
On Feb 8, 2004, at 3:37 AM, J.Pietschmann wrote:
snip/
I had a similar thought process (0_20_2-maintain for pre-1.4 users--if
it works, don't fix it?). As for 1.0 (forgive my playing the devil's
advocate here), why stop at 1.4? Assuming Java 1.5 will be released by
the time
-Original Message-
From: Clay Leeds [mailto:[EMAIL PROTECTED]
snip /
I had a similar thought process (0_20_2-maintain for pre-1.4 users--if
it works, don't fix it?). As for 1.0 (forgive my playing the devil's
advocate here), why stop at 1.4? Assuming Java 1.5 will be released by
the
I'm pleasantly surprised by your proposal. Wasn't it you who wanted the
servlet in the main source tree a year ago?
On 08.02.2004 00:38:35 J.Pietschmann wrote:
snip/
There ought to be a less messy approach. It could be an idea
to move the various packages to different base directories,
making
On 08.02.2004 01:34:16 Glen Mazza wrote:
--- J.Pietschmann [EMAIL PROTECTED] wrote:
- avalon and logging for the base library.
The avalon jar is indeed quite small (only 25K or so),
but this dependency I'd like us to eventually get rid
of in favor of what Xalan does with its messaging
Clay Leeds wrote:
As for 1.0 (forgive my playing the devil's
advocate here), why stop at 1.4? Assuming Java 1.5 will be released by
the time FOP 1.0 will be released, why not base it on the latest and
greatest? Would that offer any benefits? What problems might that lead to?
Well, 1.4 is out
The Preferences API is exactly that: for preferences. IMO this is best
for client application (GUIs) that need to save and reload preferences
for the application. That's the reason for the distinction between
system root and user root [1]. This is cool for our preview application
and the FOP
...and I should probably help since I was the main pusher here.
BTW, I've started a little something for testing the SVG transcoder
using GhostScript as converter to bitmaps. I've created little Avalon
components that can nicely be configured by XML. I hope I can soon
upload that for you to see.
It has multiple pluggable datasources (Property files, XML, JNDI)
See http://jakarta.apache.org/commons/configuration/
On 09.02.2004 01:06:08 J.Pietschmann wrote:
There's also jakarta commons configuration, which uses property
files (IIRC, may well be wrong).
Jeremias Maerki
No, the question is: How long will it take for the 1.5 platform to
establish itself? 1.4 took quite a long time, less than 1.3 but still...
You will have 1.5 on Windows, Solaris and Linux immediately but all the
other platforms are not so quick, even MacOSX which was promoted as the
best Java
+1
--- Chris Bowditch [EMAIL PROTECTED] wrote:
You would make FOP unavailable to 70% of the user
base. Take a look at
Sun's Xmlroff, it has a feature set comparable to
the maintainance
branch, its free, but FOP has a much bigger user
base. Why? because
xmlroff doesnt run on windows,
Peter B. West wrote:
If we go to 1.4, should we also use 1.4 logging (java.util.logging) and
possibly also the preferences API (java.util.prefs) for
configuration/user agent/user prefs?
I don't know Avalon, so I don't know what other facilities from there we
are using or considering
-Original Message-
From: Peter B. West [mailto:[EMAIL PROTECTED]
snip /
If we go to 1.4, should we also use 1.4 logging (java.util.logging) and
possibly also the preferences API (java.util.prefs) for
configuration/user agent/user prefs?
I like this latter proposal (using
Peter B. West wrote:
I don't know Avalon, so I don't know what other facilities from there we
are using or considering using.
Avalon is a great way to decompose a large system into components.
The real advantage is that there can be different implementations
managing the components.
For example,
-Original Message-
From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
... The settings themselves are stored in a
system location where they are not meant to be found and edited by hand...
(On Windows the more straightforward way to modify the prefs
outside of the application is
Andreas L. Delmelle wrote:
Apache projects... Perhaps someone at Jakarta already has an idea for a
common Preferences library? (AFAICT not)
It's common enough that everybody invents its own solution, as
expected.
Avalon provides for XML configuration files, there are classes
mapping XML structures
-Original Message-
From: J.Pietschmann [mailto:[EMAIL PROTECTED]
snip /
There's also jakarta commons configuration, which uses property
files (IIRC, may well be wrong).
Not wrong necessarily, I think. Just maybe a bit outdated to some. The
Properties API is treated in many docs as a
--- J.Pietschmann [EMAIL PROTECTED] wrote:
- avalon and logging for the base library.
The avalon jar is indeed quite small (only 25K or so),
but this dependency I'd like us to eventually get rid
of in favor of what Xalan does with its messaging and
i18n instead. (I suspect AH or RX don't
J.Pietschmann wrote:
...
- avalon and logging for the base library.
...
BTW
1. I'd like to get rid of the servlet.jar in our CVS.
2. If we standardize on JDK 1.4 as base (as it currently
is), we could drop the Xerces, Xalan and xml-api jars as
well. Our Jars seem to be somewhat outdated anyway.
Peter B. West wrote:
J.Pietschmann wrote:
...
- avalon and logging for the base library.
...
BTW
1. I'd like to get rid of the servlet.jar in our CVS.
2. If we standardize on JDK 1.4 as base (as it currently
is), we could drop the Xerces, Xalan and xml-api jars as
well. Our Jars seem to be
On 13.08.2002 23:15:39 J.Pietschmann wrote:
Jeremias Maerki [EMAIL PROTECTED] wrote:
The FO objects are primarily just data holder, so it doesn't make
sense to make them too heavy-weight. They need to be as light-weighted
as possible to save memory. Most of the logic is transferred to
J.Pietschmann wrote:
- If the FO objects are primarily data holders, why
have them at all, instead of using a standard DOM?
I believe standard DOM implementations are obviously too synchronized to
provide thread-safe access, while fo tree is built sequentially and is
read-only after its
Again, what else obvious components do we use? I'd like
to add stuff like PDF encryption, but I don't know enough
about this to decide how tight this has to be integrated
into the PDF renderer.
I've been having a look at encryption and components could be used
though to supply say no vs 40
23 matches
Mail list logo
