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 Felipe Leme <ja...@felipeal.net> on 2004/03/05 20:10:35 UTC
[vote] dbtags 1.0.0 and random 1.0.2
Hi all,
I closed a lot of dbtags last week (actually, most of them were related
to the same problem -
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26863), so I think
it's time for a dbtags-1.0.0 release (latest release is 1.0B1, from aug
21st, 2001).
Although JSTL's SQL replaced most of DBTags features, people still uses
the later. In fact, it is not really clear that DBTags shouldn't be used
anymore. So here is my proposal:
- mark the 2 remaining bugs as LATER
- put a warning on the main doc page stating something like this:
If you are using a recent implementation of the
Servlet specification, you should use Apache's
implementation of the JSTL, not DBTags. DBTags has
been inactive since development on JSTL began, and it
should be considered deprecated for Servlet 2.3 or 2.4
containers.
- update the rest of the documentation (including state of union)
- release 1.0.0, as the "final" DBTags release (assuming that now people will be using JSTL SQL more and more)
[ ] +1 Release dbtags-1.0.0
[ ] -0 Do not release, please explain why
NOTE: un fact, I think we should create a new category of taglibs that
are neither deprecated nor supported. Something like obsolete (i.e. the
taglib is still supported for JSP 1.1 containers, but it can be replaced
for other taglibs in a JSP 1.2 and JSP 2.0). Many of the supported
taglibs would fit in this category: dbtags, XTags, Strings, page,
application, etc... (anyway, that's a subject for another message)
Similarly, I fixed one bug on random and realized some others bug were
fixed between 1.0.1 and now
(http://jakarta.apache.org/taglibs/doc/random-doc/changes.html)
[ ] +1 Release random-1.0.2
[ ] -0 Do not release, please explain why
Regards,
Felipe
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: Taglibs, EL and JSP 2.0 (was Re: string taglib)
Posted by Felipe Leme <ja...@felipeal.net>.
On Thu, 2004-03-11 at 02:21, Henri Yandell wrote:
> Sorry, have done. Sounds good to me.
Ok, I will commit that then and ask you to test (the fix didn't quite
work for me, but I guess is a problem in my Linux/Tomcat setup - if I
run the same code standalone, it works).
> Unsure how to find your user in bugzilla to reassign over to you
It's difficult sometimes, but in this case you could get it from my
comments (the user's key is the email address)
Felipe
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: Taglibs, EL and JSP 2.0 (was Re: string taglib)
Posted by Henri Yandell <ba...@generationjava.com>.
> PS: by speaking of Strings, could you please take a look on bug 18964?
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=18964
Sorry, have done. Sounds good to me. Unsure how to find your user in
bugzilla to reassign over to you [really, really looking forward to
Commons and Taglibs moving to JIRA].
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: Taglibs, EL and JSP 2.0 (was Re: string taglib)
Posted by Felipe Leme <ja...@felipeal.net>.
On Wed, 2004-03-10 at 10:53, Henri Yandell wrote:
> impossible given the size of the developer base. By the time we draw to a
> close, 2.0 will be becoming the standard.
Believe me, even it becomes the standard, many projects will still
depend on 1.2. Unfortunately, it takes time for some companies
(specially in the financial field) to approve new app servers version in
production.
> If someone can come up with a build structure that, with minimal effort,
> allows a 1.1, 1.2 or 2.0 version to be created, with 2.0 features blocked
I agree - without such structure, it would be near impossible to do what
I propose. I will try to give it a shot later...
Felipe
PS: by speaking of Strings, could you please take a look on bug 18964?
http://issues.apache.org/bugzilla/show_bug.cgi?id=18964
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: Taglibs, EL and JSP 2.0 (was Re: string taglib)
Posted by Henri Yandell <ba...@generationjava.com>.
To argue for the other view;
It seems pointless to spend the next year getting all the taglibs to 1.2,
which mainly means ELizing them, whilst also releasing 1.1 bugfixes and
starting work on 2.0 versions. Not so much pointless, but rather
impossible given the size of the developer base. By the time we draw to a
close, 2.0 will be becoming the standard.
If someone can come up with a build structure that, with minimal effort,
allows a 1.1, 1.2 or 2.0 version to be created, with 2.0 features blocked
from 1.1/1.2 and ELisation in the 1.2 version, all from the same source,
then it seems possible. Otherwise I'm in favour of merely providing
instructions on how to ELize a 1.1 library on the site and getting on with
a big rethink of taglibs for 2.0, in time to finish around about the point
2.0 gets more popular [1 year I'm estimating].
Hen
On Tue, 9 Mar 2004, Martin Cooper wrote:
> (Changing the subject, since we're now on a much more general subject that
> could impact many more taglibs than 'string'...)
>
> I agree with Felipe here that we can't (or at least shouldn't) punt on EL
> for JSP 1.2 and go straight to JSP 2.0. As far as I'm aware, there are no
> app servers available today that support JSP 2.0, and it will likely be a
> long time before Weblogic, WebSphere, et al, release products with such
> support. We can't ignore all of the developers who need to build apps on
> those platforms, and leave them stuck with only rtexprs until the app
> servers catch up to JSP 2.0.
>
> My own to-do list includes a Mailer 2.0 release that includes EL support
> for use on a JSP 1.2 platform. I'm thinking Mailer 1.x is for JSP 1.1,
> Mailer 2.x is for JSP 1.2, and Mailer 3.x is for JSP 2.0. Of course, we
> don't necessarily need to follow the same pattern for all of the taglibs
> here, that's just where my own thoughts are headed right now.
>
> --
> Martin Cooper
>
>
> On Tue, 9 Mar 2004, Felipe Leme wrote:
>
> > On Tue, 2004-03-09 at 10:06, Henri Yandell wrote:
> >
> > > I don't see any need to do anything for EL support. New versions of
> > > taglibs etc can be JSP 2.0 only in my opinion.
> >
> > I disagree. We cannot raise the bar to JSP 2.0 - it will take some time
> > (probably years) for that version be the standard in many projects in
> > the field.
> >
> > > 6. Release JSP 2.0 versions of taglibs.
> >
> > My idea is that the JSP 2.0 EL support would be transparent. Let's take
> > as example mailer. We would have:
> >
> > http://jakarta.apache.org/taglibs/mailer - this version would works on
> > JSP 1.1/1.2 (only with RT) support and JSP 2.0 (where EL is handled by
> > the container)
> >
> > http://jakarta.apache.org/taglibs/mailer-EL - that version should be
> > used only on 1.1 and 1.2 containers and it takes care of EL handling
> > (with no RT though)
> >
> > Note that the core code would be the shared - we would only have
> > differences on how to evaluate the EL parameters (similar to the
> > situation with have on JSTL 1.0)
> >
> >
> > That figure assumes the only difference between each JSP version is the
> > EL support. For the cases where there are more differences (like tags
> > being deprecated), we would have more taglibs:
> >
> > http://jakarta.apache.org/taglibs/strings
> > http://jakarta.apache.org/taglibs/strings-EL
> > http://jakarta.apache.org/taglibs/jsp2/strings
> >
> > In the particular case of Strings on JSP 2.0, maybe we should abolish it
> > completely and release a EL functions taglib instead.
> >
> > > I've no itch to come up with endless ways to support 1.1, 1.2 and 2.0 at
> > > the same time, increasingly complicating the tag development process.
> >
> > I agree it's a pain to support both, but as I mentioned before, we
> > cannot provide only 2.0 support. Maybe we could stop supporting 1.1
> > (although I've seen projects that depend on it, or even 1.0), but not
> > 1.2.
> >
> > In fact, if we come to a clever solution on how to handle/support these
> > multiple versions, that would be great for the project, because it would
> > be a model for many people (and other projects) to follow.
> >
> >
> > Felipe
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
Taglibs, EL and JSP 2.0 (was Re: string taglib)
Posted by Martin Cooper <ma...@apache.org>.
(Changing the subject, since we're now on a much more general subject that
could impact many more taglibs than 'string'...)
I agree with Felipe here that we can't (or at least shouldn't) punt on EL
for JSP 1.2 and go straight to JSP 2.0. As far as I'm aware, there are no
app servers available today that support JSP 2.0, and it will likely be a
long time before Weblogic, WebSphere, et al, release products with such
support. We can't ignore all of the developers who need to build apps on
those platforms, and leave them stuck with only rtexprs until the app
servers catch up to JSP 2.0.
My own to-do list includes a Mailer 2.0 release that includes EL support
for use on a JSP 1.2 platform. I'm thinking Mailer 1.x is for JSP 1.1,
Mailer 2.x is for JSP 1.2, and Mailer 3.x is for JSP 2.0. Of course, we
don't necessarily need to follow the same pattern for all of the taglibs
here, that's just where my own thoughts are headed right now.
--
Martin Cooper
On Tue, 9 Mar 2004, Felipe Leme wrote:
> On Tue, 2004-03-09 at 10:06, Henri Yandell wrote:
>
> > I don't see any need to do anything for EL support. New versions of
> > taglibs etc can be JSP 2.0 only in my opinion.
>
> I disagree. We cannot raise the bar to JSP 2.0 - it will take some time
> (probably years) for that version be the standard in many projects in
> the field.
>
> > 6. Release JSP 2.0 versions of taglibs.
>
> My idea is that the JSP 2.0 EL support would be transparent. Let's take
> as example mailer. We would have:
>
> http://jakarta.apache.org/taglibs/mailer - this version would works on
> JSP 1.1/1.2 (only with RT) support and JSP 2.0 (where EL is handled by
> the container)
>
> http://jakarta.apache.org/taglibs/mailer-EL - that version should be
> used only on 1.1 and 1.2 containers and it takes care of EL handling
> (with no RT though)
>
> Note that the core code would be the shared - we would only have
> differences on how to evaluate the EL parameters (similar to the
> situation with have on JSTL 1.0)
>
>
> That figure assumes the only difference between each JSP version is the
> EL support. For the cases where there are more differences (like tags
> being deprecated), we would have more taglibs:
>
> http://jakarta.apache.org/taglibs/strings
> http://jakarta.apache.org/taglibs/strings-EL
> http://jakarta.apache.org/taglibs/jsp2/strings
>
> In the particular case of Strings on JSP 2.0, maybe we should abolish it
> completely and release a EL functions taglib instead.
>
> > I've no itch to come up with endless ways to support 1.1, 1.2 and 2.0 at
> > the same time, increasingly complicating the tag development process.
>
> I agree it's a pain to support both, but as I mentioned before, we
> cannot provide only 2.0 support. Maybe we could stop supporting 1.1
> (although I've seen projects that depend on it, or even 1.0), but not
> 1.2.
>
> In fact, if we come to a clever solution on how to handle/support these
> multiple versions, that would be great for the project, because it would
> be a model for many people (and other projects) to follow.
>
>
> Felipe
>
>
>
>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> 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: string taglib
Posted by Felipe Leme <ja...@felipeal.net>.
On Tue, 2004-03-09 at 10:06, Henri Yandell wrote:
> I don't see any need to do anything for EL support. New versions of
> taglibs etc can be JSP 2.0 only in my opinion.
I disagree. We cannot raise the bar to JSP 2.0 - it will take some time
(probably years) for that version be the standard in many projects in
the field.
> 6. Release JSP 2.0 versions of taglibs.
My idea is that the JSP 2.0 EL support would be transparent. Let's take
as example mailer. We would have:
http://jakarta.apache.org/taglibs/mailer - this version would works on
JSP 1.1/1.2 (only with RT) support and JSP 2.0 (where EL is handled by
the container)
http://jakarta.apache.org/taglibs/mailer-EL - that version should be
used only on 1.1 and 1.2 containers and it takes care of EL handling
(with no RT though)
Note that the core code would be the shared - we would only have
differences on how to evaluate the EL parameters (similar to the
situation with have on JSTL 1.0)
That figure assumes the only difference between each JSP version is the
EL support. For the cases where there are more differences (like tags
being deprecated), we would have more taglibs:
http://jakarta.apache.org/taglibs/strings
http://jakarta.apache.org/taglibs/strings-EL
http://jakarta.apache.org/taglibs/jsp2/strings
In the particular case of Strings on JSP 2.0, maybe we should abolish it
completely and release a EL functions taglib instead.
> I've no itch to come up with endless ways to support 1.1, 1.2 and 2.0 at
> the same time, increasingly complicating the tag development process.
I agree it's a pain to support both, but as I mentioned before, we
cannot provide only 2.0 support. Maybe we could stop supporting 1.1
(although I've seen projects that depend on it, or even 1.0), but not
1.2.
In fact, if we come to a clever solution on how to handle/support these
multiple versions, that would be great for the project, because it would
be a model for many people (and other projects) to follow.
Felipe
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: string taglib
Posted by Henri Yandell <ba...@generationjava.com>.
On Tue, 9 Mar 2004, Felipe Leme wrote:
> On Tue, 2004-03-09 at 04:50, Henri Yandell wrote:
> > I've been thinking recently that a new version of the String taglib is
> > needed, implemented entirely as a set of EL-functions.
>
> I agree that EL support is a must. Not only for String, but for all
> supported taglibs (like mailer, for instance). So, we need a generic
> framework to help that task (I'm working on it, but it will take a while
> until the idea is mature enough to be sent to the list)
I don't see any need to do anything for EL support. New versions of
taglibs etc can be JSP 2.0 only in my opinion.
> > Those that are already handled would be removed.
>
> Agree. For instance, the random tags. Besides being handled by another
> taglib (Random), they are based on Commnons Lang random classes, that
> have some complex syntax in some cases.
Don't agree. :) I mean the ones that the JSP 2.0 function taglib already
covers, like capitalize.
> > It's a vague todo
> > [random(6 months) eta] for me at the moment.
>
> Don't worry about time - just the fact of having these discussions is
> already a progress for the project's current status :-).
>
> Maybe a next step would be defining an execution plan for the whole
> project. Something like this:
>
> 1.Finish migration to ASF 2.0 license
> 2.Create the new Legacy category and re-classify existing taglibs
> 3.Fix existing bugs
> 4.Release new bug-fix releases
> 5.Migrate to the new EL-support schema
> 6.Release a minor/major release that supports EL and RT
I'd kill 5 and 6 and replace them with:
5. Migrate undeprecated tags from Legacy taglibs into the Unstandard
taglib.
6. Release JSP 2.0 versions of taglibs.
I've no itch to come up with endless ways to support 1.1, 1.2 and 2.0 at
the same time, increasingly complicating the tag development process.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: string taglib
Posted by Felipe Leme <ja...@felipeal.net>.
On Tue, 2004-03-09 at 04:50, Henri Yandell wrote:
> I've been thinking recently that a new version of the String taglib is
> needed, implemented entirely as a set of EL-functions.
I agree that EL support is a must. Not only for String, but for all
supported taglibs (like mailer, for instance). So, we need a generic
framework to help that task (I'm working on it, but it will take a while
until the idea is mature enough to be sent to the list)
> Those that are already handled would be removed.
Agree. For instance, the random tags. Besides being handled by another
taglib (Random), they are based on Commnons Lang random classes, that
have some complex syntax in some cases.
> It's a vague todo
> [random(6 months) eta] for me at the moment.
Don't worry about time - just the fact of having these discussions is
already a progress for the project's current status :-).
Maybe a next step would be defining an execution plan for the whole
project. Something like this:
1.Finish migration to ASF 2.0 license
2.Create the new Legacy category and re-classify existing taglibs
3.Fix existing bugs
4.Release new bug-fix releases
5.Migrate to the new EL-support schema
6.Release a minor/major release that supports EL and RT
Of course, some of these tasks could be done in parallel (for instance,
fixing bugs and planning the LE support).
> > I saw someone mention that the string taglib should also be called
> > "Legacy".
It might have me, but if so, it was a mistake.
> This taglib however contains a lot of functionality that isn't
> > provided by JSTL and I'd very much like to see it kept in...
I agree. There might be some functionality provided by JSTL 1.1
functions, but that's not enough for 2 reasons:
- string currently has more tags than what's provided by JSTL 1.1
functions
- EL functions are only available on 2.0 and it will take a while for it
to be default and 1.2 be considered "legacy"
Felipe
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
string taglib Was: [vote] dbtags 1.0.0 and random 1.0.2
Posted by Henri Yandell <ba...@generationjava.com>.
I've been thinking recently that a new version of the String taglib is
needed, implemented entirely as a set of EL-functions.
Those that are already handled would be removed. It's a vague todo
[random(6 months) eta] for me at the moment.
Hen
On Tue, 9 Mar 2004, Martin van Dijken wrote:
> Hey Felipe,
>
> I saw someone mention that the string taglib should also be called
> "Legacy". This taglib however contains a lot of functionality that isn't
> provided by JSTL and I'd very much like to see it kept in...
>
> Martin
>
>
> > -----Original Message-----
> > From: Felipe Leme [mailto:jakartalists1@felipeal.net]
> > Sent: maandag 8 maart 2004 18:48
> > To: Tag Libraries Developers List
> > Subject: Re: [vote] dbtags 1.0.0 and random 1.0.2
> >
> >
> > On Mon, 2004-03-08 at 14:33, Henri Yandell wrote:
> >
> > > That was my plan, as such, for the unstandard taglib.
> > Legacise all the
> >
> > Sorry, I didn't know that was unstandard's purpose (I thought
> > it was a taglib for generic stuff that doesn't fit anywhere else).
> >
> > > current taglibs that JSTL pretty much replaces and put all
> > the extra
> > > bits left over into the one taglib, rather than lots of JSTL
> > > competitive
> >
> > That sounds like a good plan to me.
> >
> > []s,
> >
> > Felipe
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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: [vote] dbtags 1.0.0 and random 1.0.2
Posted by Martin van Dijken <su...@windgazer.nl>.
Hey Felipe,
I saw someone mention that the string taglib should also be called
"Legacy". This taglib however contains a lot of functionality that isn't
provided by JSTL and I'd very much like to see it kept in...
Martin
> -----Original Message-----
> From: Felipe Leme [mailto:jakartalists1@felipeal.net]
> Sent: maandag 8 maart 2004 18:48
> To: Tag Libraries Developers List
> Subject: Re: [vote] dbtags 1.0.0 and random 1.0.2
>
>
> On Mon, 2004-03-08 at 14:33, Henri Yandell wrote:
>
> > That was my plan, as such, for the unstandard taglib.
> Legacise all the
>
> Sorry, I didn't know that was unstandard's purpose (I thought
> it was a taglib for generic stuff that doesn't fit anywhere else).
>
> > current taglibs that JSTL pretty much replaces and put all
> the extra
> > bits left over into the one taglib, rather than lots of JSTL
> > competitive
>
> That sounds like a good plan to me.
>
> []s,
>
> Felipe
>
>
>
>
>
> ---------------------------------------------------------------------
> 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] dbtags 1.0.0 and random 1.0.2
Posted by Felipe Leme <ja...@felipeal.net>.
On Mon, 2004-03-08 at 14:33, Henri Yandell wrote:
> That was my plan, as such, for the unstandard taglib. Legacise all the
Sorry, I didn't know that was unstandard's purpose (I thought it was a
taglib for generic stuff that doesn't fit anywhere else).
> current taglibs that JSTL pretty much replaces and put all the extra bits
> left over into the one taglib, rather than lots of JSTL competitive
That sounds like a good plan to me.
[]s,
Felipe
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: [vote] dbtags 1.0.0 and random 1.0.2
Posted by Henri Yandell <ba...@generationjava.com>.
On Mon, 8 Mar 2004, Felipe Leme wrote:
> On Sun, 2004-03-07 at 21:29, Glenn Nielsen wrote:
>
> > > NOTE: un fact, I think we should create a new category of taglibs that
> > > are neither deprecated nor supported. Something like obsolete (i.e. the
> > > taglib is still supported for JSP 1.1 containers, but it can be replaced
> > > for other taglibs in a JSP 1.2 and JSP 2.0). Many of the supported
> > > taglibs would fit in this category: dbtags, XTags, Strings, page,
> > > application, etc... (anyway, that's a subject for another message)
> > >
> >
> > How about the term "Legacy"?
>
>
> Great, that's the term I've been looking for :-)
>
> I'll be analyzing the other taglibs (like io, request, session, scope,
> application, xtags, page and response) later to see if they totally fit
> as legacy, or if they still have some feature not covered by JSTL (and
> if they do, we could probably create a branch for the taglib: the old,
> full-features legacy version and the new version, with only the features
> not covered by JSTL).
That was my plan, as such, for the unstandard taglib. Legacise all the
current taglibs that JSTL pretty much replaces and put all the extra bits
left over into the one taglib, rather than lots of JSTL competitive
taglibs.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: [vote] dbtags 1.0.0 and random 1.0.2
Posted by Felipe Leme <ja...@felipeal.net>.
On Sun, 2004-03-07 at 21:29, Glenn Nielsen wrote:
> > NOTE: un fact, I think we should create a new category of taglibs that
> > are neither deprecated nor supported. Something like obsolete (i.e. the
> > taglib is still supported for JSP 1.1 containers, but it can be replaced
> > for other taglibs in a JSP 1.2 and JSP 2.0). Many of the supported
> > taglibs would fit in this category: dbtags, XTags, Strings, page,
> > application, etc... (anyway, that's a subject for another message)
> >
>
> How about the term "Legacy"?
Great, that's the term I've been looking for :-)
I'll be analyzing the other taglibs (like io, request, session, scope,
application, xtags, page and response) later to see if they totally fit
as legacy, or if they still have some feature not covered by JSTL (and
if they do, we could probably create a branch for the taglib: the old,
full-features legacy version and the new version, with only the features
not covered by JSTL).
Felipe
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: [vote] dbtags 1.0.0 and random 1.0.2
Posted by Glenn Nielsen <gl...@mail.more.net>.
On Fri, Mar 05, 2004 at 04:10:35PM -0300, Felipe Leme wrote:
> Hi all,
>
> I closed a lot of dbtags last week (actually, most of them were related
> to the same problem -
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26863), so I think
> it's time for a dbtags-1.0.0 release (latest release is 1.0B1, from aug
> 21st, 2001).
>
> Although JSTL's SQL replaced most of DBTags features, people still uses
> the later. In fact, it is not really clear that DBTags shouldn't be used
> anymore. So here is my proposal:
>
> - mark the 2 remaining bugs as LATER
> - put a warning on the main doc page stating something like this:
>
> If you are using a recent implementation of the
> Servlet specification, you should use Apache's
> implementation of the JSTL, not DBTags. DBTags has
> been inactive since development on JSTL began, and it
> should be considered deprecated for Servlet 2.3 or 2.4
> containers.
> - update the rest of the documentation (including state of union)
> - release 1.0.0, as the "final" DBTags release (assuming that now people will be using JSTL SQL more and more)
>
> [X] +1 Release dbtags-1.0.0
> [ ] -0 Do not release, please explain why
>
> NOTE: un fact, I think we should create a new category of taglibs that
> are neither deprecated nor supported. Something like obsolete (i.e. the
> taglib is still supported for JSP 1.1 containers, but it can be replaced
> for other taglibs in a JSP 1.2 and JSP 2.0). Many of the supported
> taglibs would fit in this category: dbtags, XTags, Strings, page,
> application, etc... (anyway, that's a subject for another message)
>
How about the term "Legacy"?
>
> Similarly, I fixed one bug on random and realized some others bug were
> fixed between 1.0.1 and now
> (http://jakarta.apache.org/taglibs/doc/random-doc/changes.html)
>
> [X] +1 Release random-1.0.2
> [ ] -0 Do not release, please explain why
Glenn
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: [vote] dbtags 1.0.0 and random 1.0.2
Posted by Martin Cooper <ma...@apache.org>.
+0 on both. I don't personally use either of these taglibs, but I have no
objection to them being released with the indicated bug fixes.
--
Martin Cooper
On Fri, 5 Mar 2004, Felipe Leme wrote:
> Hi all,
>
> I closed a lot of dbtags last week (actually, most of them were related
> to the same problem -
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26863), so I think
> it's time for a dbtags-1.0.0 release (latest release is 1.0B1, from aug
> 21st, 2001).
>
> Although JSTL's SQL replaced most of DBTags features, people still uses
> the later. In fact, it is not really clear that DBTags shouldn't be used
> anymore. So here is my proposal:
>
> - mark the 2 remaining bugs as LATER
> - put a warning on the main doc page stating something like this:
>
> If you are using a recent implementation of the
> Servlet specification, you should use Apache's
> implementation of the JSTL, not DBTags. DBTags has
> been inactive since development on JSTL began, and it
> should be considered deprecated for Servlet 2.3 or 2.4
> containers.
> - update the rest of the documentation (including state of union)
> - release 1.0.0, as the "final" DBTags release (assuming that now people will be using JSTL SQL more and more)
>
> [ ] +1 Release dbtags-1.0.0
> [ ] -0 Do not release, please explain why
>
> NOTE: un fact, I think we should create a new category of taglibs that
> are neither deprecated nor supported. Something like obsolete (i.e. the
> taglib is still supported for JSP 1.1 containers, but it can be replaced
> for other taglibs in a JSP 1.2 and JSP 2.0). Many of the supported
> taglibs would fit in this category: dbtags, XTags, Strings, page,
> application, etc... (anyway, that's a subject for another message)
>
>
>
> Similarly, I fixed one bug on random and realized some others bug were
> fixed between 1.0.1 and now
> (http://jakarta.apache.org/taglibs/doc/random-doc/changes.html)
>
> [ ] +1 Release random-1.0.2
> [ ] -0 Do not release, please explain why
>
>
> Regards,
>
> Felipe
>
>
>
> ---------------------------------------------------------------------
> 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] dbtags 1.0.0 and random 1.0.2
Posted by Henri Yandell <ba...@generationjava.com>.
> > [X] +1 Release dbtags-1.0.0
> > [ ] -0 Do not release, please explain why
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: [vote] dbtags 1.0.0 and random 1.0.2
Posted by "Delagrange, Morgan" <md...@yahoo.com>.
- Morgan
>
> [X] +1 Release dbtags-1.0.0
> [ ] -0 Do not release, please explain why
>
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org