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" <dev@commons.apache.org>
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 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" <dev@commons.apache.org>; <[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]






---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to