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 Henri Yandell <ba...@generationjava.com> on 2002/09/11 15:37:04 UTC
[String] stablizing release
I'm at a touch of a quandry.
String taglib is dependent on Commons Lang, and I want to avoid releasing
String until there is a Lang release.
So lots of users are dependent on the nightly build of String.
I want to make some, not massive, but substantial changes to the taglib's
API, and also to make an attempt at adding JEL to it. I don't want to
'break' on customers though.
What I'm considering is some form of stable release, calling it a beta
feels bad, but that's what it would be, a 1.0-b1, prior to making changes
for a 1.0-b2, which would then hopefully mature to a 1.0 release.
Before I call a vote on it, does anyone have any advice about other ways
to do this etc?
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [String] stablizing release
Posted by Henri Yandell <ba...@generationjava.com>.
Definitely a milestone then.
I'm going to be throwing away a lot of tags, ie)
upperCase, lowerCase, capitalise, capitaliseAllWords, uncapitlaise all
roll into the <case> tag.
There are people who will be in pain if they find out that they've
suddenly been upgraded and that all the nightly's now have the new code,
so I want to make the old bits available, but I don't want to have a 1.1
that has to worry itself heavily about backwards compatibility.
Hen
On Fri, 13 Sep 2002, Glenn Nielsen wrote:
> Henri Yandell wrote:
> > Hey Glenn,
> >
> > I'm not planning the JSTL stuff immediately, just some refactoring of tags
> > and a few additions, so I'd like to go and make a stable release of the
> > CVS soon. My sandbox is starting to get quite different. Do you think a
> > milestone as Shawn suggested, or a beta?
> >
>
> A milestone means that not all features have been implemented.
> A beta means that all features are implemented but the release isn't
> considered production quality yet.
>
> So it depends on the state of the String taglib.
>
> You could do a 1.0 beta release of the String taglib with its current
> features, then if there are no bugs do an official 1.0 release a few
> weeks later.
>
> Any new features for the String taglib could be in a 1.1 release.
>
> We really need to get better at having official stable releases of the
> taglibs. Many won't consider using something if it hasn't had an
> official release.
>
> > Basically I aim to have a stable jar built, placed in the releases dir,
> > hooked up to the site, and then I'll throw a bunch of tags out of
> > CVS and merge them. A kind of tag-name normalisation.
> >
> > What's the process with Taglib deploying? Do you admin them and handle the
> > builds, or is it easier for you if I learn how to do so?
> >
>
> Follow the instructions at:
>
> http://jakarta.apache.org/taglibs/addtaglib.html
>
> This will help you get the taglib ready for release, I can do the
> final steps to build and publish the release.
>
> Regards,
>
> Glenn
>
> > Thanks,
> >
> > Hen
> >
> > On Wed, 11 Sep 2002, Glenn Nielsen wrote:
> >
> >
> >>I would suggest a beta release of the current code. I can help do this.
> >>Once commons-lang is released we can do the final release.
> >>
> >>JSTL requires JSP 1.2, the current String taglib works in JSP 1.1, right?
> >>
> >>I would suggest a new String taglib, perhaps STLString which adds
> >>support for JSTL and requires JSP 1.2. And leave the current String
> >>taglib as a JSP 1.1 compatible version.
> >>
> >>That would work better within the current build system.
> >>
> >>Regards,
> >>
> >>Glenn
> >>
> >>Henri Yandell wrote:
> >>
> >>>I'm at a touch of a quandry.
> >>>
> >>>String taglib is dependent on Commons Lang, and I want to avoid releasing
> >>>String until there is a Lang release.
> >>>
> >>>So lots of users are dependent on the nightly build of String.
> >>>
> >>>I want to make some, not massive, but substantial changes to the taglib's
> >>>API, and also to make an attempt at adding JEL to it. I don't want to
> >>>'break' on customers though.
> >>>
> >>>What I'm considering is some form of stable release, calling it a beta
> >>>feels bad, but that's what it would be, a 1.0-b1, prior to making changes
> >>>for a 1.0-b2, which would then hopefully mature to a 1.0 release.
> >>>
> >>>Before I call a vote on it, does anyone have any advice about other ways
> >>>to do this etc?
> >>>
> >>>Hen
> >>>
> >>>
> >>>--
> >>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> >>>For additional commands, e-mail: <ma...@jakarta.apache.org>
> >>
> >>
> >>
> >>
> >>--
> >>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> >>For additional commands, e-mail: <ma...@jakarta.apache.org>
> >>
> >>
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
XTags Question
Posted by Tod Thomas <tt...@chubb.com>.
I'm using the XTags style tag like so:
<xtags:style
xml="http://localhost/cgi-bin/test.cgi"
xsl="/xml/ldap.xsl"
outputMethod="html"/>
test.cgi performs a search and streams the results back as XML which
transforms to HTML as expected. When I try to use this:
<xtags:style
xml="http://localhost/cgi-bin/test2.cgi?base=directory&scope=sub&filter=cn=smith"
xsl="/xml/ldap.xsl"
outputMethod="html"/>
it fails. I've tried encoding the passed URL and that fails too.
Should this work? Should I be using a form instead of trying to pass
everything in the URL? If not how can I get dynamic XML on the remote
server transformed and presented on the Tomcat server? Cocoon right now
is not an option.
Thanks - Tod.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
XTags Question - Please help
Posted by Tod Thomas <tt...@chubb.com>.
I posed this question a couple weeks ago and didn't' get a response.
I'm relatively new to this and just want to make sure I understand
conceptually how the XTags taglib is supposed to work.
What I'm getting from the docs is that I should be able to call a
remote, XML streaming, cgi program (or static xml page) and have it
transformed locally on the Tomcat server, rendering HTML to the client.
This works:
<xtags:style
xml="http://localhost/cgi-bin/test.cgi"
xsl="/xml/ldap.xsl"
outputMethod="html"/>
test.cgi performs a search and streams the results back as XML which
transforms to HTML as expected.
This doesn't:
<xtags:style
xml="http://localhost/cgi-bin/test2.cgi?base=directory&scope=sub&filter=cn=smith"
xsl="/xml/ldap.xsl"
outputMethod="html"/>
Is there another way I should be passing the environment variables to
test2.cgi rather than in the URL? Should this even work? Am I missing
something?
Thanks - Tod.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [String] stablizing release
Posted by Glenn Nielsen <gl...@mail.more.net>.
+1 also, the String taglib has been around for a while
Though never officially released I am sure many depend on it now.
Timothy Kettering wrote:
> Yeah. I agree that since Strings hasn't hit 1.0 there's no
> (technically) obligation to provide that functionality, after all beta
> software is subject to change, but I know I wouldn't be an happy camper
> if I found out that I had to scramble to find an obscure nightly build
> that would be the last build of the Strings Taglib Formerly Known As
> Strings, and carefully archive that if I had built an entire web
> application around it.
>
> My opinion would be: Put out 1.0 release based on the current form, just
> so that current users can have a final build to work with, then advise
> users that development on Strings in that form will no longer continue,
> and proceed with a 2.0 release with the refactored tags. Maybe it makes
> us just as bad as MS/Netscape in the version-incrementing game, but I
> think it's a lot more user-friendly that way than putting the whammy on
> a lot of very surprised users when they find out their "1.1" Strings
> taglib binary download reduced their web application to a smoking mess
> of "500 - Servlet Exception" pages.
>
> -tim
>
>
> On Friday, September 13, 2002, at 09:46 AM, Henri Yandell wrote:
>
>>
>> Issues here are that generally when you make a 1.0 release you are
>> entering a backwards compatbility contract [or frequent arguments].
>>
>> With the changes I'd like, having functionality in two places will be
>> very
>> painful for users, but having the ones they've coded against vanish will
>> be even worse.
>>
>> It's probably a development vs user issue. Until I see a 1.0, I don't
>> feel
>> obliged to users to worry about backwards compatibility, but I'm probably
>> just fooling myself :)
>>
>> I'm happy with a 1.0 [though it depends on a beta of commons-lang] and
>> then a 2.0, or a milestone-1, and then a 1.0.
>>
>> Hen
>>
>> On Fri, 13 Sep 2002, Tim Kettering wrote:
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [String] stablizing release
Posted by Timothy Kettering <ti...@mac.com>.
Yeah. I agree that since Strings hasn't hit 1.0 there's no
(technically) obligation to provide that functionality, after all beta
software is subject to change, but I know I wouldn't be an happy camper
if I found out that I had to scramble to find an obscure nightly build
that would be the last build of the Strings Taglib Formerly Known As
Strings, and carefully archive that if I had built an entire web
application around it.
My opinion would be: Put out 1.0 release based on the current form,
just so that current users can have a final build to work with, then
advise users that development on Strings in that form will no longer
continue, and proceed with a 2.0 release with the refactored tags.
Maybe it makes us just as bad as MS/Netscape in the
version-incrementing game, but I think it's a lot more user-friendly
that way than putting the whammy on a lot of very surprised users when
they find out their "1.1" Strings taglib binary download reduced their
web application to a smoking mess of "500 - Servlet Exception" pages.
-tim
On Friday, September 13, 2002, at 09:46 AM, Henri Yandell wrote:
>
> Issues here are that generally when you make a 1.0 release you are
> entering a backwards compatbility contract [or frequent arguments].
>
> With the changes I'd like, having functionality in two places will be
> very
> painful for users, but having the ones they've coded against vanish
> will
> be even worse.
>
> It's probably a development vs user issue. Until I see a 1.0, I don't
> feel
> obliged to users to worry about backwards compatibility, but I'm
> probably
> just fooling myself :)
>
> I'm happy with a 1.0 [though it depends on a beta of commons-lang] and
> then a 2.0, or a milestone-1, and then a 1.0.
>
> Hen
>
> On Fri, 13 Sep 2002, Tim Kettering wrote:
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [String] stablizing release
Posted by Henri Yandell <ba...@generationjava.com>.
Issues here are that generally when you make a 1.0 release you are
entering a backwards compatbility contract [or frequent arguments].
With the changes I'd like, having functionality in two places will be very
painful for users, but having the ones they've coded against vanish will
be even worse.
It's probably a development vs user issue. Until I see a 1.0, I don't feel
obliged to users to worry about backwards compatibility, but I'm probably
just fooling myself :)
I'm happy with a 1.0 [though it depends on a beta of commons-lang] and
then a 2.0, or a milestone-1, and then a 1.0.
Hen
On Fri, 13 Sep 2002, Tim Kettering wrote:
>
> Now that he mentions this, I like this idea. I think it would be a good
> idea to push out a 1.0 release based on the code we have now because it
> would offer a point release based on code that's known to be stable and has
> no current bugs on it (at least according to bugzilla). We can't really
> make that same promise immediately after we do the tags consolidation, so it
> appears to me that it would be a more pragmatic approach if we release a 1.0
> release based on the current code, then do the code consolidation.
>
> My only concern with this strategy is that since Hen's planning on some
> massive changes and consolidation of the tags to make it more streamlined,
> in other words, big changes in how the tags are named, and what attributes
> they will have, it appears to me that a "1.1" release wouldn�t accurately
> reflect what really happened, because there's a good chance any JSP pages
> written against the current version of Strings will break.
>
> To me, standard versioning convention would dictate that it should be a 2.0
> release. (Incompatible with code that was developed against previous
> versions of the Strings).
>
> Just my two cents,
>
> -tim
>
> > You could do a 1.0 beta release of the String taglib with its current
> > features, then if there are no bugs do an official 1.0 release a few
> > weeks later.
> >
> > Any new features for the String taglib could be in a 1.1 release.
> >
> > We really need to get better at having official stable releases of the
> > taglibs.
> > Many won't consider using something if it hasn't had an official release.
> >
>
> --
> Tim Kettering
> timster@mac.com
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [String] stablizing release
Posted by Tim Kettering <ti...@mac.com>.
Now that he mentions this, I like this idea. I think it would be a good
idea to push out a 1.0 release based on the code we have now because it
would offer a point release based on code that's known to be stable and has
no current bugs on it (at least according to bugzilla). We can't really
make that same promise immediately after we do the tags consolidation, so it
appears to me that it would be a more pragmatic approach if we release a 1.0
release based on the current code, then do the code consolidation.
My only concern with this strategy is that since Hen's planning on some
massive changes and consolidation of the tags to make it more streamlined,
in other words, big changes in how the tags are named, and what attributes
they will have, it appears to me that a "1.1" release wouldn¹t accurately
reflect what really happened, because there's a good chance any JSP pages
written against the current version of Strings will break.
To me, standard versioning convention would dictate that it should be a 2.0
release. (Incompatible with code that was developed against previous
versions of the Strings).
Just my two cents,
-tim
> You could do a 1.0 beta release of the String taglib with its current
> features, then if there are no bugs do an official 1.0 release a few
> weeks later.
>
> Any new features for the String taglib could be in a 1.1 release.
>
> We really need to get better at having official stable releases of the
> taglibs.
> Many won't consider using something if it hasn't had an official release.
>
--
Tim Kettering
timster@mac.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [String] stablizing release
Posted by Glenn Nielsen <gl...@mail.more.net>.
Henri Yandell wrote:
> Hey Glenn,
>
> I'm not planning the JSTL stuff immediately, just some refactoring of tags
> and a few additions, so I'd like to go and make a stable release of the
> CVS soon. My sandbox is starting to get quite different. Do you think a
> milestone as Shawn suggested, or a beta?
>
A milestone means that not all features have been implemented.
A beta means that all features are implemented but the release isn't
considered production quality yet.
So it depends on the state of the String taglib.
You could do a 1.0 beta release of the String taglib with its current
features, then if there are no bugs do an official 1.0 release a few
weeks later.
Any new features for the String taglib could be in a 1.1 release.
We really need to get better at having official stable releases of the taglibs.
Many won't consider using something if it hasn't had an official release.
> Basically I aim to have a stable jar built, placed in the releases dir,
> hooked up to the site, and then I'll throw a bunch of tags out of
> CVS and merge them. A kind of tag-name normalisation.
>
> What's the process with Taglib deploying? Do you admin them and handle the
> builds, or is it easier for you if I learn how to do so?
>
Follow the instructions at:
http://jakarta.apache.org/taglibs/addtaglib.html
This will help you get the taglib ready for release, I can do the
final steps to build and publish the release.
Regards,
Glenn
> Thanks,
>
> Hen
>
> On Wed, 11 Sep 2002, Glenn Nielsen wrote:
>
>
>>I would suggest a beta release of the current code. I can help do this.
>>Once commons-lang is released we can do the final release.
>>
>>JSTL requires JSP 1.2, the current String taglib works in JSP 1.1, right?
>>
>>I would suggest a new String taglib, perhaps STLString which adds
>>support for JSTL and requires JSP 1.2. And leave the current String
>>taglib as a JSP 1.1 compatible version.
>>
>>That would work better within the current build system.
>>
>>Regards,
>>
>>Glenn
>>
>>Henri Yandell wrote:
>>
>>>I'm at a touch of a quandry.
>>>
>>>String taglib is dependent on Commons Lang, and I want to avoid releasing
>>>String until there is a Lang release.
>>>
>>>So lots of users are dependent on the nightly build of String.
>>>
>>>I want to make some, not massive, but substantial changes to the taglib's
>>>API, and also to make an attempt at adding JEL to it. I don't want to
>>>'break' on customers though.
>>>
>>>What I'm considering is some form of stable release, calling it a beta
>>>feels bad, but that's what it would be, a 1.0-b1, prior to making changes
>>>for a 1.0-b2, which would then hopefully mature to a 1.0 release.
>>>
>>>Before I call a vote on it, does anyone have any advice about other ways
>>>to do this etc?
>>>
>>>Hen
>>>
>>>
>>>--
>>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>>
>>
>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [String] stablizing release
Posted by Henri Yandell <ba...@generationjava.com>.
Hey Glenn,
I'm not planning the JSTL stuff immediately, just some refactoring of tags
and a few additions, so I'd like to go and make a stable release of the
CVS soon. My sandbox is starting to get quite different. Do you think a
milestone as Shawn suggested, or a beta?
Basically I aim to have a stable jar built, placed in the releases dir,
hooked up to the site, and then I'll throw a bunch of tags out of
CVS and merge them. A kind of tag-name normalisation.
What's the process with Taglib deploying? Do you admin them and handle the
builds, or is it easier for you if I learn how to do so?
Thanks,
Hen
On Wed, 11 Sep 2002, Glenn Nielsen wrote:
> I would suggest a beta release of the current code. I can help do this.
> Once commons-lang is released we can do the final release.
>
> JSTL requires JSP 1.2, the current String taglib works in JSP 1.1, right?
>
> I would suggest a new String taglib, perhaps STLString which adds
> support for JSTL and requires JSP 1.2. And leave the current String
> taglib as a JSP 1.1 compatible version.
>
> That would work better within the current build system.
>
> Regards,
>
> Glenn
>
> Henri Yandell wrote:
> > I'm at a touch of a quandry.
> >
> > String taglib is dependent on Commons Lang, and I want to avoid releasing
> > String until there is a Lang release.
> >
> > So lots of users are dependent on the nightly build of String.
> >
> > I want to make some, not massive, but substantial changes to the taglib's
> > API, and also to make an attempt at adding JEL to it. I don't want to
> > 'break' on customers though.
> >
> > What I'm considering is some form of stable release, calling it a beta
> > feels bad, but that's what it would be, a 1.0-b1, prior to making changes
> > for a 1.0-b2, which would then hopefully mature to a 1.0 release.
> >
> > Before I call a vote on it, does anyone have any advice about other ways
> > to do this etc?
> >
> > Hen
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [String] stablizing release
Posted by Henri Yandell <ba...@generationjava.com>.
JSTL requires JSP 1.2, but I don't know if JEL does. Shawn? Unsure if it's
possible to add JEL via the EvaluationExpression [sp] class without tying
to 1.2. Another option is to port JEL to 1.1. Again, Shawn?
I'd obviously like to avoid an STLString taglib, but forcing 1.2 is even
worse.
Hen
On Wed, 11 Sep 2002, Glenn Nielsen wrote:
> I would suggest a beta release of the current code. I can help do this.
> Once commons-lang is released we can do the final release.
>
> JSTL requires JSP 1.2, the current String taglib works in JSP 1.1, right?
>
> I would suggest a new String taglib, perhaps STLString which adds
> support for JSTL and requires JSP 1.2. And leave the current String
> taglib as a JSP 1.1 compatible version.
>
> That would work better within the current build system.
>
> Regards,
>
> Glenn
>
> Henri Yandell wrote:
> > I'm at a touch of a quandry.
> >
> > String taglib is dependent on Commons Lang, and I want to avoid releasing
> > String until there is a Lang release.
> >
> > So lots of users are dependent on the nightly build of String.
> >
> > I want to make some, not massive, but substantial changes to the taglib's
> > API, and also to make an attempt at adding JEL to it. I don't want to
> > 'break' on customers though.
> >
> > What I'm considering is some form of stable release, calling it a beta
> > feels bad, but that's what it would be, a 1.0-b1, prior to making changes
> > for a 1.0-b2, which would then hopefully mature to a 1.0 release.
> >
> > Before I call a vote on it, does anyone have any advice about other ways
> > to do this etc?
> >
> > Hen
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [String] stablizing release
Posted by Glenn Nielsen <gl...@mail.more.net>.
Henri Yandell wrote:
> Thanks Glenn,
>
> This is all done. The tag is string-1-0. I didn't see anything relating
> to:
>
> "Set the <taginfo> or <ctlxinfo> state attribute for your taglib or ctlx
> to released."
>
The taglibs main page was changed, those are no longer needed. Thanks
for reporting this, I have updated the addtaglib document.
> Hows that look?
>
Good, except your news tag wasn't closed which broke the build. Fixed. :-)
Glenn
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [String] stablizing release
Posted by Henri Yandell <ba...@generationjava.com>.
Thanks Glenn,
This is all done. The tag is string-1-0. I didn't see anything relating
to:
"Set the <taginfo> or <ctlxinfo> state attribute for your taglib or ctlx
to released."
Hows that look?
Hen
On Mon, 7 Oct 2002, Glenn Nielsen wrote:
> Henri,
>
> Make any changes you need to the taglib to identify it as a 1.0 release.
> Follow the instructions at:
>
> http://jakarta.apache.org/taglibs/addtaglib.html#Release
>
> I can act as the release manager when you get to that point.
>
> Regards,
>
> Glenn
>
> Henri Yandell wrote:
> > Hi Glenn,
> >
> > Commons-lang has released at 1.0 now, so I'd like to do a 1.0 of String
> > Taglib now and start working towards a next version. Whether 'JSTL'
> > support will be in or not in the next version, I don't know. I'm going to
> > start by assuming not and play with it at some point.
> >
> > What should/can I do towards a Taglib release?
> >
> > Hen
> >
> > On Wed, 11 Sep 2002, Glenn Nielsen wrote:
> >
> >
> >>I would suggest a beta release of the current code. I can help do this.
> >>Once commons-lang is released we can do the final release.
> >>
> >>JSTL requires JSP 1.2, the current String taglib works in JSP 1.1, right?
> >>
> >>I would suggest a new String taglib, perhaps STLString which adds
> >>support for JSTL and requires JSP 1.2. And leave the current String
> >>taglib as a JSP 1.1 compatible version.
> >>
> >>That would work better within the current build system.
> >>
> >>Regards,
> >>
> >>Glenn
> >>
> >>Henri Yandell wrote:
> >>
> >>>I'm at a touch of a quandry.
> >>>
> >>>String taglib is dependent on Commons Lang, and I want to avoid releasing
> >>>String until there is a Lang release.
> >>>
> >>>So lots of users are dependent on the nightly build of String.
> >>>
> >>>I want to make some, not massive, but substantial changes to the taglib's
> >>>API, and also to make an attempt at adding JEL to it. I don't want to
> >>>'break' on customers though.
> >>>
> >>>What I'm considering is some form of stable release, calling it a beta
> >>>feels bad, but that's what it would be, a 1.0-b1, prior to making changes
> >>>for a 1.0-b2, which would then hopefully mature to a 1.0 release.
> >>>
> >>>Before I call a vote on it, does anyone have any advice about other ways
> >>>to do this etc?
> >>>
> >>>Hen
> >>>
> >>>
> >>>--
> >>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> >>>For additional commands, e-mail: <ma...@jakarta.apache.org>
> >>
> >>
> >>
> >>
> >>--
> >>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> >>For additional commands, e-mail: <ma...@jakarta.apache.org>
> >>
> >>
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [String] stablizing release
Posted by Glenn Nielsen <gl...@mail.more.net>.
Henri,
Make any changes you need to the taglib to identify it as a 1.0 release.
Follow the instructions at:
http://jakarta.apache.org/taglibs/addtaglib.html#Release
I can act as the release manager when you get to that point.
Regards,
Glenn
Henri Yandell wrote:
> Hi Glenn,
>
> Commons-lang has released at 1.0 now, so I'd like to do a 1.0 of String
> Taglib now and start working towards a next version. Whether 'JSTL'
> support will be in or not in the next version, I don't know. I'm going to
> start by assuming not and play with it at some point.
>
> What should/can I do towards a Taglib release?
>
> Hen
>
> On Wed, 11 Sep 2002, Glenn Nielsen wrote:
>
>
>>I would suggest a beta release of the current code. I can help do this.
>>Once commons-lang is released we can do the final release.
>>
>>JSTL requires JSP 1.2, the current String taglib works in JSP 1.1, right?
>>
>>I would suggest a new String taglib, perhaps STLString which adds
>>support for JSTL and requires JSP 1.2. And leave the current String
>>taglib as a JSP 1.1 compatible version.
>>
>>That would work better within the current build system.
>>
>>Regards,
>>
>>Glenn
>>
>>Henri Yandell wrote:
>>
>>>I'm at a touch of a quandry.
>>>
>>>String taglib is dependent on Commons Lang, and I want to avoid releasing
>>>String until there is a Lang release.
>>>
>>>So lots of users are dependent on the nightly build of String.
>>>
>>>I want to make some, not massive, but substantial changes to the taglib's
>>>API, and also to make an attempt at adding JEL to it. I don't want to
>>>'break' on customers though.
>>>
>>>What I'm considering is some form of stable release, calling it a beta
>>>feels bad, but that's what it would be, a 1.0-b1, prior to making changes
>>>for a 1.0-b2, which would then hopefully mature to a 1.0 release.
>>>
>>>Before I call a vote on it, does anyone have any advice about other ways
>>>to do this etc?
>>>
>>>Hen
>>>
>>>
>>>--
>>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>>
>>
>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [String] stablizing release
Posted by Henri Yandell <ba...@generationjava.com>.
Hi Glenn,
Commons-lang has released at 1.0 now, so I'd like to do a 1.0 of String
Taglib now and start working towards a next version. Whether 'JSTL'
support will be in or not in the next version, I don't know. I'm going to
start by assuming not and play with it at some point.
What should/can I do towards a Taglib release?
Hen
On Wed, 11 Sep 2002, Glenn Nielsen wrote:
> I would suggest a beta release of the current code. I can help do this.
> Once commons-lang is released we can do the final release.
>
> JSTL requires JSP 1.2, the current String taglib works in JSP 1.1, right?
>
> I would suggest a new String taglib, perhaps STLString which adds
> support for JSTL and requires JSP 1.2. And leave the current String
> taglib as a JSP 1.1 compatible version.
>
> That would work better within the current build system.
>
> Regards,
>
> Glenn
>
> Henri Yandell wrote:
> > I'm at a touch of a quandry.
> >
> > String taglib is dependent on Commons Lang, and I want to avoid releasing
> > String until there is a Lang release.
> >
> > So lots of users are dependent on the nightly build of String.
> >
> > I want to make some, not massive, but substantial changes to the taglib's
> > API, and also to make an attempt at adding JEL to it. I don't want to
> > 'break' on customers though.
> >
> > What I'm considering is some form of stable release, calling it a beta
> > feels bad, but that's what it would be, a 1.0-b1, prior to making changes
> > for a 1.0-b2, which would then hopefully mature to a 1.0 release.
> >
> > Before I call a vote on it, does anyone have any advice about other ways
> > to do this etc?
> >
> > Hen
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [String] stablizing release
Posted by Glenn Nielsen <gl...@mail.more.net>.
I would suggest a beta release of the current code. I can help do this.
Once commons-lang is released we can do the final release.
JSTL requires JSP 1.2, the current String taglib works in JSP 1.1, right?
I would suggest a new String taglib, perhaps STLString which adds
support for JSTL and requires JSP 1.2. And leave the current String
taglib as a JSP 1.1 compatible version.
That would work better within the current build system.
Regards,
Glenn
Henri Yandell wrote:
> I'm at a touch of a quandry.
>
> String taglib is dependent on Commons Lang, and I want to avoid releasing
> String until there is a Lang release.
>
> So lots of users are dependent on the nightly build of String.
>
> I want to make some, not massive, but substantial changes to the taglib's
> API, and also to make an attempt at adding JEL to it. I don't want to
> 'break' on customers though.
>
> What I'm considering is some form of stable release, calling it a beta
> feels bad, but that's what it would be, a 1.0-b1, prior to making changes
> for a 1.0-b2, which would then hopefully mature to a 1.0 release.
>
> Before I call a vote on it, does anyone have any advice about other ways
> to do this etc?
>
> Hen
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [String] stablizing release
Posted by Shawn Bayern <ba...@essentially.net>.
On Wed, 11 Sep 2002, Henri Yandell wrote:
> What I'm considering is some form of stable release, calling it a beta
> feels bad, but that's what it would be, a 1.0-b1, prior to making
> changes for a 1.0-b2, which would then hopefully mature to a 1.0
> release.
What about a "milestone" release? I'm not sure what the convention is for
milestones and dependencies, but it seems like a good step.
--
Shawn Bayern
"JSTL in Action" http://www.jstlbook.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>