jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: CVS commit messages? was (Re: Dual Taglibs...)
Date Tue, 30 Sep 2003 16:43:49 GMT
Pierre Delisle wrote:

> Mark R. Diggory wrote:
>
>> Yes, I tested commit rights in taglibs and it works, thanks.
>>
>> On the Commons project, commit notices are forwarded to the 
>> developers list, I find this very benificial there when tracking 
>> activity on our little [math] sandbox project, are there any 
>> yay/nay's about doing this on the taglibs project?
>
>
> For taglibs, cvs notifications are sent to 
> jakarta-taglibs-cvs@apache.org.
> Personally, I prefer this as CVS notifications can generate a lot
> of uninteresting traffic.
>
> I however just checked the mailing lists page it says the following:
>
> The Taglibs Developer List
> Medium Traffic Subscribe Unsubscribe Guidelines Archive
>
> Developers of custom tag libraries gather here to discuss issues, plan 
> code changes, and accept offers of new custom tag libraries to be 
> contributed. Subscribers to this list will also get notices of every 
> CVS checkin of new or changed code modules.
> I'd see the following two options:
>
> 1. Keep cvs notifications to jakarta-taglibs-cvs and update the 
> mailing list page
>   with jakarta-taglibs-cvs
>
> 2. Move cvs notifications to taglibs-dev.
>
> My vote is for 1.
>
>    -- Pierre

I'm not an active committer on Taglibs, but all the Jakarta projects 
I've been involved in use option 2 (indirectly -- it's automatically 
redirected in the mailing list setups), and I much prefer it.  Part of 
that is philosophical (developers who aren't interested in seeing what 
is actually changing are not as likely to take part in contributing), 
part of it is responsibility (developers *should* be reviewing *all* 
changes to the code base), and part of it is the ability to filter the 
CVS commits into a separate folder if I really want to :-).

Craig

>
>
>>
>> -Mark
>>
>>
>> Craig R. McClanahan wrote:
>>
>>> Based on the vote results, Mark now has karma on jakarta-taglibs and 
>>> jakarta-taglibs-sandbox.
>>>
>>>>
>>>>
>>>> -Mark 
>>>
>>>
>>>
>>>
>>> Craig
>>>
>>>>
>>>>
>>>> Pierre Delisle wrote:
>>>>
>>>>> Another thing...
>>>>>
>>>>> Selecting proper URIs in the face of dual taglibs is a real pain. 
>>>>> I'd advise against the naming used in JSTL 1.0,
>>>>> where <name> was the EL version and <name>_rt was the RT
version.
>>>>>
>>>>> The EL version becomes deprecated under JSP 2.0, so you don't
>>>>> want it to use the URI you'd want to keep in the future.
>>>>>
>>>>> Since anyone using the EL version will have to switch URI to take
>>>>> advantage of the EL in JSP 2.0, it is therefore preferrable to 
>>>>> have the EL version have the suffix in its URI, rather than on the 
>>>>> RT version.
>>>>>
>>>>>    -- Pierre
>>>>>
>>>>> Pierre Delisle wrote:
>>>>>
>>>>>> Mark,
>>>>>>
>>>>>> The JSTL 1.1 spec says the following in the Compatibility section:
>>>>>>
>>>>>> The JSTL 1.0 URIs are deprecated as of JSTL 1.1. If used, they 
>>>>>> should normally
>>>>>> appear in a web application that has a servlet 2.3 deployment 
>>>>>> descriptor to disable
>>>>>> the JSP 2.0 EL machinery. If used with a servlet 2.4 deployment 
>>>>>> descriptor, the JSP
>>>>>> 2.0 EL machinery must be explicitely disabled for the pages where

>>>>>> the JSTL 1.0 tag
>>>>>> libraries are used. Consult the JSP specification for details.
>>>>>>
>>>>>> The intent of the expert group is to base any new development on
the
>>>>>> JSP 2.0 spec. So dual taglibraries were only a temporary fix when

>>>>>> JSTL 1.0 first came out.
>>>>>>
>>>>>> J2EE 1.4 is just around the corner, but it takes some time for 
>>>>>> vendors
>>>>>> to push their new releases and for people to adopt them.
>>>>>> If you don't mind going through the extra pain, you'll definitely

>>>>>> have more traction if you go with dual libraries.
>>>>>> But dual tag libraries will definitely be things of the past when

>>>>>> J2EE 1.4 is widely adopted.
>>>>>>
>>>>>>    -- Pierre
>>>>>>
>>>>>> Mark R. Diggory wrote:
>>>>>>
>>>>>>> I think I should try to clarify this question further. I 
>>>>>>> understand that EL support is native with JSP 2.0, and that JSTL

>>>>>>> 1.1 is designed to be backward compatable with 1.0. My question

>>>>>>> has more to do with the future direction of the JSTL dual 
>>>>>>> libraries after 1.1 and into the future.
>>>>>>>
>>>>>>> Mostly, I could model the design of the JNDI taglibrary on those

>>>>>>> of the current SQL taglibrary. In which case there would be two

>>>>>>> JNDI libraries, one RT and the other EL (both sharing a common

>>>>>>> support library). However, at this point, with the advent of
EL 
>>>>>>> support as part of JSP 2.0, is there really a need to support

>>>>>>> the EL evaluation internally within the taglibrary itself? In

>>>>>>> which case the library would really be much more like the SQL
RT 
>>>>>>> taglibrary and EL would be available on JSP 2.0 while JSP 1.2

>>>>>>> containers would rely on RT.
>>>>>>>
>>>>>>> Is there an intention to maintain these dual implementations

>>>>>>> into the future of JSTL? If so, then I would model on this, 
>>>>>>> otherwise, I would attempt to choose the design that JSTL was

>>>>>>> planning to move towards instead.
>>>>>>>
>>>>>>> -Mark
>>>>>>>
>>>>>>> Mark R. Diggory wrote:
>>>>>>>
>>>>>>>> As Standard 1.1 and Tomcat 5.0 matures, is it the intention
to 
>>>>>>>> eventually consolidate the dual rt/el packages?
>>>>>>>>
>>>>>>>> -Mark
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------

>>>>>>
>>>>>> To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
>>>>>> For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
>>>>> For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
>>>>>
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
>>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org




Mime
View raw message