Re: [jelly] Is jelly still in development vs. Open/FederatedCommons
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
Re: [jelly] Is jelly still in development vs. Open/FederatedCommons
On Mon, 2008-11-10 at 17:27 -0500, Rahul Akolkar wrote: On Mon, Nov 10, 2008 at 3:22 AM, Russel Winder [EMAIL PROTECTED] wrote: big-snip/ I think the bulk of this message would have been better off in a new thread, marked [OT]. Possibly but I didn't think of it. On other lists that would have been seen as inappropriate. So many lists, so many different protocols :-) Some of these discussions have been happening at the ASF, on a more appropriate list whose public archives are here: http://mail-archives.apache.org/mod_mbox/www-infrastructure-dev/ OK, it seems like Apache have already made the decision to go with Git, it appears to be the only DVCS mentioned in the posts. [ . . . ] -- Russel. Dr Russel Winder Partner Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203 41 Buckmaster Road, f: +44 8700 516 084 London SW11 1EN, UK. m: +44 7770 465 077 signature.asc Description: This is a digitally signed message part
Re: [jelly] Is jelly still in development vs. Open/FederatedCommons
John, On Tue, 2008-11-11 at 05:28 +, John Spackman wrote: [ . . . ] I think you're talking about a different problem - Jelly is used for far more than Ant/Maven replacement (I don't usually use either) and maintaining it is not an altruistic choice for me, but a practical one because I find it so very useful. Well that implies continued existence which implies Apache should not retire it but allow those people who are prepared to maintain it some mechanism to maintain and release. But then I am pretty much an outsider here. -- Russel. Dr Russel Winder Partner Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203 41 Buckmaster Road, f: +44 8700 516 084 London SW11 1EN, UK. m: +44 7770 465 077 signature.asc Description: This is a digitally signed message part
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] smime.p7s Description: S/MIME cryptographic signature
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]
Re: [jelly] Is jelly still in development vs. Open/FederatedCommons
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? 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]
Re: [jelly] Is jelly still in development vs. Open/FederatedCommons
On Tue, Nov 11, 2008 at 4:19 AM, Paul Libbrecht [EMAIL PROTECTED] wrote: 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? snip/ I think that'd be quite appropriate, if you wanted to. -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] Is jelly still in development vs. Open/FederatedCommons
John, On Mon, 2008-11-10 at 06:11 +, John Spackman wrote: [ . . . ] Isn't this whole Subversion centralism problem solved by using a DVCS such as Bazaar, or Git -- and soon, I gather, Mercurial. 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. Bazaar is probably easier for Subversion users to get used to as the command set is more aligned with that of Subversion. (The same goes for Mercurial, but it's Subversion interworking is not yet usable for production working as far as I know.) 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. I tend to use Launchpad as a place to store Bazaar branches where the host of the Subversion repository cannot support Bazaar. GitHub seems to be the place to store a Git repository in a similar circumstance. A word of warning: Using Bazaar or Git as a Subversion client is not the same as using them as fully-fledged DVCS. The need to rebase so as to remain consistent with the Subversion repository means that many of the aspects of workflow of using DVCS have to be amended. A Bazaar branch of a Subversion repository or a Git clone of a Subversion repository must always be treated as a view on the Subversion repository and not used as a free standing branch/repository. light-marketing If anyone is in Oxford, UK 2009-04 then you might think about attending the ACCU 2009 conference. Jim Hague, Time Penhey and myself are doing a session on DVCS. /light-marketing 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 guess I am in the XML is a data specification language and has no right having a computational model, that's what dynamic languages like Groovy, Python and Ruby are for. camp, so I don't see the demise of Jelly as a problem. Of course graceful demise is entirely appropriate. The question I have is whether putting effort into maintaining a demising system is worth it compared to putting that effort into transferring to a different (more appropriate, in my view) technology for dealing with the problem. There are some very nice candidates for Ant and Maven replacements out there: Gant, Gradle and Buildr to name the obvious trio. (Disclosure: I work on Gant and Gradle :-) These provides for scripting rather than having to create a plugin. -- Russel. Dr Russel Winder Partner Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203 41 Buckmaster Road, f: +44 8700 516 084 London SW11 1EN, UK. m: +44 7770 465 077 signature.asc Description: This is a digitally signed message part
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 smime.p7s Description: S/MIME cryptographic signature
Re: [jelly] Is jelly still in development vs. Open/FederatedCommons
On Mon, Nov 10, 2008 at 3:22 AM, Russel Winder [EMAIL PROTECTED] wrote: big-snip/ I think the bulk of this message would have been better off in a new thread, marked [OT]. Some of these discussions have been happening at the ASF, on a more appropriate list whose public archives are here: http://mail-archives.apache.org/mod_mbox/www-infrastructure-dev/ I guess I am in the XML is a data specification language and has no right having a computational model, that's what dynamic languages like Groovy, Python and Ruby are for. camp, so I don't see the demise of Jelly as a problem. Of course graceful demise is entirely appropriate. The question I have is whether putting effort into maintaining a demising system is worth it compared to putting that effort into transferring to a different (more appropriate, in my view) technology for dealing with the problem. There are some very nice candidates for Ant and Maven replacements out there: Gant, Gradle and Buildr to name the obvious trio. (Disclosure: I work on Gant and Gradle :-) These provides for scripting rather than having to create a plugin. snap/ The fact is, any component in Commons Proper will continue to live on as long as folks contribute to it (and contributions are welcome for any part of Commons). Other options are often available, but thats besides the point if folks care to continue contributing. -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] Is jelly still in development vs. Open/FederatedCommons
Hi Russel, Of course graceful demise is entirely appropriate. The question I have is whether putting effort into maintaining a demising system is worth it compared to putting that effort into transferring to a different (more appropriate, in my view) technology for dealing with the problem. There are some very nice candidates for Ant and Maven replacements out there: I think you're talking about a different problem - Jelly is used for far more than Ant/Maven replacement (I don't usually use either) and maintaining it is not an altruistic choice for me, but a practical one because I find it so very useful. John - Original Message - From: Russel Winder [EMAIL PROTECTED] To: Commons Developers List dev@commons.apache.org Sent: Monday, November 10, 2008 8:22 AM Subject: Re: [jelly] Is jelly still in development vs. Open/FederatedCommons - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] Is jelly still in development vs. Open/FederatedCommons
Hi Russel, Forgive me for butting in on a conversation but . . . Anytime :) Isn't this whole Subversion centralism problem solved by using a DVCS such as Bazaar, or Git -- and soon, I gather, Mercurial. 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. 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. John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
