Re: Removal of author tags in trunk
On Fri, Jan 24, 2014 at 11:35 PM, Mladen Turk mt...@apache.org wrote: On 01/24/2014 07:51 PM, Rainer Jung wrote: On 24.01.2014 17:24, Mladen Turk wrote: On 01/24/2014 03:14 PM, Mark Thomas wrote: If you have are for *your* @author tags to be removed from trunk, reply here and I'll make the changes. Remove either all or none. - there's to many authors we won't reach Yes, that was my point. We can all decide to remove our individual @author tag, but those folks we cannot reach will eventually stay as the sole authors of the given code. - anyone is free to remove his own author tags Is there anything that prevents us to decide to remove all @authors tags from our entire codebase? AFAICT most of the people are fine with removing their tags, so in case we can do that, I see no reason to go trough individual process. I don't see why we can't remove all. Put them into a file as the contributors (pom.xml?) and remove from the source. A lot of Commons libraries did that 5+ years back and there's been no backlash. It's not like they're Copyright statements. Hen
[Taglibs] Site updated; ready for announce.
I've updated the site to point to the 1.2.1 release. It's a bit of a kludge right now. Once RDC heads in the direction of the Attic, I'd like to move the site fully into the tomcat-site directory, avoiding any of the generated Maven noise. Then the only oddity is copying the javadoc in. Jeremy - would you like to do the honours and send the announcement email to users@tomcat and to annou...@apache.org? Hen
Re: [Taglibs] Extended?
+1 to that vision. I'll ditch the current Extended code. Hen On Tue, Jan 14, 2014 at 8:47 AM, Jeremy Boynes jboy...@apache.org wrote: On Jan 13, 2014, at 9:51 PM, Henri Yandell flame...@gmail.com wrote: Any thoughts Jeremy on our containing tags outside of the Standard implementation? I was pondering folding the Extended one (which contains two very tiny tags) into the Standard taglib, or if you don't see any likelihood for adding new ones, just removing it. If anything, I think I would rather go in the other direction, breaking Standard down into individual taglibs. I think there are a number of users who primarily rely only on core fn in their applications, using other libraries for the functionality in fmt, sql, and xml. It would be nice to be able to consume them that way. Splitting them up would also allow specific libraries to be optimized through tag plugins or by Jasper itself. Those other libraries have also not really kept up with the times. For example, fmt is heavily coupled to native Java L10N which I think still lags behind icu4j and hasn’t added basics like named placeholders, sql has been superseded by frameworks like JPA but even the basic JDBC support could take advantage of “new things like @Resource injection, and we’ve added a hard dependency on Xalan to address xml performance and the spec still hasn’t touched new features like XPath 2 or XQuery. “Extended” is a vague name so I would be in favor of just dropping it and replacing it with more specific libraries e.g. localization, xpath, json or whatever we decide to work on. Cheers Jeremy
Re: svn commit: r1555177 - in /tomcat/taglibs: extended/trunk/ rdc/trunk/ rdc/trunk/taglibs-rdc-dist/ rdc/trunk/taglibs-rdc-examples/ rdc/trunk/taglibs-rdc/ site/ standard/trunk/ taglibs-parent/trunk/
Per the below, I'll go ahead and move RDC to the Attic; waiting 72 hours in case there's a -1. Hen On Tue, Jan 14, 2014 at 4:23 PM, Rahul Akolkar rahul.akol...@gmail.comwrote: On Tue, Jan 14, 2014 at 12:49 AM, Henri Yandell flame...@gmail.com wrote: On Sun, Jan 12, 2014 at 9:16 PM, Henri Yandell flame...@gmail.com wrote: My main concern is it makes inactive codebases seem alive. ie) extended looks as though there's been code change in the last 5 years instead of only having had code in it in 2009. Similar with RDC. On this topic, I've pinged Rahul offline to get his thoughts on retiring RDC to the Attic. I'm assuming he's not tracking the dev list. snip/ I'm here, but no dev cycles for RDC at the moment or in the near future. So, attic sounds right. -Rahul
[PMC] KEYS copying [Was: Taglib Site Update]
Could someone on the PMC copy Jeremy's entry at the end of the KEYS file located here: https://svn.apache.org/repos/asf/tomcat/trunk/KEYS to here? https://www.apache.org/dist/tomcat/taglibs/KEYS Thanks :) Hen On Mon, Jan 13, 2014 at 6:58 AM, Jeremy Boynes jboy...@apache.org wrote: On Jan 12, 2014, at 10:56 PM, Henri Yandell flame...@gmail.com wrote: On Jan 11, 2014, at 10:58 PM, Henri Yandell flame...@gmail.com wrote: Remaining tasks: * Create a page to show source location. * Create a .cgi page for download mirrors *I hope that's gotten easier* * Change urls to point to mirror rather than archive * Push content into tomcat-site/taglibs manually * Change the news item on Tomcat itself to announce the release *http://tomcat.apache.org/download-taglibs.cgi http://tomcat.apache.org/download-taglibs.cgi* now exists. Jeremy - could you upload your public sig to a KEYS file at: https://www.apache.org/dist/tomcat/taglibs/KEYS It seems there's a trunk/KEYS for all Tomcat RMs, but also specific KEYS files per downloaded product. I'm not sure of the right way to put files in dist.apache.org nowadays, but I figure you would have hit it during release :) I don’t think I can - access to the release tree is limited to PMC members. I have added my key here: https://svn.apache.org/repos/asf/tomcat/trunk/KEYS if someone can copy it. Thanks Jeremy
Re: svn commit: r1555177 - in /tomcat/taglibs: extended/trunk/ rdc/trunk/ rdc/trunk/taglibs-rdc-dist/ rdc/trunk/taglibs-rdc-examples/ rdc/trunk/taglibs-rdc/ site/ standard/trunk/ taglibs-parent/trunk/
On Sun, Jan 12, 2014 at 9:16 PM, Henri Yandell flame...@gmail.com wrote: My main concern is it makes inactive codebases seem alive. ie) extended looks as though there's been code change in the last 5 years instead of only having had code in it in 2009. Similar with RDC. On this topic, I've pinged Rahul offline to get his thoughts on retiring RDC to the Attic. I'm assuming he's not tracking the dev list. Hen
[Taglibs] Extended?
Any thoughts Jeremy on our containing tags outside of the Standard implementation? I was pondering folding the Extended one (which contains two very tiny tags) into the Standard taglib, or if you don't see any likelihood for adding new ones, just removing it. Hen
Re: svn commit: r1555177 - in /tomcat/taglibs: extended/trunk/ rdc/trunk/ rdc/trunk/taglibs-rdc-dist/ rdc/trunk/taglibs-rdc-examples/ rdc/trunk/taglibs-rdc/ site/ standard/trunk/ taglibs-parent/trunk/
On Sun, Jan 12, 2014 at 3:39 AM, Rainer Jung rainer.j...@kippdata.dewrote: Hi Henri, On 11.01.2014 22:15, Henri Yandell wrote: Shouldn't be changing the copyright date until we actually make a copyrightable modification to that product. Not sure whether the until we actually make a copyrightable modification part is required. The various site pages about the NOTICE file don't clarify it. The best I could find was http://www.apache.org/legal/src-headers.html The top of each NOTICE file should include the following text, suitably modified to reflect the product name and year(s) of distribution of the current and past versions of the product:. Then there's the legal issue (still open) https://issues.apache.org/jira/browse/LEGAL-51 in which you participated and finally a reference to http://www.oppedahl.com/copyrights/#notice Most of the discussion seems to be about using only one year or a range, and if only one year whether the first year or the current publication year. The legal texts cited do not contain the terminology version for software and thus it seems unclear how to apply them. Concerning the point in time when to adopt the year (if at all): I got the impression the whole discussion is only about a release. As long as the files are only in svn the correct copyright handling is not of big importance. Now if it is acceptable at the time of a release to use the copyright notice of the form FirstYear-CurrentYear, then I think it is fine and helpful to adjust the NOTICE line at the start of a year to prevent forgetting the adjustment at the time of release. That was my motivation. Of course in the light of LEGAL-51 it might be that the whole adjustment of Copyright year in unnecessary at all - but the issue is not finally decided - and it also might be that some future release does not contain any copyrightable change. I would prefer the risk of using the wrong (newer) copyright year in this very unlikely case instead of the risk of forgetting to update NOTICE during the release process. But that's of course a very personal view. Since I never contributed to taglibs I am very unfamiliar to the project specific policies and would be fine to revert if you would prefer that. My main concern is it makes inactive codebases seem alive. ie) extended looks as though there's been code change in the last 5 years instead of only having had code in it in 2009. Similar with RDC. Other than that, I think it's mainly pedantry :) 80 years is so far off that I don't see anyone caring that the copyright to a piece of code here just expired, especially given our licence. It also seems unlikely that there would be any gain in having stated a copyright year as being later than it was; again given our license. Hen
Re: Taglib Site Update
On Jan 11, 2014, at 10:58 PM, Henri Yandell flame...@gmail.com wrote: Remaining tasks: * Create a page to show source location. * Create a .cgi page for download mirrors *I hope that's gotten easier* * Change urls to point to mirror rather than archive * Push content into tomcat-site/taglibs manually * Change the news item on Tomcat itself to announce the release *http://tomcat.apache.org/download-taglibs.cgi http://tomcat.apache.org/download-taglibs.cgi* now exists. Jeremy - could you upload your public sig to a KEYS file at: https://www.apache.org/dist/tomcat/taglibs/KEYS It seems there's a trunk/KEYS for all Tomcat RMs, but also specific KEYS files per downloaded product. I'm not sure of the right way to put files in dist.apache.org nowadays, but I figure you would have hit it during release :) Hen
Taglib Site Update
Started digging into this last night. New computer so checkout, figure out right version of Maven etc. 3.1.1 has issues with the site, so you have to stay on 3.0.5. I've made some initial changes, then discovered that we seem to have lost the xdoc for the website (one file) for the standard subcomponent. So my task tonight is to hunt that page down in the svn history and bring it back. Hen
Re: svn commit: r1555177 - in /tomcat/taglibs: extended/trunk/ rdc/trunk/ rdc/trunk/taglibs-rdc-dist/ rdc/trunk/taglibs-rdc-examples/ rdc/trunk/taglibs-rdc/ site/ standard/trunk/ taglibs-parent/trunk/
Shouldn't be changing the copyright date until we actually make a copyrightable modification to that product. Hen On Fri, Jan 3, 2014 at 10:08 AM, rj...@apache.org wrote: Author: rjung Date: Fri Jan 3 18:08:32 2014 New Revision: 1555177 URL: http://svn.apache.org/r1555177 Log: Happy new 2014! Modified: tomcat/taglibs/extended/trunk/NOTICE.txt tomcat/taglibs/rdc/trunk/NOTICE.txt tomcat/taglibs/rdc/trunk/taglibs-rdc-dist/NOTICE.txt tomcat/taglibs/rdc/trunk/taglibs-rdc-examples/NOTICE.txt tomcat/taglibs/rdc/trunk/taglibs-rdc/NOTICE.txt tomcat/taglibs/site/NOTICE.txt tomcat/taglibs/standard/trunk/NOTICE tomcat/taglibs/taglibs-parent/trunk/NOTICE Modified: tomcat/taglibs/extended/trunk/NOTICE.txt URL: http://svn.apache.org/viewvc/tomcat/taglibs/extended/trunk/NOTICE.txt?rev=1555177r1=1555176r2=1555177view=diff == --- tomcat/taglibs/extended/trunk/NOTICE.txt (original) +++ tomcat/taglibs/extended/trunk/NOTICE.txt Fri Jan 3 18:08:32 2014 @@ -1,5 +1,5 @@ Apache Extended Taglib -Copyright 2009-2012 The Apache Software Foundation +Copyright 2009-2014 The Apache Software Foundation -This product includes software developed by +This product includes software developed at The Apache Software Foundation (http://www.apache.org/). Modified: tomcat/taglibs/rdc/trunk/NOTICE.txt URL: http://svn.apache.org/viewvc/tomcat/taglibs/rdc/trunk/NOTICE.txt?rev=1555177r1=1555176r2=1555177view=diff == --- tomcat/taglibs/rdc/trunk/NOTICE.txt (original) +++ tomcat/taglibs/rdc/trunk/NOTICE.txt Fri Jan 3 18:08:32 2014 @@ -1,5 +1,5 @@ Apache Jakarta Taglibs Reusable Dialog Components (RDC) Tag Library -Copyright 2004-2012 The Apache Software Foundation +Copyright 2004-2014 The Apache Software Foundation -This product includes software developed by +This product includes software developed at The Apache Software Foundation (http://www.apache.org/). Modified: tomcat/taglibs/rdc/trunk/taglibs-rdc-dist/NOTICE.txt URL: http://svn.apache.org/viewvc/tomcat/taglibs/rdc/trunk/taglibs-rdc-dist/NOTICE.txt?rev=1555177r1=1555176r2=1555177view=diff == --- tomcat/taglibs/rdc/trunk/taglibs-rdc-dist/NOTICE.txt (original) +++ tomcat/taglibs/rdc/trunk/taglibs-rdc-dist/NOTICE.txt Fri Jan 3 18:08:32 2014 @@ -1,5 +1,5 @@ Apache Jakarta Taglibs Reusable Dialog Components (RDC) Tag Library Distributions -Copyright 2004-2012 The Apache Software Foundation +Copyright 2004-2014 The Apache Software Foundation -This product includes software developed by +This product includes software developed at The Apache Software Foundation (http://www.apache.org/). Modified: tomcat/taglibs/rdc/trunk/taglibs-rdc-examples/NOTICE.txt URL: http://svn.apache.org/viewvc/tomcat/taglibs/rdc/trunk/taglibs-rdc-examples/NOTICE.txt?rev=1555177r1=1555176r2=1555177view=diff == --- tomcat/taglibs/rdc/trunk/taglibs-rdc-examples/NOTICE.txt (original) +++ tomcat/taglibs/rdc/trunk/taglibs-rdc-examples/NOTICE.txt Fri Jan 3 18:08:32 2014 @@ -1,5 +1,5 @@ Apache Jakarta Taglibs Reusable Dialog Components (RDC) Tag Library Examples Application -Copyright 2004-2012 The Apache Software Foundation +Copyright 2004-2014 The Apache Software Foundation -This product includes software developed by +This product includes software developed at The Apache Software Foundation (http://www.apache.org/). Modified: tomcat/taglibs/rdc/trunk/taglibs-rdc/NOTICE.txt URL: http://svn.apache.org/viewvc/tomcat/taglibs/rdc/trunk/taglibs-rdc/NOTICE.txt?rev=1555177r1=1555176r2=1555177view=diff == --- tomcat/taglibs/rdc/trunk/taglibs-rdc/NOTICE.txt (original) +++ tomcat/taglibs/rdc/trunk/taglibs-rdc/NOTICE.txt Fri Jan 3 18:08:32 2014 @@ -1,5 +1,5 @@ Apache Jakarta Taglibs Reusable Dialog Components (RDC) Tag Library -Copyright 2004-2012 The Apache Software Foundation +Copyright 2004-2014 The Apache Software Foundation -This product includes software developed by +This product includes software developed at The Apache Software Foundation (http://www.apache.org/). Modified: tomcat/taglibs/site/NOTICE.txt URL: http://svn.apache.org/viewvc/tomcat/taglibs/site/NOTICE.txt?rev=1555177r1=1555176r2=1555177view=diff == --- tomcat/taglibs/site/NOTICE.txt (original) +++ tomcat/taglibs/site/NOTICE.txt Fri Jan 3 18:08:32 2014 @@ -1,5 +1,5 @@ Apache Jakarta Taglib Website -Copyright 2009-2012 The Apache Software Foundation +Copyright 2009-2014 The Apache Software Foundation -This product includes software developed by +This
Re: svn commit: r1555177 - in /tomcat/taglibs: extended/trunk/ rdc/trunk/ rdc/trunk/taglibs-rdc-dist/ rdc/trunk/taglibs-rdc-examples/ rdc/trunk/taglibs-rdc/ site/ standard/trunk/ taglibs-parent/trunk/
On Saturday, January 11, 2014, Konstantin Kolinko wrote: 2014/1/12 Henri Yandell flame...@gmail.com javascript:;: Shouldn't be changing the copyright date until we actually make a copyrightable modification to that product. I think this itself is one, as it fixes typos in the NOTICE files. That's not a copyrightable change :) Best regards, Konstantin Kolinko On Fri, Jan 3, 2014 at 10:08 AM, rj...@apache.org wrote: Author: rjung Date: Fri Jan 3 18:08:32 2014 New Revision: 1555177 URL: http://svn.apache.org/r1555177 Log: Happy new 2014! Modified: tomcat/taglibs/extended/trunk/NOTICE.txt tomcat/taglibs/rdc/trunk/NOTICE.txt tomcat/taglibs/rdc/trunk/taglibs-rdc-dist/NOTICE.txt tomcat/taglibs/rdc/trunk/taglibs-rdc-examples/NOTICE.txt tomcat/taglibs/rdc/trunk/taglibs-rdc/NOTICE.txt tomcat/taglibs/site/NOTICE.txt tomcat/taglibs/standard/trunk/NOTICE tomcat/taglibs/taglibs-parent/trunk/NOTICE Modified: tomcat/taglibs/extended/trunk/NOTICE.txt URL: http://svn.apache.org/viewvc/tomcat/taglibs/extended/trunk/NOTICE.txt?rev=1555177r1=1555176r2=1555177view=diff == --- tomcat/taglibs/extended/trunk/NOTICE.txt (original) +++ tomcat/taglibs/extended/trunk/NOTICE.txt Fri Jan 3 18:08:32 2014 @@ -1,5 +1,5 @@ Apache Extended Taglib -Copyright 2009-2012 The Apache Software Foundation +Copyright 2009-2014 The Apache Software Foundation -This product includes software developed by +This product includes software developed at The Apache Software Foundation (http://www.apache.org/). Modified: tomcat/taglibs/rdc/trunk/NOTICE.txt URL: http://svn.apache.org/viewvc/tomcat/taglibs/rdc/trunk/NOTICE.txt?rev=1555177r1=1555176r2=1555177view=diff == --- tomcat/taglibs/rdc/trunk/NOTICE.txt (original) +++ tomcat/taglibs/rdc/trunk/NOTICE.txt Fri Jan 3 18:08:32 2014 @@ -1,5 +1,5 @@ Apache Jakarta Taglibs Reusable Dialog Components (RDC) Tag Library -Copyright 2004-2012 The Apache Software Foundation +Copyright 2004-2014 The Apache Software Foundation -This product includes software developed by +This product includes software developed at The Apache Software Foundation (http://www.apache.org/). Modified: tomcat/taglibs/rdc/trunk/taglibs-rdc-dist/NOTICE.txt URL: http://svn.apache.org/viewvc/tomcat/taglibs/rdc/trunk/taglibs-rdc-dist/NOTICE.txt?rev=1555177r1=1555176r2=1555177view=diff == --- tomcat/taglibs/rdc/trunk/taglibs-rdc-dist/NOTICE.txt (original) +++ tomcat/taglibs/rdc/trunk/taglibs-rdc-dist/NOTICE.txt Fri Jan 3 18:08:32 2014 @@ -1,5 +1,5 @@ Apache Jakarta Taglibs Reusable Dialog Components (RDC) Tag Library Distributions -Copyright 2004-2012 The Apache Software Foundation +Copyright 2004-2014 The Apache Software Foundation -This product includes software developed by +This product includes software developed at The Apache Software Foundation (http://www.apache.org/). Modified: tomcat/taglibs/rdc/trunk/taglibs-rdc-examples/NOTICE.txt URL: http://svn.apache.org/viewvc/tomcat/taglibs/rdc/trunk/taglibs-rdc-examples/NOTICE.txt?rev=1555177r1=1555176r2=1555177view=diff
Re: Taglib Site Update
Thanks. Wish I'd looked here before digging myself. I assumed it was something weird I did when moving over from Jakarta and spent far too much time digging into the old code there :) --- I've gone ahead and put that file back in, but in the overall Taglibs site. I'm not convinced we need a separate Maven generated site. A single file, and copy the apidocs over from the taglib itself. I'm also going to dump the link to CI (not working), test javadoc (dull) and the link to the wiki (not there). The main loss in ditching the separate Maven site are any items of value in the project reports at http://tomcat.apache.org/taglibs/standard/project-info.html. Most are noise or duplicates. Primarily we lack a page showing where to get the source. Remaining tasks: * Create a page to show source location. * Create a .cgi page for download mirrors *I hope that's gotten easier* * Change urls to point to mirror rather than archive * Push content into tomcat-site/taglibs manually * Change the news item on Tomcat itself to announce the release Hen On Sat, Jan 11, 2014 at 3:52 PM, Konstantin Kolinko knst.koli...@gmail.comwrote: 2014/1/12 Henri Yandell flame...@gmail.com: Started digging into this last night. New computer so checkout, figure out right version of Maven etc. 3.1.1 has issues with the site, so you have to stay on 3.0.5. I've made some initial changes, then discovered that we seem to have lost the xdoc for the website (one file) for the standard subcomponent. So my task tonight is to hunt that page down in the svn history and bring it back. https://svn.apache.org/r1540559 ? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Standard Taglib 1.2.1
A very late and non-binding +1 :) On Wed, Nov 13, 2013 at 6:58 PM, Jeremy Boynes jboy...@apache.org wrote: I'd like to release Apache Standard Taglib 1.2.1. This is an update to the withdrawn 1.2.0, built with JDK 1.7.0_45 to address JavaDoc issues and incorporating feedback on the documentation. Maven Staging Repository: https://repository.apache.org/content/repositories/orgapachetomcat-132/ Source Distribution: https://repository.apache.org/content/repositories/orgapachetomcat-132/org/apache/taglibs/taglibs-standard/1.2.1/ SVN tag: https://svn.apache.org/repos/asf/tomcat/taglibs/standard/tags/taglibs-standard-1.2.1@ r1541786 https://svn.apache.org/r1541786 KEYS: https://svn.apache.org/repos/asf/tomcat/trunk/KEYS The proposed 1.2.1 release is: [ ] Broken - do not release [ ] OK - release as 1.2.1 Thanks Jeremy
Re: [taglibs] Examples and doc
Shall we move the examples up to tomcat/taglibs/standard-examples/trunk? On Fri, Aug 23, 2013 at 2:37 PM, Henri Yandell flame...@gmail.com wrote: +1 to both. On Friday, August 9, 2013, Jeremy Boynes wrote: On Aug 6, 2013, at 10:13 PM, Henri Yandell flame...@gmail.com wrote: Slowly digging into this. Thus far I've confirmed the source builds :) Next up is working out how to deploy the examples. Wondering here if it would be better to release the examples separately as they can be decoupled. IOW, we would expect the example code not to change wiht releases of the main libraries, and vice versa. Also, how about dropping the doc directory and rolling the content into the website? - Jeremy
Re: [taglibs] Examples
Tomorrow takes time apparently :) Here's my current status: General Purpose Tags - PASSED Conditional Tags - PASSED Iterator Tags - PASSED Import Tags I18N Formatting Tags XML Tags SQL Tags Functions - PASSED Tag Library Validators Hen On Tue, Aug 6, 2013 at 11:16 PM, Henri Yandell flame...@gmail.com wrote: To test out Jeremy's proposed alpha Standard 1.2 release I needed some code to run against it. I turned to the old examples that at some point were used to verify things (the standard/examples directory). Surprisingly, I've got them up and running. I build with mvn package then copy the war to a Tomcat 7 to be deployed. A few examples error - I suspect because of either issues in setup or because later servlet/jsp/jstl specs made what they're doing illegal. I'll aim to go through them tomorrow and list the ones that appear to be problematic. Hen
Re: [taglibs] Examples and doc
+1 to both. On Friday, August 9, 2013, Jeremy Boynes wrote: On Aug 6, 2013, at 10:13 PM, Henri Yandell flame...@gmail.comjavascript:; wrote: Slowly digging into this. Thus far I've confirmed the source builds :) Next up is working out how to deploy the examples. Wondering here if it would be better to release the examples separately as they can be decoupled. IOW, we would expect the example code not to change wiht releases of the main libraries, and vice versa. Also, how about dropping the doc directory and rolling the content into the website? - Jeremy
[taglibs] Examples
To test out Jeremy's proposed alpha Standard 1.2 release I needed some code to run against it. I turned to the old examples that at some point were used to verify things (the standard/examples directory). Surprisingly, I've got them up and running. I build with mvn package then copy the war to a Tomcat 7 to be deployed. A few examples error - I suspect because of either issues in setup or because later servlet/jsp/jstl specs made what they're doing illegal. I'll aim to go through them tomorrow and list the ones that appear to be problematic. Hen
Re: [VOTE] Release Apache Taglibs 1.2.0-RC1
Slowly digging into this. Thus far I've confirmed the source builds :) Next up is working out how to deploy the examples. Hen On Fri, Aug 2, 2013 at 12:32 PM, Jeremy Boynes jboy...@apache.org wrote: A proposed release candidate Apache Taglibs 1.2.0-RC1 is now available for voting. This is release candidate for an implementation of JSTL 1.2 and can be obtained from the staging repo at: https://repository.apache.org/content/repositories/orgapachetomcat-053/ The source distribution can be obtained from: https://repository.apache.org/content/repositories/orgapachetomcat-053/org/apache/taglibs/taglibs-standard/1.2.0-RC1/ The proposed 1.2.0-RC1 candidate is: [ ] Broken - do not release [ ] Alpha - can be released as 1.2.0-RC1 alpha This is the first release in a long time, and the first since switching to Maven. If there are issues, please list all concerns so they can be addressed. Thanks Jeremy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [taglibs] Site plans
On Mon, Jul 1, 2013 at 3:04 AM, Olivier Lamy ol...@apache.org wrote: Apologize for delayed response. 2013/6/26 Jeremy Boynes jboy...@apache.org: On Jun 25, 2013, at 7:54 AM, Henri Yandell flame...@gmail.com wrote: Help much appreciated - but do we want all the content of all the modules to be there? It feels to me that the website does not map directly to the codebase. We want an overall site, and subsites for Standard and for RDC. We don't want to have the 14 pom.xmls become a site structure, or the 4 pom.xmls (tld-generator and extended). Three mini-sites sounds good: a top-level one holding things together and then sub-sites for standard and RDC. Is there a way to associate the top-level one with the parent POM and the others with the root poms in standard and rdc? That would match with the things that are likely to be released (being all standard packages together, or all rdc packages together, but not both at the same time). Do we still need an aggregator pom as well - how about setting up separate CI jobs for standard and rdc? Coud be possible but do you want to deploy sites from tagged modules versions ? (I presume yes). In such case that will changed a bit as all modules will be in a different svn path. Apologies for no change on this - I've spent the week with flu. I wouldn't expect to deploy the site from tags - a site is a live/current thing. Hen
Re: [taglibs] Site plans
Help much appreciated - but do we want all the content of all the modules
to be there?
It feels to me that the website does not map directly to the codebase. We
want an overall site, and subsites for Standard and for RDC. We don't want
to have the 14 pom.xmls become a site structure, or the 4 pom.xmls
(tld-generator and extended).
Hen
On Mon, Jun 24, 2013 at 5:23 AM, Olivier Lamy ol...@apache.org wrote:
Hi,
Can be easy :-)
mvn site site:stage and all the content of all modules will be in
${project.build.directory}/staging (target/staging).
But to achieve this and having something easy we must the site module
on the top!
Means here http://svn.apache.org/repos/asf/tomcat/taglibs/trunks/
As we don't release the site (that doesn't shok me :-) ).
With this tree deploying the site will be as easy as: mvn clean site
site:stage mvn scm-publish:publish-scm
Make sense ?
I can work on that or help you if you want.
2013/6/24 Henri Yandell flame...@gmail.com:
FYI that I'm digging into the Taglibs site to figure out how it is we go
from 15 Maven target/site directories to 1 site.
I'm then going to write a dumb shell script that copies the relevant
parts
to a Tomcat site/taglibs checkout, allowing for the site to be updated.
I'm
sure there's a very clever Maven plugin that can take care of this and
handle the logic of the 15 maven projects becoming 1 site, but I'd rather
build Lego :)
Hen
--
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[taglibs] Building Standard
Coming back to this after a while :) Does anyone else get errors when trying to build standard regarding LocaleUtils? /Users/hen/Keep/OSS/apache/tomcat-taglibs/standard/jstlel/src/main/java/org/apache/taglibs/standard/tag/el/fmt/ParseDateTag.java:[25,49] cannot find symbol symbol : class LocaleUtil location: package org.apache.taglibs.standard.tag.common.fmt /Users/hen/Keep/OSS/apache/tomcat-taglibs/standard/jstlel/src/main/java/org/apache/taglibs/standard/tag/el/fmt/ParseNumberTag.java:[25,49] cannot find symbol symbol : class LocaleUtil location: package org.apache.taglibs.standard.tag.common.fmt /Users/hen/Keep/OSS/apache/tomcat-taglibs/standard/jstlel/src/main/java/org/apache/taglibs/standard/tag/el/fmt/ParseDateTag.java:[194,28] cannot find symbol symbol : variable LocaleUtil location: class org.apache.taglibs.standard.tag.el.fmt.ParseDateTag /Users/hen/Keep/OSS/apache/tomcat-taglibs/standard/jstlel/src/main/java/org/apache/taglibs/standard/tag/el/fmt/ParseNumberTag.java:[164,28] cannot find symbol symbol : variable LocaleUtil location: class org.apache.taglibs.standard.tag.el.fmt.ParseNumberTag ?
Re: [taglibs] Building Standard
Figured out. I was using mvn package rather than mvn install. Too used to simple dependency structures over in Commons. Hen On Fri, Jun 21, 2013 at 7:51 AM, Henri Yandell flame...@gmail.com wrote: Coming back to this after a while :) Does anyone else get errors when trying to build standard regarding LocaleUtils? /Users/hen/Keep/OSS/apache/tomcat-taglibs/standard/jstlel/src/main/java/org/apache/taglibs/standard/tag/el/fmt/ParseDateTag.java:[25,49] cannot find symbol symbol : class LocaleUtil location: package org.apache.taglibs.standard.tag.common.fmt /Users/hen/Keep/OSS/apache/tomcat-taglibs/standard/jstlel/src/main/java/org/apache/taglibs/standard/tag/el/fmt/ParseNumberTag.java:[25,49] cannot find symbol symbol : class LocaleUtil location: package org.apache.taglibs.standard.tag.common.fmt /Users/hen/Keep/OSS/apache/tomcat-taglibs/standard/jstlel/src/main/java/org/apache/taglibs/standard/tag/el/fmt/ParseDateTag.java:[194,28] cannot find symbol symbol : variable LocaleUtil location: class org.apache.taglibs.standard.tag.el.fmt.ParseDateTag /Users/hen/Keep/OSS/apache/tomcat-taglibs/standard/jstlel/src/main/java/org/apache/taglibs/standard/tag/el/fmt/ParseNumberTag.java:[164,28] cannot find symbol symbol : variable LocaleUtil location: class org.apache.taglibs.standard.tag.el.fmt.ParseNumberTag ?
Re: Time for Taglibs to be sent to the archive?
On Mon, Jan 28, 2013 at 3:46 AM, Mark Thomas ma...@apache.org wrote: On 26/01/2013 21:51, Henri Yandell wrote: On Fri, Jan 18, 2013 at 8:30 AM, Jeremy Boynes jer...@boynes.com wrote: On Jan 18, 2013, at 1:34 AM, Konstantin Kolinko wrote: Regarding the two taglibs that are not yet in the attic, I have no interest in RDC taglib, but I am interested in JSTL one. +1 I think once we make the first release, things should go easier after that. A few notes after quick review of the sources: 1. Can we go up from Java 5 and require/use at least Java 6 to build the project? I am even OK to be brave and go up to Java 7. I do not like Java 5, because a) It is outdated. It would be strange for a new project to use that if we are going to support it for long. b) It is not opensource. OpenJDK is since Java 6. The version of Java is important for this class, that implements javax.sql.DataSource: \standard\impl\src\main\java\org\apache\taglibs\standard\tag\common\sql\DataSourceWrapper.java Java 7 will allow us to support a later version of JDBC and will allow this project to build on Gump. There is also an issue with the I18N tags taking a long time to start on a Java6 platform due to changes in the way Locales are located by the JRE. I remember some discussion on fixing this but a requirement to stay on Java 5 meant having to build two implementations and switch between them which I'd planned to do once a release was out. If we pre-req 6 or 7 then the implementation can just be updated and this issue closed easier. Would the TCK pass if it was on Java 7? We are talking about Taglibs 1.2 right? (If not adjust versions below accordingly). Taglibs 1.2 requires JSP 2.1. JSP 2.1 requires Java 5 or later (as does Servlet 2.5 and J2EE 5). Based on that, I would say that the TCK has to pass when running on Java 5. /me goes looking for some TCK docs I've just checked the latest version of the TCK documentation for JSTL 1.2 and while the TCK has been updated so it will run on Java 7, the reference runtime remains Java 5. My interpretation of that is that the TCK must pass when running with a Java 5 JRE. We could use the Tomcat trick though. if(passTCKFlag) then do the no-one-wants option. Then by default it could run smoothly on JDK 7. I've vague memories that the SQL side of things makes that painful. Did you look at that Jeremy? Hen - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Time for Taglibs to be sent to the archive?
On Fri, Jan 18, 2013 at 8:30 AM, Jeremy Boynes jer...@boynes.com wrote: On Jan 18, 2013, at 1:34 AM, Konstantin Kolinko wrote: Regarding the two taglibs that are not yet in the attic, I have no interest in RDC taglib, but I am interested in JSTL one. +1 I think once we make the first release, things should go easier after that. A few notes after quick review of the sources: 1. Can we go up from Java 5 and require/use at least Java 6 to build the project? I am even OK to be brave and go up to Java 7. I do not like Java 5, because a) It is outdated. It would be strange for a new project to use that if we are going to support it for long. b) It is not opensource. OpenJDK is since Java 6. The version of Java is important for this class, that implements javax.sql.DataSource: \standard\impl\src\main\java\org\apache\taglibs\standard\tag\common\sql\DataSourceWrapper.java Java 7 will allow us to support a later version of JDBC and will allow this project to build on Gump. There is also an issue with the I18N tags taking a long time to start on a Java6 platform due to changes in the way Locales are located by the JRE. I remember some discussion on fixing this but a requirement to stay on Java 5 meant having to build two implementations and switch between them which I'd planned to do once a release was out. If we pre-req 6 or 7 then the implementation can just be updated and this issue closed easier. Would the TCK pass if it was on Java 7? Hen - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Time for Taglibs to be sent to the archive?
Do we have to do any bureaucratize to register as having passed the TCK? Or is it: * Generate release artifacts. * VOTE on release. * VOTE on Attic. * Publish. * Make project read-only. Hen On Mon, Dec 31, 2012 at 3:11 PM, Henri Yandell flame...@gmail.com wrote: What exactly is left to do the release? Not having a permissively licensed JSTL 1.2 is a shame when the code is there. Even if we put it in the Attic, I'd love to say And here is a 1.2 compliant version, good luck rather than sorry, get it from SVN. I'd be happy to put in the effort to do the votes/website. I'd need to hit the site anyway as a part of sending it to the Attic. Is it 100% good on the TCK, nothing more needed? Hen On Mon, Nov 26, 2012 at 4:44 PM, Jeremy Boynes jboy...@apache.org wrote: +0 It's perhaps not surprising that there is not much activity as there has been no update to the JSR in many years. The JSTL code in trunk does pass the 1.2 TCK and could be released if someone had the energy to fix the website and rustle up votes. On Oct 13, 2012, at 10:58 AM, Henri Yandell wrote: Hard to argue against it. I've no energy for Taglibs coding. I wish we'd got a JSTL 1.2 released, but c'est la vie. All the steps listed sound good except removing the website. Historically on the Attic side we've kept the websites up with a notice that the project is dead, rather than going dark on people. Hen On Mon, Oct 1, 2012 at 12:55 AM, Henri Gomez henri.go...@gmail.com wrote: If there is no activity, it make sense. +0 2012/10/1 Mark Thomas ma...@apache.org: In the two+ years since Taglibs moved to the Tomcat project there have been a few short bursts of activity totalling just over 200 commits but no releases. There has also been no progress towards a migration to svnpubsub for the taglibs part of the web site. Given the lack of progress I would propose that Taglibs is moved to our archive. This would mean: - removing the Taglibs link from tomcat.a.o - removing the Taglibs web pages - moving the tomcat/tagslibs svn tree to tomcat/archive/taglibs - making the Taglibs BZ project read-only - moving the Taglibs committers to emeritus status - removing the Taglibs from Gump There is nothing to remove from dist.a.o since there have been no releases Note: This is intended as a discussion topic - not a formal proposal/vote. Thoughts? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Time for Taglibs to be sent to the archive?
What exactly is left to do the release? Not having a permissively licensed JSTL 1.2 is a shame when the code is there. Even if we put it in the Attic, I'd love to say And here is a 1.2 compliant version, good luck rather than sorry, get it from SVN. I'd be happy to put in the effort to do the votes/website. I'd need to hit the site anyway as a part of sending it to the Attic. Is it 100% good on the TCK, nothing more needed? Hen On Mon, Nov 26, 2012 at 4:44 PM, Jeremy Boynes jboy...@apache.org wrote: +0 It's perhaps not surprising that there is not much activity as there has been no update to the JSR in many years. The JSTL code in trunk does pass the 1.2 TCK and could be released if someone had the energy to fix the website and rustle up votes. On Oct 13, 2012, at 10:58 AM, Henri Yandell wrote: Hard to argue against it. I've no energy for Taglibs coding. I wish we'd got a JSTL 1.2 released, but c'est la vie. All the steps listed sound good except removing the website. Historically on the Attic side we've kept the websites up with a notice that the project is dead, rather than going dark on people. Hen On Mon, Oct 1, 2012 at 12:55 AM, Henri Gomez henri.go...@gmail.com wrote: If there is no activity, it make sense. +0 2012/10/1 Mark Thomas ma...@apache.org: In the two+ years since Taglibs moved to the Tomcat project there have been a few short bursts of activity totalling just over 200 commits but no releases. There has also been no progress towards a migration to svnpubsub for the taglibs part of the web site. Given the lack of progress I would propose that Taglibs is moved to our archive. This would mean: - removing the Taglibs link from tomcat.a.o - removing the Taglibs web pages - moving the tomcat/tagslibs svn tree to tomcat/archive/taglibs - making the Taglibs BZ project read-only - moving the Taglibs committers to emeritus status - removing the Taglibs from Gump There is nothing to remove from dist.a.o since there have been no releases Note: This is intended as a discussion topic - not a formal proposal/vote. Thoughts? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Time for Taglibs to be sent to the archive?
Should we have a formal vote Mark? Hen On Mon, Nov 26, 2012 at 4:44 PM, Jeremy Boynes jboy...@apache.org wrote: +0 It's perhaps not surprising that there is not much activity as there has been no update to the JSR in many years. The JSTL code in trunk does pass the 1.2 TCK and could be released if someone had the energy to fix the website and rustle up votes. On Oct 13, 2012, at 10:58 AM, Henri Yandell wrote: Hard to argue against it. I've no energy for Taglibs coding. I wish we'd got a JSTL 1.2 released, but c'est la vie. All the steps listed sound good except removing the website. Historically on the Attic side we've kept the websites up with a notice that the project is dead, rather than going dark on people. Hen On Mon, Oct 1, 2012 at 12:55 AM, Henri Gomez henri.go...@gmail.com wrote: If there is no activity, it make sense. +0 2012/10/1 Mark Thomas ma...@apache.org: In the two+ years since Taglibs moved to the Tomcat project there have been a few short bursts of activity totalling just over 200 commits but no releases. There has also been no progress towards a migration to svnpubsub for the taglibs part of the web site. Given the lack of progress I would propose that Taglibs is moved to our archive. This would mean: - removing the Taglibs link from tomcat.a.o - removing the Taglibs web pages - moving the tomcat/tagslibs svn tree to tomcat/archive/taglibs - making the Taglibs BZ project read-only - moving the Taglibs committers to emeritus status - removing the Taglibs from Gump There is nothing to remove from dist.a.o since there have been no releases Note: This is intended as a discussion topic - not a formal proposal/vote. Thoughts? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Time for Taglibs to be sent to the archive?
Hard to argue against it. I've no energy for Taglibs coding. I wish we'd got a JSTL 1.2 released, but c'est la vie. All the steps listed sound good except removing the website. Historically on the Attic side we've kept the websites up with a notice that the project is dead, rather than going dark on people. Hen On Mon, Oct 1, 2012 at 12:55 AM, Henri Gomez henri.go...@gmail.com wrote: If there is no activity, it make sense. +0 2012/10/1 Mark Thomas ma...@apache.org: In the two+ years since Taglibs moved to the Tomcat project there have been a few short bursts of activity totalling just over 200 commits but no releases. There has also been no progress towards a migration to svnpubsub for the taglibs part of the web site. Given the lack of progress I would propose that Taglibs is moved to our archive. This would mean: - removing the Taglibs link from tomcat.a.o - removing the Taglibs web pages - moving the tomcat/tagslibs svn tree to tomcat/archive/taglibs - making the Taglibs BZ project read-only - moving the Taglibs committers to emeritus status - removing the Taglibs from Gump There is nothing to remove from dist.a.o since there have been no releases Note: This is intended as a discussion topic - not a formal proposal/vote. Thoughts? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Taglibs] Is anyone looking after taglibs?
I'll take care of it as a part of the Jakarta retirement. Hen On Thu, Nov 3, 2011 at 10:33 AM, sebb seb...@gmail.com wrote: The Jakarta TLP is about to retire to the attic; however the taglibs site still refers to non-existent jakarta pages for the downloads. A bug [1] was raised for this for this some while ago, but there appears to be no-one interested in fixing the issue. [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=51382 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [taglibs] downloads and Jakarta references
Yeah, we need to add some local pages. Hen On Thu, Feb 24, 2011 at 3:58 AM, sebb seb...@gmail.com wrote: The RDC and JSTL pages still point to the Jakarta site for download links. Would it be possible to create local download pages instead? The download links don't appear on the Jakarta site, so it means the html and cgi files need special handling. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [taglibs] Time to release 1.2.0?
On Sun, Jan 23, 2011 at 12:41 PM, Jeremy Boynes jboy...@apache.org wrote: The only bug remaining that impact the JSTL libraries is #46052 (locale performance on 1.6). Henri suggested releasing in its current form which sounds reasonable. Should we release this as 1.2.0? Is this a good version number - should we use something like 1.2.0-beta? This will be the first release in a long time and the first since the switch to a Maven based build. The process is described here http://www.apache.org/dev/publishing-maven-artifacts.html I think we need to release the parent POM first to get it in the central repo, and then the artifacts that depend on it. I'd volunteer to RM this but: 1) I'm not a PMC member (which I don't think matters if we get enough votes from PMC members) None of the Taglib committers are, so not an important one :) 2) I'd need to update my PGP key in the WoT (somehow) Do we need new keys now? I can obviously hook you into the WoT if I'm still in it given that we can arrange something during the day. 3) I've not done the above process before so will likely mess things up. Me neither. Best foot forward etc :) +1 Hen - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [taglibs] Move to pre-req Java 1.6 for Locale services?
As an alternative - can we implement this such that it uses this in Java6 and falls back to the old bad code in 1.5 and before? On Tue, Jan 11, 2011 at 1:43 AM, Henri Yandell flame...@gmail.com wrote: +1, Java 1.5 is EOL as you say. While Oracle are in the business of supporting the old versions when it gets painful, we're not. Hen On Sun, Jan 2, 2011 at 3:27 PM, Jeremy Boynes jboy...@apache.org wrote: In Java6 support was added for LocaleServiceProviders that extend the Locales supported by the java.text formatters. This causes #46052 as getAvailableLocales() now needs to scan the entire classpath rather than just return the Locales built in to the JRE. It also means we cannot continue to cache the returned set of Locales if the taglib is shared between different applications (for example, in a JavaEE6 environment where the taglibs are supplied by the container) as it will now vary with context ClassLoader. The java.text getInstance() methods work around this by not scanning the classpath if a match is found with one of the built-in providers. We can use this method directly if the context only requires a single Locale (either because we are using application-specified Locales, or because the request only specified a single one, or because multiple ones in the request match the resolution order (e.g. Firefox's en-us,en). However, where a request specifies multiple Locales with different prefixes, we still need to perform the matching ourselves as the JRE will *always* match something (at least the ROOT Locale) but we cannot tell which. If we stick to using the 1.5 level API we will trigger the uncacheable classpath scan on 1.6 level VMs; however, 1.6 provides the ServiceLoader#loadInstalled() API which can be used to determine the locales installed in the JRE and hence avoid the application classpath scan for JRE supplied locales (which are likely to be the most commonly used). As most users are likely to be running on 1.6 and we've not actually released a version needing 1.5 and Sun's 1.5 is generally end-of-lifed, I'd like to propose solving this with the 1.6 APIs and making it a pre-requisite. Any issue with this? Cheers Jeremy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [taglibs] Move to pre-req Java 1.6 for Locale services?
+1, Java 1.5 is EOL as you say. While Oracle are in the business of supporting the old versions when it gets painful, we're not. Hen On Sun, Jan 2, 2011 at 3:27 PM, Jeremy Boynes jboy...@apache.org wrote: In Java6 support was added for LocaleServiceProviders that extend the Locales supported by the java.text formatters. This causes #46052 as getAvailableLocales() now needs to scan the entire classpath rather than just return the Locales built in to the JRE. It also means we cannot continue to cache the returned set of Locales if the taglib is shared between different applications (for example, in a JavaEE6 environment where the taglibs are supplied by the container) as it will now vary with context ClassLoader. The java.text getInstance() methods work around this by not scanning the classpath if a match is found with one of the built-in providers. We can use this method directly if the context only requires a single Locale (either because we are using application-specified Locales, or because the request only specified a single one, or because multiple ones in the request match the resolution order (e.g. Firefox's en-us,en). However, where a request specifies multiple Locales with different prefixes, we still need to perform the matching ourselves as the JRE will *always* match something (at least the ROOT Locale) but we cannot tell which. If we stick to using the 1.5 level API we will trigger the uncacheable classpath scan on 1.6 level VMs; however, 1.6 provides the ServiceLoader#loadInstalled() API which can be used to determine the locales installed in the JRE and hence avoid the application classpath scan for JRE supplied locales (which are likely to be the most commonly used). As most users are likely to be running on 1.6 and we've not actually released a version needing 1.5 and Sun's 1.5 is generally end-of-lifed, I'd like to propose solving this with the 1.6 APIs and making it a pre-requisite. Any issue with this? Cheers Jeremy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat 7 regex
May I suggest you emit a warning to the logs when comma is used in the regexp for a few versions? Hen On Fri, Dec 24, 2010 at 10:34 AM, Mark Thomas ma...@apache.org wrote: There are a number of configuration properties defined as comma separated regular expressions. As someone pointed out at at ApacheCon that is a little odd. It stops , being used in an expression and is inefficient. Having just been bitten by this while setting up the new Jira instance, I intend change all properties that take regex in Tomcat 7 to use a single regex. This will simplify the code, simplify configuration and make the regex processing faster. I probably won't get around to actually doing this until the new year. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [taglibs] Tab police
+1 for reformatting. I've lived with the terrible code style in taglibs for years because I felt that reformatting it just for me was over the top. Now there are more eyes on the code; PLEASE MAKE IT READABLE! :) I'm assuming it's a one-time only reformat to get us onto something sane. Hen On Tue, Nov 16, 2010 at 7:45 PM, Rex Wang rwo...@gmail.com wrote: What's the formatter you plan to use? Is it public and other committer obeyed? Otherwise, it will mess up again in future.. Anyway, +1 for tab replacement with 4 spaces. -Rex 2010/11/16 Jeremy Boynes jboy...@apache.org As well as the tabs, there are broader inconsistencies in the style (e.g. consistent braces, missing javadoc, and the like) that lead to IDE warnings. How about running everything through a re-formatter to clean this up? Downside is that it will make back-patching harder. +1 from me. On Nov 16, 2010, at 5:28 AM, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=50279 Summary: Tab police Product: Taglibs Version: unspecified Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Unknown Taglib AssignedTo: dev@tomcat.apache.org ReportedBy: s...@apache.org Created an attachment (id=26301) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=26301) Fix tabs in examples code There are oodles of tabs in the Taglibs code. Tabs seem to be set at 8 spaces, at least in the examples section. I can provide patches for the other code if required. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org -- Lei Wang (Rex) rwonly AT apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [taglibs] XPath support
On Wed, Jul 14, 2010 at 8:45 PM, Jeremy Boynes jboy...@apache.org wrote: On Jul 12, 2010, at 7:04 PM, Jeremy Boynes wrote: I'm going to ping Xalan about the increase in time taken as expressions are evaluated as I would assume I'm doing something silly. I looked into the Xalan implementation and the problem appears to be in creation of the DTM used by the underlying implementation. To evaluate the expression it walks up the DOM tree to the parent and then iterates forward over the tree until it reaches the initial context node. This leads to a linear increase in execution time as the context node progresses through the NodeList from the forEach. I changed x:forEach and x:out to use Jaxen and did not see this issue. The execution time for xpath evalutation over 1000 iterations was constant and substantially faster than with Xalan: total of 62ms reparsing each time or 21ms if precompiled, down from 1800ms. In light of this I'd like to propose we switch to Jaxen and add it as a dependency. Absolutely: +1 Great work :) Hen - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [taglibs] XPath support
On Fri, Jul 9, 2010 at 12:51 PM, Jeremy Boynes jboy...@apache.org wrote: In light of the performance issues logged against the XML taglib and functional issues like #49578, I was looking at refactor the XML tags to use the JAXP XPath API to pre-compile expressions and dynamically resolve variables. I think this can be done fairly easily and will eliminate a lot of the integration code in XPathUtil. However, I could not see how to expose the full iteration context described in the spec for x:forEach: * the context position is the iteration 'count' (with the same meaning as in c:forEach) * the context size is equal to the number of nodes in the node-set over which x:forEach is iterating It looks like the current implementation does not support this: https://issues.apache.org/bugzilla/show_bug.cgi?id=22765 and in testing these functions always return -1 and 0 respectively. Presumably these should be returned by the XPath core functions position() and last() respectively. However, the JAXP API only allows a single Node to be passed in for evaluation and I could not see a way to provide the context needed by these functions. I think this might be a limitation of JAXP. I plan to go ahead with the refactor as I think by simplifying our implementation we will address the current performance issues and fix some of the functional edge cases. It will also remove the hard dependency on the Xalan implementation.The iteration context functions will remain broken consistent with the current implementation. It might be possible to make this work using the low-level internal Xalan APIs as this functionality is supported in Xalan's XSLT processing. To support this in the future, I'll try to make the XPath usage pluggable so we can drop in a Xalan-specific version in the future. Thoughts? +1. Resolving the speed and some of the issues is worth making it harder to resolve the other issues imo. Hen - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release build 6.0.28
On Thu, Jul 8, 2010 at 3:59 AM, Rainer Jung rainer.j...@kippdata.de wrote: On 08.07.2010 01:14, sebb wrote: On 7 July 2010 21:19, Rainer Jungrainer.j...@kippdata.de wrote: On 07.07.2010 21:00, sebb wrote: On 7 July 2010 10:47, Rainer Jungrainer.j...@kippdata.de wrote: On 29.06.2010 17:17, jean-frederic clere wrote: - build.properties: it would be nice, if you did the release changes to the file before tagging (and undo after) like Mark does for TC 7 (properties version and version.build). That way checking the identity between the tag and the release source would be easier (less deltas to ignore). Or: Create clean workspace from SVN. Make any necessary updates that apply to the tag only. Create the tag from the workspace using svn copy dir https://.../ Trunk is then untainted by unnecessary changes, and the tag commit e-mail shows the changes made. History is also preseved. I personally do not like edits of tags. I think tags should be used as a single cross cut through the code (like in CVS) and uniquely identify one revision, so not be edited. Personal preference though. My preference too. Tags should be immutable. I see now that my phrase the tag commit e-mail shows the changes made. could be taken to mean that the tag is editted. However that is not the case. The tag is created from the workspace + changes; the e-mail shows the changes from the initial workspace checkout. So instead of seeing the changes as commits to trunk, followed by a simple SVN copy which creates the tag, the copy and changes appear in the tag creation e-mail itself. OK? Interesting, never tried that, sounds good, especially since the email you describe would contain the info you'd like to see (the changes relative to trunk). Good idea. IIUC, it means the tag would not refer to any trunk revision. It gets around having a commit to a tag by hiding the change in the copy. I'd rather get over the notion that tags can't be modified than be tagging uncommitted code. Hen - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release build 6.0.28
On Thu, Jul 8, 2010 at 9:36 AM, sebb seb...@gmail.com wrote: On 8 July 2010 16:22, Henri Yandell flame...@gmail.com wrote: IIUC, it means the tag would not refer to any trunk revision. Strictly speaking, yes, there is no exact match in trunk, because the version fixes are deliberately not applied to trunk. It gets around having a commit to a tag by hiding the change in the copy. Sort of. The changes are not hidden, they are shown in the commit e-mail. e-mails are fairly worthless though. The issue for me is that while it is in the svn log history, it's in a trunk-tag copy that many will assume is an atomic step. Immutability of tags vs atomic commits. I'd rather get over the notion that tags can't be modified than be tagging uncommitted code. All the code is committed; it's just not all in trunk. However, if you modify the tag after creation as you suggest, again the revisions to the tag won't appear in trunk. AFAICT, the only way to ensure that a tag corresponds to a trunk revision is to tag from trunk and then never change the tag = immutable tag. Agreed; but not agreed on it being important. The need for a tag to point to a trunk revision is an arbitrary invention of our development process; instead: * Create release branch. * Develop on release branch. * Declare release branch releaseable [vote]. * 'Tag' by making release branch read-only. In SVN terms, mv the release branch from 7.0.0-release to 7.0.0. Not saying that's great, just that issue may be in how we're defining the problem. The end result of the method I propose is similar to creating the tag and then updating it, but it's easier to spot violations, because a tag should only appear the once, and never in an update commit. But obscures history. I may be weird - I seem to spend a lot of my time in source control history so care a lot about keeping it simple. Also I'm bikeshedding - I've not been a Tomcat release manager, so there may be details that differ from my experience elsewhere. Hen - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [taglibs] Null handling in Functions
With Tomcat 7 now out, it's tempting to focus on Taglibs in that space rather than worrying about JavaEE5. Does it do much for the user to add the annotations? Does it do much for us on the development side? On Mon, Jul 5, 2010 at 12:17 AM, Jeremy Boynes jboy...@apache.org wrote: I work on a patch to remove them and add JavaDoc. What do you think of adding JSR-303 javax.validation annotations like NotNull? Those are part of JavaEE 6 so are guaranteed to be available there but would require a dependency for a JavaEE5 environment. My thought would be not to use them yet. Jeremy On Jul 4, 2010, at 11:36 PM, Henri Yandell wrote: Agreed on 1.18.2. For String params (and Number, Character and Boolean) it looks like Functions should be able to assume that they're null-safe. Hen On Sun, Jul 4, 2010 at 12:20 PM, Jeremy Boynes jboy...@apache.org wrote: Different methods in our Functions implementation handle null parameters inconsistently; for example, toUpperCase does not perform any null check whereas indexOf does. If I grok the EL spec correctly, all String parameter values should be coerced by the rules in 1.18.2 which would guarantee that nulls are converted to and hence the null checks in the implementation are redundant. I confirmed that the EL implementation in Tomcat 7 [1] does this. My thought would be to remove them and rely on the JSP Engine to coerce correctly. If this isn't safe then we should add similar checks to the other methods. Thoughts? Thanks Jeremy [1] http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/el/lang/ELSupport.java?view=markup#l405 called from AstFunction#getValue - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [taglibs] Null handling in Functions
Agreed on 1.18.2. For String params (and Number, Character and Boolean) it looks like Functions should be able to assume that they're null-safe. Hen On Sun, Jul 4, 2010 at 12:20 PM, Jeremy Boynes jboy...@apache.org wrote: Different methods in our Functions implementation handle null parameters inconsistently; for example, toUpperCase does not perform any null check whereas indexOf does. If I grok the EL spec correctly, all String parameter values should be coerced by the rules in 1.18.2 which would guarantee that nulls are converted to and hence the null checks in the implementation are redundant. I confirmed that the EL implementation in Tomcat 7 [1] does this. My thought would be to remove them and rely on the JSP Engine to coerce correctly. If this isn't safe then we should add similar checks to the other methods. Thoughts? Thanks Jeremy [1] http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/el/lang/ELSupport.java?view=markup#l405 called from AstFunction#getValue - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [taglibs] Questions in ForEachSupport
On Tue, Jun 29, 2010 at 11:45 PM, Jeremy Boynes jboy...@apache.org wrote: In bug 45197 https://issues.apache.org/bugzilla/show_bug.cgi?id=45197 Henri wrote: * Look at questions in the length method in ForEachSupport.java * Look at commented out code in prepre in ForEachSupport.java By in the length method did you mean line #241 where the length gets set to 0? That's different to the non-deferred case which throws an exception on line #402. I'd suggest we do the same for both (throwing the exception). That was the one. And agreed - throwing a JspTagException makes sense. The commented code in prepare that sets the itemsName EL variable is redundant as that is also done in LoopTagSupport line #532 (assuming the Apache implementation of the JSTL API). Looks like this can just be deleted. Looks good; and that would have been the commented code in question. The commented out ResultSet code below is also presumably just chaff, but it was the variable setting that was newly introduced. if that sounds good, I'll contribute a patch for those changes. Many thanks :) Hen - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SSL Tomcat
On Wed, Nov 11, 2009 at 12:09 AM, Luciana Moreira Sa de Souza Signed by - PrivaSphere AG s...@privasphere.com wrote: Hello, I am currently working on my company's platform to get around this security problem during re-negotiation. After discussing with my group about the progress being made towards a fix for tomcat, some questions were raised and I was hoping you could help me answer them. We use Tomcat 5.5 with JSSE installed via apt-get in the debian lenny distribution. Are there any plans of putting this fix as an update in the debian package? The other question is in relation to the configuration of this fix. I saw proposals of putting a property in the server.xml to prevent renegotiation from happening. Will this be done on a per Connector basis or will this be Server setting? I ask this since we have parts of the server were we would like to keep the old behavior and other parts that we have to completely stop re-negotiations. Noting that the patch disables handshake renegotiation by default and it's enabled per connector. i.e. opposite of your question. Hen - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SSL Tomcat
On Sat, Nov 7, 2009 at 8:59 AM, Mark Thomas ma...@apache.org wrote: All, I was thinking about this on my way back from ApacheCon and we probably need to get some advice out to users early next week. My current understanding is that the MITM attack is triggered by a renegotiation. On this basis I suggest something along the following lines: SSL using JSSE (BIO and NIO connectors) - Don't use SSL configs that require renegotiation. i.e. SSL config should be the same for the entire host. Sites that require SSL in some places and SSL + CLIENT-CERT in others will require reconfiguration. Sites that require SSL for some parts should be OK. - Keep watch for a Sun update to the JDK that may help address the issue Also IBM, BEA, Apple etc. I'm not sure if JSSE is something Sun license to everyone, or if other JVMs have their own implementation (maybe OpenSSL based?). Harmony presumably does, though no idea if it's OpenSSL or clean room (couldn't see anything on a vague browse through their svn). SSL using tc Native - tcnative does not support renegotiation (https://issues.apache.org/bugzilla/show_bug.cgi?id=46950) so for now users of tc native with SSL should be OK +1 We also need to think about what to do with tc native. Maybe something like: - release 1.1.17 with binaries built with 0.9.8l (so renegotiation is disabled) - keep an eye on httpd and if they find a work-around, copy it and release 1.1.18 with renegotiation enabled Plus keeping an eye on the next openssl version for https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt ? Hen - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Question ad alternative of BSF taglib in Tomcat ? [Fwd: In the move of some taglibs to Tomcat, the BSF taglib got retired]
Not sure where Christopher's email was, but: If there is any interest in a retired taglib, I'm all for it being merged into the Extended Taglib. Currently I plan to consider replacing the functionality from String Taglib (mostly as EL functions), Log Taglib and JNDI Taglib (perhaps). It sounds like BSF taglib, given it has only the two tags, might be very interesting if a dependency on BSF itself can be avoided (ie: base it on javax.script). Hen On Sun, Oct 11, 2009 at 4:31 AM, Rony G. Flatscher (Apache) r...@apache.org wrote: Christopher, thanks for your information! AFAIK the BSF taglib has been allowing one to add code in all of the BSF supported scripting languages to JSPs. Not knowing, wheter there are alternatives available in the current Tomcat Tomcat itself contains little in the way of tag libraries, except for the JSTL required by the JSP 2.1 specification (and higher). In case the BSF taglib is needed for adding scripts in scripting languages to JSPs, I would kindly suggest to not retire it, but to keep it available for interested parties in the Tomcat realm. So, let me clear a few things up: 1. The Tomcat team didn't retire the BSF tag library. The Jakarta BSF tag library folks retired it. You should complain to them. They are all off (enjoying retirement) ... ;-) 2. The Apache Software Foundation (ASF) never deletes code forever. Just because it's retired doesn't mean it's no longer available: it just means that they will no longer be maintaining it by adding features, fixing bugs, or answering questions about it. Yes, but the semantics of retirement indicates that they go out of service (are not useful in todays world anymore). Note that the jakarta-taglibs-BSF project hadn't had a news announcement since 2002, so it was pretty much already dead. Yes, but does that mean it is not useful anymore, needs to get retired, has become irrelevant? In this particular case it is just a sign that this particular functionality has become stable and there has not been a need to add new functionality (what functionality would have been needed in this taglib, other than enabling scripting languages to become usable to create scripts embedded in JSPs) ? Coming from BSF (which BSF taglib exploits) it is not clear to me, whether Tomcat users have been exploiting this taglib or not (actually, if it gets retired, this means that either the taglib is not needed anymore, because of an alternative technology put in place, or the taglib has not been exploited, used at all). In case there are alternatives available in Tomcat to the BSF taglib, please be so kind and point them out (just short pointers would suffice!). What is it that you are trying to do, exactly? It's possible that simply using the BSF library directly (without a tag library) is your best option. There was a fad for a while where everything was being wrapped into a tag library and JSP was starting to look like ColdFusion. CF was eventually re-implemented in Java using JSP tag libraries so I guess JSP had the last laugh. I never thought non-UI-related tag libraries had any business existing because I firmly believe in separation between model/controller and view: the view simply should not be sending emails, communicating with databases (at least not directly), sending JMS messages, or copying files around. E.g. if you look into the MS world you will immediately stumble over tons of ASPs which employ tons (even a mix) of scripting languages. Scripting languages in that world empower even end-user kind of programmers to quickly and easily insert code in a language they can master for web-based applications (and again, they take advantage of that possibility). (There are more reasons, arguments, why it may actually make sense to allow scripting languages to be used in server pages, of cours.) Also, experts in once scripting language are enabled to apply their knowledge for Web apps by creating the needed logic in their scripting language for server pages, removing the need for them to learn a new programming language. (Again, there are other good reasons as well.) If you want to use another scripting language to generate content, then why bother with JSP in the first place? Why not use a tool geared towards allowing you to use your scripting-language of choice outside of a JSP context? This would lead to environments that lock-in the developers in specific environments, which only are available for themselves (cf. PHP, Ruby, etc. environments). Having an established and proven environment available, like Tomcat, making it possible to mix-in code in scripting languages, would be a boon. If it is possible to include script code into JSPs, then why not allow for that? The BSF taglib would allow for that, making it possible to mix-and-match all supported scripting languages in JSPs. (And again, there may be many different reasons for doing that.) ---
Re: Question ad alternative of BSF taglib in Tomcat ? [Fwd: In the move of some taglibs to Tomcat, the BSF taglib got retired]
(dropping tomcat-users@) The BSF Taglib was deprecated in July 2007, one of the first to be recognized as unsupported. And as you say below, retired in the Taglibs move to Tomcat. If BSF users still have a strong need for it for legacy reasons, I'd suggest it go in Jakarta BSF. There's been no one in the Jakarta Taglibs (and now Tomcat I'll assume) project with an interest for many years now (the last code change being in 2002). If there's strong interest in JSP support of the JSR-223, that would be tempting either for Extended Taglib if simple enough an API or its own BSF/JSR223 Taglib that (assuming people wanted to actually code it) could be in Apache Taglibs at Tomcat. An opinion anyway :) Hen On Fri, Oct 9, 2009 at 4:30 AM, Rony G. Flatscher (Apache) r...@apache.org wrote: Hi there, not sure whether this is a user or dev question, hence sending it to both, please forgive, if wrong. Learning about the finalization of moving taglib from jakarta to tomcat, one could also learn that the BSF taglib got retired in the process. AFAIK the BSF taglib has been allowing one to add code in all of the BSF supported scripting languages to JSPs. Not knowing, wheter there are alternatives available in the current Tomcat (did a coarse research on that issue, but did not find any info on this) I created the enclosed e-mail to the BSF user and dev list to make sure, that users of the BSF taglib learn about where it has moved to, in case it is still needed. In case the BSF taglib is needed for adding scripts in scripting languages to JSPs, I would kindly suggest to not retire it, but to keep it available for interested parties in the Tomcat realm. In case there are alternatives available in Tomcat to the BSF taglib, please be so kind and point them out (just short pointers would suffice!). TIA, ---rony P.S.: If the BSF taglib is still needed, then one more (dev) point to discuss/raise would be to create in a addition a new JSR-223/BSF3 taglib for the newly released BSF 3.0, which implements the JSR-223 (javax.script) specs. Unlike JSR-223, which is only available starting with Java 6, BSF 3 supplies the same functionality for Java 1.4 installations or higher, making it a very attractive technology for Java 1.4 and 1.5 installations, as they gain the standard scripting APIs with it. There would be more to this, but should only be discussed, if a need for this exists. Original Message Subject: In the move of some taglibs to Tomcat, the BSF taglib got retired Date: Fri, 09 Oct 2009 12:18:31 +0200 From: Rony G. Flatscher rony.flatsc...@wu-wien.ac.at Reply-To: Bean Scripting Framework developers bsf-...@jakarta.apache.org To: Bean Scripting Framework developers bsf-...@jakarta.apache.org, Bean Scripting Framework users bsf-u...@jakarta.apache.org Hi there, just learned from the announcement that in the process of moving taglibs from Jakarta to Tomcat a lot of taglibs got retired, among them the BSF taglib. Not sure at the moment how Tomcat will allow for creating JSPs that embed code in scripting languages, which was one of the original applications of BSF, when it was originally developed at IBM (as a matter of fact, IBM's WebSphere distributed BSF in order to enable Java Server Page authors to embed scripts in any of its supported scripting languages, very much like MS allows for in their ASPs). So for those who have a need for the BSF taglib, here the relevant links: Information about BSF taglib and examples on how to use it: http://jakarta.apache.org/taglibs/doc/bsf-doc/ Download BSF taglib from: http://svn.apache.org/repos/asf/jakarta/taglibs/deprecated/bsf/trunk/ Retired taglibs as of 2009-10: http://jakarta.apache.org/site/retired-taglibs.html ---rony - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Taglibs website migration
Thanks all - I've gone with option a) and will change if there's a change of consensus. Should show up on the site in a few hours. Migration complete :) Hen On Tue, Oct 6, 2009 at 6:58 AM, Rainer Jung rainer.j...@kippdata.de wrote: On 05.10.2009 22:11, Henri Yandell wrote: This is now live. The Jakarta side of things has been retired and some redirects exist. It's ready to be linked to from tomcat.apache.org. What do people think is best? a) A Taglibs entry under the Home link. +1 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Taglibs website migration
This is now live. The Jakarta side of things has been retired and some redirects exist. It's ready to be linked to from tomcat.apache.org. What do people think is best? a) A Taglibs entry under the Home link. b) Individual entries per Taglib under Download and Documentation. c) A Taglibs entry under Download and one under Documentation (currently there's not a Taglibs download page - each taglib handles its own). d) Something else. Hen On Sat, Sep 19, 2009 at 2:40 AM, Henri Yandell flame...@gmail.com wrote: I've pushed the current state of the Taglibs site out: http://tomcat.apache.org/taglibs/ It's not ready to go live, but it gives us a good feel for what's left to do. Hen - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r816441 - /tomcat/taglibs/taglibs-parent/trunk/src/site/site.xml
On Tue, Sep 22, 2009 at 10:06 AM, Rahul Akolkar rahul.akol...@gmail.com wrote: On Thu, Sep 17, 2009 at 10:32 PM, bay...@apache.org wrote: Author: bayard Date: Fri Sep 18 02:32:18 2009 New Revision: 816441 URL: http://svn.apache.org/viewvc?rev=816441view=rev Log: Commenting out the list of taglibs. Changing urls to be tomcat.apache.org except for the Download one which we'll handle later. Hope this doesn't hurt RDC Rahul. snip/ Thanks Hen, should be OK now that the migration is complete -- ISTR running into relative URL issues when the RDC site was migrated but the parent and rest were still pointing to Jakarta. Out of curiosity, whats your m2 and site plugin version? -Rahul My m2 is 2.2.0. Latest site plugin in .m2 is 2.0-beta-7. Hen - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Taglibs website migration
I've pushed the current state of the Taglibs site out: http://tomcat.apache.org/taglibs/ It's not ready to go live, but it gives us a good feel for what's left to do. Hen - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Testing new website sync process
Did this go through Mark? Where do I commit the Taglibs site? Hen On Thu, Sep 3, 2009 at 3:59 AM, Mark Thomas ma...@apache.org wrote: Folks, As part of the response to the recent compromise of ASF servers [1] the infrastructure team are introducing a new way to sync web sites from svn and are looking for PMS to volunteer to test the new process. I'd like to volunteer the Tomcat website. Any objections? I'm happy to take on fixing any teething problems. The advantage is that commits to svn will be reflected on the live site within a few seconds. If we want we can also have a staging site tomcat.staging.a.o where we could preview stuff [2] My own view is that a staging site isn't necessary. Our site is simple. We can test locally before committing and with commits affecting the live site within a few seconds, fixing any snafus should be easy. Cheers, Mark [1] http://blogs.apache.org/infra/ [2] This require a separate svn location to sync from. Something like: http://svn.apache.org/repos/asf/tomcat/site/branches/live would sync to http://tomcat.apache.org/ and http://svn.apache.org/repos/asf/tomcat/site/trunk would sync to http://tomcat.staging.apache.org/ and we would have to svn merge changes from trunk to live. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Testing new website sync process
Generally +1. Noting that this includes the Taglibs subsites which are Maven based. Hen On Thu, Sep 3, 2009 at 3:59 AM, Mark Thomasma...@apache.org wrote: Folks, As part of the response to the recent compromise of ASF servers [1] the infrastructure team are introducing a new way to sync web sites from svn and are looking for PMS to volunteer to test the new process. I'd like to volunteer the Tomcat website. Any objections? I'm happy to take on fixing any teething problems. The advantage is that commits to svn will be reflected on the live site within a few seconds. If we want we can also have a staging site tomcat.staging.a.o where we could preview stuff [2] My own view is that a staging site isn't necessary. Our site is simple. We can test locally before committing and with commits affecting the live site within a few seconds, fixing any snafus should be easy. Cheers, Mark [1] http://blogs.apache.org/infra/ [2] This require a separate svn location to sync from. Something like: http://svn.apache.org/repos/asf/tomcat/site/branches/live would sync to http://tomcat.apache.org/ and http://svn.apache.org/repos/asf/tomcat/site/trunk would sync to http://tomcat.staging.apache.org/ and we would have to svn merge changes from trunk to live. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Taglibs SVN migration to Tomcat
On Wed, Aug 19, 2009 at 9:25 PM, Rahul Akolkarrahul.akol...@gmail.com wrote: On Wed, Aug 19, 2009 at 11:00 AM, Henri Yandellflame...@gmail.com wrote: So... steps: * New Standard site that merges 1.0, 1.1 and 1.x docs together, rather than treating them as separate taglibs. * Retired Jakarta Taglibs page. * New Taglibs site that flattens and updates for Tomcat land. * RDC Taglib regenerated from final taglib-parent. * Extended Taglib site. Can be pretty minimal. * Jakarta Taglibs htaccess rules. * Link on tomcat.apache.org when all looks good and Tomcat dev@ approves. snap/ Looks reasonable to me. I've created a Retired Jakarta Taglibs page. Not hooked up yet; two small missing steps at the end of the above are: * Add link to Retired Jakarta Taglibs page from Jakarta Retired page. * Move Taglibs into the Ex-Jakarta on the LHS. We should also link to the Retired Jakarta Taglibs page from the Tomcat Taglibs front page. Once the rsync happens, the url will be: http://jakarta.apache.org/site/retired-taglibs.html Hen - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Taglibs SVN migration to Tomcat
On Tue, Aug 18, 2009 at 9:16 PM, Rahul Akolkarrahul.akol...@gmail.com wrote: On Mon, Aug 17, 2009 at 1:51 PM, Rahul Akolkarrahul.akol...@gmail.com wrote: On Mon, Aug 17, 2009 at 1:04 AM, Henri Yandellflame...@gmail.com wrote: snip/ The Standard taglib's site is not in a happy state so I'll be working on getting that setup next. Rahul and I both have the tomcat unix group now, so I'll work on moving the sites over into tomcat.apache.org/taglibs this week; and setting up the redirects on the Jakarta side. snip/ I can certainly push out a site or two -- if you want, I can do RDC (and extended even) while you appease Standard. A start: http://tomcat.apache.org/taglibs/rdc/ General theme looks good :) The title still mentions Jakarta. Should rename to: Apache RDC Taglib - Reusable Dialog Components Tag Library Basically we should have been branding ourselves with Apache rather than Jakarta for about 6 years now :) For the main site, couple of changes come to mind before deploying, we should: (a) flatten out the directory structure a bit (stuff in this site directory [1] can just go in the parent xdoc directory really) I've found it makes things easier to have these all together (like redirecting them for example), but given that Maven puts other files into the parent directory anyway it's not much of a justification. (b) list only the bits moved over in the LHS menu. -Rahul [1] http://svn.apache.org/repos/asf/tomcat/taglibs/site/src/site/xdoc/site/ I think we also need a simultaneous page in jakarta/site/retired/taglibs.html that lists out the retired taglibs. Plus that means a bit of complexity in the .htaccess; we'll want to keep the old sites for retired taglibs so no global redirect of /taglibs/ over. Instead we'll need to list explicitly the items to redirect over to the Tomcat side. So... steps: * New Standard site that merges 1.0, 1.1 and 1.x docs together, rather than treating them as separate taglibs. * Retired Jakarta Taglibs page. * New Taglibs site that flattens and updates for Tomcat land. * RDC Taglib regenerated from final taglib-parent. * Extended Taglib site. Can be pretty minimal. * Jakarta Taglibs htaccess rules. * Link on tomcat.apache.org when all looks good and Tomcat dev@ approves. Hen - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Taglibs SVN migration to Tomcat
On Mon, Aug 17, 2009 at 10:51 AM, Rahul Akolkarrahul.akol...@gmail.com wrote:
On Mon, Aug 17, 2009 at 1:04 AM, Henri Yandellflame...@gmail.com wrote:
I hand edited the RDC website to point over to the Tomcat SVN location
on people.apache.org.
snap/
Not clear what that means.
I modified the pom and edited
http://jakarta.apache.org/taglibs/rdc/source-repository.html - but I
missed that RDC has multiple poms in it.
The Standard taglib's site is not in a happy
state so I'll be working on getting that setup next. Rahul and I both
have the tomcat unix group now, so I'll work on moving the sites over
into tomcat.apache.org/taglibs this week; and setting up the redirects
on the Jakarta side.
snip/
I can certainly push out a site or two -- if you want, I can do RDC
(and extended even) while you appease Standard.
No real site for extended yet - but feel very free to put something
simple together if you'd like :)
Which reminds me, our commit messages are not hitting the list (I made
a pom update as well). I'll wait a bit more and then will ping
dev-owner to allow {bayard,rahul,kris}.
Thanks.
Hen
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Taglibs SVN migration to Tomcat
SVN move done. The Jakarta side points over to Tomcat for now, I'll be retiring what's left over there later. I hand edited the RDC website to point over to the Tomcat SVN location on people.apache.org. The Standard taglib's site is not in a happy state so I'll be working on getting that setup next. Rahul and I both have the tomcat unix group now, so I'll work on moving the sites over into tomcat.apache.org/taglibs this week; and setting up the redirects on the Jakarta side. Hen On Thu, Aug 13, 2009 at 1:48 AM, Henri Yandellflame...@gmail.com wrote: Post discussion between Tomcat PMC and Jakarta PMC (with myself as the go between), the Jakarta Taglibs subproject is going to move over to Tomcat land. Chiefly this means: * The JSTL implementations: 1.0, 1.1 and unreleased 1.2. * RDC Taglib. * An in development 'extended' taglib. The Jakarta Taglibs site will become a Retired page, and move into the Attic once a few remaining bits of code have been picked over for the extended taglib. A year or so. I'd like to do the SVN move, dev@ permitting. This would mean something like the following in the ASF public repo: tomcat/ taglibs/ standard/ tags/ branches/ trunk/ extended/ tags/ (empty) branches/ (empty) trunk/ rdc/ tags/ branches/ (empty) trunk/ site/ [subsite - tomcat.apache.org/taglibs/] taglibs-parent/ [maven parent pom] The tags and branches are generally historical in that they're hard to build directly as there are missing parent build.xml and common.xml files. Trunk uses Maven 2 as its build system. If a JSTL 1.0 or JSTL 1.1 bugfix is needed, then migrating them to Maven2 or fixing their build systems are options. Tomcat svn karma would be given to bayard, kris + rahul. Mailing lists - I'm thinking of moving the taglibs-user@ list from Jakarta to Tomcat while killing the taglibs-dev list in favour of d...@tomcat. Anyway - all open to discussion + debate; let me know what works best from this list's point of view. Hen - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Taglibs SVN migration to Tomcat
Post discussion between Tomcat PMC and Jakarta PMC (with myself as the go between), the Jakarta Taglibs subproject is going to move over to Tomcat land. Chiefly this means: * The JSTL implementations: 1.0, 1.1 and unreleased 1.2. * RDC Taglib. * An in development 'extended' taglib. The Jakarta Taglibs site will become a Retired page, and move into the Attic once a few remaining bits of code have been picked over for the extended taglib. A year or so. I'd like to do the SVN move, dev@ permitting. This would mean something like the following in the ASF public repo: tomcat/ taglibs/ standard/ tags/ branches/ trunk/ extended/ tags/ (empty) branches/ (empty) trunk/ rdc/ tags/ branches/ (empty) trunk/ site/ [subsite - tomcat.apache.org/taglibs/] taglibs-parent/ [maven parent pom] The tags and branches are generally historical in that they're hard to build directly as there are missing parent build.xml and common.xml files. Trunk uses Maven 2 as its build system. If a JSTL 1.0 or JSTL 1.1 bugfix is needed, then migrating them to Maven2 or fixing their build systems are options. Tomcat svn karma would be given to bayard, kris + rahul. Mailing lists - I'm thinking of moving the taglibs-user@ list from Jakarta to Tomcat while killing the taglibs-dev list in favour of d...@tomcat. Anyway - all open to discussion + debate; let me know what works best from this list's point of view. Hen - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Binary build procedures
On 5/25/06, Mark Claassen [EMAIL PROTECTED] wrote: I have a question about two optional packages: mx4j and junit. Are they really optional? I realize that some build processes may use junit to test the build, but does it need to in the distribution? Looking at the latest binary, junit doesn't get shipped. Also, what is mx4j used for. If I don't it, can I not use JMX? connectors/jk/java/org/apache/jk/common/JkMX.java is the only class using mx4j. Check its javadoc out to decide if you want to be distributing mx4j in your Tomcat build. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Missing tag in SVN
It was pointed out to me that Tomcat/servletapi is missing a tag. In https://svn.apache.org/repos/asf/tomcat/servletapi/tags/servlet2.4-jsp2.0-tc5.x/ there is no TOMCAT_5_5_12. Looking at /home/cvs/servletapi-5/LICENSE,v there definitely was such a tag, and a quick set of find's and a diff show that said tag was identical to the TOMCAT_5_5_11 tag. -bash-2.05b$ find . -type f | xargs grep TOMCAT_5_5_12 | sed 's/5_5_12/5_5_X/' ~/TC-12 -bash-2.05b$ find . -type f | xargs grep TOMCAT_5_5_11 | sed 's/5_5_11/5_5_X/' ~/TC-11 -bash-2.05b$ diff ~/TC-12 ~/TC-11 -bash-2.05b$ wc ~/TC-* 207 436 12846 /home/bayard/TC-11 207 436 12846 /home/bayard/TC-12 414 872 25692 total -bash-2.05b$ So it seems to me that we could just copy the 5_5_11 tag to 5_5_12 and everything would be rosy. Any thoughts? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Missing tag in SVN
Nope, just a colleague looking to prove they can recreate the 5.5.12 build. On 1/5/06, Yoav Shapira [EMAIL PROTECTED] wrote: Hi, Hmm, strange. But this shouldn't be a big deal to anyone: we can copy the tag as you suggest IMHO. Did the person pointing it out have some problem/issue, or just happen to notice this oddity? Yoav On 1/5/06, Henri Yandell [EMAIL PROTECTED] wrote: It was pointed out to me that Tomcat/servletapi is missing a tag. In https://svn.apache.org/repos/asf/tomcat/servletapi/tags/servlet2.4-jsp2.0-tc5.x/ there is no TOMCAT_5_5_12. Looking at /home/cvs/servletapi-5/LICENSE,v there definitely was such a tag, and a quick set of find's and a diff show that said tag was identical to the TOMCAT_5_5_11 tag. -bash-2.05b$ find . -type f | xargs grep TOMCAT_5_5_12 | sed 's/5_5_12/5_5_X/' ~/TC-12 -bash-2.05b$ find . -type f | xargs grep TOMCAT_5_5_11 | sed 's/5_5_11/5_5_X/' ~/TC-11 -bash-2.05b$ diff ~/TC-12 ~/TC-11 -bash-2.05b$ wc ~/TC-* 207 436 12846 /home/bayard/TC-11 207 436 12846 /home/bayard/TC-12 414 872 25692 total -bash-2.05b$ So it seems to me that we could just copy the 5_5_11 tag to 5_5_12 and everything would be rosy. Any thoughts? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yoav Shapira System Design and Management Fellow MIT Sloan School of Management Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.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]
jakarta site leftovers
Now that tomcat.apache.org contains a site, anyone mind if I remove /www/jakarta.apache.org/tomcat and tomcat-temp? Also, could the watchdog directory be moved over to /www/tomcat.apache.org/watchdog please? Thanks, Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
