[proposal] Unstandard Taglib creation/release (and future of Taglibs)

[Henri Yandell <fl...@gmail.com>]

Based on the Taglibs future email a while back, it sounds like we
might have some number of people interested in working on things.
Here's a proposal for a general direction:


1) Taglibs contains three active items:

* Standard 1.1 (1.0 being considered an older, unsupported release).
* Unstandard - containing a merger of all useful parts of the other Taglibs.
* RDC.

3) Merge the following into Unstandard. Then retire them.

* Log. Tempted to dump commons-logging from trunk and have two log
taglibs, one for log4j and one for jdk logging.
* DateTime. JSTL replaces this, but before we retire it we should
investigate for snippets for Unstandard.
* i18n. Same as DateTime.
* JNDI. Be interesting to see if there's anything we could grab from this.
* Random. Maybe something for Unstandard. Overlap with String.
* Regexp. We should investigate whether any of its bits are worth
rewriting on top of JDK 1.4 for Unstandard.
* String. Hesistant to push too much of what's in here into
Unstandard, but a few
might be worth it.


2) Retire the following:

* DataGrid. Better to work well with and recommend DisplayTag.
* Benchmark. Not a big enough deal.
* BSF. I wonder if we should offer this over to the BSF project?
* Cache. This was never released and should still be in the sandbox.
* Input. I don't think anyone is using this anymore.
* IO. This stuff should be done in Java imo.
* JMS. Messenger was never released. Again, this should be in Java.
* Mailer. This is a tough one, users bring it up, and find problems.
I'd rather see people being encouraged to work with commons-email with
a templating language and dropping this.
* Scrape. Best done in Java methinks.
* XTags. Not used enough.
* Ultradev. I'm sure this is ages out of date.
* Image. Better as an API, which I think Abey had somewhere.
* Mailer2. I'm still not sure about email from jsp pages :) Again,
commons-email.

Also all the Deprecated's should be Retired.

Thoughts?

Hen

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

Re: [proposal] Unstandard Taglib creation/release (and future of Taglibs)

[Rahul Akolkar <ra...@gmail.com>]

On 5/21/07, Henri Yandell <fl...@gmail.com> wrote:
<snip/>
>
> Immediate anything else thoughts....
>
> Can we move to JIRA? :)
> We need to retire the components in bugzilla so people don't report
> issues against them there (there's always the mailing list).
>
> We'll need to update the unstandard build significantly to support
> multiple taglibs.
>
<snap/>

Multi-module m2 builds -- for example, unstandard will have n modules
(jar packaging) for n taglibs + 1 for examples (war) + 1 for docs
(war).

-Rahul


> Hen
>

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

Re: [proposal] Unstandard Taglib creation/release (and future of Taglibs)

[Henri Yandell <fl...@gmail.com>]

On 5/21/07, Henri Yandell <fl...@gmail.com> wrote:
> On 5/16/07, Henri Yandell <fl...@gmail.com> wrote:
> > Based on the Taglibs future email a while back, it sounds like we
> > might have some number of people interested in working on things.
>
> Summarizing:
>
> Four 'volunteers' so far:
>
> Martin, Rahul, Kris, myself.
>
> It sounds like we're all of a consensus on there being three
> subprojects: Standard 1.1, Unstandard, RDC. Unstandard might need a
> new name.
>
> We'll retire Standard 1.0, DataGrid, Benchmark, BSF, Cache, IO, JMS,
> Mailer, Mailer2, Scrape, XTags, Ultradev, Image, Random; and anything
> deprecated.
>
> Unstandard will pick and choose from Log, DateTime, i18n, JNDI,
> Regexp, String, Input then they will be retired.
>
> ---
>
> Next steps seem to be:
>
> 1) Retire things
> 2) Discuss Unstandard
>
> On the retiring process, it seems that we need to:
>
> 1) Update the website nav moving to 'retired'
> 2) Update the individual websites saying that they're retired.
> 3) Move from proper -> retired in svn; and remove from the svn:externals.
>
> Anything else?

Immediate anything else thoughts....

Can we move to JIRA? :)
We need to retire the components in bugzilla so people don't report
issues against them there (there's always the mailing list).

We'll need to update the unstandard build significantly to support
multiple taglibs.

Hen

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

Re: [proposal] Unstandard Taglib creation/release (and future of Taglibs)

[Henri Yandell <fl...@gmail.com>]

More old threads.

Here we chose to retire random. That didn't get done (though Input did
get retired).

So planning to also deprecate Random.

Hen

On Mon, May 21, 2007 at 11:18 AM, Henri Yandell <fl...@gmail.com> wrote:
> On 5/16/07, Henri Yandell <fl...@gmail.com> wrote:
>>
>> Based on the Taglibs future email a while back, it sounds like we
>> might have some number of people interested in working on things.
>
> Summarizing:
>
> Four 'volunteers' so far:
>
> Martin, Rahul, Kris, myself.
>
> It sounds like we're all of a consensus on there being three
> subprojects: Standard 1.1, Unstandard, RDC. Unstandard might need a
> new name.
>
> We'll retire Standard 1.0, DataGrid, Benchmark, BSF, Cache, IO, JMS,
> Mailer, Mailer2, Scrape, XTags, Ultradev, Image, Random; and anything
> deprecated.
>
> Unstandard will pick and choose from Log, DateTime, i18n, JNDI,
> Regexp, String, Input then they will be retired.
>
> ---
>
> Next steps seem to be:
>
> 1) Retire things
> 2) Discuss Unstandard
>
> On the retiring process, it seems that we need to:
>
> 1) Update the website nav moving to 'retired'
> 2) Update the individual websites saying that they're retired.
> 3) Move from proper -> retired in svn; and remove from the svn:externals.
>
> Anything else?
>
> Hen
>

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

Re: [proposal] Unstandard Taglib creation/release (and future of Taglibs)

[Martin van den Bemt <ml...@mvdb.net>]

Isn't that enough for TLP ? ;)

Mvgr,
Martin

Henri Yandell wrote:
> On 5/16/07, Henri Yandell <fl...@gmail.com> wrote:
>> Based on the Taglibs future email a while back, it sounds like we
>> might have some number of people interested in working on things.
> 
> Summarizing:
> 
> Four 'volunteers' so far:
> 
> Martin, Rahul, Kris, myself.
> 
> It sounds like we're all of a consensus on there being three
> subprojects: Standard 1.1, Unstandard, RDC. Unstandard might need a
> new name.
> 
> We'll retire Standard 1.0, DataGrid, Benchmark, BSF, Cache, IO, JMS,
> Mailer, Mailer2, Scrape, XTags, Ultradev, Image, Random; and anything
> deprecated.
> 
> Unstandard will pick and choose from Log, DateTime, i18n, JNDI,
> Regexp, String, Input then they will be retired.
> 
> ---
> 
> Next steps seem to be:
> 
> 1) Retire things
> 2) Discuss Unstandard
> 
> On the retiring process, it seems that we need to:
> 
> 1) Update the website nav moving to 'retired'
> 2) Update the individual websites saying that they're retired.
> 3) Move from proper -> retired in svn; and remove from the svn:externals.
> 
> Anything else?
> 
> Hen
> 
> ---------------------------------------------------------------------
> 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: [proposal] Unstandard Taglib creation/release (and future of Taglibs)

[Kris Schneider <kr...@dotech.com>]

Henri Yandell wrote:
> On 5/21/07, Karl von Randow <ka...@xk72.com> wrote:
> 
>> Henri Yandell wrote:
>> >
>> > Four 'volunteers' so far:
>> >
>> > Martin, Rahul, Kris, myself.
>>
>> me too
> 
> 
> Oops - mental slip. I meant Karl rather than Kris.
> 
> Kris, you up for any of this?

Absolutely. I think someone else mentioned looking at Unstandard for 
opportunities to provide EL functions instead of just tags. I've got a 
handful of functions that I've been carting around to the various projects 
I've been working on and I think they're generic enough to be useful. Oh, 
I'm also up for just focusing on JSP 2.0 - I think Unstandard is currently 
focused on JSP 1.2 (it does its own EL eval). One other thing - someone 
else had talked about compiling against various JDK version, but we have a 
commitment to meet the requirements of whatever spec version we're 
targeting. For example, I think JSP 2.0 still supports JDK 1.3.1, so, IMHO, 
that's what we need to compile against and distribute...at a minimum. Not 
very sexy, but there it is. Of course, there's nothing stopping us from 
providing alternate version compiled against 1.4.2, 1.5.0, etc. Although, 
that's one of the reasons to provide source code...

> Hen

-- 
Kris Schneider <ma...@dotech.com>
D.O.Tech       <http://www.dotech.com/>

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

Re: [proposal] Unstandard Taglib creation/release (and future of Taglibs)

[Henri Yandell <fl...@gmail.com>]

On 5/21/07, Karl von Randow <ka...@xk72.com> wrote:
> Henri Yandell wrote:
> >
> > Four 'volunteers' so far:
> >
> > Martin, Rahul, Kris, myself.
>
> me too

Oops - mental slip. I meant Karl rather than Kris.

Kris, you up for any of this?

Hen

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

Re: [proposal] Unstandard Taglib creation/release (and future of Taglibs)

[Karl von Randow <ka...@xk72.com>]

Henri Yandell wrote:
>
> Four 'volunteers' so far:
>
> Martin, Rahul, Kris, myself.

me too


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

Re: [proposal] Unstandard Taglib creation/release (and future of Taglibs)

[Henri Yandell <fl...@gmail.com>]

On 5/16/07, Henri Yandell <fl...@gmail.com> wrote:
> Based on the Taglibs future email a while back, it sounds like we
> might have some number of people interested in working on things.

Summarizing:

Four 'volunteers' so far:

Martin, Rahul, Kris, myself.

It sounds like we're all of a consensus on there being three
subprojects: Standard 1.1, Unstandard, RDC. Unstandard might need a
new name.

We'll retire Standard 1.0, DataGrid, Benchmark, BSF, Cache, IO, JMS,
Mailer, Mailer2, Scrape, XTags, Ultradev, Image, Random; and anything
deprecated.

Unstandard will pick and choose from Log, DateTime, i18n, JNDI,
Regexp, String, Input then they will be retired.

---

Next steps seem to be:

1) Retire things
2) Discuss Unstandard

On the retiring process, it seems that we need to:

1) Update the website nav moving to 'retired'
2) Update the individual websites saying that they're retired.
3) Move from proper -> retired in svn; and remove from the svn:externals.

Anything else?

Hen

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

Re: [proposal] Unstandard Taglib creation/release (and future of Taglibs)

[Rahul Akolkar <ra...@gmail.com>]

On 5/19/07, Karl von Randow <ka...@xk72.com> wrote:
> Rahul Akolkar wrote:
> > Karl -
> >
> > Your email below is not subscribed, so needs moderation ATM (I'll
> > respond to the content of this thread later).
> Sorry, I repeatedly forget to switch to my subscribed address before
> sending - I hit Cancel while it's sending but I did wonder if it was in
> time. I'm working on getting the point of realisation a little earlier
> in the process.
>
<snip/>

Don't worry about it, post away :-)

-Rahul


> cheers,
> Karl
>

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

Re: [proposal] Unstandard Taglib creation/release (and future of Taglibs)

[Karl von Randow <ka...@xk72.com>]

Rahul Akolkar wrote:
> Karl -
>
> Your email below is not subscribed, so needs moderation ATM (I'll
> respond to the content of this thread later).
Sorry, I repeatedly forget to switch to my subscribed address before 
sending - I hit Cancel while it's sending but I did wonder if it was in 
time. I'm working on getting the point of realisation a little earlier 
in the process.

cheers,
Karl

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

Re: [proposal] Unstandard Taglib creation/release (and future of Taglibs)

[Rahul Akolkar <ra...@gmail.com>]

On 5/18/07, Martin Cooper <ma...@apache.org> wrote:
> On 5/18/07, Rahul Akolkar <ra...@gmail.com> wrote:
> >
> > Karl -
> >
> > Your email below is not subscribed, so needs moderation ATM
>
>
> Next time you moderate him through, just do a Reply-All instead of a Reply
> and his address will be 'allow'ed to post to the list in the future without
> moderation.
>
<snip/>

Thats what I did to Karl's apache.org email to let the commit messages
through, but I wasn't sure if being a little more conservative on
other emails made any sense. Having had a chance to think about it, it
doesn't (for known people atleast).

-Rahul


> --
> Martin Cooper
>
<snap/>

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

Re: [proposal] Unstandard Taglib creation/release (and future of Taglibs)

[Martin Cooper <ma...@apache.org>]

On 5/18/07, Rahul Akolkar <ra...@gmail.com> wrote:
>
> Karl -
>
> Your email below is not subscribed, so needs moderation ATM


Next time you moderate him through, just do a Reply-All instead of a Reply
and his address will be 'allow'ed to post to the list in the future without
moderation.

--
Martin Cooper


(I'll
> respond to the content of this thread later).
>
> -Rahul
>
>
> On 5/17/07, Karl von Randow <ka...@cactuslab.com> wrote:
> > Henri Yandell wrote:
> > >
> > > I think...
> > >
> > > a) Agree on the breakdown of taglibs from above (ie: decide on what
> > > we're going to use as input for the taglib, and what maintenance tasks
> > > we need to do to move those to inactive)
> > > b) As a part of that deciding; we'll learn who 'we' is :)
> > Sounds good to me. Let's have a good old hands-up who is interested in
> > participating, then perhaps after the weekend we'll regroup and break
> > out the red pens. Things can always be resurrected if we're a little
> > hasty; I think we'd all be surprised and pleased if there was any kind
> > of haste in this project anyway!
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
>
>

Re: [proposal] Unstandard Taglib creation/release (and future of Taglibs)

[Rahul Akolkar <ra...@gmail.com>]

Karl -

Your email below is not subscribed, so needs moderation ATM (I'll
respond to the content of this thread later).

-Rahul


On 5/17/07, Karl von Randow <ka...@cactuslab.com> wrote:
> Henri Yandell wrote:
> >
> > I think...
> >
> > a) Agree on the breakdown of taglibs from above (ie: decide on what
> > we're going to use as input for the taglib, and what maintenance tasks
> > we need to do to move those to inactive)
> > b) As a part of that deciding; we'll learn who 'we' is :)
> Sounds good to me. Let's have a good old hands-up who is interested in
> participating, then perhaps after the weekend we'll regroup and break
> out the red pens. Things can always be resurrected if we're a little
> hasty; I think we'd all be surprised and pleased if there was any kind
> of haste in this project anyway!
>

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

Re: [proposal] Unstandard Taglib creation/release (and future of Taglibs)

[Karl von Randow <ka...@cactuslab.com>]

Henri Yandell wrote:
>
> I think...
>
> a) Agree on the breakdown of taglibs from above (ie: decide on what
> we're going to use as input for the taglib, and what maintenance tasks
> we need to do to move those to inactive)
> b) As a part of that deciding; we'll learn who 'we' is :)
Sounds good to me. Let's have a good old hands-up who is interested in 
participating, then perhaps after the weekend we'll regroup and break 
out the red pens. Things can always be resurrected if we're a little 
hasty; I think we'd all be surprised and pleased if there was any kind 
of haste in this project anyway!

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

Re: [proposal] Unstandard Taglib creation/release (and future of Taglibs)

[Henri Yandell <fl...@gmail.com>]

On 5/17/07, Karl von Randow <ka...@xk72.com> wrote:
> Henri Yandell wrote:
> > On 5/16/07, Karl von Randow <ka...@xk72.com> wrote:
> >> Great. Yeah, that sounds reasonable. So once the chaff is cut from the
> >> taglibs project, what "is" unstandard?
> >
> > It's the things that would be in JSTL if it was an open source project
> > and not tied to a spec.
> >
> > Probably not the best name. It was a cheeky/quirky thing I kicked off
> > when JSTL came out based on things that new JSTL users were asking
> > for.
> You're right: it's what you need as a companion to Standard to make JSP
> development better... all the things that you'd like to do without
> writing scriptlets or beans. So in that sense a name that is tied to
> Standard makes very good sense.
>
> The changes I committed to <input> last month bring it up to a very
> usable level and are quite extended from the previous version (backwards
> compatible, though) so it would make sense to release it on the back of
> a new "unstandard" platform.
>
> So let's get cracking. What do we need to do? (with the caveat that we
> all have no time, but at least we can have a plan).

I think...

a) Agree on the breakdown of taglibs from above (ie: decide on what
we're going to use as input for the taglib, and what maintenance tasks
we need to do to move those to inactive)
b) As a part of that deciding; we'll learn who 'we' is :)

Hen

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

Re: [proposal] Unstandard Taglib creation/release (and future of Taglibs)

[Karl von Randow <ka...@xk72.com>]

Henri Yandell wrote:
> On 5/16/07, Karl von Randow <ka...@xk72.com> wrote:
>> Great. Yeah, that sounds reasonable. So once the chaff is cut from the
>> taglibs project, what "is" unstandard?
>
> It's the things that would be in JSTL if it was an open source project
> and not tied to a spec.
>
> Probably not the best name. It was a cheeky/quirky thing I kicked off
> when JSTL came out based on things that new JSTL users were asking
> for.
You're right: it's what you need as a companion to Standard to make JSP 
development better... all the things that you'd like to do without 
writing scriptlets or beans. So in that sense a name that is tied to 
Standard makes very good sense.

The changes I committed to <input> last month bring it up to a very 
usable level and are quite extended from the previous version (backwards 
compatible, though) so it would make sense to release it on the back of 
a new "unstandard" platform.

So let's get cracking. What do we need to do? (with the caveat that we 
all have no time, but at least we can have a plan).

cheers,
Karl

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

Re: [proposal] Unstandard Taglib creation/release (and future of Taglibs)

[Henri Yandell <fl...@gmail.com>]

On 5/16/07, Karl von Randow <ka...@xk72.com> wrote:
> Henri Yandell wrote:
> > Had a vague memory it might be - but always best to bid low as such
> > and force activity :) Sounds like one to look at including in
> > Unstandard. By merging the small taglibs together I think we can get
> > enough overlap to increase activity.
> Great. Yeah, that sounds reasonable. So once the chaff is cut from the
> taglibs project, what "is" unstandard?

It's the things that would be in JSTL if it was an open source project
and not tied to a spec.

> Is it just a bundle of what's
> left? I imagine that the intention is that the tag libraries would still
> have separate URIs and thus separate prefixes when in use, so
> "unstandard" is just a brand that we put on the collection of tag
> libraries and presumably they can all be downloaded together as one jar.

I guess so. JSTL has multiple tag libraries; so it would make sense to
do the same here.

Ideally we will have libraries that match the JSTL libraries, and
extra ones. What's currently in Unstandard would probably be something
for 'core' etc, but we would still have a 'log' one.

> Is "unstandard" the best name for what this is? I'm not sure if that's
> the final name or just a place-holder. It feels pejorative and
> cheeky/quirky at the same time; I like the later and dislike the former
> so I raise it as a potential discussion issue. Perhaps once we see
> clearly what might be included in the package it would be a better time
> to revisit it.

Probably not the best name. It was a cheeky/quirky thing I kicked off
when JSTL came out based on things that new JSTL users were asking
for.

Hen

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

Re: [proposal] Unstandard Taglib creation/release (and future of Taglibs)

[Karl von Randow <ka...@xk72.com>]

Henri Yandell wrote:
> Had a vague memory it might be - but always best to bid low as such
> and force activity :) Sounds like one to look at including in
> Unstandard. By merging the small taglibs together I think we can get
> enough overlap to increase activity.
Great. Yeah, that sounds reasonable. So once the chaff is cut from the 
taglibs project, what "is" unstandard? Is it just a bundle of what's 
left? I imagine that the intention is that the tag libraries would still 
have separate URIs and thus separate prefixes when in use, so 
"unstandard" is just a brand that we put on the collection of tag 
libraries and presumably they can all be downloaded together as one jar.

Is "unstandard" the best name for what this is? I'm not sure if that's 
the final name or just a place-holder. It feels pejorative and 
cheeky/quirky at the same time; I like the later and dislike the former 
so I raise it as a potential discussion issue. Perhaps once we see 
clearly what might be included in the package it would be a better time 
to revisit it.

cheers,
Karl

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

Re: [proposal] Unstandard Taglib creation/release (and future of Taglibs)

[Henri Yandell <fl...@gmail.com>]

On 5/16/07, Karl von Randow <ka...@xk72.com> wrote:
> Henri Yandell wrote:
> >
> > * Input. I don't think anyone is using this anymore.
> >
> On the Input tag library:
>
> I've committed a whole bag of fixes and improvements recently and I
> think it is still a useful library. I have had several email exchanges
> regarding the changes so I think there are people out there are using it.
>
> It suffers from the same problem as the other tag libraries: too small
> to make much noise about, potentially quite useful and solves a problem
> in an unobtrusive way (ie. it's not part of a framework). Because
> they're small there's not much reason for people to enthuse about them,
> or perhaps even opportunity to find out about them.
>
> I believe that the input tag library solves a useful problem and as such
> is worth hanging on to - so I request that it remains on the list or at
> least a part of unstandard.

Had a vague memory it might be - but always best to bid low as such
and force activity :) Sounds like one to look at including in
Unstandard. By merging the small taglibs together I think we can get
enough overlap to increase activity.

Hen

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

Re: [proposal] Unstandard Taglib creation/release (and future of Taglibs)

[Karl von Randow <ka...@xk72.com>]

Henri Yandell wrote:
>
> * Input. I don't think anyone is using this anymore.
>
On the Input tag library:

I've committed a whole bag of fixes and improvements recently and I 
think it is still a useful library. I have had several email exchanges 
regarding the changes so I think there are people out there are using it.

It suffers from the same problem as the other tag libraries: too small 
to make much noise about, potentially quite useful and solves a problem 
in an unobtrusive way (ie. it's not part of a framework). Because 
they're small there's not much reason for people to enthuse about them, 
or perhaps even opportunity to find out about them.

I believe that the input tag library solves a useful problem and as such 
is worth hanging on to - so I request that it remains on the list or at 
least a part of unstandard.

cheers,
Karl

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

Re: [proposal] Unstandard Taglib creation/release (and future of Taglibs)

[Rahul Akolkar <ra...@gmail.com>]

On 5/19/07, Karl von Randow <ka...@xk72.com> wrote:
> Rahul Akolkar wrote:
> > On 5/18/07, Henri Yandell <fl...@gmail.com> wrote:
> >> >
> >> > I like the idea of lumping the various pieces we want to keep into
> >> a single
> >> > jar, a la JSTL. One thing, though: Wouldn't we want to ensure that
> >> all of
> >> > the pieces in that jar are EL-enabled? Have some enabled and some
> >> not would
> >> > be funky, to say the least. (But then we could be in good shape
> >> here and I
> >> > just don't know it.)
> >>
> >> Absolutely. I'm thinking more that we would refactor things utterly
> >> and assume 2.4/2.0. That makes the EL stuff easier doesn't it?
> >>
> > Yes, and I've been a 2.0 proponent for a while, where we can (even tag
> > files etc.).
> I actually still have some cause to build applications pre 2.0 so I'd
> like to retain pre-support if possible... cf. I get a bit frustrated by
> Java projects that are compiled 1.5 when they could be compiled pre-1.5
> compatible.
>
<snip/>

I think that adds another axis of complexity (since at some point
we'll want to have a 2.0 worthy release to stay reasonably current).
However, if there are still volunteers for a pre 2.0 distro, so be it.

-Rahul


> Isn't every tag library EL-enabled in 2.0 as long as it has rtexpr
> allowed? By EL-enabled do you mean similar to the EL / RT flavour tab
> libraries that JSTL has (had?)? I would be in favour of that approach,
> except perhaps it isn't necessary if most people are going to be 2.0+
> and no need it, and those of us still deploying pre-2.0 never had EL
> support in the tag libaries anyway...
>
> cheers,
> Karl
>

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

Re: [proposal] Unstandard Taglib creation/release (and future of Taglibs)

[Karl von Randow <ka...@xk72.com>]

Rahul Akolkar wrote:
> On 5/18/07, Henri Yandell <fl...@gmail.com> wrote:
>> >
>> > I like the idea of lumping the various pieces we want to keep into 
>> a single
>> > jar, a la JSTL. One thing, though: Wouldn't we want to ensure that 
>> all of
>> > the pieces in that jar are EL-enabled? Have some enabled and some 
>> not would
>> > be funky, to say the least. (But then we could be in good shape 
>> here and I
>> > just don't know it.)
>>
>> Absolutely. I'm thinking more that we would refactor things utterly
>> and assume 2.4/2.0. That makes the EL stuff easier doesn't it?
>>
> Yes, and I've been a 2.0 proponent for a while, where we can (even tag
> files etc.).
I actually still have some cause to build applications pre 2.0 so I'd 
like to retain pre-support if possible... cf. I get a bit frustrated by 
Java projects that are compiled 1.5 when they could be compiled pre-1.5 
compatible.

Isn't every tag library EL-enabled in 2.0 as long as it has rtexpr 
allowed? By EL-enabled do you mean similar to the EL / RT flavour tab 
libraries that JSTL has (had?)? I would be in favour of that approach, 
except perhaps it isn't necessary if most people are going to be 2.0+ 
and no need it, and those of us still deploying pre-2.0 never had EL 
support in the tag libaries anyway...

cheers,
Karl

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

Re: [proposal] Unstandard Taglib creation/release (and future of Taglibs)

[Rahul Akolkar <ra...@gmail.com>]

On 5/18/07, Henri Yandell <fl...@gmail.com> wrote:
> On 5/18/07, Martin Cooper <ma...@apache.org> wrote:
<snip/>
> >
> > I like the idea of lumping the various pieces we want to keep into a single
> > jar, a la JSTL. One thing, though: Wouldn't we want to ensure that all of
> > the pieces in that jar are EL-enabled? Have some enabled and some not would
> > be funky, to say the least. (But then we could be in good shape here and I
> > just don't know it.)
>
> Absolutely. I'm thinking more that we would refactor things utterly
> and assume 2.4/2.0. That makes the EL stuff easier doesn't it?
>
<snap/>

Yes, and I've been a 2.0 proponent for a while, where we can (even tag
files etc.).

-Rahul


> Hen
>

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

Re: [proposal] Unstandard Taglib creation/release (and future of Taglibs)

[Henri Yandell <fl...@gmail.com>]

On 5/18/07, Martin Cooper <ma...@apache.org> wrote:
> On 5/16/07, Henri Yandell <fl...@gmail.com> wrote:
> >
> > Based on the Taglibs future email a while back, it sounds like we
> > might have some number of people interested in working on things.
> > Here's a proposal for a general direction:
> >
> >
> > 1) Taglibs contains three active items:
> >
> > * Standard 1.1 (1.0 being considered an older, unsupported release).
> > * Unstandard - containing a merger of all useful parts of the other
> > Taglibs.
> > * RDC.
> >
> > 3) Merge the following into Unstandard. Then retire them.
> >
> > * Log. Tempted to dump commons-logging from trunk and have two log
> > taglibs, one for log4j and one for jdk logging.
> > * DateTime. JSTL replaces this, but before we retire it we should
> > investigate for snippets for Unstandard.
> > * i18n. Same as DateTime.
> > * JNDI. Be interesting to see if there's anything we could grab from this.
> > * Random. Maybe something for Unstandard. Overlap with String.
>
>
> I can't say I've ever understood what this is useful for. Personally, I'd be
> for adding it to the 'retire' list.
>
> * Regexp. We should investigate whether any of its bits are worth
> > rewriting on top of JDK 1.4 for Unstandard.
> > * String. Hesistant to push too much of what's in here into
> > Unstandard, but a few
> > might be worth it.
>
>
> Much of this stuff would be a more natural fit into the JSTL world if it was
> in the form of EL functions. Not sure if anyone would actually be up for the
> work to convert them, though.
>
> 2) Retire the following:
> >
> > * DataGrid. Better to work well with and recommend DisplayTag.
> > * Benchmark. Not a big enough deal.
> > * BSF. I wonder if we should offer this over to the BSF project?
> > * Cache. This was never released and should still be in the sandbox.
> > * Input. I don't think anyone is using this anymore.
> > * IO. This stuff should be done in Java imo.
> > * JMS. Messenger was never released. Again, this should be in Java.
> > * Mailer. This is a tough one, users bring it up, and find problems.
> > I'd rather see people being encouraged to work with commons-email with
> > a templating language and dropping this.
>
>
> Funny you should mention that. When I worked on Mailer (several years and
> two companies ago), it was because we were using JSP as the template
> language you mention. ;-) Ultimately that wasn't a great idea, though.
>
> * Scrape. Best done in Java methinks.
> > * XTags. Not used enough.
> > * Ultradev. I'm sure this is ages out of date.
> > * Image. Better as an API, which I think Abey had somewhere.
> > * Mailer2. I'm still not sure about email from jsp pages :) Again,
> > commons-email.
>
>
> Yeah.
>
> Also all the Deprecated's should be Retired.
> >
> > Thoughts?
>
>
> I like the idea of lumping the various pieces we want to keep into a single
> jar, a la JSTL. One thing, though: Wouldn't we want to ensure that all of
> the pieces in that jar are EL-enabled? Have some enabled and some not would
> be funky, to say the least. (But then we could be in good shape here and I
> just don't know it.)

Absolutely. I'm thinking more that we would refactor things utterly
and assume 2.4/2.0. That makes the EL stuff easier doesn't it?

Hen

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

Re: [proposal] Unstandard Taglib creation/release (and future of Taglibs)

[Martin Cooper <ma...@apache.org>]

On 5/16/07, Henri Yandell <fl...@gmail.com> wrote:
>
> Based on the Taglibs future email a while back, it sounds like we
> might have some number of people interested in working on things.
> Here's a proposal for a general direction:
>
>
> 1) Taglibs contains three active items:
>
> * Standard 1.1 (1.0 being considered an older, unsupported release).
> * Unstandard - containing a merger of all useful parts of the other
> Taglibs.
> * RDC.
>
> 3) Merge the following into Unstandard. Then retire them.
>
> * Log. Tempted to dump commons-logging from trunk and have two log
> taglibs, one for log4j and one for jdk logging.
> * DateTime. JSTL replaces this, but before we retire it we should
> investigate for snippets for Unstandard.
> * i18n. Same as DateTime.
> * JNDI. Be interesting to see if there's anything we could grab from this.
> * Random. Maybe something for Unstandard. Overlap with String.


I can't say I've ever understood what this is useful for. Personally, I'd be
for adding it to the 'retire' list.

* Regexp. We should investigate whether any of its bits are worth
> rewriting on top of JDK 1.4 for Unstandard.
> * String. Hesistant to push too much of what's in here into
> Unstandard, but a few
> might be worth it.


Much of this stuff would be a more natural fit into the JSTL world if it was
in the form of EL functions. Not sure if anyone would actually be up for the
work to convert them, though.

2) Retire the following:
>
> * DataGrid. Better to work well with and recommend DisplayTag.
> * Benchmark. Not a big enough deal.
> * BSF. I wonder if we should offer this over to the BSF project?
> * Cache. This was never released and should still be in the sandbox.
> * Input. I don't think anyone is using this anymore.
> * IO. This stuff should be done in Java imo.
> * JMS. Messenger was never released. Again, this should be in Java.
> * Mailer. This is a tough one, users bring it up, and find problems.
> I'd rather see people being encouraged to work with commons-email with
> a templating language and dropping this.


Funny you should mention that. When I worked on Mailer (several years and
two companies ago), it was because we were using JSP as the template
language you mention. ;-) Ultimately that wasn't a great idea, though.

* Scrape. Best done in Java methinks.
> * XTags. Not used enough.
> * Ultradev. I'm sure this is ages out of date.
> * Image. Better as an API, which I think Abey had somewhere.
> * Mailer2. I'm still not sure about email from jsp pages :) Again,
> commons-email.


Yeah.

Also all the Deprecated's should be Retired.
>
> Thoughts?


I like the idea of lumping the various pieces we want to keep into a single
jar, a la JSTL. One thing, though: Wouldn't we want to ensure that all of
the pieces in that jar are EL-enabled? Have some enabled and some not would
be funky, to say the least. (But then we could be in good shape here and I
just don't know it.)

--
Martin Cooper


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