Fair comment; I've created a seperate JIRA entry JELLY-286 so that this
conversation is kept seperate from the issues themselves and because it gets
virtually impossible to seperate subsequent patches.
I've started going through the JIRA issues from the top and have done 17 so
far; the patch in JELLY-286 fixes 5 bugs, and AFAICT many of the other 12
issues can be recategorised. Here's my list:
230 "Problem with default namespace in imported scripts" - NOTABUG
187 "Wrong composite expression evaluation" - FIXED
180 "ClassLoader Problems with XMLParser and XMLParser reuse" - DUPLICATE 44
184 "Using namespace-prefixes breaks Jelly" - FIXED
170 "Nested scripts should be compiled and cached" - IMPRACTICAL
193 & 167 "add 'public JellyContext newEmptyJellyContext()' to
JellyContext" - Pending patch being applied
165 "CatchTag closest from java tryCatch block (with expected exceptions
list)" - FIXED
163 "Allow Expressions to throw exceptions" - FIXED
144 "XMLParser should not depend on JellyContext" - POSTPONED (requires more
consideration and anyway would mandate API changes)
143 "Support for pluggable expression languages" - POSTPONED
121 "Policy for output of lexical XML data" - POSTPONED
188 "Core should have a forTokens tag" - POSTPONED (what conclusion from
comments in JIRA?)
112 "Create Script from SAX events" - NOTABUG
44 "[jelly] ClassLoader Problems with XMLParser and XMLParser reuse" -
POSTPONED
82 "Add UseVector tag" - POSTPONED (no response from submitter)
13 "Jelly should throw an exception if an unknown tag is used in a
TagLibrary" - FIXED
Regards,
John
----- Original Message -----
From: "sebb" <[EMAIL PROTECTED]>
To: "Commons Developers List" <dev@commons.apache.org>
Sent: Tuesday, November 11, 2008 11:48 AM
Subject: Re: [jelly] Is jelly still in development vs. Open/FederatedCommons
On 11/11/2008, John Spackman <[EMAIL PROTECTED]> wrote:
Hi Paul,
Great :)
I'm working on some addition patches for JELLY-184 and a few others; they
don't always make a lot of sense added to a single JIRA entry though, IE
patch for one bug affecting the patch script for another - is it OK to
just
email an update here instead?
Please do not send patches to the mailing list, unless they are *very*
small.
It's much more difficult to keep track of them, and to reference them
in SVN logs.
Also, JIRA has a checkbox to say that you grant ASF the rights to use the
patch.
If there are several JIRA issues, but one patch, then I suggest adding
the patch to one issue, and list which other issues it fixes. The
issues can also be linked together.
John
----- Original Message ----- From: "Paul Libbrecht" <[EMAIL PROTECTED]>
To: "Commons Developers List" <dev@commons.apache.org>
Sent: Tuesday, November 11, 2008 9:19 AM
Subject: Re: [jelly] Is jelly still in development vs.
Open/FederatedCommons
We're converging John here,
I'll try to keep up with patches and commits in order for you to
become a committer.
Henri, can you please agree that we "try to make jelly enter a
maintained mode", within a month or so, before we show "not actively
maintained" on the web-page?
thanks in advance
paul
Le 11-nov.-08 à 06:28, John Spackman a écrit :
> Hi Paul,
>
> I agree that this is _not_ something where a technical solution is
_needed_ to go forward, I'm simply trying to keep the options open so
that
Jelly does not disappear (IMHO marking a project as "Not Actively
Maintained" is the beginning of the end).
>
> IMHO keeping Jelly in Commons Proper is the best choice for Jelly,
> while
the 2nd choice is to keep it alive elsewhere as a federated Commons is a
close second, the 3rd choice as a last resort is to create a fork. And I
also agree that you need to be able to see who you're supporting, hence
the
reason for a patch submission to JIRA yesterday (with a follow-up in
response to your comments today).
>
> John
>
> ----- Original Message ----- From: "Paul Libbrecht" <[EMAIL PROTECTED]
> >
> To: "Commons Developers List" <dev@commons.apache.org>
> Sent: Monday, November 10, 2008 11:16 AM
> Subject: Re: [jelly] Is jelly still in development vs. Open/
FederatedCommons
>
>
> John,
>
> Le 10-nov.-08 à 07:11, John Spackman a écrit :
>
> > Yes, kind of - I've only recently come across Git and the concept of
DVCS but it was my intention to look at using a DVCS for this.
> > But DVCS "only" does source code - setting up a seperate branch only
works if the community at large see the new branch, whereas the Commons
group are considering marking Jelly as "No Longer Maintained" and moving
the repository out of the main branch.
> >
>
> Hey no!
> It's lacking maintainer and we shall be more than happy to make you a
> committer having been able to measure the quality of contributions!
>
> The problem is not the technical approach of DVCS, the problem is only
> endorsement: it seems rather normal that a person that hasn't been
> seen is first a bit observed or?
>
> Setting up a separate fork for a while to achieve this sounds an
> avenue to me.
> Suggesting patches on jira or any other method or paced-down
> contribution should be supported.
> I'm happy to receive your source tree from time to time, in full,
> inspect it and commit it as is for example.
>
>
> > From my point of view, I would only want to perform a public branch
with the endorsment of the Commons team; IMHO it's important for new and
existing users to see a future for the project, and for there to be a
link
from the official Commons website to the federated Jelly site. The
original downloads would remain for backward compatability, but the
Commons site would clearly refer users onto the new site for upgrades
and
future development.
> >
>
> I don't see any reason why commons would say "things are happening
> elsewhere" while it could happen here real soon now. The issue is
> endorsement and not distribution.
>
> paul
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
[EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
