commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Spackman" <john.spack...@zenesis.com>
Subject Re: [jelly] Is jelly still in development vs. Open/Federated Commons
Date Mon, 10 Nov 2008 06:11:13 GMT
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" <paul@activemath.org>
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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message