cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Camenen <>
Subject RE: Central repository for taglibs
Date Wed, 28 Mar 2001 20:32:24 GMT
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.

Yann Camenen

-----Original Message-----
From: Jeff Turner []
Sent: Wednesday, March 28, 2001 4:40 AM
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
> > ./ 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

> > 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


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: <>

View raw message