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
smime.p7s
Description: S/MIME cryptographic signature
