releasing as RC, I am +1 on this, but after-all, that's only my
silent vote :-)
Regards
Diogo
Hi list,
As recently and quickly discussed on irc with Dion, I was wondering if
there would be any possible plans for releasing jelly and
jelly-tags-xml. I'm writing as one of th
Hi Paul,
On 20/01/06, Paul Libbrecht <[EMAIL PROTECTED]> wrote:
> There's at least a major issue to be solved before a release of jelly
> and jelly-xml: Gump testing, including the usage of the latest jexl as
> well as hope for a release of jaxen.
>
> The problems is that
There's at least a major issue to be solved before a release of jelly
and jelly-xml: Gump testing, including the usage of the latest jexl as
well as hope for a release of jaxen.
The problems is that many unit-tests currently fail because jexl now
handles correctly primitive types but the
://issues.apache.org/jira/browse/JELLY-213
Regarding releasing as RC, I am +1 on this, but after-all, that's only my
silent vote :-)
Regards
Diogo
> Hi list,
>
> As recently and quickly discussed on irc with Dion, I was wondering if
> there would be any possible plans for releasing jelly and
--- Grégory Joseph <[EMAIL PROTECTED]> wrote:
> Of course we'd be very keen on testing any RC, and
> our test codebase
> might help in that respect.
>
> Does this sound feasible / would anyone be
> interested in pushing this out ?
As we are used to live off their snapshots, we will
get no
mor
Hi list,
As recently and quickly discussed on irc with Dion, I was wondering if
there would be any possible plans for releasing jelly and
jelly-tags-xml. I'm writing as one of the xdoclet2 developers: we
currently depend on post-1.0 snapshots of both of -core and -tags-xml,
and, as you
Paul Libbrecht wrote:
Le 2 nov. 04, à 21:04, Brett Porter a écrit :
are you sure it isn't jellydoc?
Yes.
Ok, I'll try it and find out why.
this was "corrected" in maven by adding:
maven.jar.javadoc=${java.home}/lib/tools.jar
But this is not done in maven-1.0, is that correct ?
No. It existed in
Wednesday, November 03, 2004 12:48 PM
Subject: Re: [VOTE] Jelly and a release
Le 2 nov. 04, à 21:04, Brett Porter a écrit :
> are you sure it isn't jellydoc?
Yes.
> this was "corrected" in maven by adding:
> maven.jar.javadoc=${java.home}/lib/tools.jar
But this is no
Le 2 nov. 04, à 21:04, Brett Porter a écrit :
are you sure it isn't jellydoc?
Yes.
this was "corrected" in maven by adding:
maven.jar.javadoc=${java.home}/lib/tools.jar
But this is not done in maven-1.0, is that correct ?
Then it's a known bug and someone should succeed without this
javadoc-1.3.
it was pulled from the repository for licensing reasons.
are you sure it isn't jellydoc?
this was "corrected" in maven by adding:
maven.jar.javadoc=${java.home}/lib/tools.jar
- Brett
Paul Libbrecht wrote:
Le 1 nov. 04, à 07:01, Dion Gillard a écrit :
i'm having some problems running site:generate (
Le 1 nov. 04, à 07:01, Dion Gillard a écrit :
i'm having some problems running site:generate (from the jelly build).
1. does anyone know if this is working at the moment?
2. some of these problems also seem to occur when running the
site:generate from within the tag libraries. is this a issue that
'site' definitely works.
I don't usually just do site:generate.
I am currently off air and oversaes, and will definitely be able to
check in a couple of days...
On Sun, 31 Oct 2004 21:38:55 +, robert burrell donkin
<[EMAIL PROTECTED]> wrote:
> On 29 Oct 2004, at 20:00, Dion Gillard wrote:
>
On 29 Oct 2004, at 20:00, Dion Gillard wrote:
On Fri, 29 Oct 2004 18:17:34 +0100, robert burrell donkin
<[EMAIL PROTECTED]> wrote:
this isn't really a release stopper but it's been bothering me for a
while and so this seems like a good excuse to try to resolve it...
the sub-sites for the tag librar
On Fri, 29 Oct 2004 18:17:34 +0100, robert burrell donkin
<[EMAIL PROTECTED]> wrote:
> this isn't really a release stopper but it's been bothering me for a
> while and so this seems like a good excuse to try to resolve it...
>
> the sub-sites for the tag libraries don't seem to inherit any common
this isn't really a release stopper but it's been bothering me for a
while and so this seems like a good excuse to try to resolve it...
the sub-sites for the tag libraries don't seem to inherit any common
navigation elements from either the main commons site or from the jelly
site. i think that
Le 28 oct. 04, à 19:24, Dion Gillard a écrit :
[X] +1. Release 1.0-RC1.
[ ] +0. Sounds good but I can't help
[ ] -0. I don't agree, but don't want to hold the release.
[ ] -1. Please don't. Here's why:
-
To unsubscribe, e-mai
On Oct 28, 2004, at 1:24 PM, Dion Gillard wrote:
We've covered most of the issues in Jira for Jelly to make a 1.0
release.
I'd like to go ahead and make the current code a release candidate,
1.0-RC1.
If anyone has changes or bugs that need to be addressed in 1.0,
*please* raise them now, so tha
I just ran the tests and it looks like you forgot to commit outputData.jelly.
On Fri, 29 Oct 2004 00:30:46 +0200, Paul Libbrecht <[EMAIL PROTECTED]> wrote:
> As, in my head, this was mostly be overridden by "receiving"
> subclasses, I didn't really care.
>
> I have done as you suggest, though, an
As, in my head, this was mostly be overridden by "receiving"
subclasses, I didn't really care.
I have done as you suggest, though, and, indeed, it makes the MuteTag
better: this one can now avoid the toString of such things as the
result of a Jexl expression, some speed improvement I think.
Als
I thought we were going to make the default behaviour of that method
to write the object.toString() to the output?
On Thu, 28 Oct 2004 22:13:25 +0200, Paul Libbrecht <[EMAIL PROTECTED]> wrote:
> Done that, thanks for the precision. I was unclear from the last mails.
> I feared for a while at the
Hmmm...
I setup the checkstyle config in two sections: Errors are things we
really don't want, and warnings are less of an issue and things we
could discuss and change.
I haven't looked at the report for a while.
Hopefully it's not a barrier to release.
On Thu, 28 Oct 2004 22:13:25 +0200, Paul
Done that, thanks for the precision. I was unclear from the last mails.
I feared for a while at the amount of checkstyle complaints... did
anyone pay attention to them ? It seems quite of an annoying task!
Maybe it would be simper to relax the requirements ?
paul
Le 28 oct. 04, à 21:23, Dion Gil
Hi Paul,
I think we agreed it would be a good addition, and that the name
should be objectData.
Is that right? If so, go for it.
On Thu, 28 Oct 2004 20:38:52 +0200, Paul Libbrecht <[EMAIL PROTECTED]> wrote:
> My little addition XMLOutput.objectData() has received little feedback
> but I'd like
My little addition XMLOutput.objectData() has received little feedback
but I'd like it to get into 1.0. If no-one objects, I'd put it in...
just... I'd like enough feedback.
paul
Le 28 oct. 04, à 19:24, Dion Gillard a écrit :
We've covered most of the issues in Jira for Jelly to make a 1.0
rele
We've covered most of the issues in Jira for Jelly to make a 1.0 release.
I'd like to go ahead and make the current code a release candidate, 1.0-RC1.
If anyone has changes or bugs that need to be addressed in 1.0,
*please* raise them now, so that we can decide to either include them
or wait.
So
On Sep 19, 2004, at 8:33 PM, Hans Gilde wrote:
Yeah, no problem. No huge memory leak for 1.0. :)
yes please! :)
+1
-pete
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I'm Ok with that.
paul
Le 21 sept. 04, à 02:46, Dion Gillard a écrit :
My take is:
* 1.0 should be as close as API compatible with the beta releases
since the betas were so long lived.
* 1.1 should be functional updates to 1.0 but no API change.
* 2.0 should clean the API.
How does this sound?
---
+1
I don't really see any other good way.
-Original Message-
From: Dion Gillard [mailto:[EMAIL PROTECTED]
Sent: Monday, September 20, 2004 7:47 PM
To: Jakarta Commons Developers List
Subject: Re: Jelly and a 1.0 release
My take is:
* 1.0 should be as close as API compatible wit
o:[EMAIL PROTECTED]
> Sent: Monday, September 20, 2004 7:16 PM
> To: 'Jakarta Commons Developers List'; 'Dion Gillard'
> Subject: RE: Jelly and a 1.0 release
>
> I do allot of extending of Jelly and Embedded is good for embedding the part
> about running a s
0, 2004 7:16 PM
To: 'Jakarta Commons Developers List'; 'Dion Gillard'
Subject: RE: Jelly and a 1.0 release
I do allot of extending of Jelly and Embedded is good for embedding the part
about running a script.
I'm more afraid that the public API changes will break existing
I do allot of extending of Jelly and Embedded is good for embedding the part
about running a script.
I'm more afraid that the public API changes will break existing TagLibs.
It's a matter of releasing 1.0 and breaking existing TagLibs vs. risking
people developing lots more TagLibs tha
That's a good point... except that's nowhere in the docs except in the
javadoc.
Maybe add a paragraph in the page "Details" (which sadly carries an
"overview" section title) ?
paul
Le 20 sept. 04, à 13:42, Dion Gillard a écrit :
I thought that was what Embedded was for. Simple embedding of jelly
I thought that was what Embedded was for. Simple embedding of jelly...
On Mon, 20 Sep 2004 13:32:04 +0200, Paul Libbrecht <[EMAIL PROTECTED]> wrote:
> Trouble with this is that developers may start binding into, possibly
> wrong, entry-points to embed jelly that may go away in 1.1.
> Maybe a much
Trouble with this is that developers may start binding into, possibly
wrong, entry-points to embed jelly that may go away in 1.1.
Maybe a much more moderate proposal than jelly-api.jar, e.g., one or
two classes that encompass most common usages and are recommended
officially would do the trick a
Yeah, no problem. No huge memory leak for 1.0. :)
-Original Message-
From: Dion Gillard [mailto:[EMAIL PROTECTED]
Sent: Sunday, September 19, 2004 6:58 PM
To: Hans Gilde
Subject: Re: Jelly and a 1.0 release
That sounds like a good idea.
I've also been following your work on the m
: Dion Gillard [mailto:[EMAIL PROTECTED]
Sent: Friday, September 17, 2004 1:02 AM
To: Jakarta Commons Developers List; Jakarta Commons Users List
Subject: Jelly and a 1.0 release
There's currently one issue in Jira for Jelly Core against v1.0, which
is the public API.
If there is anything p
Nothing from me. I'd say do the public API and push out RC1.
Nice work.
Cheers,
Brett
Quoting Dion Gillard <[EMAIL PROTECTED]>:
> There's currently one issue in Jira for Jelly Core against v1.0, which
> is the public API.
>
> If there is anything people want fixed for 1.0, please enter it into
There's currently one issue in Jira for Jelly Core against v1.0, which
is the public API.
If there is anything people want fixed for 1.0, please enter it into JIRA ASAP.
Please note that the taglibs are now able to be released separately
from Jelly Core, so fixing those is a separate thing to get
But don't let any of this worry you. If we come up with a good way of
declaring converters, it will be no problem to implement it. Just as
long aswe separate the discussions of "whether to use BeanUtils in
core Jelly" and "how to implement per-bean-property, declared
converte
JComponent
setGraphicsDebugOptions(int) method. Unfortunately, this broke all
other int-based bean properties.
But don't let any of this worry you. If we come up with a good way of
declaring converters, it will be no problem to implement it. Just as
long aswe separate the discussions of "
you. If we come up with a good way of
declaring converters, it will be no problem to implement it. Just as long as
we separate the discussions of "whether to use BeanUtils in core Jelly" and
"how to implement per-bean-property, declared converters".
A basic proposal for conve
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
Hello,
When I am trying to process the following Jelly script I've got the error:
[java] org.apache.commons.jelly.JellyTagException:
file:/C:/Work/SDS/templates/sample1.xhtml:31:105: The node "[EMAIL
PROTECTED] [Element: ]" could not be added to the branch "null"
because: Cannot add another el
It looks like v1.32 of BeanUtils caused the problem.
Here's the (massive) setProperty method code I think (but haven't tested)
causes the issue:
} else if (ConvertUtils.lookup(value.getClass()) != null) {
newValue = ConvertUtils.convert(value.toString(), type);
I originally implemented the tag with a fallsThru parameter, so
that the following:
would evaluate the both the block marked and the block marked
, but not .
For better or worse (I'm starting to think worse) I let "false" be the
default for fallsThru, thinking that's
s).
James
---
http://radio.weblogs.com/0112098/
- Original Message -
From: "Jason Horman" <[EMAIL PROTECTED]>
To: "'Jakarta Commons Developers List'" <[EMAIL PROTECTED]>
Sent: Tuesday, October 01, 2002 7:51 PM
Subject: RE: [jelly] RE: Jelly and properties
JELLY_PROPERTIES
-jason
-Original Message-
From: Jim Birchfield [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 01, 2002 11:40 AM
To: Jakarta Commons Developers List
Subject: RE: [jelly] RE: Jelly and properties
This fix is actually submitted and hopefully to be committed soon. No need
to
)
-Original Message-
From: Jason Horman [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 01, 2002 2:32 PM
To: 'Jakarta Commons Developers List'
Subject: [jelly] RE: Jelly and properties
How about as a temporary fix you just have jelly(.sh) source ~/.jelly if it
exists. This would avoid
I would like to see Jelly look for a jelly.properties file on the classpath
and load the properties to be available for Jelly to use in the script.
James, have you had any thoughts around this issue? It is easy to set the
properties when using Maven, but as I am starting to use Jelly as a
scripti
56 matches
Mail list logo
