You are viewing a plain text version of this content. The canonical link for it is here.
Posted to taglibs-dev@jakarta.apache.org by Pierre Delisle <Pi...@Sun.COM> on 2003/09/26 23:50:26 UTC
[VOTE] New committer: Mark Diggory
OK, let's make this official :-)
Committers:
I'd like to nominate Mark Diggory as a committer for Jakarta Taglibs.
He's been contributing to this community in various ways and would
be a a welcome addition to our group of committers.
+1 for adding Mark as a committer.
-- Pierre
Re: [VOTE] New committer: Mark Diggory
Posted by Glenn Nielsen <gl...@mail.more.net>.
+1, Welcome aboard!
Pierre Delisle wrote:
> OK, let's make this official :-)
>
> Committers:
>
> I'd like to nominate Mark Diggory as a committer for Jakarta Taglibs.
> He's been contributing to this community in various ways and would
> be a a welcome addition to our group of committers.
>
> +1 for adding Mark as a committer.
>
> -- Pierre
>
>
>
>
>
>
> ---------------------------------------------------------------------
> 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
Re: [VOTE] New committer: Mark Diggory
Posted by Glenn Nielsen <gl...@mail.more.net>.
+1, Welcome aboard!
Pierre Delisle wrote:
> OK, let's make this official :-)
>
> Committers:
>
> I'd like to nominate Mark Diggory as a committer for Jakarta Taglibs.
> He's been contributing to this community in various ways and would
> be a a welcome addition to our group of committers.
>
> +1 for adding Mark as a committer.
>
> -- Pierre
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
>
Re: [VOTE] New committer: Mark Diggory
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Pierre Delisle wrote:
> OK, let's make this official :-)
>
> Committers:
>
> I'd like to nominate Mark Diggory as a committer for Jakarta Taglibs.
> He's been contributing to this community in various ways and would
> be a a welcome addition to our group of committers.
>
> +1 for adding Mark as a committer.
>
> -- Pierre
+1.
Mark is one of the good guys :-).
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: [VOTE] New committer: Mark Diggory
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Pierre Delisle wrote:
> OK, let's make this official :-)
>
> Committers:
>
> I'd like to nominate Mark Diggory as a committer for Jakarta Taglibs.
> He's been contributing to this community in various ways and would
> be a a welcome addition to our group of committers.
>
> +1 for adding Mark as a committer.
>
> -- Pierre
+1.
Mark is one of the good guys :-).
Craig
Re: CVS commit messages? was (Re: Dual Taglibs...)
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Craig R. McClanahan wrote:
> Pierre Delisle wrote:
> Actually, #2 *is* the way it's set up ... it's just that the first
> commit from a new committer goes to the taglibs-dev moderator,
> husted@apache.org (where it must still be sitting, waiting to be
> "allowed" through with no further moderations).
>
> I'll take care of the latter part (so that Mark's subsequent commits)
> flow through directly -- don't know at the moment how to moderate
> through the old message, so I'll have to do some research on that.
>
>
Looks good to go, thanks!
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: CVS commit messages? was (Re: Dual Taglibs...)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Pierre Delisle wrote:
> Just like Mark, I' easy on this issue.
> I don't mind going with 2, especially if that is how all the other
> jakarta projects operate.
>
> Craig, since you were involved in creating jakarta-taglibs, would
> you know (out of curiosity) how we ended up with cvs notifications
> going to jakarta-taglibs-cvs instead of taglibs-dev?
I have a vague recollection of people working on taglib "a" that didn't
care about commit messages for taglib "b" ... but separating the two
lists doesn't solve that problem anyway.
>
> Also, if there are no objections with going to 2 (let's give it
> a couple days), would you mind making the switch happen (or let
> us know how to do it).
Actually, #2 *is* the way it's set up ... it's just that the first
commit from a new committer goes to the taglibs-dev moderator,
husted@apache.org (where it must still be sitting, waiting to be
"allowed" through with no further moderations).
I'll take care of the latter part (so that Mark's subsequent commits)
flow through directly -- don't know at the moment how to moderate
through the old message, so I'll have to do some research on that.
>
> Thanks,
>
> -- Pierre
Craig
>
> Mark R. Diggory wrote:
>
>>
>>
>> Craig R. McClanahan wrote:
>>
>>> Pierre Delisle wrote:
>>>
>>>> Mark R. Diggory wrote:
>>>>
>>>>> 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
>>>
>>
>> The struggle I have with this is the following:
>>
>> 1.) Yes all developers should be reviewing the commit logs, email is
>> great in accomplishing this.
>>
>> 2.) Dumping commits into the developer list possibly makes searching
>> them more difficult in terms of matching discussions and not commit
>> events. By separating the lists, this issue is managed at the list
>> level (not the user level). Of course if the commit and NoReply
>> events were not archived even though they were sent out on the list,
>> this would easily solve such a problem.
>>
>> 3.) IMHO, Archiving commit events isn't of much benefit, one usually
>> would check the cvs log directly.
>>
>> My opinion is not that strong on all of this, whatever "The
>> Management" recommends or requests is fine with me too.
>>
>> -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
Re: CVS commit messages? was (Re: Dual Taglibs...)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Pierre Delisle wrote:
> Just like Mark, I' easy on this issue.
> I don't mind going with 2, especially if that is how all the other
> jakarta projects operate.
>
> Craig, since you were involved in creating jakarta-taglibs, would
> you know (out of curiosity) how we ended up with cvs notifications
> going to jakarta-taglibs-cvs instead of taglibs-dev?
I have a vague recollection of people working on taglib "a" that didn't
care about commit messages for taglib "b" ... but separating the two
lists doesn't solve that problem anyway.
>
> Also, if there are no objections with going to 2 (let's give it
> a couple days), would you mind making the switch happen (or let
> us know how to do it).
Actually, #2 *is* the way it's set up ... it's just that the first
commit from a new committer goes to the taglibs-dev moderator,
husted@apache.org (where it must still be sitting, waiting to be
"allowed" through with no further moderations).
I'll take care of the latter part (so that Mark's subsequent commits)
flow through directly -- don't know at the moment how to moderate
through the old message, so I'll have to do some research on that.
>
> Thanks,
>
> -- Pierre
Craig
>
> Mark R. Diggory wrote:
>
>>
>>
>> Craig R. McClanahan wrote:
>>
>>> Pierre Delisle wrote:
>>>
>>>> Mark R. Diggory wrote:
>>>>
>>>>> 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
>>>
>>
>> The struggle I have with this is the following:
>>
>> 1.) Yes all developers should be reviewing the commit logs, email is
>> great in accomplishing this.
>>
>> 2.) Dumping commits into the developer list possibly makes searching
>> them more difficult in terms of matching discussions and not commit
>> events. By separating the lists, this issue is managed at the list
>> level (not the user level). Of course if the commit and NoReply
>> events were not archived even though they were sent out on the list,
>> this would easily solve such a problem.
>>
>> 3.) IMHO, Archiving commit events isn't of much benefit, one usually
>> would check the cvs log directly.
>>
>> My opinion is not that strong on all of this, whatever "The
>> Management" recommends or requests is fine with me too.
>>
>> -Mark
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: CVS commit messages? was (Re: Dual Taglibs...)
Posted by Pierre Delisle <Pi...@Sun.COM>.
Just like Mark, I' easy on this issue.
I don't mind going with 2, especially if that is how all the other
jakarta projects operate.
Craig, since you were involved in creating jakarta-taglibs, would
you know (out of curiosity) how we ended up with cvs notifications going to
jakarta-taglibs-cvs instead of taglibs-dev?
Also, if there are no objections with going to 2 (let's give it
a couple days), would you mind making the switch happen (or let
us know how to do it).
Thanks,
-- Pierre
Mark R. Diggory wrote:
>
>
> Craig R. McClanahan wrote:
>
>> Pierre Delisle wrote:
>>
>>> Mark R. Diggory wrote:
>>>
>>>> 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
>>
>
> The struggle I have with this is the following:
>
> 1.) Yes all developers should be reviewing the commit logs, email is
> great in accomplishing this.
>
> 2.) Dumping commits into the developer list possibly makes searching
> them more difficult in terms of matching discussions and not commit
> events. By separating the lists, this issue is managed at the list level
> (not the user level). Of course if the commit and NoReply events were
> not archived even though they were sent out on the list, this would
> easily solve such a problem.
>
> 3.) IMHO, Archiving commit events isn't of much benefit, one usually
> would check the cvs log directly.
>
> My opinion is not that strong on all of this, whatever "The Management"
> recommends or requests is fine with me too.
>
> -Mark
>
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: CVS commit messages? was (Re: Dual Taglibs...)
Posted by Pierre Delisle <Pi...@Sun.COM>.
Just like Mark, I' easy on this issue.
I don't mind going with 2, especially if that is how all the other
jakarta projects operate.
Craig, since you were involved in creating jakarta-taglibs, would
you know (out of curiosity) how we ended up with cvs notifications going to
jakarta-taglibs-cvs instead of taglibs-dev?
Also, if there are no objections with going to 2 (let's give it
a couple days), would you mind making the switch happen (or let
us know how to do it).
Thanks,
-- Pierre
Mark R. Diggory wrote:
>
>
> Craig R. McClanahan wrote:
>
>> Pierre Delisle wrote:
>>
>>> Mark R. Diggory wrote:
>>>
>>>> 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
>>
>
> The struggle I have with this is the following:
>
> 1.) Yes all developers should be reviewing the commit logs, email is
> great in accomplishing this.
>
> 2.) Dumping commits into the developer list possibly makes searching
> them more difficult in terms of matching discussions and not commit
> events. By separating the lists, this issue is managed at the list level
> (not the user level). Of course if the commit and NoReply events were
> not archived even though they were sent out on the list, this would
> easily solve such a problem.
>
> 3.) IMHO, Archiving commit events isn't of much benefit, one usually
> would check the cvs log directly.
>
> My opinion is not that strong on all of this, whatever "The Management"
> recommends or requests is fine with me too.
>
> -Mark
>
Re: CVS commit messages? was (Re: Dual Taglibs...)
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Craig R. McClanahan wrote:
> Pierre Delisle wrote:
>
>> Mark R. Diggory wrote:
>>> 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
>
The struggle I have with this is the following:
1.) Yes all developers should be reviewing the commit logs, email is
great in accomplishing this.
2.) Dumping commits into the developer list possibly makes searching
them more difficult in terms of matching discussions and not commit
events. By separating the lists, this issue is managed at the list level
(not the user level). Of course if the commit and NoReply events were
not archived even though they were sent out on the list, this would
easily solve such a problem.
3.) IMHO, Archiving commit events isn't of much benefit, one usually
would check the cvs log directly.
My opinion is not that strong on all of this, whatever "The Management"
recommends or requests is fine with me too.
-Mark
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
Re: CVS commit messages? was (Re: Dual Taglibs...)
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Craig R. McClanahan wrote:
> Pierre Delisle wrote:
>
>> Mark R. Diggory wrote:
>>> 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
>
The struggle I have with this is the following:
1.) Yes all developers should be reviewing the commit logs, email is
great in accomplishing this.
2.) Dumping commits into the developer list possibly makes searching
them more difficult in terms of matching discussions and not commit
events. By separating the lists, this issue is managed at the list level
(not the user level). Of course if the commit and NoReply events were
not archived even though they were sent out on the list, this would
easily solve such a problem.
3.) IMHO, Archiving commit events isn't of much benefit, one usually
would check the cvs log directly.
My opinion is not that strong on all of this, whatever "The Management"
recommends or requests is fine with me too.
-Mark
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: CVS commit messages? was (Re: Dual Taglibs...)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: CVS commit messages? was (Re: Dual Taglibs...)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
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
Re: CVS commit messages? was (Re: Dual Taglibs...)
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
I'd vote for "1" too. I just didn't realize the cvs list existed.
-Mark
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
>
>
>>
>> -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
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: CVS commit messages? was (Re: Dual Taglibs...)
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
I'd vote for "1" too. I just didn't realize the cvs list existed.
-Mark
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
>
>
>>
>> -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
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
Re: CVS commit messages? was (Re: Dual Taglibs...)
Posted by Pierre Delisle <Pi...@Sun.COM>.
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
>
> -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
>>
>
Re: CVS commit messages? was (Re: Dual Taglibs...)
Posted by Pierre Delisle <Pi...@Sun.COM>.
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
>
> -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
CVS commit messages? was (Re: Dual Taglibs...)
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
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?
-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
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
CVS commit messages? was (Re: Dual Taglibs...)
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
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?
-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
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: Dual Taglibs...
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Mark R. Diggory wrote:
> Great, this is all really good to know.
>
> It makes sense to try to get as much traction as possible right now,
> (we're actually struggling to get over Tomcat5.0 due to some RPM
> related issues external to Tomcat). So we do need a Servlet 2.3 el
> impl if we want to take advantage of jndi tags with el in our products.
>
> Its not difficult to reorganize to support el internally in an
> alternative implementation for Servlet 2.3 applications. The two
> implementations would share the same common support for now (like in
> the standard packages), as JSTL evolves, then JNDI can parallel its
> design.
>
> It does make logical senese (as you've said below) to make the el
> taglib the alternative jndi_el as opposed making rt the alternative
> (jndi_rt). I will do this too.
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
>>
>
Re: Dual Taglibs...
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Mark R. Diggory wrote:
> Great, this is all really good to know.
>
> It makes sense to try to get as much traction as possible right now,
> (we're actually struggling to get over Tomcat5.0 due to some RPM
> related issues external to Tomcat). So we do need a Servlet 2.3 el
> impl if we want to take advantage of jndi tags with el in our products.
>
> Its not difficult to reorganize to support el internally in an
> alternative implementation for Servlet 2.3 applications. The two
> implementations would share the same common support for now (like in
> the standard packages), as JSTL evolves, then JNDI can parallel its
> design.
>
> It does make logical senese (as you've said below) to make the el
> taglib the alternative jndi_el as opposed making rt the alternative
> (jndi_rt). I will do this too.
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
Re: Dual Taglibs...
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Great, this is all really good to know.
It makes sense to try to get as much traction as possible right now,
(we're actually struggling to get over Tomcat5.0 due to some RPM related
issues external to Tomcat). So we do need a Servlet 2.3 el impl if we
want to take advantage of jndi tags with el in our products.
Its not difficult to reorganize to support el internally in an
alternative implementation for Servlet 2.3 applications. The two
implementations would share the same common support for now (like in the
standard packages), as JSTL evolves, then JNDI can parallel its design.
It does make logical senese (as you've said below) to make the el taglib
the alternative jndi_el as opposed making rt the alternative (jndi_rt).
I will do this too.
-Mark
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
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
Re: Dual Taglibs...
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Great, this is all really good to know.
It makes sense to try to get as much traction as possible right now,
(we're actually struggling to get over Tomcat5.0 due to some RPM related
issues external to Tomcat). So we do need a Servlet 2.3 el impl if we
want to take advantage of jndi tags with el in our products.
Its not difficult to reorganize to support el internally in an
alternative implementation for Servlet 2.3 applications. The two
implementations would share the same common support for now (like in the
standard packages), as JSTL evolves, then JNDI can parallel its design.
It does make logical senese (as you've said below) to make the el taglib
the alternative jndi_el as opposed making rt the alternative (jndi_rt).
I will do this too.
-Mark
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
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: Dual Taglibs...
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Great, this is all really good to know.
It makes sense to try to get as much traction as possible right now,
(we're actually struggling to get over Tomcat5.0 due to some RPM related
issues external to Tomcat). So we do need a Servlet 2.3 el impl if we
want to take advantage of jndi tags with el in our products.
Its not difficult to reorganize to support el internally in an
alternative implementation for Servlet 2.3 applications. The two
implementations would share the same common support for now (like in the
standard packages), as JSTL evolves, then JNDI can parallel its design.
It does make logical senese (as you've said below) to make the el taglib
the alternative jndi_el as opposed making rt the alternative (jndi_rt).
I will do this too.
-Mark
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
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: Dual Taglibs...
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Great, this is all really good to know.
It makes sense to try to get as much traction as possible right now,
(we're actually struggling to get over Tomcat5.0 due to some RPM related
issues external to Tomcat). So we do need a Servlet 2.3 el impl if we
want to take advantage of jndi tags with el in our products.
Its not difficult to reorganize to support el internally in an
alternative implementation for Servlet 2.3 applications. The two
implementations would share the same common support for now (like in the
standard packages), as JSTL evolves, then JNDI can parallel its design.
It does make logical senese (as you've said below) to make the el taglib
the alternative jndi_el as opposed making rt the alternative (jndi_rt).
I will do this too.
-Mark
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
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
Re: Dual Taglibs...
Posted by Pierre Delisle <Pi...@Sun.COM>.
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
>
>
Re: Dual Taglibs...
Posted by Pierre Delisle <Pi...@Sun.COM>.
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
Re: Dual Taglibs...
Posted by Pierre Delisle <Pi...@Sun.COM>.
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
>>
>
Re: Dual Taglibs...
Posted by Pierre Delisle <Pi...@Sun.COM>.
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
Re: Dual Taglibs...
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
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
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: Dual Taglibs...
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
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
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
Dual Taglibs...
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
As Standard 1.1 and Tomcat 5.0 matures, is it the intention to
eventually consolidate the dual rt/el packages?
-Mark
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Dual Taglibs...
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
As Standard 1.1 and Tomcat 5.0 matures, is it the intention to
eventually consolidate the dual rt/el packages?
-Mark
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
Re: [VOTE] New committer: Mark Diggory
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
:)
Much Happiness, thanks guys!
-Mark
bhasker wrote:
> +1 for Mark
> ----- Original Message -----
> From: "Pierre Delisle" <Pi...@Sun.COM>
> To: <ta...@jakarta.apache.org>
> Sent: Friday, September 26, 2003 10:50 PM
> Subject: [VOTE] New committer: Mark Diggory
>
>
>
>>OK, let's make this official :-)
>>
>>Committers:
>>
>>I'd like to nominate Mark Diggory as a committer for Jakarta Taglibs.
>>He's been contributing to this community in various ways and would
>>be a a welcome addition to our group of committers.
>>
>> +1 for adding Mark as a committer.
>>
>> -- Pierre
>>
>>
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>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
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: [VOTE] New committer: Mark Diggory
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
:)
Much Happiness, thanks guys!
-Mark
bhasker wrote:
> +1 for Mark
> ----- Original Message -----
> From: "Pierre Delisle" <Pi...@Sun.COM>
> To: <ta...@jakarta.apache.org>
> Sent: Friday, September 26, 2003 10:50 PM
> Subject: [VOTE] New committer: Mark Diggory
>
>
>
>>OK, let's make this official :-)
>>
>>Committers:
>>
>>I'd like to nominate Mark Diggory as a committer for Jakarta Taglibs.
>>He's been contributing to this community in various ways and would
>>be a a welcome addition to our group of committers.
>>
>> +1 for adding Mark as a committer.
>>
>> -- Pierre
>>
>>
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>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
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
Re: [VOTE] New committer: Mark Diggory
Posted by bhasker <bh...@ukgateway.net>.
+1 for Mark
----- Original Message -----
From: "Pierre Delisle" <Pi...@Sun.COM>
To: <ta...@jakarta.apache.org>
Sent: Friday, September 26, 2003 10:50 PM
Subject: [VOTE] New committer: Mark Diggory
> OK, let's make this official :-)
>
> Committers:
>
> I'd like to nominate Mark Diggory as a committer for Jakarta Taglibs.
> He's been contributing to this community in various ways and would
> be a a welcome addition to our group of committers.
>
> +1 for adding Mark as a committer.
>
> -- Pierre
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
>
Re: [VOTE] New committer: Mark Diggory
Posted by bhasker <bh...@ukgateway.net>.
+1 for Mark
----- Original Message -----
From: "Pierre Delisle" <Pi...@Sun.COM>
To: <ta...@jakarta.apache.org>
Sent: Friday, September 26, 2003 10:50 PM
Subject: [VOTE] New committer: Mark Diggory
> OK, let's make this official :-)
>
> Committers:
>
> I'd like to nominate Mark Diggory as a committer for Jakarta Taglibs.
> He's been contributing to this community in various ways and would
> be a a welcome addition to our group of committers.
>
> +1 for adding Mark as a committer.
>
> -- Pierre
>
>
>
>
>
>
> ---------------------------------------------------------------------
> 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
Re: [VOTE] New committer: Mark Diggory
Posted by Henri Yandell <ba...@generationjava.com>.
+1
On Fri, 26 Sep 2003, Pierre Delisle wrote:
> OK, let's make this official :-)
>
> Committers:
>
> I'd like to nominate Mark Diggory as a committer for Jakarta Taglibs.
> He's been contributing to this community in various ways and would
> be a a welcome addition to our group of committers.
>
> +1 for adding Mark as a committer.
>
> -- Pierre
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
>
Re: [VOTE] New committer: Mark Diggory
Posted by Henri Yandell <ba...@generationjava.com>.
+1
On Fri, 26 Sep 2003, Pierre Delisle wrote:
> OK, let's make this official :-)
>
> Committers:
>
> I'd like to nominate Mark Diggory as a committer for Jakarta Taglibs.
> He's been contributing to this community in various ways and would
> be a a welcome addition to our group of committers.
>
> +1 for adding Mark as a committer.
>
> -- Pierre
>
>
>
>
>
>
> ---------------------------------------------------------------------
> 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