Return-Path: Delivered-To: apmail-xml-cocoon-users-archive@xml.apache.org Received: (qmail 52142 invoked by uid 500); 28 Mar 2001 20:23:59 -0000 Mailing-List: contact cocoon-users-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-users@xml.apache.org Delivered-To: mailing list cocoon-users@xml.apache.org Received: (qmail 52130 invoked from network); 28 Mar 2001 20:23:59 -0000 Message-ID: From: Yann Camenen To: "'cocoon-users@xml.apache.org'" Subject: RE: Central repository for taglibs Date: Wed, 28 Mar 2001 12:32:24 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Hello all, I would definitely go for that idea. I believe that one of the reasons Ulrich's of Jeff's taglibs are not as widely used as they could be, is because they're not part of the Cocoon distribution, or any distribution for that matter, and thus not so easy for users to integrate in the Cocoon framework (Ok, maybe that's also because not many people use SOAP or LDAP that much yet). Also, where is that logicsheet/taglib documentation that everybody is asking for ? I know there are resources, they're just not easily accessible to new users. What about the taglib schema validation idea that came up a few weeks ago ? There probably could also be some kind of taglib schema for logicsheet authors to extend. I believe that some sort of organisation would allow for a higher degree of coordination on such projects. If a structure existed, it probably would induce some additional overhead for existing taglib authors but would definitely facilitate entry for new contributors. It doesn't necessarily mean a new mailing list and web site, just a few pages on the Cocoon site and a [Taglib] subject line. Finally, how many people here have modified/improved versions of the esql or fp taglibs that they don't know what to do with ? Who should these modifications be submitted to (especially for those taglibs that don't have a well-known maintainer) and how ? Are patches to taglibs to be treated the same way as cocoon contrib patches are ? Are the same people supposed to handle both ? Just my opinion. Regards, Yann Camenen -----Original Message----- From: Jeff Turner [mailto:jeff@socialchange.net.au] Sent: Wednesday, March 28, 2001 4:40 AM To: cocoon-users@xml.apache.org Subject: Re: Central repository for taglibs On Wed, Mar 28, 2001 at 10:09:37AM +0200, Ulrich Mayring wrote: > Jeff Turner wrote: > > > > It would be a separate project, like jakarta-taglibs is separate > > from tomcat-users. Separate CVS, different set of contributors.. > > why would it affect, or be affected by, the existing Cocoon > > project infrastructure? > > Taglibs are inseperable from Cocoon. Think of the most widely used > taglibs like sql or esql - Donald can make sure that esql runs with > every new release, because he is on top of the developments of > Cocoon and can, if need be, change something in Cocoon to benefit > his taglib. I didn't think esql, for example, and Cocoon were that tightly coupled. What sort of dependencies are you thinking of? I'd have thought that it's not so much "what new stuff has Cocoon got that breaks my taglib", but more "what new XSP features can I use that will break backwards-compatibility". That's the decision of the taglib author. If esql x.x won't work with later versions of Cocoon, might as well bundle it with the version that works. The vast majority of taglibs, I'd guess, are not tied to Cocoon versions at all. XSP enhancements in C1 have been mostly cosmetic or under the hood. I'm walking on thin factual ice.. better stop, But are any of your taglibs incompatible with old C1 versions? > > By reference platform, I assume you mean Tomcat, JRun, Resin, etc? > > I quote from the website: > > All new code should be tested under the following servlet engines: > > - Apache JServ 1.1.2 (NOTE: This uses Servlet API 2.0) - Apache > Tomcat 3.1 > - Resin 1.2.0 > > It should also be tested on the following: > > - A Windows operating system > - A UNIX-type operating system > - A JDK version 1.1.x > > So this comes out to nine reference platforms. That's for Cocoon. Any reason why it should apply to a collection of Cocoon taglibs? Some taglib authors depend on servlet2.2 features, so it would be impractical anyway. In the jakarta-taglibs project, there are already taglibs popping up that depend on 2.3 features. Of course that doesn't mean certain taglibs can't mandate a level of backwards-compatibility. I'd imagine you'd get upset if someone added 2.2 code to your taglibs :) > > I doubt if you'd even find volunteers even to test Cocoon, let > > alone a whole bunch of taglibs. How does lack of universal testing > > detract from the benefits of a separate taglibs project? Testing > > on multiple platforms is one of those "maintenance overheads" that > > a centralized taglibs project alleviates. To test them all under > > my environment, I'd go: > > > > cd xsp-taglibs > > ./build.sh dist > > cp dist/*.war /var/tomcat/webapps > > tomcat stop ; tomcat start > > > > Much easier than anything possible today. > > How would that apply to JServ and Resin? It would work fine for Resin, and any servlet2.2-compliant server. JServ, obviously not, but see my question above as to why taglibs must be tied to Cocoon platform requirements. The point of the above example is that a taglib repository makes testing a lot easier *in most cases*, and no harder in the JServ case. > And why should I test taglibs that I don't use? I test my own > taglibs on my platform and for esql I trust Donald :) You don't have to. The advantages of a taglib repository are that of a consistent build, examples, documentation and (for 2.2 users) testing system. > > If there was a common taglib repository and mailing list, > > communication in this area could only improve. Currently, every > > taglib developer needs to be on top of changes, or risk their > > taglib being quietly obsoleted. If maintenance was centralized, > > this is much less likely, as any committer can update multiple > > taglibs. > > Cool, so you will fix my taglibs? :) A counter-question: are you going to upgrade your taglibs to support C2 soon? ;) I presume not, because it's not something you need. If they were in a central project, it only takes one C2 guru (with a lot of spare time) to get the whole lot, including yours, working with C2. That is the key to why a taglib repository would work: ** Issue-specific knowledge cross-cuts taglibs ** These issues can be C2 support, developing good taglib docs, knowledge of schemas, doing cool things with RDDL, fixing Cocoon-specific bugs, clever XSP techniques, etc. Very, very few taglib developers can do all of this. But chances are that, in a group, at least one can do each, and contribute that skill. One person could take responsibility for writing schemas; another could create a schema->documentation system. Another could do RDDL docs for taglibs. I'm not saying all this has to happen for the project to be successful, but it will happen to a much greater extent than if taglibs are not centralized. Yes, I'll fix your, and any other taglib, if the improvement is something I can do. Sadly, all I can do *well* is documentation ;P Hence the long-winded emails.. --Jeff --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. To unsubscribe, e-mail: For additional commands, e-mail: --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. To unsubscribe, e-mail: For additional commands, e-mail: