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" <dev@commons.apache.org>
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)
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
