commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Libbrecht <>
Subject Re: [jelly] Is jelly still in development vs. Open/Federated Commons
Date Sun, 09 Nov 2008 20:26:28 GMT

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?

View raw message