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]
