On 15 Sep 2004, at 21:05, Paul Libbrecht wrote:
Quickly on these first:
However, the "instance-based set of converters" doesn't help us here.
Because even in an instance of BeanUtils, you can't attach a
converter to a specific property by name. Only to all ints using that
instance.
For example
Quickly on these first:
Le 15 sept. 04, à 07:07, Hans Gilde a écrit :
If you're saying that all we have to do is write a class that
implements the BeanUtils interface Converter, where the Converter uses
JEXL to do the conversion, then I'm right there with you. This would
allow us to mix and matc
inal Message-
From: Paul Libbrecht [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 14, 2004 3:44 AM
To: Jakarta Commons Developers List
Subject: Re: Jelly and a new beta release
So that means that it would be easy, with this instance-based set of
converters, to write a converter:
- attached
So that means that it would be easy, with this instance-based set of
converters, to write a converter:
- attached to a mapping type (attribute-value to class xxx)
- attached to a named attribute
(note, attribute values are not always strings!
they're jexl results)
For example, the FontTag could a
do you really need to ask? :)
+1
- Brett
Quoting Dion Gillard <[EMAIL PROTECTED]>:
> Ok,
>
> all known issues for beta-4 have been completed.
>
> I'd like to do a beta release in the next day or so. Please vote on
> the beta release:
>
> [ ] +1 - Yes release
> [ ] +0 - Release, I have minor
Ok,
all known issues for beta-4 have been completed.
I'd like to do a beta release in the next day or so. Please vote on
the beta release:
[ ] +1 - Yes release
[ ] +0 - Release, I have minor issues which can wait
[ ] -1 - No, don't release! Here's why
On Tue, 31 Aug 2004 14:46:24 +1000
I'll wait a few more days for feedback from this email, and unless
there's a blocker in jira, the plan is to release beta-4 early next
week, and then start work on RC1, with the focus on bug fixes for core
only.
Once core goes into RC1, the plan is to do the same for all taglibs as
well, so that t
The CDATA test case fails on dom4j 1.5-rc1 because the CDATA test is
escaped and we explicitly ask for it not to be.
This is a bug, and I'm happy delaying the use of dom4j, or working
with them to fix the bug for 1.5.
On Tue, 31 Aug 2004 12:28:53 +0300, Paul Libbrecht <[EMAIL PROTECTED]> wrote:
>
How important is it ?
I think the current behaviour is just of "swallowing" CDATA sections
which isn't an XML offense...
How about delaying this for a further version where lexical data is
kind of working ?
paul
Le 31 août 04, à 09:34, Dion Gillard a écrit :
I remember I couldn't entirely switch
I'm a strong +1 on this.
Should we start working towards a release candidate next? What sort of new
features/major issues are there outstanding?
- Brett
Quoting Dion Gillard <[EMAIL PROTECTED]>:
> >From JIRA there is one issue remaining for beta 4 :
>
> http://issues.apache.org/jira/browse/JE
>From JIRA there is one issue remaining for beta 4 :
http://issues.apache.org/jira/browse/JELLY-47
which seems to be a dom4j related issue.
I'd like to do a new release of Jelly ASAP and start planning the next beta.
If anyone has bugs they'd like fixed for the beta or *urgent* new
functionali
11 matches
Mail list logo