Mailing list deletion
Noting that I've asked for this mailing list to be deleted. Any Taglibs development discussions should now occur on the Tomcat developer list. http://tomcat.apache.org/lists.html#tomcat-dev Hen - To unsubscribe, e-mail: taglibs-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-dev-h...@jakarta.apache.org
Parts of SVN moved
Various parts of SVN moved over to http://svn.apache.org/repos/asf/tomcat/taglibs/ Namely standard, rdc, extended, site and taglibs-parent. Hen - To unsubscribe, e-mail: taglibs-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-dev-h...@jakarta.apache.org
Re: Heads up on potential move for Taglibs
Expecting that they'd be maintained for those who are committing. So Rahul, myself and you if you're interested. Hen On Mon, Jul 13, 2009 at 6:36 AM, Kris Schneiderk...@directthought.com wrote: Seems reasonable. Any idea what happens to commit rights? On Sun, Jul 12, 2009 at 1:30 AM, Henri Yandell flame...@gmail.com wrote: Jakarta is a slowly dwindling project at Apache. A long time ago we agreed that its deep structure created isolated sub communities and Apache decided to become a flat organization. Thus for all projects in Jakarta there is the question of where to go. I've been floating the idea to Jakarta and Tomcat of moving the active parts of Taglibs over to Tomcat. This idea seems to be getting +1s on all sides. The general idea is: * Move Standard, JSTL implementation, over to Tomcat. 1.0 would be deprecated. * Move RDC over to Tomcat. * Start a new taglib (my new favourite name is Extended; ie: Apache Extended Taglib to complement the Apache Standard Taglib) that is built from the undeprecated parts of Taglibs that find favour. Some might be refactored from Taglibs to EL functions. Think the Commons Lang of Taglibs. * Other taglibs to be retired within Jakarta and make their way over to the Apache Attic. Hen -- Kris Schneider mailto:k...@directthought.com directThought http://www.directThought.com/ - To unsubscribe, e-mail: taglibs-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-dev-h...@jakarta.apache.org
Heads up on potential move for Taglibs
Jakarta is a slowly dwindling project at Apache. A long time ago we agreed that its deep structure created isolated sub communities and Apache decided to become a flat organization. Thus for all projects in Jakarta there is the question of where to go. I've been floating the idea to Jakarta and Tomcat of moving the active parts of Taglibs over to Tomcat. This idea seems to be getting +1s on all sides. The general idea is: * Move Standard, JSTL implementation, over to Tomcat. 1.0 would be deprecated. * Move RDC over to Tomcat. * Start a new taglib (my new favourite name is Extended; ie: Apache Extended Taglib to complement the Apache Standard Taglib) that is built from the undeprecated parts of Taglibs that find favour. Some might be refactored from Taglibs to EL functions. Think the Commons Lang of Taglibs. * Other taglibs to be retired within Jakarta and make their way over to the Apache Attic. Hen - To unsubscribe, e-mail: taglibs-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-dev-h...@jakarta.apache.org
Deprecating Standard 1.0.x
The recent Bugzilla entry regarding Tomcat 5.0 made me realize that we really should deprecate and end of life JSTL 1.0. Presumably it's linked to the same spec as Tomcat 4.x, and that has had its last release. We should mark it as deprecated and close out the open Bugzilla items as WONTFIX. Hen - To unsubscribe, e-mail: taglibs-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-dev-h...@jakarta.apache.org
Taglibs deprecated
Random, DateTime and I18N taglibs have all been deprecated. In the former case because it's not that interesting a taglib, and the latter two because they offer only very little extra functionality on top of JSTL. Thanks, Hen - To unsubscribe, e-mail: taglibs-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-dev-h...@jakarta.apache.org
Re: [unstandard] Picking through the datetime taglib
Pulling in an old thread :) I think datetime taglib should be deprecated. I don't think it is interesting enough on top of JSTL to keep alive. Hen On Mon, Jul 23, 2007 at 2:44 PM, Henri Yandell flame...@gmail.com wrote: Here are the tags in the DateTime taglib: * currentTime Gets the current time in milliseconds since Jan 1, 1970 GMT. * format Formats a date in milliseconds since Jan 1, 1970 GMT for output as a date string. * parse Parses a date string and outputs the time in milliseconds since Jan 1, 1970 GMT. * timeZone Create a time zone script variable for use with the parse or format tags. * timeZones Loop through all time zones. * months Loop through the months of the year. * weekdays Loop through the days of the week. * amPms Loop through the am/pm names. * eras Loop through the era names. - Of the first batch; format and parse are taken of care of in JSTL with fmt:formatDate and fmt:parseDate. The currentTime tag is effectively handled by doing: jsp:useBean id=now class=java.util.Date / I'm never sure whether it's better to educate people in doing such things, or if there should be a: un:currentTime var=now/ Probably it's best to just push towards useBean. Also, the timeZone attribute to the two fmt: tags can take a String as well as an Object, so presumably that makes that one redundant. So the question becomes whether there is any value in the iterator style tags. I don't see a lot. Any thoughts? I'm tempted to think 'deprecate' for datetime and bring nothing into Unstandard. Hen - To unsubscribe, e-mail: taglibs-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-dev-h...@jakarta.apache.org
Re: [proposal] Unstandard Taglib creation/release (and future of Taglibs)
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 flame...@gmail.com wrote: On 5/16/07, Henri Yandell flame...@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-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-dev-h...@jakarta.apache.org
Re: [unstandard] Picking through the datetime taglib
Ditto for the i18n taglib. Nothing jumping out there. On Mon, May 25, 2009 at 2:19 AM, Henri Yandell flame...@gmail.com wrote: Pulling in an old thread :) I think datetime taglib should be deprecated. I don't think it is interesting enough on top of JSTL to keep alive. Hen On Mon, Jul 23, 2007 at 2:44 PM, Henri Yandell flame...@gmail.com wrote: Here are the tags in the DateTime taglib: * currentTime Gets the current time in milliseconds since Jan 1, 1970 GMT. * format Formats a date in milliseconds since Jan 1, 1970 GMT for output as a date string. * parse Parses a date string and outputs the time in milliseconds since Jan 1, 1970 GMT. * timeZone Create a time zone script variable for use with the parse or format tags. * timeZones Loop through all time zones. * months Loop through the months of the year. * weekdays Loop through the days of the week. * amPms Loop through the am/pm names. * eras Loop through the era names. - Of the first batch; format and parse are taken of care of in JSTL with fmt:formatDate and fmt:parseDate. The currentTime tag is effectively handled by doing: jsp:useBean id=now class=java.util.Date / I'm never sure whether it's better to educate people in doing such things, or if there should be a: un:currentTime var=now/ Probably it's best to just push towards useBean. Also, the timeZone attribute to the two fmt: tags can take a String as well as an Object, so presumably that makes that one redundant. So the question becomes whether there is any value in the iterator style tags. I don't see a lot. Any thoughts? I'm tempted to think 'deprecate' for datetime and bring nothing into Unstandard. Hen - To unsubscribe, e-mail: taglibs-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-dev-h...@jakarta.apache.org
Maven + Cactus unit test success
I've finally got Maven2, Cactus and Jetty playing happily together. Sure it seems to repeat a step 3 times... sure I've made it a separate Maven project but it works! :) The JSTL implementation is now split into three projects: The JSTL jar itself, though due to Glassfish we have to put it in our own groupId: https://svn.apache.org/repos/asf/jakarta/taglibs/proper/standard/trunk/spec The Standard jar, which includes JUnit testing: https://svn.apache.org/repos/asf/jakarta/taglibs/proper/standard/trunk/impl The Cactus tests: https://svn.apache.org/repos/asf/jakarta/taglibs/proper/standard/trunk/standard-test Tests pass. Except the JUnit ones that are turned off - one has never passed and the other started failing in the 1.2 update and I need to grok why. There's also a string-test directory in the String Taglib - its one Cactus test is failing right now, this is because String puts its var into PAGE_SCOPE and Cactus needs to pull from APPLICATION_SCOPE as (I think) the Page is dead and flushed by the time the unit test gets to the assert step. Simple answer is that String (and other taglibs) should support scope :) Another todo is to look at creating a parent pom for the integration projects. Hen - To unsubscribe, e-mail: taglibs-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-dev-h...@jakarta.apache.org
Dormant sites hidden
I've rewritten the dormant/deprecated taglibs page so it doesn't induce people to ask for nightly downloads. The main page links to the documentation and either an svn or build link. http://jakarta.apache.org/taglibs/site/dormant.html Hen - To unsubscribe, e-mail: taglibs-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-dev-h...@jakarta.apache.org
Re: [Jakarta Standard Taglib] Cactus + Jetty + Maven2
Problem might be because Jetty embeds a copy of JSTL inside itself. Hen On Thu, Apr 23, 2009 at 1:44 AM, Henri Yandell flame...@gmail.com wrote: I'm frustratingly close to having the Cactus Maven2 plugin working with the Jetty Maven2 plugin for the Jakarta Standard Taglib. Here's what you have to do to replicate my current status: svn co https://svn.apache.org/repos/asf/jakarta/taglibs/proper/taglibs-parent/trunk taglibs-parent cd taglibs-parent mvn install cd .. svn co https://svn.apache.org/repos/asf/jakarta/taglibs/proper/standard/trunk standard cd standard mvn install cd standard-test mvn package integration-test The cactus tests are in the subdirectory of standard-test. I know it's a bit hacky having it as the subdirectory, but it's proof of concept and then I'll rip things apart in the standard directory and do things properly. Current status is: Once you have the taglib parent pom and the jstl+impl combo jar deployed, the war builds happily, it gets cactified, it goes into jetty as jetty starts up, surefire kicks in and fails the tests due to JSP webapp setup reasons. Then jetty turns itself off. Oddly, some change I made recently has it doing the war stages multiple times. Not sure why. If anyone gets interested, a second pair of eyes on the JSP webapp setup reasons would be cool; as would any suggestions on how the pom.xml could be simplified or is doing the wrong thing. Thanks, Hen - To unsubscribe, e-mail: taglibs-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-dev-h...@jakarta.apache.org
[Jakarta Standard Taglib] Cactus + Jetty + Maven2
I'm frustratingly close to having the Cactus Maven2 plugin working with the Jetty Maven2 plugin for the Jakarta Standard Taglib. Here's what you have to do to replicate my current status: svn co https://svn.apache.org/repos/asf/jakarta/taglibs/proper/taglibs-parent/trunk taglibs-parent cd taglibs-parent mvn install cd .. svn co https://svn.apache.org/repos/asf/jakarta/taglibs/proper/standard/trunk standard cd standard mvn install cd standard-test mvn package integration-test The cactus tests are in the subdirectory of standard-test. I know it's a bit hacky having it as the subdirectory, but it's proof of concept and then I'll rip things apart in the standard directory and do things properly. Current status is: Once you have the taglib parent pom and the jstl+impl combo jar deployed, the war builds happily, it gets cactified, it goes into jetty as jetty starts up, surefire kicks in and fails the tests due to JSP webapp setup reasons. Then jetty turns itself off. Oddly, some change I made recently has it doing the war stages multiple times. Not sure why. If anyone gets interested, a second pair of eyes on the JSP webapp setup reasons would be cool; as would any suggestions on how the pom.xml could be simplified or is doing the wrong thing. Thanks, Hen - To unsubscribe, e-mail: taglibs-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-dev-h...@jakarta.apache.org
Sandbox policy as per Commons
I've a Taglib I'd like to have live in the Taglibs sandbox. All my own work etc. Can I go ahead and put it in and see what happens; should I do something else? Hen - To unsubscribe, e-mail: taglibs-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-dev-h...@jakarta.apache.org
Standard 1.2 Beta?
I'm thinking we should do a beta release of the Standard 1.2 code. Or alpha. Any thoughts? One other question - is it v1.2 or v2.0? Hen - To unsubscribe, e-mail: taglibs-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-dev-h...@jakarta.apache.org
Re: [RDC] m2 migration, trunk broken this weekend
On Sun, Jan 11, 2009 at 5:55 PM, Rahul Akolkar rahul.akol...@gmail.com wrote: On Sun, Jan 11, 2009 at 2:16 AM, Henri Yandell flame...@gmail.com wrote: If you haven't already, go register a user at: http://vmbuild.apache.org/continuum/projectGroupSummary.action?projectGroupId=145 The let me know and I'll add you to the project admin. Then you can add RDC to the nightly. snip/ The continuum username is ra...@a.o (domain spelled out). TIA. I've added you to the project. Hen - To unsubscribe, e-mail: taglibs-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-dev-h...@jakarta.apache.org
Re: [m2] Build observations
Agreed on the first two. artifactIds and sourceDirectories changed. Rest still feels up in the air. Am also tempted to do some releases :) On Sun, Jan 11, 2009 at 6:11 PM, Rahul Akolkar rahul.akol...@gmail.com wrote: So I think we're doing well on the m2 stuff (thanks for getting it started Hen). Various observations that came to mind as I looked at this during the last couple of days: * Artifact IDs - Lets have the invariant part first (so 'taglibs-string' rather than 'string-taglib') ... I like the former better, similar to Commons and I've used such artifactIDs for the RDC build. * The sourceDirectory defined in the parent pom is non-standard, required overrides in RDC modules. However, RDC is the only taglib using the standard directory for this so may be less effort to let this be rather than redo rest of the taglibs. * The RDC build uses multiple modules, particularly because the size of the taglib is much bigger compared to some of the others, and we have a couple of sample apps so its important to separate out the sources etc. TBD whether all taglibs should do the same, but this approach scales very well (perhaps standard can adopt it). * The RDC taglib does not use the taglib-plugin to generate the docs (I have a couple of changes to the site in mind and will publish it in a day or two). Its hard to un-inherit a plugin from the parent so I've worked around it a bit, but again, since all other taglibs are using it I think we should leave it in the parent. * At this point, the distros produced by the RDC build are close enough to what we had before and immediately usable IMO. We can slap an 'rc' profile on the parent pom for sums, sigs etc. and then use the release plugin. So releasing will amount to: mvn -Prc release:prepare mvn -Prc release:perform Given the above, I'm actually tempted to produce an RC for RDC v1.1. There were a bunch of improvements couple of years ago (a new component, an SCXML-based dialog manager, minor improvements here and there) and it'd be good to get a release out. Will also be a good test to see if we have enough folks around at Taglibs. Thoughts? -Rahul - To unsubscribe, e-mail: taglibs-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-dev-h...@jakarta.apache.org - To unsubscribe, e-mail: taglibs-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-dev-h...@jakarta.apache.org
Re: [RDC] m2 migration, trunk broken this weekend
Why a module for producing the distro? +1 on the examples/sample apps - fun part is how to try and overlap that with Cactus. It should be deploying the examples as our test layer. One possible idea is to have taglibs-example.pom extending taglibs-parent.pom then rdc-example.pom extending taglibs-example.pom that depends on rdc.jar. ie) we have examples as a group of things rather than examples inside each taglib. Hen On Sat, Jan 10, 2009 at 11:32 AM, Rahul Akolkar rahul.akol...@gmail.com wrote: I'm planning on moving the RDC taglib to m2 this weekend. I'd like to retain as much as the old distro flavor as possible since I think its quite useful. Therefore, I think the best way to go about this is to have a multi-module m2 build: * One module for the taglib jar * One for the examples and sample apps war file * One for assembling the distros (two: source and binary -- and as before binary will contain, the above jar, war and tld, javadocs and tlddoc) * Probably a parent pom for dependencyManagement mostly Some experimentation involved, but I'd rather just do this on trunk. As a result, the RDC trunk will be broken this weekend. Once I'm done and the build is usable, I'll reply to this message. Must you need a working base this weekend, you can get it off the PRE_M2 tag: http://svn.apache.org/repos/asf/jakarta/taglibs/proper/rdc/tags/PRE_M2/ -Rahul - To unsubscribe, e-mail: taglibs-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-dev-h...@jakarta.apache.org - To unsubscribe, e-mail: taglibs-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-dev-h...@jakarta.apache.org
Re: [RDC] m2 migration, trunk broken this weekend
Very cool :) If you haven't already, go register a user at: http://vmbuild.apache.org/continuum/projectGroupSummary.action?projectGroupId=145 The let me know and I'll add you to the project admin. Then you can add RDC to the nightly. Irritatingly, ri...@apache has taken your rahul@ login there. Hen On Sat, Jan 10, 2009 at 2:37 PM, Rahul Akolkar rahul.akol...@gmail.com wrote: As a quick update: The taglib jar now builds as expected, so trunk should be usable to that extent. I'll be finishing the examples app module (w/o Cactus) and the distro assemblies tomorrow. -Rahul - To unsubscribe, e-mail: taglibs-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-dev-h...@jakarta.apache.org - To unsubscribe, e-mail: taglibs-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-dev-h...@jakarta.apache.org
New site deploying
I've deployed the new top level maven2 site to replace the taglibs site. We'll see how it goes, it feels good, but I have to wait for it to get copied to the real webserver to do proper testing. The 'addtaglib.html' page is the only one that should start breaking. It doesn't make any sense anymore with the Incubator, so no point trying to redirect the url. Currently it keeps the old sites for each taglib. Assuming this goes well, I'll go ahead and phase those out with new sites. Hen - To unsubscribe, e-mail: taglibs-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-dev-h...@jakarta.apache.org
Re: New site deploying
New site deployed. A couple of broken links (bugs, ci, mail lists) which I've pushed a fix out to and will check in the morning to see if that worked. Old site: http://people.apache.org/~bayard/OldTaglibsSite.png New site: http://people.apache.org/~bayard/NewTaglibsSite.png The 'Building' page is complete crap now and needs rewriting or just deleting. The old addtaglib page needs to be looked at to see if anything is needed, and then the old site directory in svn can be deleted. Hen On Tue, Jan 6, 2009 at 1:47 AM, Henri Yandell flame...@gmail.com wrote: I've deployed the new top level maven2 site to replace the taglibs site. We'll see how it goes, it feels good, but I have to wait for it to get copied to the real webserver to do proper testing. The 'addtaglib.html' page is the only one that should start breaking. It doesn't make any sense anymore with the Incubator, so no point trying to redirect the url. Currently it keeps the old sites for each taglib. Assuming this goes well, I'll go ahead and phase those out with new sites. Hen - To unsubscribe, e-mail: taglibs-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-dev-h...@jakarta.apache.org
Re: New site deploying
Tbh, I deploy by hand. I wanted to get it in place and remove the old files. Need to test the site-deploy side of things. Sneek peek link fixed - thanks for pointing that out :) Hen On Tue, Jan 6, 2009 at 1:03 PM, Rahul Akolkar rahul.akol...@gmail.com wrote: On Tue, Jan 6, 2009 at 5:59 AM, Henri Yandell flame...@gmail.com wrote: New site deployed. snip/ Neatness! So I assume 'mvn site-deploy' in taglibs/proper/site for main site and same command in individual taglibs for their site? Any other magic to remember? I'll make some minor change to the main site and try deploying it soon. Oh, and fix the sneak peek broken link to the string taglib on your blog :-) -Rahul A couple of broken links (bugs, ci, mail lists) which I've pushed a fix out to and will check in the morning to see if that worked. Old site: http://people.apache.org/~bayard/OldTaglibsSite.png New site: http://people.apache.org/~bayard/NewTaglibsSite.png The 'Building' page is complete crap now and needs rewriting or just deleting. The old addtaglib page needs to be looked at to see if anything is needed, and then the old site directory in svn can be deleted. Hen On Tue, Jan 6, 2009 at 1:47 AM, Henri Yandell flame...@gmail.com wrote: I've deployed the new top level maven2 site to replace the taglibs site. We'll see how it goes, it feels good, but I have to wait for it to get copied to the real webserver to do proper testing. The 'addtaglib.html' page is the only one that should start breaking. It doesn't make any sense anymore with the Incubator, so no point trying to redirect the url. Currently it keeps the old sites for each taglib. Assuming this goes well, I'll go ahead and phase those out with new sites. Hen - To unsubscribe, e-mail: taglibs-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-dev-h...@jakarta.apache.org - To unsubscribe, e-mail: taglibs-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-dev-h...@jakarta.apache.org - To unsubscribe, e-mail: taglibs-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-dev-h...@jakarta.apache.org
Re: New site deploying
scpexe is my preference too :) screw the scp desirers 'til they do some real work. I've pushed up the other taglib directories that have been migrated so far, so feel free to have a play. Next steps are to look at those after they deploy (in 15 min I think). If they look good, then to change the site/ links and parent/site.xml to point to the new sites for those taglibs. Hen On Tue, Jan 6, 2009 at 9:48 PM, Rahul Akolkar rahul.akol...@gmail.com wrote: On Tue, Jan 6, 2009 at 11:01 PM, Henri Yandell flame...@gmail.com wrote: Tbh, I deploy by hand. I wanted to get it in place and remove the old files. Need to test the site-deploy side of things. snip/ OK. When you give the green signal, I'll try deploying as well (BTW, I'll change the distribution management URLs I'll be dealing with to scpexe:// -- that'll work for me and continue to work for you). -Rahul Sneek peek link fixed - thanks for pointing that out :) Hen On Tue, Jan 6, 2009 at 1:03 PM, Rahul Akolkar rahul.akol...@gmail.com wrote: On Tue, Jan 6, 2009 at 5:59 AM, Henri Yandell flame...@gmail.com wrote: New site deployed. snip/ Neatness! So I assume 'mvn site-deploy' in taglibs/proper/site for main site and same command in individual taglibs for their site? Any other magic to remember? I'll make some minor change to the main site and try deploying it soon. Oh, and fix the sneak peek broken link to the string taglib on your blog :-) -Rahul A couple of broken links (bugs, ci, mail lists) which I've pushed a fix out to and will check in the morning to see if that worked. Old site: http://people.apache.org/~bayard/OldTaglibsSite.png New site: http://people.apache.org/~bayard/NewTaglibsSite.png The 'Building' page is complete crap now and needs rewriting or just deleting. The old addtaglib page needs to be looked at to see if anything is needed, and then the old site directory in svn can be deleted. Hen On Tue, Jan 6, 2009 at 1:47 AM, Henri Yandell flame...@gmail.com wrote: I've deployed the new top level maven2 site to replace the taglibs site. We'll see how it goes, it feels good, but I have to wait for it to get copied to the real webserver to do proper testing. The 'addtaglib.html' page is the only one that should start breaking. It doesn't make any sense anymore with the Incubator, so no point trying to redirect the url. Currently it keeps the old sites for each taglib. Assuming this goes well, I'll go ahead and phase those out with new sites. Hen - To unsubscribe, e-mail: taglibs-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-dev-h...@jakarta.apache.org - To unsubscribe, e-mail: taglibs-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-dev-h...@jakarta.apache.org
Re: Parent pom and site (was Re: svn commit: r731428)
On Sun, Jan 4, 2009 at 7:50 PM, Rahul Akolkar rahul.akol...@gmail.com wrote: On Sun, Jan 4, 2009 at 10:39 PM, bay...@apache.org wrote: Author: bayard Date: Sun Jan 4 19:39:53 2009 New Revision: 731428 URL: http://svn.apache.org/viewvc?rev=731428view=rev Log: Making the pom a child of the taglibs-parent. Wondering if there's any reason for keeping the site separate. snip/ Yup, we want the pom to stand by itself. That way its easier to release. I kind of went with that. The site.xml is there with the pom (no arguments expected). However, I also have the index.html with the parent pom and the rest of the site is in a site/ subdirectory that is a sibling to the other components. Having pootled on a bit further though with the fun that is Maven2 site plugin url trickery, I suspect I could put it back in the site and move all the rest down into a site directory. Hen - To unsubscribe, e-mail: taglibs-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-dev-h...@jakarta.apache.org
Re: M2 migrations
On Sat, Jan 3, 2009 at 8:29 PM, Rahul Akolkar rahul.akol...@gmail.com wrote: On Sat, Jan 3, 2009 at 8:52 PM, Henri Yandell flame...@gmail.com wrote: * Create M2 based parent site. Very tempted not to have subsites, but to link the top site in directly given that I've always wanted to do that. snip/ Not sure what you mean above. I'd say we have something like the Commons site? (except the main site is also m2, rather than m1 ofcourse) It's much the same. I'd like the main site page that lists components to be more of a 1-stop-shop - ie: downloads and documentation are linked from there. Less of a feel that each component is its own subsite and more of a feel that they're part of the same site. Haven't tried seeing if you can inject a component menu at the top of the LHS when it shows up. Not sure I want to do that, but would be nice to know if it was possible. Hen - To unsubscribe, e-mail: taglibs-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-dev-h...@jakarta.apache.org
Re: [g...@vmgump]: Project jakarta-taglibs-standard (in module jakarta-taglibs) failed
Repeating as I suspect the gump email got stuck in moderation. Any idea on the gump side? I'm not sure how things appear in bootclasspath and then not in classpath. There's a debug that it's decided not to include tomcat6 for the jsp21/servlet25 properties, but that doesn't seem to imply it's going to forget them all together. Hen On Tue, Dec 23, 2008 at 2:08 PM, Henri Yandell flame...@gmail.com wrote: [cc'ing gene...@gump.apache.org] Any ideas why this is failing? servlet-api and jsp-api appear in the bootclasspath debug, but then are absent from the CLASSPATH debug. Hen On Tue, Dec 23, 2008 at 3:20 AM, Martin Cooper mart...@apache.org wrote: To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project jakarta-taglibs-standard has an issue affecting its community integration. This issue affects 45 projects, and has been outstanding for 4 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly : Commons Jelly - commons-jelly-tags-ant : Commons Jelly - commons-jelly-tags-antlr : Commons Jelly - commons-jelly-tags-avalon : Commons Jelly - commons-jelly-tags-bean : Commons Jelly - commons-jelly-tags-beanshell : Commons Jelly - commons-jelly-tags-betwixt : Commons Jelly - commons-jelly-tags-bsf : Commons Jelly - commons-jelly-tags-define : Commons Jelly - commons-jelly-tags-define-test : Commons Jelly - commons-jelly-tags-dynabean : Commons Jelly - commons-jelly-tags-email : Commons Jelly - commons-jelly-tags-fmt : Commons Jelly - commons-jelly-tags-fmt-test : Commons Jelly - commons-jelly-tags-html : Commons Jelly - commons-jelly-tags-http : Commons Jelly - commons-jelly-tags-interaction : Commons Jelly - commons-jelly-tags-jaxme : Commons Jelly - commons-jelly-tags-jetty : Commons Jelly - commons-jelly-tags-jface : Commons Jelly - commons-jelly-tags-jms : Commons Jelly - commons-jelly-tags-jmx : Commons Jelly - commons-jelly-tags-jsl : Commons Jelly - commons-jelly-tags-jsl-test : Commons Jelly - commons-jelly-tags-junit : Commons Jelly - commons-jelly-tags-log : Commons Jelly - commons-jelly-tags-memory : Commons Jelly - commons-jelly-tags-quartz : Commons Jelly - commons-jelly-tags-regexp : Commons Jelly - commons-jelly-tags-soap : Commons Jelly - commons-jelly-tags-sql : Commons Jelly - commons-jelly-tags-swing : Commons Jelly - commons-jelly-tags-swt : Commons Jelly - commons-jelly-tags-threads : Commons Jelly - commons-jelly-tags-util : Commons Jelly - commons-jelly-tags-validate : Commons Jelly - commons-jelly-tags-velocity : Commons Jelly - commons-jelly-tags-xml : Commons Jelly - commons-jelly-tags-xml-test : Commons Jelly - commons-jelly-tags-xmlunit : Commons Jelly - commons-jelly-test : Commons Jelly - htmlunit : A tool for testing web based applications - jakarta-taglibs-standard : Standard Taglib - maven : Project Management Tools - maven-bootstrap : Project Management Tools Full details are available at: http://vmgump.apache.org/gump/public/jakarta-taglibs/jakarta-taglibs-standard/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on jaxp exists, no need to add for property jaxp-api.jar. -DEBUG- Dependency on jaxp exists, no need to add for property sax.jar. -DEBUG- Dependency on tomcat-tc6 exists, no need to add for property jsp21.jar. -DEBUG- Dependency on tomcat-tc6 exists, no need to add for property servlet25.jar. -DEBUG- Dependency on xalan exists, no need to add for property xalan.jar. -DEBUG- Dependency on xml-xerces exists, no need to add for property xercesImpl.jar. -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-taglibs/jakarta-taglibs-standard/gump_work/build_jakarta-taglibs_jakarta-taglibs-standard.html Work Name: build_jakarta-taglibs_jakarta-taglibs-standard (Type: Build) Work ended in a state of : Failed Elapsed: 8 secs Command Line: /usr/lib/jvm/java-1.5.0-sun/bin/java -Djava.awt.headless=true -Xbootclasspath/p:/srv/gump/public/workspace/xml-xalan/build/serializer.jar:/srv/gump/public/workspace/xml-xalan/build/xalan-unbundled.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/packages/jaxp-1_3/dom.jar org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml
M2 migrations
String, Unstandard, Log, Random and Regexp have all been migrated to M2. This means: * M2 builds added, Ant builds removed. * No longer can produce old servlet versions, everything is jsp 2.0/servlet 2.4 currently. Probably worth a global update to 2.1/2.5 later and maybe putting the version in the parent pom. * Examples wars not being built. * Doc wars won't be built anymore - replaced by Maven Taglib plugin. * Added to Continuum (vmbuild.apache.org) * Likely to break in Gump as I don't know what I'm doing there. TODO: * Migrate others - Datetime, JNDI, i18n, RDC, Standard, Iterator. * Replace examples with unit testing (Cactus? Probably as Standard will want this). * Include taglib docs in download. * Include tld in download. * Create M2 based parent site. Very tempted not to have subsites, but to link the top site in directly given that I've always wanted to do that. * Delete old build system once all are done. * Update Regexp to JDK Regexp instead of ORO. If anyone wants to claim a particular task, or has other ones that need doing, feel free to pipe up. Hen - To unsubscribe, e-mail: taglibs-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-dev-h...@jakarta.apache.org
Re: M2 migrations
JNDI done :) RDC has a bunch of deps, so will be a little involved. Datetime depends on the deprecated request taglib for its tests, so we'll need to port to JSTL for the tests I imagine. i18n has a fun bit locale wise, that could be fun to set tests up for. Iterator is pretty easy I imagine. On Sat, Jan 3, 2009 at 5:22 PM, Henri Yandell flame...@gmail.com wrote: String, Unstandard, Log, Random and Regexp have all been migrated to M2. This means: * M2 builds added, Ant builds removed. * No longer can produce old servlet versions, everything is jsp 2.0/servlet 2.4 currently. Probably worth a global update to 2.1/2.5 later and maybe putting the version in the parent pom. * Examples wars not being built. * Doc wars won't be built anymore - replaced by Maven Taglib plugin. * Added to Continuum (vmbuild.apache.org) * Likely to break in Gump as I don't know what I'm doing there. TODO: * Migrate others - Datetime, JNDI, i18n, RDC, Standard, Iterator. * Replace examples with unit testing (Cactus? Probably as Standard will want this). * Include taglib docs in download. * Include tld in download. * Create M2 based parent site. Very tempted not to have subsites, but to link the top site in directly given that I've always wanted to do that. * Delete old build system once all are done. * Update Regexp to JDK Regexp instead of ORO. If anyone wants to claim a particular task, or has other ones that need doing, feel free to pipe up. Hen - To unsubscribe, e-mail: taglibs-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-dev-h...@jakarta.apache.org
Re: [g...@vmgump]: Project jakarta-taglibs-standard (in module jakarta-taglibs) failed
[cc'ing gene...@gump.apache.org] Any ideas why this is failing? servlet-api and jsp-api appear in the bootclasspath debug, but then are absent from the CLASSPATH debug. Hen On Tue, Dec 23, 2008 at 3:20 AM, Martin Cooper mart...@apache.org wrote: To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project jakarta-taglibs-standard has an issue affecting its community integration. This issue affects 45 projects, and has been outstanding for 4 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly : Commons Jelly - commons-jelly-tags-ant : Commons Jelly - commons-jelly-tags-antlr : Commons Jelly - commons-jelly-tags-avalon : Commons Jelly - commons-jelly-tags-bean : Commons Jelly - commons-jelly-tags-beanshell : Commons Jelly - commons-jelly-tags-betwixt : Commons Jelly - commons-jelly-tags-bsf : Commons Jelly - commons-jelly-tags-define : Commons Jelly - commons-jelly-tags-define-test : Commons Jelly - commons-jelly-tags-dynabean : Commons Jelly - commons-jelly-tags-email : Commons Jelly - commons-jelly-tags-fmt : Commons Jelly - commons-jelly-tags-fmt-test : Commons Jelly - commons-jelly-tags-html : Commons Jelly - commons-jelly-tags-http : Commons Jelly - commons-jelly-tags-interaction : Commons Jelly - commons-jelly-tags-jaxme : Commons Jelly - commons-jelly-tags-jetty : Commons Jelly - commons-jelly-tags-jface : Commons Jelly - commons-jelly-tags-jms : Commons Jelly - commons-jelly-tags-jmx : Commons Jelly - commons-jelly-tags-jsl : Commons Jelly - commons-jelly-tags-jsl-test : Commons Jelly - commons-jelly-tags-junit : Commons Jelly - commons-jelly-tags-log : Commons Jelly - commons-jelly-tags-memory : Commons Jelly - commons-jelly-tags-quartz : Commons Jelly - commons-jelly-tags-regexp : Commons Jelly - commons-jelly-tags-soap : Commons Jelly - commons-jelly-tags-sql : Commons Jelly - commons-jelly-tags-swing : Commons Jelly - commons-jelly-tags-swt : Commons Jelly - commons-jelly-tags-threads : Commons Jelly - commons-jelly-tags-util : Commons Jelly - commons-jelly-tags-validate : Commons Jelly - commons-jelly-tags-velocity : Commons Jelly - commons-jelly-tags-xml : Commons Jelly - commons-jelly-tags-xml-test : Commons Jelly - commons-jelly-tags-xmlunit : Commons Jelly - commons-jelly-test : Commons Jelly - htmlunit : A tool for testing web based applications - jakarta-taglibs-standard : Standard Taglib - maven : Project Management Tools - maven-bootstrap : Project Management Tools Full details are available at: http://vmgump.apache.org/gump/public/jakarta-taglibs/jakarta-taglibs-standard/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on jaxp exists, no need to add for property jaxp-api.jar. -DEBUG- Dependency on jaxp exists, no need to add for property sax.jar. -DEBUG- Dependency on tomcat-tc6 exists, no need to add for property jsp21.jar. -DEBUG- Dependency on tomcat-tc6 exists, no need to add for property servlet25.jar. -DEBUG- Dependency on xalan exists, no need to add for property xalan.jar. -DEBUG- Dependency on xml-xerces exists, no need to add for property xercesImpl.jar. -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-taglibs/jakarta-taglibs-standard/gump_work/build_jakarta-taglibs_jakarta-taglibs-standard.html Work Name: build_jakarta-taglibs_jakarta-taglibs-standard (Type: Build) Work ended in a state of : Failed Elapsed: 8 secs Command Line: /usr/lib/jvm/java-1.5.0-sun/bin/java -Djava.awt.headless=true -Xbootclasspath/p:/srv/gump/public/workspace/xml-xalan/build/serializer.jar:/srv/gump/public/workspace/xml-xalan/build/xalan-unbundled.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/packages/jaxp-1_3/dom.jar org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Del.jar=/srv/gump/public/workspace/tomcat-tc6/output/build/lib/el-api.jar -DxercesImpl.jar=/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar -Dbuild.dir=/srv/gump/public/workspace/jakarta-taglibs/build -Djsp21.jar=/srv/gump/public/workspace/tomcat-tc6/output/build/lib/jsp-api.jar -Dsax.jar=/srv/gump/packages/jaxp-1_3/sax.jar
JSTL 1.2 patch applied
I finished my first pass through the patch and applied it. I put a fair amount of info into the commit message - I think it's worth reading for the link to the spec update page and then the breakdown of which files relate to which change. http://svn.apache.org/viewvc?view=revrevision=728565 I've some open items for discussion: * Look at the question in SetSupport.java and resolve. * Look at questions in the length method in ForEachSupport.java * Look at commented out code in prepre in ForEachSupport.java * javadoc for new Expression classes * Ensure equals()/hashCode() is fine in new Expression classes # Not covered and suggest cactus tests are implemented for each if possible: * Example involving fmt:parseDate in section 9.9 was incorrect. A pattern has been added so the date can be parsed properly. * Clarified the fact that the output of c:url wont work for the url attribute value of c:import for context relative URLs (URLs that start with a '/'). (section 7.4) # Create cactus tests for JSTL change #1 # Create cactus tests for JSTL change #2 - To unsubscribe, e-mail: taglibs-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-dev-h...@jakarta.apache.org
[standard] trunk is now JSTL 1.2
I've branched the current trunk off as a Standard 1.1.x branch (alongside the 1.0.x branch in branches/) and trunk is now for 1.2.x work. Hopefully I'll have the minor updates to the build done and a confirmation of Robert Goff's patch applied soon. Basically need to get the build working, show it builds and passes tests (and probably that it has the same failures for EvaluationTest as 1.1), then do dig the 1.2 spec out again and compare the deltas to sanity check Robert's code. Anyone else also got time to do the latter? Hen - To unsubscribe, e-mail: taglibs-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-dev-h...@jakarta.apache.org
Re: JSTL 1.2 implemented
The second I have a software grant I'll commit away :) Would love to see it there and Geronimo using it. Hen On Fri, Nov 14, 2008 at 2:10 PM, Joe Bohn [EMAIL PROTECTED] wrote: Did anything ever come of this? If not, is it still a possibility? We'd still love to use an apache JSTL 1.2 rather than glassfish possibly pulling it in for our upcoming 2.2 release. Thanks, Joe Henri Yandell wrote: On Mon, Feb 18, 2008 at 1:45 PM, Robert E Goff [EMAIL PROTECTED] wrote: Hi, I have downloaded the 1.1.2 version of JSTL and updated it to support the new JSTL 1.2 features. Is there a desire for a JSTL 1.2 opensource branch? This version has currently passed the JSTL 1.2 TCK. Let me know if there is interest for this spec update? Is anyone willing to take these contributions and commit it? (The changes are minimal. A slight tld change, 3 new classes, and 10 file changes.) Thanks. Absolutely interested. Very cool :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/JSTL-1.2-implemented-tp15554874p20509181.html Sent from the Taglibs - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Slowly x:forEach/x:out tags
On Mon, Oct 27, 2008 at 11:48 AM, Kris Schneider [EMAIL PROTECTED] wrote: On Mon, Oct 27, 2008 at 12:44 PM, emerson cargnin [EMAIL PROTECTED] wrote: So there is no plans to fix this is future versions? I'd have to say, no, there doesn't seem to be a plan to fix this in Standard 1.1. We have quite a few number of x:forEach/x:out on our JSPs. I believe our managers wouldn't be willing to refactor all the pages to switch that for xslt, which I'd believe would be overkill. Understood. Is there someone in charge of the x taglibs? I suppose that would be Jakarta committers with an interest in the Standard taglib. I happen to be one of those, but I'm not actively working on it at the moment. It seems like this is really one of the worst areas of the implementation, but it's hard to gauge how much pain it's actually causing (besides yours, of course). There's not much traffic on the Jakarta taglibs lists and I have no idea if this ever comes up on other lists/forums. Personally, I'd love to be able to fix it, but I just can't promise to be able to make the time to do it. Maybe... It's the ugliest bug in the taglibs. I spent some time on it last year, but couldn't identify a solution as I was knee deep in copied Xerces (or was it Xalan?) internals. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ApacheCon
Anyone going to be at ApacheCon? Am pondering some effort to release the latest code in trunk. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A suggestion about jakarta-taglibs-standard-1.1.2-src
Depends on whether JDK 1.2/1.3 support is expected. I suspect 1.1.2 is expected to work on those versions, but will need to check. Hen On Wed, Mar 12, 2008 at 4:46 AM, knlyknly [EMAIL PROTECTED] wrote: I've downloaded jakarta-taglibs-standard-1.1.2-src.tar.gz 2008.3.12 in the file /jakarta-taglibs-standard-1.1.2-src/standard/src/org/apache/taglibs/standard/tag/common/sql/QueryTagSupport.java Line 276-278: throw new JspException(Resources.getMessage(DATASOURCE_INVALID,ex.toString())); and I think throw new JspException(Resources.getMessage(DATASOURCE_INVALID,ex.toString()),ex); would be better for users who want to get the cause exception instead of only a message. And how about if(ex instanceof SQLException) throw (SQLException)ex; else throw new JspException(Resources.getMessage(DATASOURCE_INVALID,ex.toString()),ex); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSTL 1.2 implemented
On Mon, Feb 18, 2008 at 1:45 PM, Robert E Goff [EMAIL PROTECTED] wrote: Hi, I have downloaded the 1.1.2 version of JSTL and updated it to support the new JSTL 1.2 features. Is there a desire for a JSTL 1.2 opensource branch? This version has currently passed the JSTL 1.2 TCK. Let me know if there is interest for this spec update? Is anyone willing to take these contributions and commit it? (The changes are minimal. A slight tld change, 3 new classes, and 10 file changes.) Thanks. Absolutely interested. Very cool :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: m2 builds (was: Where can I get a recent nightly build?)
On Jan 9, 2008 9:01 AM, Rahul Akolkar [EMAIL PROTECTED] wrote: On 1/9/08, Henri Yandell [EMAIL PROTECTED] wrote: My fault on the dupe - I've been shoving user and dev into the same folder for years, so tend not to notice which list I'm on. I've started with String taglib - best to scratch the itch you have etc. First easy steps are done, next steps are the taglibs specific bits. Namely: * Generating the TLD (and putting in the jar as taglib.tld). * Building an example war. * Building a doc war. snip/ My initial impression at recreating the current release artifacts using m2 (whether we should stick to the current style of release artifacts TBD, but current packaging has worked for us so far) has been that each taglib will have a multi-module build, one that has a jar packaging (for taglibs-foo.jar) and two that will have war packaging (foo-examples.war and foo-doc.war). Probably need some antrun execution for the TLDs, possibly for parts of the doc jar (especially for RDC, which uses tag files and custom stylesheets to generate TLD reference docs). The above plan will require quite a reshuffle in the svn layout (hence I opted for a branch). Yeah - I really hate having to have multiple projects. The example and doc war are not projects, they are part of the website in Maven terms - we just don't want to do things in xdoc or apt. Feels that it should still be entirely doable as a single project. I think we should try for an atomic project; see if that works. Only if we can't make that fit should we go the triple project route. The Ant system has the ability to output different versions of the specification - I think we'll probably be losing that given that we have to specify which servlet jar we're using. So I'm not sure if 'Generating the TLD' is worthwhile, or if we should just change the xml file into an actual tld file. I guess it depends if we lose any data. snap/ Yup, see antrun bit above. About different specifications, it may be possible to do that using m2 profiles. I think this is the first decision - is there any value in keeping the tld generation. It's not as if we've been building and distributing taglibs for different spec versions; the RM has always chosen one. The simpler we keep the build, the more we can maintain with less effort. While powerful, I think the build system's complexity has been one factor in lack of energy to do anything. Course - the other part is the general lack of energy in JSP :) I'm not sure if the wars will be easy or hard - haven't done that in m2, and it tends to be single-artifact focused. Need to investigate. The example war is presumably easy - need to figure out how to build it. The doc war involves generating the documentation. Need to see what is out there plugin wise. snip/ Producing wars isn't hard (once you have all the contents). There is atleast one taglib plugin [1], though I haven't used it. Yeah, didn't look too hard, just haven't done it since m1. http://maven.apache.org/plugins/maven-war-plugin/ [1] http://maven-taglib.sourceforge.net/m2/ Artistic licensed - so made me wince and I looked for others :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bugzilla 29878 - NPE when using Xerces version that ships with JSTL 1.0.5
On 10/25/07, Bjorn Townsend [EMAIL PROTECTED] wrote: On Oct 25, 2007, at 10:33 PM October 25, Henri Yandell wrote: Done and done. When I merged the FAQ on the 1.1.3 page into the main one I cleaned it up a bit so the wiki makes a nice table of contents for us. Think we should get rid of the 1.1.3 FAQ page or blow it away? Both? Not sure what the difference is :) Think I parsed this right... yes, I performed both of the suggested actions, merging the 1.1.3 FAQ in with the main JSTL FAQ and labelling the JSTL FAQ as such on the main Jakarta Taglibs wiki page. :) Think we should get rid of the 1.1.3 FAQ page or blow it away?. Both say 'delete the page' to me; which is cool. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bugzilla 29878 - NPE when using Xerces version that ships with JSTL 1.0.5
On 10/25/07, Bjorn Townsend [EMAIL PROTECTED] wrote: Hello the list, I'm writing to suggest that the following be resolved -- it's got a workaround and there's a FAQ entry written for it, so in my opinion it's not impactful enough to worry about bothering with in a future 1.0.x release. http://issues.apache.org/bugzilla/show_bug.cgi?id=29878 Any thoughts? +1. I just realized there are two FAQs - we need to: a) Merge the new FAQ on the 1.1.3 page into the main one and; b) Rename the link on the main page to indicate that it is a JSTL FAQ - there's nothing about any other taglib there afaict. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bugzilla 29878 - NPE when using Xerces version that ships with JSTL 1.0.5
On 10/25/07, Bjorn Townsend [EMAIL PROTECTED] wrote: On Oct 25, 2007, at 7:36 PM October 25, Henri Yandell wrote: I just realized there are two FAQs - we need to: a) Merge the new FAQ on the 1.1.3 page into the main one and; b) Rename the link on the main page to indicate that it is a JSTL FAQ - there's nothing about any other taglib there afaict. Done and done. When I merged the FAQ on the 1.1.3 page into the main one I cleaned it up a bit so the wiki makes a nice table of contents for us. Think we should get rid of the 1.1.3 FAQ page or blow it away? Both? Not sure what the difference is :) I've resolved the issue as a wontfix. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bugzilla issue 43393
Sounds good. Only a month old issue, so hopefully he'll reply. Hen On 10/11/07, Bjorn Townsend [EMAIL PROTECTED] wrote: Hello all, Regarding the following: http://issues.apache.org/bugzilla/show_bug.cgi?id=43393 I looked into the issue but wasn't able to reproduce it. Henri, can you think of anything I might have missed in my attempt at reproing it? If not, and we don't hear from the reporter, might be puntable... Thanks, Bjorn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [standard] More bugs to resolve - thoughts?
On 8/24/07, Kris Schneider [EMAIL PROTECTED] wrote: On 8/24/07, Henri Yandell [EMAIL PROTECTED] wrote: I've been churning on with my patch to add a caching SPI to Standard. Here's the state, and what I think we should do: 17700 - Ostensibly this is a complaint that there is no caching in the i18n stuff. When you dig deeper, it doesn't make sense as the poster is complaining that the Resources class that handles errors for Standard is the one that needs caching, and he refers to ResourceMessages which does not exist. Too confusing, so WONTFIX. 31789 - Memory leak in ELEvaluator. This is the big issue - EL bits are never GC'd it seems and it grows and grows until things OOM. This is because caching is done. I've not tested this, though all I'm adding is the ability to plug your own cache in, or choose between forever caching or no caching. It's open source. If someone feels this problem strongly enough, it's not hard to go in and change it so it uses a LRUCache or something. So WONTFIX. At one point, there was a fairly healthy discussion about this: http://marc.info/?t=10982070521 Unfortunately, it seemed to just die rather abruptly. Since we're focusing on JSTL 1.1, I'd want to go back and review the code to see what's what. Based on my schedule, I won't be able to do that for another week. At the very least, I think we should expose ELEvaluator.mBypassCache via configuration and then actually honor it if it's set to false. I believe the current code skips the cache lookup when it's false but still caches the evaluation results - that seems like a bug (except that the code comments seem to imply that was the desired behavior). What do you think to the latest commit Kris? Is Justyna's unreleased 1.0.x fix good enough for us to use for 1.1.3? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory leak in ELEvaluator: approaches and alternatives
On 9/26/07, Bjorn Townsend [EMAIL PROTECTED] wrote: On Sep 26, 2007, at 10:02 PM September 26, Henri Yandell wrote: Looks good - I'll look into committing it tomorrow night, unless anyone sees a reason not to. Thanks for looking at it. I'll be happy to help out with the refactoring of the stuff from Collections. Commit applied. I'm unsure if refactoring the collections is good or not. On the one hand it feels very bad to add 16 java files for one feature, that at the end of the day is just a List and a Map tied together; and on the other hand I don't want to go changing things and making it harder to apply bugfixes in the future. Currently I'm avoiding the Collections refactor. Bugfixes win; though the worry is that people might start depending on the code as it's necessarily public. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory leak in ELEvaluator: approaches and alternatives
Interesting difference... from the previous patches. So there's the addition of the LRUMap and its baggage. Definitely better than depending on Collections, I'm very sure we don't want to add a dependency to Standard and to EL, and presumably we can't go to a 1.4 dependency, so no LinkedHashMap for us. I'm tempted to refactor things so all the interfaces aren't there, flatten it all into a single package and make it tighter. On the one hand that will make it harder to bring bugfixes over, but on the other hand it will do a lot to lowering the window that adding this opens to the API. Refactoring is best done after the first bit goes in. We should also add a Contains code from Commons Collections. Evaluator.java adds a bit where it always bypasses the cache when calling validate. I guess that makes sense and doesn't hurt to do. ELEvaluator.java is again where all the fun is. BypassCache becomes a full on property so that Evaluator can turn it off. It also adds a pageContext to allow the configuration to be set. Looks good - I'll look into committing it tomorrow night, unless anyone sees a reason not to. Hen On 9/26/07, Bjorn Townsend [EMAIL PROTECTED] wrote: I've gone ahead and created a patch for 1.1 and attached it to the issue: http://issues.apache.org/bugzilla/show_bug.cgi?id=31789 Unit tests pass nicely. Thanks, Bjorn On Sep 26, 2007, at 12:06 AM September 26, Henri Yandell wrote: * Is there any interest in adopting this solution for 1.1 given that (from my reading of the code) it could be dropped into place fairly readily and is less complex than Henri's proposed API solution? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [g...@vmgump]: Project jakarta-taglibs-datetime (in module jakarta-taglibs) failed
I'll turn off the datetime build. It depends on the request taglib, which we've deprecated. I imagine we'll be deprecating the datetime taglib pretty soon as it's pretty much replaced by JSTL. Hen On 7/25/07, Martin Cooper [EMAIL PROTECTED] wrote: To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project jakarta-taglibs-datetime has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 7 runs. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - jakarta-taglibs-datetime : DateTime Taglib Full details are available at: http://vmgump.apache.org/gump/public/jakarta-taglibs/jakarta-taglibs-datetime/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [taglibs-datetime.jar] identifier set to project name -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: jakarta-taglibs-request : unknown to *this* workspace -INFO- Failed to extract fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/jakarta-taglibs/jakarta-taglibs-datetime/rss.xml - Atom: http://vmgump.apache.org/gump/public/jakarta-taglibs/jakarta-taglibs-datetime/atom.xml == Gump Tracking Only === Produced by Gump version 2.3. Gump Run 0525072007, vmgump:vmgump-public:0525072007 Gump E-mail Identifier (unique within run) #8. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump failures
Or maybe not. Wonder why that failed On 7/22/07, Henri Yandell [EMAIL PROTECTED] wrote: Should be fixed - or send less mail anyway: svn ci -m Removing deprecated libraries, putting datetime back in though it'll probably be deprecated very soon, updating the site targets jakarta-taglibs.xml Sendingjakarta-taglibs.xml Transmitting file data . Committed revision 558511. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[unstandard] Ingesting the Log taglib
I'm +1 to pulling the whole log taglib into Unstandard. My only question is what we should put it on top of. Should we: a) Go with the last release and use log4j. b) Use the current trunk's approach and use commons-logging. c) Give up the ghost and use the JDK logging. I'm tempted by c), it's just easier. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[unstandard] Picking through the datetime taglib
Here are the tags in the DateTime taglib: * currentTimeGets the current time in milliseconds since Jan 1, 1970 GMT. * formatFormats a date in milliseconds since Jan 1, 1970 GMT for output as a date string. * parse Parses a date string and outputs the time in milliseconds since Jan 1, 1970 GMT. * timeZone Create a time zone script variable for use with the parse or format tags. * timeZones Loop through all time zones. * monthsLoop through the months of the year. * weekdays Loop through the days of the week. * amPms Loop through the am/pm names. * eras Loop through the era names. - Of the first batch; format and parse are taken of care of in JSTL with fmt:formatDate and fmt:parseDate. The currentTime tag is effectively handled by doing: jsp:useBean id=now class=java.util.Date / I'm never sure whether it's better to educate people in doing such things, or if there should be a: un:currentTime var=now/ Probably it's best to just push towards useBean. Also, the timeZone attribute to the two fmt: tags can take a String as well as an Object, so presumably that makes that one redundant. So the question becomes whether there is any value in the iterator style tags. I don't see a lot. Any thoughts? I'm tempted to think 'deprecate' for datetime and bring nothing into Unstandard. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [unstandard] Picking through the datetime taglib
On 7/23/07, Rahul Akolkar [EMAIL PROTECTED] wrote: On 7/23/07, Henri Yandell [EMAIL PROTECTED] wrote: Here are the tags in the DateTime taglib: snip/ So the question becomes whether there is any value in the iterator style tags. I don't see a lot. Any thoughts? I'm tempted to think 'deprecate' for datetime and bring nothing into Unstandard. snap/ Its upto you :-) Hope not - I don't use JSP much anymore :) The iterators are quite helpful, however, when it comes to i18n'zed old school day and date widgets etc. (for those who haven't switched to AJAXy calendar widgets yet, not that everyone can or should either). Do they work well with JSTL in their current state? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] JPA taglib
I came across this on Ohloh: https://jpa-taglib.dev.java.net/ I thought I was the only person mad enough to have done such a thing: http://osjava.googlecode.com/svn/trunk/dormant/hibernate-taglib/ Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Gump failures
Should be fixed - or send less mail anyway: svn ci -m Removing deprecated libraries, putting datetime back in though it'll probably be deprecated very soon, updating the site targets jakarta-taglibs.xml Sendingjakarta-taglibs.xml Transmitting file data . Committed revision 558511. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Micronova-Yuzu
The author of the Micronova Yuzu library, Makoto Nagata, emailed me a while back after reading about our Unstandard plans: https://micronova-yuzu.dev.java.net/ Makoto suggests that there's a lot of overlap, and wonders about sharing or collaboration. Makoto, do you have anything to add? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Unstandard Taglib creation/release (and future of Taglibs)
On 5/16/07, Henri Yandell [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Unstandard Taglib creation/release (and future of Taglibs)
On 5/21/07, Henri Yandell [EMAIL PROTECTED] wrote: On 5/16/07, Henri Yandell [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Unstandard Taglib creation/release (and future of Taglibs)
On 5/21/07, Karl von Randow [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Unstandard Taglib creation/release (and future of Taglibs)
On 5/18/07, Martin Cooper [EMAIL PROTECTED] wrote: On 5/16/07, Henri Yandell [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Unstandard Taglib creation/release (and future of Taglibs)
On 5/16/07, Karl von Randow [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FYI: enhancement to taglibs log project
Thanks Matthew, Things move slow here in Taglibs, but I'll make sure I've looked at this by the end of the week. How are you finding trunk of the Log Taglib? Specifically the usage of commons-logging rather than log4j? I made that change years ago and it's never been released. I'm not sure if it would be better to use that, or to create two taglibs, one for log4j and one for jdk logging. Hen On 5/14/07, matthewadams [EMAIL PROTECTED] wrote: Hi all, FYI, I just added a patch with enhancements that I made to the Jakarta Taglibs Log project. It's in Bugzilla at # http://issues.apache.org/bugzilla/show_bug.cgi?id=42413 http://issues.apache.org/bugzilla/show_bug.cgi?id=42413 . Patch is attached there. I hope it gets included helps out! Credit to F5 Networks ( http://www.f5.com http://www.f5.com ) for the donation. -matthew -- View this message in context: http://www.nabble.com/FYI%3A--enhancement-to-taglibs-log-project-tf3754158.html#a10609658 Sent from the Taglibs - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[proposal] Unstandard Taglib creation/release (and future of Taglibs)
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Unstandard Taglib creation/release (and future of Taglibs)
On 5/16/07, Karl von Randow [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Taglibs future
On 4/11/07, Kris Schneider [EMAIL PROTECTED] wrote: Henri Yandell wrote: The Taglibs project has been dead for years. I'm sure it's not going to improve; taglibs are a pain to implement (especially if support is targeting older JSP specs), JSTL replaced many and at the same time JSP stopped being the obvious choice for web applications. It's frustrating to both users and committers to have the project sitting with doors apparently open, so I'd like to suggest a closing up of shop. Using a similar argument - app servers are a pain to implement and Java stopped being the obvious choice for web applications - one could argue that Tomcat should pack it in. Obviously, I disagree that those are valid reasons for taking action. I'm also at a loss as to what having the doors apparently open implies. I can't recall many (any?) user questions posted to the list going unanswered. A few of the answers might amount to, Yup, looks like a bug, but that taglib isn't currently under development, but they're still answers ;-). Sorry - the complicated one wasn't meant to be a reason for shutting down, rather a reason for why activity went away. I know that I found taglibs a lot of fun at first, but then with multiple specs to support it all became quite nitty gritty and releasing another taglib (I wrote a couple more) wasn't a high itch. Mostly it was that JSTL knocked the existing Taglibs out of the water, and JSP then became uncool. For me, the biggest difference between Taglibs and a project like Tomcat is simply the community. That's the focus of Apache, right? So, the only justifiable reason for closing up shop would be the loss of community (dev and/or user). Unfortunately, that's a difficult argument to refute for Taglibs and I agree that the situation is unlikely to improve. My guess is that Tomcat and Geronimo are probably serving the community needs of the users. +1. The user list used to be active (outliving the dev list activity as you'd expect), but now we're increasingly into an inactive user list, even with the fact that's its also been a bit of a jstl-help@ mailing list. I'm not sure I understand exactly what you're suggesting from a big-picture perspective. Do you think that the entire Taglibs project should go away or do you think that it should remain but only support three taglibs: Standard 1.1, Unstandard and RDC? I'm causing trouble :) I've suggested a big picture perspective of all of Jakarta going away. With respect to Taglibs, I don't think there's any dev activity likely to happen apart from RDC. Standard 1.1.3 will hopefully happen, but we'll have taken care of the major issues and I suspect a 1.1.4 won't be very likely and there's no likelyhood on a 1.2. Though it is very tempting to sit down and talk about a 1.2. As Glassfish's 1.2 is based on our 1.1 ource, it has all the bugs and we might reach the point where people are complaining about bugs in 1.2 that we've fixed in 1.1. The 1.2 spec doesn't add that much, so would it be worth the time required to grok that and release a 1.2. Other than that, I doubt we'll see any activity. In my dreams I'd love to see us coalesce the useful parts of the taglibs into a single JSTL enhancing one, but that's a good chunk of work and I have to accept that I've not worked on a production Java webapp in a good many years - so lack of itch for me at least. Here's what I'm thinking: 1) Standard Taglib 1.1.3 release. This is getting pretty close, so it would be very nice to get a release out. Sure. I'm happy to do some more work on it. http://wiki.apache.org/jakarta-taglibs/Standard_1%2e1%2e3 There are three performance issues (17700, 32311, 31789) I've put together an SPI style fix for. I've been testing it a bit when I have time and it has bugs, but do you think that is worth doing or should we avoid such major work? 2) RDC Taglib needs to continue. It's not had a lot of activity recently, but I'm presuming that Rahul is still active on this one and that it would need to continue. My suggestion is that it joins Jakarta Commons (either at jakarta.apache.org/commons or commons.apache.org if Commons moves there). Its build system could be brought up to date too. Can't really speak to that, but Rahul's already responded. I couldn't locate it, but I thought there was supposed to be some sort of generic Web Components project. Ring a bell for anyone else? Yeah, it had general approval but the energy wasn't there to make changes. 3) Others would be end of lifed - with a request going out to find out which ones are strongly active. I would still like to coalesce many into the sandbox'd Unstandard Taglib, ie) a single taglib with various bits of value that JSTL did not replace (and making it JSP 2.0 or 2.1 specific); so I am interested in hearing which functionalities are valuable. Kicking a useful Unstandard release out the door would be great. I'd be happy to work on that as well. Since Standard 1.1 is a JSP 2.0
Re: Discussion of Bug 33934
On 3/28/07, Kris Schneider [EMAIL PROTECTED] wrote: Henri Yandell wrote: Not great feedback I'm afraid - the suggestion of fixing things in doEndTag sounds fine to me (null or ), but I'm not deep into the spec. If it's not an attribute of the tag, and it'll get recreated anew in doStartTag I don't see any reason to avoid GC having a chance. At least it's something ;-). I'd thought about trying to track down the right place to post some questions to the current JSTL (1.2) implementors (Glassfish? jstl-spec-public and/or jsp-spec-public on java.net? or?), but haven't bothered yet. I gave up on that one - the mail alias bounces and I get the distinct feeling that there's no one active on it. So I've been throwing issues into Glassfish that are spec like and resolving them on our side. Maybe I just didn't find the right place. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion of Bug 33934
Not great feedback I'm afraid - the suggestion of fixing things in doEndTag sounds fine to me (null or ), but I'm not deep into the spec. If it's not an attribute of the tag, and it'll get recreated anew in doStartTag I don't see any reason to avoid GC having a chance. Same for the c:forEach, though I've no great itch to hunt down other cases. Hen On 3/27/07, Kris Schneider [EMAIL PROTECTED] wrote: On further reflection, perhaps target should be set to instead of null to maintain exception consistency... Kris Schneider wrote: http://issues.apache.org/bugzilla/show_bug.cgi?id=33934 After some thought, here's why I think we can actually set the target property to null in doEndTag (or doFinally, if we add it) instead of release. If a request-time value is used (scriptlet expression or EL), then the spec requires that the container must reset the property's value between all reuses. In other words, setTarget should be called each time the tag is (re)used. If a literal value is used, then the container is not required to reset the property's value. First, there's type conversion to deal with. However, since the property's type is Object, a new String instance will be used. In turn, this will cause doEndTag to throw an exception because String does not expose any writable Bean properties. So, AFAICT, the only way to get a valid value for target is with a request-time value. Feedback? P.S. This is in the context of JSP 2.0 and JSTL 1.1. It may still hold true for JSP 1.2 and JSTL 1.0, even for different reasons ;-), but I haven't thought much about it... -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[standard] Remaining open 1.1.3 issues
(cf: http://wiki.apache.org/jakarta-taglibs/Standard_1%2e1%2e3 ) There are 13 issues left open now: Performance: 17700 - Someone wants caching for MessageFormat. This one would be tricky I think as it would need a proper pooling mechanism to exist. One avenue we could take is to allow for extension here via a StandardTaglibPool interface that people could implement. 27717 - x:forEach is slow. There are various solutions here, Kris was involved back in 2004 so maybe you have more thoughts on which direction we should take here Kris? 32311 - Someone wants Calendar.getInstance caching. Same issue as 17700 basically, though it would be less damaging to implement dumb caching here (I think) as Calendar patterns are _much_ more likely to repeat than message formats. We could use the same StandardTaglibPool extension interface here, I'm pretty sure both cases are a lookup(String pattern) approach. Leaks: 17388 - Various closing issues. Looks like you've got this one taken care of Kris. I hadn't clicked it was this issue when I suggested unit tests - might be painful to try and recreate this stuff so I'm +1 to charge on without trying to test for this. 25623 - Potential memory leak in tag closing in c:forEach. I think we should go with Justyna's reply here and WONTFIX it. However 33934 - Similar to the last one. Tag closing in c:set. Tim Burrell suggests a general approach that would help with 25623 too (by the sounds of it). Thoughts on these two? 31789 - Interesting one - leak in ELEvaluator. Are you still around Felipe? Seems that this is an issue where we already have a dumb pooling strategy and it needs to improve. Anyone have thoughts on solutions? 34896 - Leak in TransactionTagSupport. Looks like a problem, I suggest removing the conn = null; line in init();. Misc: 39438 - Change to use VariableResolver. I've not looked into this one yet - it seems a valid request but I don't know if we can just change things and have it still work. 31084 - Bug in formatting. Anyone here used the LocalizationContext setting? It seems pretty simple in that localtext isn't applicable as a String as far as I can tell, so it must be a reference to a LocalizationContext object. The code looks good in BundleSupport for that, so I can only assume there was a configuration error in setting that up. I'm +1 for WONTFIX, but not experienced with this feature. 22765 - first()/last() not working as desired. Deep in the XPath innards - suggest we a) make a unit test that WARNs rather than fails, b) FAQ it, and c) leave it open. Should probably do a) for 33032 too. 39195 - JBoss specific bug. Seems right and an easy fix, though I disagree with the original posters fix. Seems to me that an empty enumeration should be returned. Thoughts? 41221 - Fix source headers. I'll take care of this when the time comes. Any opinions very much appreciated, Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 17388] - Result set created in query tag is never released + update tag
I put together a Derby test bit for a different issue that I ended up WONTFIXing. I could add this in so you can make a test for this issue? Hen On 1/29/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=17388. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=17388 --- Additional Comments From [EMAIL PROTECTED] 2007-01-29 11:04 --- Just a quick note that I checked-in a fix last week (r499150): http://svn.apache.org/viewvc/jakarta/taglibs/proper/standard/trunk/src/org/apache/taglibs/standard/tag/common/sql/QueryTagSupport.java?view=diffrev=499150r1=499149r2=499150 I guess I won't close this until it can be tested properly... -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 17388] - Result set created in query tag is never released + update tag
On 1/29/07, Kris Schneider [EMAIL PROTECTED] wrote: Henri Yandell wrote: I put together a Derby test bit for a different issue that I ended up WONTFIXing. I could add this in so you can make a test for this issue? If you think that'll work, sure. I haven't given the test too much thought yet ;-). I should probably go back and make similar changes in UpdateTagSupport. I know it already takes care of closing the PreparedStatement, but there can still be some exception hiding. I'm also not sure why Throwable is being caught in those two tags... Committed. It's part of the Cactus test suite, which is a pain in the arse to setup the first time. If you've not got that setup yet, let me know if you hit any problems. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Potentially resolvable issues
Looking at the bottom of http://people.apache.org/~bayard/jstl.html (will move this over to the wiki), I've got 5 issues in a state of potential resolution: Two that are 1.0.x issues. I'm guessing the resolution here is to keep open until such time as a 1.0.x happens (with a comment that it is likely not to be released) (?): # 17440 - Locale bug. Fixed in 1.1. Needs backporting to 1.0.x (?). Leave open for 1.0.7. # 29878 - Request to update the shipped Xerces version in 1.0.x. Leaving open for 1.0.7. And three for which opinions would definitely be welcomed: # 39719 - JstlCoreTLV too strict. ACTION: WONTFIX after communicating to EG. # 30068 - x:out bug in x:forEach. ACTION: Patch ready. # 34109 - c:url double-/ problem. ACTION: Patch ready. For 30068 and 34109, my plan is to apply the patches once there are JUnit or Cactus tests to go with them (Standard has both Cactus and JUnit, but only 1 test in each currently). For 39719, I'll try sending an email to their comments@ list and if that fails I'll raise it as an issue in Glassfish. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Going beyond the spec?
On 12/14/06, Kris Schneider [EMAIL PROTECTED] wrote: I have to admit I'm a bit curious about the JSTL 1.2 code in GlassFish. I'm pretty sure it was seeded with the code from Standard 1.1, but at some point the license was just switched to CDDL. Is that kosher? There is still an org.apache package structure in the source tree: https://glassfish.dev.java.net/source/browse/glassfish/appserv-jstl/src/org/apache/ Yeah, it's based on the Apache code. I've had a high level look at the diff between that and this and it's not huge. Mostly additions for the spec I suspect, though I'm avoiding looking too closely as those changes are under CDDL and I'm pretty sure we can't apply them here. Keeping the org.apache structure is weak, but not a problem under our license. Makes it easier for them to diff, so that's an advantage of keeping the old one. The actual license change is a bit odd. The source that is there is mostly AL 2.0 licensed with the changes under CDDL and the collective files under CDDL. The new source just specifies 'Some portions copyright Apache' or some such, but doesn't mention the license that source is under. I've not looked to see if the license file and notice file are maintained - it'd be the downloaded file where it would matter most rather than what's in SVN. Apart from making sure bugs are fixed, I don't think it's likely we'd want to get into the add-ons niche. Sounds like we've quite the consensus so far on this question. No New Features!. I'll continue to punt such enhancements over to Glassfish and the EG; depending on their fix we could then consider the fix here. Just a note that there are differences between spec features and implementation features. For example, we could completely replace the XPath engine (again) if there were compelling reasons to do so. Right. There are definitely some juicy implementation features that are there to be worked on. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Going beyond the spec?
We've a few issues that are asking for things not in the spec. In some cases the spec clearly states not to do that, so I've WONTFIX'd. However in others this is something that is undefined by the spec. For example: https://issues.apache.org/bugzilla/show_bug.cgi?id=34315 [which I've WONTFIXd, but we could reopen] and https://issues.apache.org/bugzilla/show_bug.cgi?id=39431 Seems like now is a good time to decide what the next release will be. As far as I understand, this is where the RI was developed, but the RI itself sits over at Sun. The 1.2 RI is a fork of this code sitting in Glassfish. Whatever 1.1.x we release now wouldn't be an RI release (??). That said - do we want to be allowing things that differ from the spec? Changing the tld by allowing optional user/passwd bits (as per 34315) seems unlikely. However having a system property of jakarta.taglibs.standard.apos.escape=true seems doable (for 39431). Thoughts? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Going beyond the spec?
On 12/13/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 12/13/06, Henri Yandell [EMAIL PROTECTED] wrote: We've a few issues that are asking for things not in the spec. In some cases the spec clearly states not to do that, so I've WONTFIX'd. However in others this is something that is undefined by the spec. For example: https://issues.apache.org/bugzilla/show_bug.cgi?id=34315 [which I've WONTFIXd, but we could reopen] and https://issues.apache.org/bugzilla/show_bug.cgi?id=39431 Seems like now is a good time to decide what the next release will be. As far as I understand, this is where the RI was developed, but the RI itself sits over at Sun. The 1.2 RI is a fork of this code sitting in Glassfish. Whatever 1.1.x we release now wouldn't be an RI release (??). snip/ We should eradicate any references alluding to being an RI in any subsequent releases, IMO. Martin suggests differently. I suspect we'll need to talk to the EG to figure out what is going to happen when we do the next release. Two things jump to mind as questions: 1) Will the EG be redistributing the release from java.sun as the official RI? 2) Is there a TCK we need to run to claim that we are a JSTL implementation? That said - do we want to be allowing things that differ from the spec? Changing the tld by allowing optional user/passwd bits (as per 34315) seems unlikely. However having a system property of jakarta.taglibs.standard.apos.escape=true seems doable (for 39431). snap/ No, IMO. Opens the door for but you allowed foo, so why not bar kind of logic, which gets subjective and extremely hard to put a cap on. OTOH, why would anyone use the Jakarta Taglibs releases instead of the RI? One reason that is often compeling (in the generic RI vs. other impl arguments) is the availability of non-standard, but highly useful features and add-ons. This is where a niche could be carved (ofcourse, needs dev resources, since see above para). Amicable licensing could be another advantage. Amicable licensing is likely to be the main reason if we ever do a JSTL 1.2. The 1.2 spec doesn't seem much changed from the 1.1 spec so it wouldn't be impossible. Glassfish is still licensed under CDDL (dual with GPL), so as long as we don't need to modify it and re-ship it (in Tomcat, Geronimo etc) then we don't have any driving need for an AL 2.0 licensed version. Apart from making sure bugs are fixed, I don't think it's likely we'd want to get into the add-ons niche. Sounds like we've quite the consensus so far on this question. No New Features!. I'll continue to punt such enhancements over to Glassfish and the EG; depending on their fix we could then consider the fix here. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[standard] Thoughts on currently open bugs
Spent a while going through the current open bugs in Jakarta Standard. Here are my thoughts: http://people.apache.org/~bayard/jstl.html Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Reminder to subscribe to general@
We're discussing various ideas and thoughts on restructuring Jakarta on the [EMAIL PROTECTED] mailing list. On the off chance that someone isn't subscribed to the general@jakarta.apache.org mailing list, I thought I'd drop an email to each of the -dev mailing lists so they have a chance to be involved. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Standard] Applying patches
On 9/17/05, Rahul Akolkar [EMAIL PROTECTED] wrote: On 9/15/05, Felipe Leme [EMAIL PROTECTED] wrote: Rahul, AFAIK, we are all developers for all taglibs, so please feel free to apply the patches yourself without review if you are confident to do so. snip/ Just broadcasting my intent to see if anyone has anything insightful to say ;-) Of course, a peer review would be nice, but giving the current status of the project, I wouldn't count on that. In fact, I have the feeling that the even the Standard taglibs are going to be dormant, as JSTL 1.2 is now being developed at Glassfish (I just realized it these days - we have not talked about it on the list and I guess Sun just opted for this path as Glassfish is open-source and our project is dormant)... snap/ And indeed, you had quite some insight. Given the above, I'll just leave things where they are in Jakarta Taglibs Standard land. On 9/16/05, Felipe Leme [EMAIL PROTECTED] wrote: Henri Yandell wrote: Hmm. So maybe we shouldn't be moving Standard to subproject level, maybe we should just be planning to put Standard into dormancy. Haven't thought about that, but it could be an option. Anyway, I think we should ask the JSTL EG group about its plan first - I don't like the way Sun has silently hijacked JSTL to Glassfish (*), so let's not do the same. snap/ Definitely. Felipe, would you like to initiate that conversation with the JSTL EG (you might be best equipped to do that)? We're also going to have to revisit the decision about Standard's future. Cc me on that if you mail about it Felipe. As far as I understand, the JSTL EG makes up the Standard committers and their failure to be involved in the discussions about Standard implies they're not really around here anymore. I'd definitely appreciate if you took the lead on it (it's one part of the inactivity jigsaw that I'll be looking at next quarter), but if not it'll slowly rise to the top of my TODO list :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Standard] Applying patches
On 9/15/05, Felipe Leme [EMAIL PROTECTED] wrote: Rahul, AFAIK, we are all developers for all taglibs, so please feel free to apply the patches yourself without review if you are confident to do so. Of course, a peer review would be nice, but giving the current status of the project, I wouldn't count on that. In fact, I have the feeling that the even the Standard taglibs are going to be dormant, as JSTL 1.2 is now being developed at Glassfish (I just realized it these days - we have not talked about it on the list and I guess Sun just opted for this path as Glassfish is open-source and our project is dormant)... Hmm. So maybe we shouldn't be moving Standard to subproject level, maybe we should just be planning to put Standard into dormancy. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[rdc] Board report
Reminder to add a subproject report on the RDC release to the wiki (http://wiki.apache.org/jakarta/JakartaBoardReport-September2005) for the board report. The other entries there should give you a good idea as to the kind of things to say. Looking for the why's and wherefore's of the release, rather than just a reiteration of the fact the release happened. Adding some colour for the board. If you could get it done tomorrow (Thursday) or by Friday evening at the latest I would appreciate it as I try to get the report to the board by Friday night. Sorry for not reminding you earlier, most of the subprojects on the list have had this kind of thing before but I'm unsure if RDC has hit it yet. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Deprecate Redundant Taglibs
+1 to all of the below. On 8/5/05, Glenn Nielsen [EMAIL PROTECTED] wrote: +1 to deprecate all the taglibs listed below Glenn On Thu, Aug 04, 2005 at 07:18:29PM -0700, Rahul Akolkar wrote: This has been discussed before, but its time for some book-keeping. I would like to call a VOTE for declaring the following Taglibs as deprecated. The reasons, in each case, are (probably in the order of importance): 1) Much of the functionality provided by these Taglibs is now available via JSTL 2) There are no immediate plans (that I am aware of) for any dev activity for these Taglibs projects 3) There has been little dev activity for these Taglibs projects over the last year For the votes that pass, the respective Taglibs will be listed as deprecated on the Taglibs website. Ofcourse, the versioned releases will continue to be available, but there will be no nightlies (Glenn has already removed these from the nightlies last week). VOTE (A) - Application Taglib: [ ] +1 - Yes, please deprecate [ ] +0 - I'm OK with this [ ] -0 - Maybe we shouldn't (please specify reasons) [ ] -1 - We definitely shouldn't (please specify reasons) VOTE (B) - DBTags Taglib: [ ] +1 - Yes, please deprecate [ ] +0 - I'm OK with this [ ] -0 - Maybe we shouldn't (please specify reasons) [ ] -1 - We definitely shouldn't (please specify reasons) VOTE (C) - Page Taglib: [ ] +1 - Yes, please deprecate [ ] +0 - I'm OK with this [ ] -0 - Maybe we shouldn't (please specify reasons) [ ] -1 - We definitely shouldn't (please specify reasons) VOTE (D) - Request Taglib: [ ] +1 - Yes, please deprecate [ ] +0 - I'm OK with this [ ] -0 - Maybe we shouldn't (please specify reasons) [ ] -1 - We definitely shouldn't (please specify reasons) VOTE (E) - Response Taglib: [ ] +1 - Yes, please deprecate [ ] +0 - I'm OK with this [ ] -0 - Maybe we shouldn't (please specify reasons) [ ] -1 - We definitely shouldn't (please specify reasons) VOTE (F) - Session Taglib: [ ] +1 - Yes, please deprecate [ ] +0 - I'm OK with this [ ] -0 - Maybe we shouldn't (please specify reasons) [ ] -1 - We definitely shouldn't (please specify reasons) I'm +1 to deprecating all six. Not to take anything away from the utility they provided in their heyday. -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Progress on RDC release
On 7/20/05, Rahul P Akolkar [EMAIL PROTECTED] wrote: Haven't completed the release because I had a couple of questions: 1) I do not have permissions to the Jakarta site. I suppose I will need a volunteer to complete the remaining bits? I'll happily volunteer to do the relevant bits, or I can give you permission to make the changes. Remember it takes 2 hours for a change to be shown on the jakarta.apache.org site. I've given you rw permission for svn:/jakarta/site in case you want to do it. Try to use JDK 1.5 if you can, 1.4 and 1.5 XSL engines like to play around with tag order and indentation. However, feel free to use me as a resource to do it if you wish. 2) How is [ http://www.apache.org/dist/jakarta/taglibs/KEYS ] updated? Manually. /www/www.apache.org/dist/jakarta/taglibs/KEYS You copy and paste your public key onto the end of the file using the same style of format as the other entries. I read [ http://www.apache.org/dev/committers.html ]. I cannot find the Jakarta Taglibs KEYS in the jakarta.apache.org or www.apache.org site svn repositories. Since software distributions are an exception to the rule (not versioned), maybe its tied to that. If its relevant, found this comment in the apache site repository's STATUS quotedist/[ignore -- move when new site is up]/quote. Can someone guide me home? Right, as they live in the www.apache.org/dist space, and that's not handled by CVS/SVN, they've never been in the relevant repositories. I'll put it on my todo list to bring up on the relevant list (probably the [EMAIL PROTECTED] or whatever that address is). Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS-SVN Migration complete
Forgot to add that if you've not used Apache's SVN repository before, you should log onto people.apache.org and run svnpasswd to create your subversion password. Hen On 7/13/05, Henri Yandell [EMAIL PROTECTED] wrote: Taglibs is now loaded into the Apache Subversion repository. Open the following in a browser and take a look around: http://svn.apache.org/repos/asf/jakarta/taglibs/ The svn externals are setup for proper and sandbox, so you can use the following two lines to check out the equivalent of the current jakarta-taglibs modules: svn co https://svn.apache.org/repos/asf/jakarta/taglibs/trunks-proper jakarta-taglibs svn co https://svn.apache.org/repos/asf/jakarta/taglibs/trunks-sandbox jakarta-taglibs-sandbox I was able to do 'ant string' (after jar setup), and a commit went to the right mail list. Let me know if you have any problems, gotta go get a baby with an ear infection to sleep. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
CVS-SVN Migration complete
Taglibs is now loaded into the Apache Subversion repository. Open the following in a browser and take a look around: http://svn.apache.org/repos/asf/jakarta/taglibs/ The svn externals are setup for proper and sandbox, so you can use the following two lines to check out the equivalent of the current jakarta-taglibs modules: svn co https://svn.apache.org/repos/asf/jakarta/taglibs/trunks-proper jakarta-taglibs svn co https://svn.apache.org/repos/asf/jakarta/taglibs/trunks-sandbox jakarta-taglibs-sandbox I was able to do 'ant string' (after jar setup), and a commit went to the right mail list. Let me know if you have any problems, gotta go get a baby with an ear infection to sleep. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Taglibs in Subversion building
Oops, missed these replies. I will lock CVS down at 2000 US Eastern Time tomorrow (Wednesday 13th) and proceed with the migration. I'll be on #asfinfra if needed. I'll be (more as a list for me tomorrow): Migrating jakarta-taglibs-jakarta/taglibs/proper Migrating jakarta-taglibs-sandbox-jakarta/taglibs/sandbox Creating trunks-proper and trunks-sandbox directories with files at the top level of their CVS directories Editing svn:externals on these directories Setting up authentication stuff Setting up commit notifications Checking out and building String taglib Sending email If there are big problems, I'll back out and re-open cvs. Steps 3 and 4 are going to happen in the opposite way to the test repo migration, but shouldn't cause a problem. Hen On 7/10/05, Felipe Leme [EMAIL PROTECTED] wrote: Glenn Nielsen wrote: I have updated and tested the nightly build to make sure it works with the SVN repositories. I have not tested the sandbox build yet. If the main taglibs worked, the sandbox should not be a problem. Given the fact that the migration is taking forever, we should migrate the sandbox as well - if something breaks, it shouldn't be hard to fix. I will continue running the CVS version until we make the official switch. I have a patch to apply on the Datagrid, but haven't had the time to do so yet (because my environment is messed up). Anyway, I can wait until the migration... -- Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion in test repo
On 7/11/05, Martin Cooper [EMAIL PROTECTED] wrote: On Sun, 10 Jul 2005, Felipe Leme wrote: Rahul P Akolkar wrote: on the svn migration, it seems this might be a good time to request the RDC move. What do you think? I don't know about Hen, but I agree the time is appropriated. Once Taglibs is in SVN, moving RDC out of the sandbox is one SVN command, so that would definitely be the best time. ;-) Yep. We can do it post-migration. Have any of you had a chance to look at the migration? See how well it works for you and see how happy you are with svn client stuff. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion in test repo
On 6/30/05, Tim O'Brien [EMAIL PROTECTED] wrote: 2) Missing files. The migration only gets subdirectories, there are 8 files in jakarta-taglibs/ and 7 in jakarta-taglibs-sandbox/ that (I assume) need to find their way over to the trunks-proper and trunks-sandbox directories. Next step for me is to adjust Tim's scripts so they import these files at the end. Again, the solution for commons was to simply import these over manually. It wasn't pretty, but it worked. Import as in copy-svn-add/svn-import, or import as in run cvs2svn? Looks like I can use cvs2svn, provided I do it before making those directories and setting up the svn externals (needs testing). We lose the branch information on those files, 151 commits in general, 26 on branches. But it does keep the 125 HEAD commit history. I'm adding them by hand (ie no history) for the moment so we can start testing build success etc. I'll need to do a full migration again to test the cvs2svn of the top level files. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion migration Was: The current directory in taglibs SVN
On 6/26/05, Henri Yandell [EMAIL PROTECTED] wrote: On 6/26/05, Henri Yandell [EMAIL PROTECTED] wrote: Thanks Tim :) I'll play with Tims stuff tonight with the aim of having taglibs in the test repository; mostly just to confirm that I grokk Tim's stuff and can repeat it. I'll email after doing that on status, but I imagine if it's gone well I'll aim to do the migration in the day on Tuesday. Played with TIm's stuff a bit, not fully grokking it so I've mailed Tim with questions and played with variants. There are local issues (different users, existing repository) that I suspect Justin just adjusted for before with Commons but that I'm being cautious about. Tim helped me get over my confusion; works a lot better when you understand it's meant to be run locally and not against the ASF server :) Child's ear infection and work have burnt a bit more energy than I expected to lose, but I'm plugging away. Will report back tomorrow, hopefully with a test repo and a series of questions to Tim on how to setup the svn:externals trickery. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Subversion in test repo
Taglibs is now loaded into the test repo. Open the following in a browser and take a look around: http://svn.apache.org/repos/test/jakarta/taglibs/ The svn externals are setup for proper and sandbox, so you can use the following two lines to check out the equivalent of the current jakarta-taglibs modules: svn co https://svn.apache.org/repos/test/jakarta/taglibs/trunks-proper jakarta-taglibs svn co https://svn.apache.org/repos/test/jakarta/taglibs/trunks-sandbox jakarta-taglibs-sandbox There are some obvious problems to solve: 1) You can't just check out a single taglib and build it, as you need the build directories. I've not tried to see if checking out the trunks-proper and trunks-sandbox is buildable. 2) Missing files. The migration only gets subdirectories, there are 8 files in jakarta-taglibs/ and 7 in jakarta-taglibs-sandbox/ that (I assume) need to find their way over to the trunks-proper and trunks-sandbox directories. Next step for me is to adjust Tim's scripts so they import these files at the end. 3) What else? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion migration Was: The current directory in taglibs SVN
On 6/26/05, Henri Yandell [EMAIL PROTECTED] wrote: Thanks Tim :) I'll play with Tims stuff tonight with the aim of having taglibs in the test repository; mostly just to confirm that I grokk Tim's stuff and can repeat it. I'll email after doing that on status, but I imagine if it's gone well I'll aim to do the migration in the day on Tuesday. Played with TIm's stuff a bit, not fully grokking it so I've mailed Tim with questions and played with variants. There are local issues (different users, existing repository) that I suspect Justin just adjusted for before with Commons but that I'm being cautious about. CVS/SVN is down for part of tomorrow, so that'll push me back a bit, along with tonight's questions. Keep ploughing on with CVS usage; once I successfully get it in the test svn repository we'll find a time to freeze things etc. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Standard goes where? Was: Jakarta Taglibs as part of something bigger?
On 6/14/05, Martin Cooper [EMAIL PROTECTED] wrote: So a suggestion was made that Jakarta Taglibs could morph into a part of the new WebApp Commons subproject. Not only would this bring it together with other webapp-building components, but it has the potential to bring fresh blood to Taglibs and revitalise the community. I just suggested on general@ that in the case of Taglibs moving to a web-components subproject, that I thought the Standard taglib should move up to being a subproject, rather than remaining inside the component subproject. It's quite disjunct from the other taglibs (as it's a spec implementation, large, and high profile), and seems that it would do better as its own subcommunity. Any thoughts? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion migration Was: The current directory in taglibs SVN
I've started doing SVN migrations in an infra role, so if we can probably go ahead and get this moving again if you're available Tim? As a Taglibs committer, I can double-check builds and authorisation, so that should help speed it up, I just need Tim to walk me through his script and for us (taglibs) to decide another time. Hen On 5/13/05, Henri Yandell [EMAIL PROTECTED] wrote: Tim, sounds like a go to talk to Noel/Infra about next Wednesday+. Hen On 5/12/05, Glenn Nielsen [EMAIL PROTECTED] wrote: On Wed, May 11, 2005 at 09:06:59PM -0400, Rahul P Akolkar wrote: On 5/11/05, Henri Yandell [EMAIL PROTECTED] wrote: snip Rahul/Felipe/others, how does next Wednesday-ish sound? Works for me, assuming we've checked Glenn's availability since he's doing the nightlies for the sandbox (and maybe others too), and I suspect he might need to touch up on his scripts. I already have svn installed on the build system. All I can do is work on the build scripts once taglibs have been migrated to SVN. Shouldn't take me to long to update the scripts. Just let me know when. Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion migration Was: The current directory in taglibs SVN
Tim, sounds like a go to talk to Noel/Infra about next Wednesday+. Hen On 5/12/05, Glenn Nielsen [EMAIL PROTECTED] wrote: On Wed, May 11, 2005 at 09:06:59PM -0400, Rahul P Akolkar wrote: On 5/11/05, Henri Yandell [EMAIL PROTECTED] wrote: snip Rahul/Felipe/others, how does next Wednesday-ish sound? Works for me, assuming we've checked Glenn's availability since he's doing the nightlies for the sandbox (and maybe others too), and I suspect he might need to touch up on his scripts. I already have svn installed on the build system. All I can do is work on the build scripts once taglibs have been migrated to SVN. Shouldn't take me to long to update the scripts. Just let me know when. Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion migration Was: The current directory in taglibs SVN
On 5/11/05, Tim O'Brien [EMAIL PROTECTED] wrote: Hey, I'm back. I was away for some time busy writing and being expectant. But, the offer still stands, the same script we used for commons could be dusted off and used for the taglibs conversion. I'm going to NYC until Monday so next week - Wednesday would probably be a good time. I'll also check on the availability of someone from infrastructure with sufficient root-privs for this conversion. Sounds good to me. Noel's been doing the latest SVN migrations rather than Justin, you may need to start at the beginning and explain why the script is needed etc. Rahul/Felipe/others, how does next Wednesday-ish sound? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [REQUEST FOR VOTES] New committers status
On 3/6/05, Felipe Leme [EMAIL PROTECTED] wrote: Hi all, There's been 2 proposals for new committers in the last weeks (Rahul and Dhiru), but few of us has voted. I see Rahul committing back in Feb 28th. I only see two votes for Rahul. You have 3 or 4 votes for Dhiru, which is all that's needed. I'd like to request that we speed up the vote process, so we can have more committers ASAP. Nudge people for votes. Martin, Glenn, Pierre, myself are all good targets. Plus all you need is 3 +1s. I tend to avoid putting my +1 in if I call a vote, but if I need to I'll add a +1. PS: independently of the vote process, it's necessary to sign and submit a CLA (http://www.apache.org/licenses/) to the ASF in order to have commit rights. In other words, you guys could start the CLA process in parallel to the committer one... Probably not a good idea. If -1s happen, it could get weird and I think it'd be better for the confusion to be here instead of with the Apache secretary (considering that he's bottlenecked enough already). Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Subversion migration Was: The current directory in taglibs SVN
Any plans for scheduling an SVN migration? I suspect Taglibs, while pretty simple after the success of the Commons migration, is a fair amount of work for whichever admin runs the scripts so doing it towards the end of the year would be painful. Mostly I'm looking for two things. Firstly Tim/Martin to be available to assist/direct the move and secondly for the Taglib community to give them some guidance to issues/releases/commits that would need to happen before any migration could happen. Most likely it would take up most of a day in which commits would not be able to happen. Hen On 2/22/05, Martin Cooper [EMAIL PROTECTED] wrote: On Sat, 12 Feb 2005, Henri Yandell wrote: Just thought I'd ping to see where things stood on the SVN migration. Any decisions left to make, or just a question of deciding when to do it? I think we're good to go. It's just a matter of when, now. -- Martin Cooper Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Logging
On Sun, 6 Mar 2005 20:46:44 -0500, Rahul P Akolkar [EMAIL PROTECTED] wrote: -- Henri wrote: -- Been a while, but I'm pretty sure that the released log taglib (1.0) uses log4j, snip Shouldn't be that hard to release a 2.0 of the log taglib. Or 1.0 of a commons-logging taglib (rename the existing one), and maybe a 1.0 of a UGLI taglib. snap logging.apache.org do have their UGLI (or something..JULI?) interface which is a competitor to clogging now. This is great, I'd be very happy with the second option you propose: 1.0s of both clogging and UGLI. I suspect having the freedom to choose between the two will be appreciated by many JSP/taglib developers down the road. Makes sense. Some suggestion of bringing the UGLI and JCL groups together, but unsure if that'll happen or not. For my bit, I'm happy to contribute to either or both. [it seems you have most of it done already for clogging ;-)] Search and replace rocks :) Unsure how we would maintain separate UGLI and JCL versions. Working out the patches needed for UGLI-support (instead of JCL) would be very useful. Then we could try and figure out whether to have 2 branches, 2 modules, 2 packages in the same module etc. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[site] Source downloads
When redoing the Jakarta download stuff, I couldn't find a way to download the source for a Taglibs release. The Taglibs site points to the sourceindex page, but that page contained nothing for Taglibs (apart from the nightly source). Does anyone know where source tars/zips are to be found? They're not with the binaries. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[site] Download page
Just thought I'd mention the result of the last hour or so of typing: http://jakarta.apache.org/site/downloads/downloads_taglibs.html I believe all the links are good, and that it has everything currently available to download. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The current directory in taglibs SVN
Just thought I'd ping to see where things stood on the SVN migration. Any decisions left to make, or just a question of deciding when to do it? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Wiki for Taglibs?
I'm +1. Hen On Wed, 29 Sep 2004 09:37:27 +0530, Abey Mullassery [EMAIL PROTECTED] wrote: [X] +1 I want my Taglibs Wiki! [ ] 0 I am neutral on a Taglibs wiki [ ] -1 No Wiki for Taglibs! Yeah, we can put up a FAQ before the questions are asked frequently :) It would be great if we also had a place (server with JSP support) to put up the working (dynamic) examples of the taglibs. Abey Mullassery http://www.mullassery.com PS. I plan to put up atleast an applet (static) if JSP support cannot be made available. For eg. http://www.mullassery.com/software/PMIW/ (but it needs Java 1.2!) Kris Schneider wrote: Right, we'll make that the first FAQ: How should I answer a FAQ? ;-) [ ] +1 I want my Taglibs Wiki! [ ] 0 I am neutral on a Taglibs wiki [ ] -1 No Wiki for Taglibs! Quoting Martin Cooper [EMAIL PROTECTED]: If you want to make this thread the vote thread, then you should prefix the subject with [VOTE] so that people know there's a vote going on, rather than just a discussion thread. I am neutral on a Taglibs wiki, simply because there isn't all that much traffic on the lists, so I'm not sure how much it would be used. On the other hand, I do see that we could put a FAQ there, so I'd be supportive it if people promise to answer questions with just links to the FAQ instead of repeating the solutions. ;-) -- Martin Cooper On Tue, 28 Sep 2004 11:43:09 -0400, Kris Schneider [EMAIL PROTECTED] wrote: If I'm grokking the Apache Wiki structure properly, Taglibs isn't included. It seems like it would be a helpful resource to have available, so I found this at http://wiki.apache.org/general/HowToMakeWikiAdminRequests: If your request is for a new subwiki to be set up, take these steps: 1. discuss the plan with the appropriate development teams and gain consensus. 2. make sure the appropriate Project Management Committee (PMC) wants to have the wiki set up and assume responsibility over it. 3. only after #1 and #2 are done, send an e-mail. So I guess this note qualifies as the start of #1. I'll jump right in and call for a vote, but additional discussion is certainly welcome (especially if I'm being clueless about how to get this thing set up). [ ] +1 I want my Taglibs Wiki! [ ] -1 No Wiki for Taglibs! My vote's a +1. -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
string 1.1 tag missing
Just wanted to point out that we're missing a cvs tag for the 1.1 release of the string taglib. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
