+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 wind
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 plat
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
...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.
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 utili
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 sin
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 it
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:
> There ought to be a less messy approach. It could be an idea
> to move the various packages to different base directories,
> making FOP
> -Original Message-
> From: Clay Leeds [mailto:[EMAIL PROTECTED]
>
> 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
Clay Leeds wrote:
On Feb 8, 2004, at 3:37 AM, J.Pietschmann wrote:
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 FOP 1.
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
> -Original Message-
> From: J.Pietschmann [mailto:[EMAIL PROTECTED]
> 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 sort
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: 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
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, w
> -Original Message-
> From: Peter B. West [mailto:[EMAIL PROTECTED]
>
> 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 preference
> 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 c
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 some
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.
--- "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:
> - 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 b
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 transfe
On Tue, 2002-08-13 at 23:15, J.Pietschmann wrote:
> Well, I'm not a real Avalon guru (and actually not the
> greatest of the Avalon fans, after several dozen hours
> of stepping through Excalibur stuff in a Cocoon
> application). Therefore I need some explanations (read past
> the questions first)
> 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 4
24 matches
Mail list logo
