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" 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" 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" > 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 th
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? > 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
On Tue, Nov 11, 2008 at 4:05 AM, Russel Winder <[EMAIL PROTECTED]> wrote: > 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: >> >> >> 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 :-) > Understandable :-) >> 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. > There have been discussions mainly involving Git, but no such decision has been made (and IMO, neither is it imminent). -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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" > 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" > > 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/Federated Commons
Hi Henri, Using Henri's analogies from his recent blog, I took Jelly home from the Commons a couple of years ago and we're now ready to "put it in the window and see if we're invited to play" [...snip...] As below - analogy was about other Apache projects but probably applies here as you say. It's slowly dawned on me that Commons isn't a collection of independant projects under a title but a single project - that explained quite a bit about how things work :) There's also a legal bit - need to get committers to sign CLAs as they're expected to do larger pieces of work. I don't have a scanner here but I'll put that on my todo list for when I get back next week John - 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" 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" 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
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" 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
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
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: > > > 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
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" 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]
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" 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/Federated Commons
Repling inline to both Paul and John: On Sun, Nov 9, 2008 at 2:26 PM, Paul Libbrecht <[EMAIL PROTECTED]> wrote: > > Le 09-nov.-08 à 05:35, John Spackman a écrit : >> Using Henri's analogies from his recent blog, I took Jelly home from the >> Commons a couple of years ago and we're now ready to "put it in the window >> and see if we're invited to play". If we're invited to play then great - >> any changes we make will be contributed back (and documentation will come >> with those changes) - but my "home life" is a small business that keeps me >> very busy and my focus here is on gradually contributing fixes/improvements >> and documentation rather than taking Jelly a great leap forward as an O/S >> product. As below - analogy was about other Apache projects but probably applies here as you say. Don't worry about great leap forwards btw - scratch your itch to reduce maintenance pain of your fork; that's all anyone does and it adds up to value. > We can make a vote on that... or we can simply try to make it cleaner and > start applying code patches. I don't think retirement was what Henri > suggested. Paul: Well... definitely a strong line towards retirement. :) Informing users that it's an inactive project. >> Please don't get me wrong - I am very grateful for your offer to apply >> patches etc sent via JIRA but I am cautious as I think of the potential >> extra work that would entail and how much simpler it would be if I could >> just issue an SVN commit. > > I fully understand but Apache foundations' practice has really always been > such. There are a few bits at play here. There's a cultural pressure in that we don't want to give committer rights to people until they show commitment as we're indicating to the rest of Apache's communities that this person has shown commitment somewhere. There's also a legal bit - need to get committers to sign CLAs as they're expected to do larger pieces of work. >> Returning again to Henri's blog, instead of Jelly being a first use case >> for retiring a commons project, how about it being a first use case for a >> "Federated Commons" subproject? Blog wise that was targetted more at the Commons like components inside other Apache projects, than moving an item out of Commons. >> I appreciate the point that making commits >> open to anybody has it's problems and is not something the team want to do >> right now, but given that the list is contemplating retiring Jelly this >> could be an ideal opportunity to experiment with something where the team >> has little to lose. >> The original SVN archive would remain intact at Apache, >> and I'd take a copy of it for my 1.x trunk so that I could create branches >> (possibly using Git); any projects already using Jelly 1.0 would be >> completely unaffected, but new users and users wishing to update would be >> referred to the new Federated Jelly website & repository. There's a separate concept called Apache Attic that this fits into. Basically Apache will retire something and if people want it to continue life there are various ways back, including the one above of a fork being created elsewhere and linked to from Apache as a known fork that people are recommended to go get involved in. Though the plan isn't to do it for Commons components per se - as usual Commons doesn't quite fit the model :) Reminds me that I need to send in the board resolution/proposal for that ... I've been in a maintenance process mood recently it seems :/ Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] Is jelly still in development
Hi all, Just for the record, I have used Jelly in a commercial project as well, in the installer of an application that supported multiple databases (like Oracle and MySql) - we developed the database installation/update script in Jelly. So, regardless of the discussion of wheter Jelly is appropriate or not, I think it has its merit and have been used out there more than we (ASF guys) suspect. That being said, it would be great if could bring the project back to life. I might even be able to help by applying a patch or two (I'm a Jakarta committer), but can't commit (no pun intended :-) to do much more than that. -- Felipe On Sat, Nov 8, 2008 at 1:20 AM, John Spackman <[EMAIL PROTECTED]> wrote: > We're still actively using Jelly and while the usefulness of some of the > extension modules may be debatable (and definitely without wishing to enter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] Is jelly still in development vs. Open/FederatedCommons
On Mon, Nov 10, 2008 at 3:22 AM, Russel Winder <[EMAIL PROTECTED]> wrote: 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. 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
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
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. 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. > 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
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]
Re: [jelly] Is jelly still in development vs. Open/Federated Commons
Hi Paul, I wasn't talking about *writing the documentation* but cleanly linking to it. Ah, ISWYM! In that case I completely agree :) I am prepared to upgrade Jelly to Maven2 (not that I know much about what that involves, yet) I would rather disadvise that especially for the huge effort of maven 1 scripting that was put in jelly building. Oh OK - this really underlines my lack of familiarity with the Commons group because I was under the impression that M2 was wanted across the project. Returning again to Henri's blog, instead of Jelly being a first use case for retiring a commons project, how about it being a first use case for a "Federated Commons" subproject? [...snip...] And you would host that? Not me personally but an independent body such as SourceForge, Codehaus, etc; anything so long as it's open and easily accessible for everyone, and can have any/all Commons members immediately added as project administrators That might be a clean way to attempt maybe... and I see this fairly easy to use so as to port back changes although it might byte us from time to time. I think a self-hosted fixed web-site is, for example, a very useful thing to use! Cool! This is actually my preferred option and I hope it would give the Commons team a way to wind-down a project which is no longer key, but at the same time to keep it alive and get some bugs fixed and patches applied. Most importantly, using Git or similar would mean that there is a route back into the Commons in the future if necessary. What about identifying a handful of issues that you think you could submit one or several patches for? I'm on holiday right now so the quickest way for you to see something would be to generate a patch for a bug I've recently found and fixed with selecting the expression parser - please see JELLY-285. The patch includes inline documentation and test cases. I quickly went through the top 10 bugs in JIRA (ordered by priority) and there are 6 bug reports already with patches ready to be added; of the remaining 4, 1 was without a straightforward test case, 1 minor feature request, 1 questionable report, leaving 1 to be worked on (JELLY-184). Some of these date back to 2004. (The 11th one was one reported by you via Hans Gilde, in 2004 - JELLY-163 about handling JEXL expression exceptions) I can have a look at JELLY-184 when I get back but it's surprising to see how many bug reports are still open which had been submitted with patches; obviously this is only because the project has not been maintained for several years but it's a real shame that they haven't been incorporated. One of the first tasks I'd undertake in rejuvenating Jelly would be to integrate patches and start updating JIRA. Regards John - Original Message - From: "Paul Libbrecht" <[EMAIL PROTECTED]> To: "Commons Developers List" Sent: Sunday, November 09, 2008 8:26 PM Subject: Re: [jelly] Is jelly still in development vs. Open/Federated Commons Le 09-nov.-08 à 05:35, John Spackman a écrit : I agree that the website needs some changes although I had thought that this was largely for broken links and for a consistent left- hand side menu; updating the documentation for the taglibs is a pretty herculean task, not least because in order to document a taglib you have to fully understand it first, and that would often mean having a test environment and ideally a practical application for them. Oh boy, sure! I wasn't talking about *writing the documentation* but cleanly linking to it. There's been an attempt of making documentation a bit better with examples' link... but it hasn't been pushed enough and, I think, should mostly be retired going back to jelly doc which has a sufficient amount of content I believe. Generally, however, although not perfect I think that the current documentation is "adequate" - it certainly was enough for me to get the concepts and get going with it quickly. Right... but there are slightly misleading parts (including wrong tag- doc-links and "take maven to start") which really need fixes. Using Henri's analogies from his recent blog, I took Jelly home from the Commons a couple of years ago and we're now ready to "put it in the window and see if we're invited to play". If we're invited to play then great - any changes we make will be contributed back (and documentation will come with those changes) - but my "home life" is a small business that keeps me very busy and my focus here is on gradually contributing fixes/improvements and documentation rather than taking Jelly a great leap forward as an O/S product. I believe that this is what jelly needs... maintenance I am prepared to upgrade Jelly to Maven2 (not that I know much about what that involves, yet)
Re: [jelly] Is jelly still in development vs. Open/Federated Commons
Le 09-nov.-08 à 05:35, John Spackman a écrit : I agree that the website needs some changes although I had thought that this was largely for broken links and for a consistent left- hand side menu; updating the documentation for the taglibs is a pretty herculean task, not least because in order to document a taglib you have to fully understand it first, and that would often mean having a test environment and ideally a practical application for them. Oh boy, sure! I wasn't talking about *writing the documentation* but cleanly linking to it. There's been an attempt of making documentation a bit better with examples' link... but it hasn't been pushed enough and, I think, should mostly be retired going back to jelly doc which has a sufficient amount of content I believe. Generally, however, although not perfect I think that the current documentation is "adequate" - it certainly was enough for me to get the concepts and get going with it quickly. Right... but there are slightly misleading parts (including wrong tag- doc-links and "take maven to start") which really need fixes. Using Henri's analogies from his recent blog, I took Jelly home from the Commons a couple of years ago and we're now ready to "put it in the window and see if we're invited to play". If we're invited to play then great - any changes we make will be contributed back (and documentation will come with those changes) - but my "home life" is a small business that keeps me very busy and my focus here is on gradually contributing fixes/improvements and documentation rather than taking Jelly a great leap forward as an O/S product. I believe that this is what jelly needs... maintenance I am prepared to upgrade Jelly to Maven2 (not that I know much about what that involves, yet) I would rather disadvise that especially for the huge effort of maven 1 scripting that was put in jelly building. and to improve the website but I have to be confident that the changes will happen quickly and easily, and that the project will not be retired. We can make a vote on that... or we can simply try to make it cleaner and start applying code patches. I don't think retirement was what Henri suggested. Please don't get me wrong - I am very grateful for your offer to apply patches etc sent via JIRA but I am cautious as I think of the potential extra work that would entail and how much simpler it would be if I could just issue an SVN commit. I fully understand but Apache foundations' practice has really always been such. Returning again to Henri's blog, instead of Jelly being a first use case for retiring a commons project, how about it being a first use case for a "Federated Commons" subproject? I appreciate the point that making commits open to anybody has it's problems and is not something the team want to do right now, but given that the list is contemplating retiring Jelly this could be an ideal opportunity to experiment with something where the team has little to lose. The original SVN archive would remain intact at Apache, and I'd take a copy of it for my 1.x trunk so that I could create branches (possibly using Git); any projects already using Jelly 1.0 would be completely unaffected, but new users and users wishing to update would be referred to the new Federated Jelly website & repository. And you would host that? That might be a clean way to attempt maybe... and I see this fairly easy to use so as to port back changes although it might byte us from time to time. I think a self-hosted fixed web-site is, for example, a very useful thing to use! What about identifying a handful of issues that you think you could submit one or several patches for? paul smime.p7s Description: S/MIME cryptographic signature
Re: [jelly] Is jelly still in development vs. Open/Federated Commons
On Sun, 2008-11-09 at 04:35 +, John Spackman wrote: [ . . . ] > I am prepared to upgrade Jelly to Maven2 (not that I know much about what > that involves, yet) and to improve the website but I have to be confident > that the changes will happen quickly and easily, and that the project will > not be retired. Please don't get me wrong - I am very grateful for your > offer to apply patches etc sent via JIRA but I am cautious as I think of the > potential extra work that would entail and how much simpler it would be if I > could just issue an SVN commit. [ . . . ] Forgive me for butting in on a conversation but . . . Isn't this whole Subversion centralism problem solved by using a DVCS such as Bazaar, or Git -- and soon, I gather, Mercurial. Bazaar and Git can both be used as Subversion clients, using the bzr-svn and git-svn plugins respectively -- and I believe Mercurial will getting equivalent capability in the future. A Bazaar branch and a Git repository carry the entire history, can be rebased, can be used to create patches, and indeed you can commit to a Subversion repository direct from a branch or repository. For a couple of my projects, Codehaus is the host so the central mainline is a Subversion repository. However most work is done using Bazaar or Git since people do not need an account to be able to work using a full VCS. Using a DVCS makes working on a FOSS project truly open. -- 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/Federated Commons
Hi Paul, I agree that the website needs some changes although I had thought that this was largely for broken links and for a consistent left-hand side menu; updating the documentation for the taglibs is a pretty herculean task, not least because in order to document a taglib you have to fully understand it first, and that would often mean having a test environment and ideally a practical application for them. Generally, however, although not perfect I think that the current documentation is "adequate" - it certainly was enough for me to get the concepts and get going with it quickly. Using Henri's analogies from his recent blog, I took Jelly home from the Commons a couple of years ago and we're now ready to "put it in the window and see if we're invited to play". If we're invited to play then great - any changes we make will be contributed back (and documentation will come with those changes) - but my "home life" is a small business that keeps me very busy and my focus here is on gradually contributing fixes/improvements and documentation rather than taking Jelly a great leap forward as an O/S product. I am prepared to upgrade Jelly to Maven2 (not that I know much about what that involves, yet) and to improve the website but I have to be confident that the changes will happen quickly and easily, and that the project will not be retired. Please don't get me wrong - I am very grateful for your offer to apply patches etc sent via JIRA but I am cautious as I think of the potential extra work that would entail and how much simpler it would be if I could just issue an SVN commit. Returning again to Henri's blog, instead of Jelly being a first use case for retiring a commons project, how about it being a first use case for a "Federated Commons" subproject? I appreciate the point that making commits open to anybody has it's problems and is not something the team want to do right now, but given that the list is contemplating retiring Jelly this could be an ideal opportunity to experiment with something where the team has little to lose. The original SVN archive would remain intact at Apache, and I'd take a copy of it for my 1.x trunk so that I could create branches (possibly using Git); any projects already using Jelly 1.0 would be completely unaffected, but new users and users wishing to update would be referred to the new Federated Jelly website & repository. Regards, John - Original Message - From: "Paul Libbrecht" <[EMAIL PROTECTED]> To: "Commons Developers List" Sent: Saturday, November 08, 2008 11:27 PM Subject: Re: [jelly] Is jelly still in development Hello John, I think it would be lovely to start some maintenance and to get an extra committer aboard. The procedure to become so, however, really starts with the "other methods" (mailing-list and jira in particular). The focus on the core of jira is rather happy. I am more than happy to restrict such things as the xml taglib which has been my main usage of jelly (together with ant). As a first maintenance suggestion, ignoring a possible retirement, I would really like to get the web-pages in a more up-to-date state. (correct getting-started, tag-ref somewhat consistent, ...). How doable would it be for you to tackle such repair? I could then try to apply a patch you submit to jira. I am not sure (and hope not) that the web-site can only be fixed by the migration to maven2... paul Le 08-nov.-08 à 10:20, John Spackman a écrit : We're still actively using Jelly and while the usefulness of some of the extension modules may be debatable (and definitely without wishing to enter into a debate of whether it is appropriate to have "executable" data), as a core tool Jelly has allowed us to rapidly produce pluggable languages for defining drawings, web services, schedules, JDBC configuration, and more where the tag implementation configures POJOs. Coincidentally, we've recently reached the point where we must make changes to the code base (bug fixes and new features) and so a couple of weeks ago I emailed James asking if he was still maintaining the project and if so what is plans were and whether I'd be able to contribute. Perhaps not surprisingly I didn't receive a reply, and now it seems I might have broken protocol by asking him direct instead of asking here. My apologies if that was inappropriate. We have a number of changes to make to Jelly, and I am prepared to put myself and my company forward as a maintainer. If that's acceptable to you all, the first task would be to briefly update the website and make a maintenance release (there are some essential bug fixes in SVN that are not in the official release), followed by various other fixes and additions in a beta release. Admittedly, my focus would be th
Re: [jelly] Is jelly still in development
Hello John, I think it would be lovely to start some maintenance and to get an extra committer aboard. The procedure to become so, however, really starts with the "other methods" (mailing-list and jira in particular). The focus on the core of jira is rather happy. I am more than happy to restrict such things as the xml taglib which has been my main usage of jelly (together with ant). As a first maintenance suggestion, ignoring a possible retirement, I would really like to get the web-pages in a more up-to-date state. (correct getting-started, tag-ref somewhat consistent, ...). How doable would it be for you to tackle such repair? I could then try to apply a patch you submit to jira. I am not sure (and hope not) that the web-site can only be fixed by the migration to maven2... paul Le 08-nov.-08 à 10:20, John Spackman a écrit : We're still actively using Jelly and while the usefulness of some of the extension modules may be debatable (and definitely without wishing to enter into a debate of whether it is appropriate to have "executable" data), as a core tool Jelly has allowed us to rapidly produce pluggable languages for defining drawings, web services, schedules, JDBC configuration, and more where the tag implementation configures POJOs. Coincidentally, we've recently reached the point where we must make changes to the code base (bug fixes and new features) and so a couple of weeks ago I emailed James asking if he was still maintaining the project and if so what is plans were and whether I'd be able to contribute. Perhaps not surprisingly I didn't receive a reply, and now it seems I might have broken protocol by asking him direct instead of asking here. My apologies if that was inappropriate. We have a number of changes to make to Jelly, and I am prepared to put myself and my company forward as a maintainer. If that's acceptable to you all, the first task would be to briefly update the website and make a maintenance release (there are some essential bug fixes in SVN that are not in the official release), followed by various other fixes and additions in a beta release. Admittedly, my focus would be the core of Jelly and the core tags - I do not use the additional tag libraries and would find it difficult to provide a significant amount of regression testing and support for them but I'll keep them going where possible and try to help out any users with problems. Is this something you would be interested in? If the conclusion by the list is that Jelly should still be retired then as an alternative would it be possible for me to fork the Jelly project out of commons and into (for example) SourceForge? In case it makes a difference, I am not currently an Apache committer. Regards, John - Original Message - From: "Henri Yandell" <[EMAIL PROTECTED]> To: "Commons Developers List" ; <[EMAIL PROTECTED] > Sent: Friday, November 07, 2008 12:00 AM Subject: Re: [jelly] Is jelly still in development On Thu, Nov 6, 2008 at 3:11 PM, ralph.goers @dslextreme.com <[EMAIL PROTECTED]> wrote: On Thu, Nov 6, 2008 at 11:44 AM, Henri Yandell <[EMAIL PROTECTED]> wrote: I'm thinking we should: a) remove from trunks-proper b) Update the homepage to say "Not Actively Maintained" c) Update the Commons homepage to put this into a release subcategory of "Not Actively Maintained" d) Put said N.A.M. note on the JIRA page. Thoughts? If it is removed from trunks-proper where does it go? trunks-proper is a dir of svn:externals, so it's not lost just not in our active development set. Hen - 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] smime.p7s Description: S/MIME cryptographic signature
Re: [jelly] Is jelly still in development
Hi, We're still actively using Jelly and while the usefulness of some of the extension modules may be debatable (and definitely without wishing to enter into a debate of whether it is appropriate to have "executable" data), as a core tool Jelly has allowed us to rapidly produce pluggable languages for defining drawings, web services, schedules, JDBC configuration, and more where the tag implementation configures POJOs. Coincidentally, we've recently reached the point where we must make changes to the code base (bug fixes and new features) and so a couple of weeks ago I emailed James asking if he was still maintaining the project and if so what is plans were and whether I'd be able to contribute. Perhaps not surprisingly I didn't receive a reply, and now it seems I might have broken protocol by asking him direct instead of asking here. My apologies if that was inappropriate. We have a number of changes to make to Jelly, and I am prepared to put myself and my company forward as a maintainer. If that's acceptable to you all, the first task would be to briefly update the website and make a maintenance release (there are some essential bug fixes in SVN that are not in the official release), followed by various other fixes and additions in a beta release. Admittedly, my focus would be the core of Jelly and the core tags - I do not use the additional tag libraries and would find it difficult to provide a significant amount of regression testing and support for them but I'll keep them going where possible and try to help out any users with problems. Is this something you would be interested in? If the conclusion by the list is that Jelly should still be retired then as an alternative would it be possible for me to fork the Jelly project out of commons and into (for example) SourceForge? In case it makes a difference, I am not currently an Apache committer. Regards, John - Original Message - From: "Henri Yandell" <[EMAIL PROTECTED]> To: "Commons Developers List" ; <[EMAIL PROTECTED]> Sent: Friday, November 07, 2008 12:00 AM Subject: Re: [jelly] Is jelly still in development On Thu, Nov 6, 2008 at 3:11 PM, ralph.goers @dslextreme.com <[EMAIL PROTECTED]> wrote: On Thu, Nov 6, 2008 at 11:44 AM, Henri Yandell <[EMAIL PROTECTED]> wrote: I'm thinking we should: a) remove from trunks-proper b) Update the homepage to say "Not Actively Maintained" c) Update the Commons homepage to put this into a release subcategory of "Not Actively Maintained" d) Put said N.A.M. note on the JIRA page. Thoughts? If it is removed from trunks-proper where does it go? trunks-proper is a dir of svn:externals, so it's not lost just not in our active development set. Hen - 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
On Thu, Nov 6, 2008 at 3:11 PM, ralph.goers @dslextreme.com <[EMAIL PROTECTED]> wrote: > On Thu, Nov 6, 2008 at 11:44 AM, Henri Yandell <[EMAIL PROTECTED]> wrote: > >> >> I'm thinking we should: >> >> a) remove from trunks-proper >> b) Update the homepage to say "Not Actively Maintained" >> c) Update the Commons homepage to put this into a release subcategory >> of "Not Actively Maintained" >> d) Put said N.A.M. note on the JIRA page. >> >> Thoughts? >> > If it is removed from trunks-proper where does it go? trunks-proper is a dir of svn:externals, so it's not lost just not in our active development set. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] Is jelly still in development
On Thu, Nov 6, 2008 at 11:44 AM, Henri Yandell <[EMAIL PROTECTED]> wrote: > > I'm thinking we should: > > a) remove from trunks-proper > b) Update the homepage to say "Not Actively Maintained" > c) Update the Commons homepage to put this into a release subcategory > of "Not Actively Maintained" > d) Put said N.A.M. note on the JIRA page. > > Thoughts? > If it is removed from trunks-proper where does it go? Ralph
Re: [jelly] Is jelly still in development
On Wed, Nov 5, 2008 at 8:25 AM, Henri Yandell <[EMAIL PROTECTED]> wrote: > On Wed, Nov 5, 2008 at 3:55 AM, Paul Libbrecht <[EMAIL PROTECTED]> wrote: >> Le 05-nov.-08 à 10:22, XuQing Tan a écrit : >>> >>> I'm recently investigating some excutable xml scripters. So I want to know >>> is Jelly still in development, since it's last release is in 2004? >> >> Nick, >> >> Unfortunately no. >> For a long time it was annoyed by the fact that building it required huge >> resources but since maven 1.1 this is all very easy. Still, since James left >> it, it is kind of dormant with several unsolved issues, the biggest one >> being the website I feel. >> >> Some people still use it though and adding a few feature is quite easy... >> Jelly is still unbeatable as a glue in xml processing. >> What took James from Jelly, I think, is Groovy but that is incomparable... >> data in groovy is just as ugly as data in java while data in jelly is kind >> of natural and mixing data and scripting is exactly where jelly is at glory. > > Let's get this reflected on the website, and figure out how to > dormantize an already released project then. I bet we have others that > need to also be retired. I'm thinking we should: a) remove from trunks-proper b) Update the homepage to say "Not Actively Maintained" c) Update the Commons homepage to put this into a release subcategory of "Not Actively Maintained" d) Put said N.A.M. note on the JIRA page. Thoughts? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] Is jelly still in development
On Wed, Nov 5, 2008 at 3:55 AM, Paul Libbrecht <[EMAIL PROTECTED]> wrote: > Le 05-nov.-08 à 10:22, XuQing Tan a écrit : >> >> I'm recently investigating some excutable xml scripters. So I want to know >> is Jelly still in development, since it's last release is in 2004? > > Nick, > > Unfortunately no. > For a long time it was annoyed by the fact that building it required huge > resources but since maven 1.1 this is all very easy. Still, since James left > it, it is kind of dormant with several unsolved issues, the biggest one > being the website I feel. > > Some people still use it though and adding a few feature is quite easy... > Jelly is still unbeatable as a glue in xml processing. > What took James from Jelly, I think, is Groovy but that is incomparable... > data in groovy is just as ugly as data in java while data in jelly is kind > of natural and mixing data and scripting is exactly where jelly is at glory. Let's get this reflected on the website, and figure out how to dormantize an already released project then. I bet we have others that need to also be retired. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] Is jelly still in development
On Wed, 2008-11-05 at 10:55 +0100, Paul Libbrecht wrote: > Jelly is still unbeatable as a glue in xml processing. I think that is a conjecture, a claim even, that needs justification and support. Groovy, Python, Ruby people would argue (and I think quite rightly) that XML is a data specification notation that has no computational model, and shouldn't have. Groovy, Python and Ruby have all the computational model and XML processing features needed -- or if they don't they should have. > What took James from Jelly, I think, is Groovy but that is > incomparable... data in groovy is just as ugly as data in java while > data in jelly is kind of natural and mixing data and scripting is > exactly where jelly is at glory. Lisp is probably what you really want :-) -- 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
Le 05-nov.-08 à 10:22, XuQing Tan a écrit : I'm recently investigating some excutable xml scripters. So I want to know is Jelly still in development, since it's last release is in 2004? Nick, Unfortunately no. For a long time it was annoyed by the fact that building it required huge resources but since maven 1.1 this is all very easy. Still, since James left it, it is kind of dormant with several unsolved issues, the biggest one being the website I feel. Some people still use it though and adding a few feature is quite easy... Jelly is still unbeatable as a glue in xml processing. What took James from Jelly, I think, is Groovy but that is incomparable... data in groovy is just as ugly as data in java while data in jelly is kind of natural and mixing data and scripting is exactly where jelly is at glory. paul smime.p7s Description: S/MIME cryptographic signature
[jelly] Is jelly still in development
Hi, all I'm recently investigating some excutable xml scripters. So I want to know is Jelly still in development, since it's last release is in 2004? -- Thanks & Best Regards! Nick