Re: [ANNOUNCEMENT] Apache Jakarta Commons Logging 1.1 Released
Congratulations - great! After endless needed quality checks, a final optimal release. Hopefully many users will try and migrate to it. Regards Boris --- Ursprüngliche Nachricht --- Von: robert burrell donkin [EMAIL PROTECTED] The Jakarta Commons team are pleased to announced that Apache Jakarta Commons Logging (JCL) 1.1 has been released. JCL is a thin bridging API for logging with adapters for many common logging systems. Read more about JCL at http://jakarta.apache.org/commons/logging. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] Jira projects
Sorry Henry, I suppose this was later than your deletion which I didn't notice... Note that Jelly doesn't use Bugzilla since ages so the only advantage of such an import would be to merge these lost contributions, several of which are actually duplicated, all of which are resolved. The best thing would be to keep it for archive purposes in Bugzilla, I think. paul Paul Libbrecht wrote: Henri Yandell wrote: There are now two projects in Jira, Jelly and Commons JellyImported. If someone has a moment, it'd be a real help if they could take a look at the two of these and let me know if JellyImported can be deleted or if it should have its issues moved into Jelly. I just didn't find JellyImported. It's not findable in: http://issues.apache.org/jira/secure/BrowseProject.jspa and both: http://issues.apache.org/jira/browse/JELLYIMPORTED http://issues.apache.org/jira/browse/JellyImported are not found... can you maybe give a URL ? I'll be renaming Jelly to Commons Jelly in a bit. Project names in Jira are in capital... so renaming to COMMONS-JELLY or so would be pretty ugly... and would break all current URLs... but if you have to... Also jakarta only appears once in the project list... why? paul - 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]
[ANNOUNCE] Commons Collections 3.2 released
The Commons Collections team is pleased to announce the release of commons-collections-3.2. Commons Collections is a library that builds upon the Java Collection Framework. It provides additional Map, List and Set implementations and utilities. It also builds on the framework by providing new interfaces and implementations. This release fixes numerous bugs, and adds a limited number of enhancements, including: - MultiValueMap - A flexible MultiMap implementation - DefaultedMap - A map that returns a default value when the key is not found - GrowthList - A list where set and add expand the list rather than throw IndexOutOfBoundsException - LoopingListIterator - A never-ending list iterator - CollectionUtils.addIgnoreNull - Adds to the collection if the value being added is not null - isEmpty - Checks maps and collections for empty or null - BlockingBuffer - Add timeout handling to any buffer implementation - ListOrderedMap - additional list-style methods This release is binary and source compatible with 3.1 according to our tests. There are two new deprecations, see the release notes for details. We recommend all users of commons-collections to upgrade to 3.2 to pickup the bug fixes. Commons Collections Website: http://jakarta.apache.org/commons/collections/ Release notes: http://jakarta.apache.org/commons/collections/release_3_2.html Download: http://jakarta.apache.org/site/downloads/downloads_commons-collections.cgi Enjoy! The Commons Collections Team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-230) Problem with default namespace in imported scripts
[
http://issues.apache.org/jira/browse/JELLY-230?page=comments#action_12402283 ]
Diogo Bacelar Quintela commented on JELLY-230:
--
You could use the replaceNamespace tag..
x:replaceNamespace fromURI=dummy toURI=
project name=${pom.artifactId} default=jar basedir=.
target name=clean description=Clean up
delete dir=$${defaulttargetdir}/
delete dir=$${distdir}/
/target
/project
/x:replaceNamespace
It should work dispite i haven't tested.
Problem with default namespace in imported scripts
--
Key: JELLY-230
URL: http://issues.apache.org/jira/browse/JELLY-230
Project: Jelly
Type: Bug
Components: core / taglib.core
Versions: 1.1
Environment: jelly-1.1-SNAPSHOT
Reporter: Lukas Theussl
Assignee: james strachan
Priority: Critical
I am trying to build Maven with jelly-1.1-SNAPSHOT from svn trunk because it
contains a fix for a regression that has blocked us for a long time, see
http://jira.codehaus.org/browse/MAVEN-1691 (gee, I wish I'd checked the svn
archives earlier!).
However, even though jelly-1.1-SNAPSHOT solves the above issue, it also leads
to a whole bunch of test failures in several of our plugins.
After some investigation I found that they all turn out to be due to the same
cause, an apparent backwards incompatibility introduced in the fix for
JELLY-213.
I am not sure actually if this is a bug or the intended behavior, but it
certainly breaks backwards compatibility.
To illustrate the problem: in the ant plugin we use the following snippet to
generate an ant build.xml file from a template:
j:file name=build.xml prettyPrint=true
j:import file=templates/build.jelly inherit=true/
/j:file
where the template file build.jelly looks like this (simplified):
j:jelly
xmlns:ant=jelly:ant
xmlns:j=jelly:core
xmlns=dummy
project name=${pom.artifactId} default=jar basedir=.
target name=clean description=Clean up
delete dir=$${defaulttargetdir}/
delete dir=$${distdir}/
/target
/project
/j:jelly
Note the xmlns=dummy namespace declaration which is necessary to
distinguish the default namespace of the template script from Maven's default
namespace. Now with jelly-1.0, this works as expected, but with the current
jelly-1.1-SNAPSHOT, I get:
project xmlns=dummy name=test-maven-ant-plugin default=jar basedir=.
target description=Clean up name=clean
delete dir=${defaulttargetdir}
/delete
delete dir=${distdir}
/delete
/target
project
ie the dummy namespace declaration makes it into the top-level element of the
generated file. This makes ant very unhappy when invoked on this build file...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-230) Problem with default namespace in imported scripts
[
http://issues.apache.org/jira/browse/JELLY-230?page=comments#action_12402290 ]
Paul Libbrecht commented on JELLY-230:
--
I fear that the problem is considered to be backwards compatibility even
though a normal perspective would be call to it a bug-fix.
Lukas, does the solution replaceNamespace sound doable for you ?
Alternatively, what about having a flag at XMLOutput (which is probably
instantiated by Maven anyways) to do this?
(it seems pretty equivalent, actually)
As far as I know this has nothing to do with import... or I'd need an extra
explanation
paul
Problem with default namespace in imported scripts
--
Key: JELLY-230
URL: http://issues.apache.org/jira/browse/JELLY-230
Project: Jelly
Type: Bug
Components: core / taglib.core
Versions: 1.1
Environment: jelly-1.1-SNAPSHOT
Reporter: Lukas Theussl
Assignee: james strachan
Priority: Critical
I am trying to build Maven with jelly-1.1-SNAPSHOT from svn trunk because it
contains a fix for a regression that has blocked us for a long time, see
http://jira.codehaus.org/browse/MAVEN-1691 (gee, I wish I'd checked the svn
archives earlier!).
However, even though jelly-1.1-SNAPSHOT solves the above issue, it also leads
to a whole bunch of test failures in several of our plugins.
After some investigation I found that they all turn out to be due to the same
cause, an apparent backwards incompatibility introduced in the fix for
JELLY-213.
I am not sure actually if this is a bug or the intended behavior, but it
certainly breaks backwards compatibility.
To illustrate the problem: in the ant plugin we use the following snippet to
generate an ant build.xml file from a template:
j:file name=build.xml prettyPrint=true
j:import file=templates/build.jelly inherit=true/
/j:file
where the template file build.jelly looks like this (simplified):
j:jelly
xmlns:ant=jelly:ant
xmlns:j=jelly:core
xmlns=dummy
project name=${pom.artifactId} default=jar basedir=.
target name=clean description=Clean up
delete dir=$${defaulttargetdir}/
delete dir=$${distdir}/
/target
/project
/j:jelly
Note the xmlns=dummy namespace declaration which is necessary to
distinguish the default namespace of the template script from Maven's default
namespace. Now with jelly-1.0, this works as expected, but with the current
jelly-1.1-SNAPSHOT, I get:
project xmlns=dummy name=test-maven-ant-plugin default=jar basedir=.
target description=Clean up name=clean
delete dir=${defaulttargetdir}
/delete
delete dir=${distdir}
/delete
/target
project
ie the dummy namespace declaration makes it into the top-level element of the
generated file. This makes ant very unhappy when invoked on this build file...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20523] - [fileupload] Model FileUpload model to mimic javax.servlet.Request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=20523. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=20523 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20838] - [fileupload] Add a new property maxFileSize to control a size of separate uploaded file but not a whole request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=20838. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=20838 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38742] - [fileupload] Fails to apply fieldname
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38742. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38742 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 39584] New: - [collections] Upload to m2 repo @ibiblio.org
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=39584. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=39584 Summary: [collections] Upload to m2 repo @ibiblio.org Product: Commons Version: 3.2 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Collections AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Could somebody upload collections 3.2 to www.ibiblio.org/maven2 repo? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r406658 - in /jakarta/commons/proper/httpclient/trunk: project.xml xdocs/news.xml
Author: olegk Date: Mon May 15 08:41:23 2006 New Revision: 406658 URL: http://svn.apache.org/viewcvs?rev=406658view=rev Log: Issue management migrated to Jira Modified: jakarta/commons/proper/httpclient/trunk/project.xml jakarta/commons/proper/httpclient/trunk/xdocs/news.xml Modified: jakarta/commons/proper/httpclient/trunk/project.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/httpclient/trunk/project.xml?rev=406658r1=406657r2=406658view=diff == --- jakarta/commons/proper/httpclient/trunk/project.xml (original) +++ jakarta/commons/proper/httpclient/trunk/project.xml Mon May 15 08:41:23 2006 @@ -24,7 +24,7 @@ logo/images/httpclient_logo.png/logo urlhttp://jakarta.apache.org/commons/httpclient//url - issueTrackingUrl![CDATA[http://issues.apache.org/bugzilla/buglist.cgi?query_format=advancedshort_desc_type=allwordssubstrshort_desc=product=HttpClientcomponent=Commons+HttpClientlong_desc_type=allwordssubstrlong_desc=bug_file_loc_type=allwordssubstrbug_file_loc=keywords_type=anywordskeywords=bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=NEEDINFOemailassigned_to1=1emailtype1=substringemail1=emailreporter2=1emailtype2=substringemail2=bugidtype=includebug_id=votes=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+last+timefield0-0-0=nooptype0-0-0=noopvalue0-0-0=]]/issueTrackingUrl + issueTrackingUrlhttp://issues.apache.org/jira/browse/HTTPCLIENT/issueTrackingUrl siteAddresspeople.apache.org/siteAddress siteDirectory/www/jakarta.apache.org/commons/httpclient//siteDirectory Modified: jakarta/commons/proper/httpclient/trunk/xdocs/news.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/httpclient/trunk/xdocs/news.xml?rev=406658r1=406657r2=406658view=diff == --- jakarta/commons/proper/httpclient/trunk/xdocs/news.xml (original) +++ jakarta/commons/proper/httpclient/trunk/xdocs/news.xml Mon May 15 08:41:23 2006 @@ -10,6 +10,22 @@ /properties body +section name=12 May 2006 - HttpClient issue tracking migrated to Jira +p + HttpClient issue tracking has migrated from Bugzilla to Jira. Please do not enter new bug reports + and update exiting ones in Bugzilla. HttpComponents project will be using + a href=http://issues.apache.org/jira/;Jira/a to manage HttpClient related issues as of today. + Please use a href=http://issues.apache.org/jira/browse/HTTPCLIENT;this project/a in Jira to + report new issues against HttpClient and search for reported ones. All existing issue reports can + be accessed in Jira by their original Bugzilla bug id. +/p +/section +section name=08 May 2006 - HttpClient 3.0.1 released +p + HttpClient 3.0.1 has been released. This version fixes a number of bugs found since the release of 3.0. + All HttpClient users are encouraged to upgrade. +/p +/section section name=27 February 2006 - HttpClient 2.x codebase declared 'End of Life' p HttpClient 2.x will no longer be supported. There will be no more HttpClient 2.x releases - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE : [ANNOUNCEMENT] Apache Jakarta Commons Logging 1.1 Released
Hi,n Thanks it's great job which fixes some troubles. But I have a trouble concerning the pom published [1]. I have recorded an MEV issue [2] A commons-logging developper's can put a comment or approve it ? Thanks, - Olivier [1] http://www.ibiblio.org/maven2/commons-logging/commons-logging/1.1/common s-logging-1.1.pom [2] http://jira.codehaus.org/browse/MEV-392 -Message d'origine- De : robert burrell donkin [mailto:[EMAIL PROTECTED] Envoyé : lundi 15 mai 2006 00:04 À : commons-user@jakarta.apache.org; commons-dev@jakarta.apache.org; announcements@jakarta.apache.org; announce@apache.org Objet : [ANNOUNCEMENT] Apache Jakarta Commons Logging 1.1 Released The Jakarta Commons team are pleased to announced that Apache Jakarta Commons Logging (JCL) 1.1 has been released. JCL is a thin bridging API for logging with adapters for many common logging systems. Read more about JCL at http://jakarta.apache.org/commons/logging. JCL 1.1 is a maintenance release. A few new configuration features are provided but the focus has been on improving the discovery of logging implementations and in error handling whilst maintaining backwards compatibility. A number of problems that have troubled some users in past releases will hopefully be significantly reduced or cured. This is covered in more detail in the release notes (http://jakarta.apache.org/commons/logging/RELEASE-NOTES.txt). Some changes have been made to the class-wise composition of the distributed jars. Some deprecated classes are no longer shipped. This is covered in more detail in the release notes (http://jakarta.apache.org/commons/logging/RELEASE-NOTES.txt. The JCL documentation has also been improved. A Technology Guide (http://jakarta.apache.org/commons/logging/tech.html) offering an introduction to classloading issues and a Troubleshooting Guide (http://jakarta.apache.org/commons/logging/troubleshooting.html') complement an improved User Guide (http://jakarta.apache.org/commons/logging/guide.html) Binary and source distributions are available at http://jakarta.apache.org/site/downloads/downloads_commons-logging.cgi. The jars are available from the usual repositories with codegroupId: commons-logging/code and codeartifactId: commons-logging/code. Please remember to verify the signatures. Robert Burrell Donkin This e-mail, any attachments and the information contained therein (this message) are confidential and intended solely for the use of the addressee(s). If you have received this message in error please send it back to the sender and delete it. Unauthorized publication, use, dissemination or disclosure of this message, either in whole or in part is strictly prohibited. -- Ce message électronique et tous les fichiers joints ainsi que les informations contenues dans ce message ( ci après le message ), sont confidentiels et destinés exclusivement à l'usage de la personne à laquelle ils sont adressés. Si vous avez reçu ce message par erreur, merci de le renvoyer à son émetteur et de le détruire. Toutes diffusion, publication, totale ou partielle ou divulgation sous quelque forme que se soit non expressément autorisées de ce message, sont interdites. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] Jira projects
On 5/14/06, Paul Libbrecht [EMAIL PROTECTED] wrote: Henri Yandell wrote: There are now two projects in Jira, Jelly and Commons JellyImported. If someone has a moment, it'd be a real help if they could take a look at the two of these and let me know if JellyImported can be deleted or if it should have its issues moved into Jelly. I just didn't find JellyImported. It's not findable in: http://issues.apache.org/jira/secure/BrowseProject.jspa and both: http://issues.apache.org/jira/browse/JELLYIMPORTED http://issues.apache.org/jira/browse/JellyImported are not found... can you maybe give a URL ? I rolled things back, sorry. Basically the question is - should I migrate the Jelly issues from Bugzilla or leave them. I'll be renaming Jelly to Commons Jelly in a bit. Project names in Jira are in capital... so renaming to COMMONS-JELLY or so would be pretty ugly... and would break all current URLs... but if you have to... That's project keys, which are immutable. Thus why I have to have JELLYIMPORTED to avoid a clash. Project names are just loose strings, currently it's 'Jelly', I'll be making it 'Commons Jelly'. Names mostly just affect drop-downs. Also jakarta only appears once in the project list... why? It shouldn't appear at all. Jakarta is a category not a project. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r406662 - /jakarta/commons/proper/httpclient/trunk/project.xml
Author: olegk Date: Mon May 15 09:08:33 2006 New Revision: 406662 URL: http://svn.apache.org/viewcvs?rev=406662view=rev Log: Added 3.0.1 release version Modified: jakarta/commons/proper/httpclient/trunk/project.xml Modified: jakarta/commons/proper/httpclient/trunk/project.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/httpclient/trunk/project.xml?rev=406662r1=406661r2=406662view=diff == --- jakarta/commons/proper/httpclient/trunk/project.xml (original) +++ jakarta/commons/proper/httpclient/trunk/project.xml Mon May 15 09:08:33 2006 @@ -34,6 +34,11 @@ /repository versions version + id3.0.1/id + name3.0.1/name + tagHTTPCLIENT_3_0_1/tag +/version +version id3.0/id name3.0/name tagHTTPCLIENT_3_0/tag - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r406665 - /jakarta/commons/proper/httpclient/branches/HTTPCLIENT_3_0_BRANCH/project.xml
Author: olegk Date: Mon May 15 09:18:12 2006 New Revision: 406665 URL: http://svn.apache.org/viewcvs?rev=406665view=rev Log: Issue management migrated to Jira Modified: jakarta/commons/proper/httpclient/branches/HTTPCLIENT_3_0_BRANCH/project.xml Modified: jakarta/commons/proper/httpclient/branches/HTTPCLIENT_3_0_BRANCH/project.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/httpclient/branches/HTTPCLIENT_3_0_BRANCH/project.xml?rev=406665r1=406664r2=406665view=diff == --- jakarta/commons/proper/httpclient/branches/HTTPCLIENT_3_0_BRANCH/project.xml (original) +++ jakarta/commons/proper/httpclient/branches/HTTPCLIENT_3_0_BRANCH/project.xml Mon May 15 09:18:12 2006 @@ -24,7 +24,7 @@ logo/images/httpclient_logo.png/logo urlhttp://jakarta.apache.org/commons/httpclient//url - issueTrackingUrl![CDATA[http://issues.apache.org/bugzilla/buglist.cgi?query_format=advancedshort_desc_type=allwordssubstrshort_desc=product=HttpClientcomponent=Commons+HttpClientlong_desc_type=allwordssubstrlong_desc=bug_file_loc_type=allwordssubstrbug_file_loc=keywords_type=anywordskeywords=bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=NEEDINFOemailassigned_to1=1emailtype1=substringemail1=emailreporter2=1emailtype2=substringemail2=bugidtype=includebug_id=votes=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+last+timefield0-0-0=nooptype0-0-0=noopvalue0-0-0=]]/issueTrackingUrl + issueTrackingUrlhttp://issues.apache.org/jira/browse/HTTPCLIENT/issueTrackingUrl siteAddresspeople.apache.org/siteAddress siteDirectory/www/jakarta.apache.org/commons/httpclient//siteDirectory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r406667 - /jakarta/commons/proper/httpclient/trunk/project.xml
Author: olegk Date: Mon May 15 09:27:32 2006 New Revision: 406667 URL: http://svn.apache.org/viewcvs?rev=406667view=rev Log: Set current version to 3.0.1 Modified: jakarta/commons/proper/httpclient/trunk/project.xml Modified: jakarta/commons/proper/httpclient/trunk/project.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/httpclient/trunk/project.xml?rev=406667r1=40r2=406667view=diff == --- jakarta/commons/proper/httpclient/trunk/project.xml (original) +++ jakarta/commons/proper/httpclient/trunk/project.xml Mon May 15 09:27:32 2006 @@ -7,7 +7,7 @@ artifactIdcommons-httpclient/artifactId gumpRepositoryIdjakarta-commons-httpclient/gumpRepositoryId inceptionYear2001/inceptionYear - currentVersion3.0/currentVersion + currentVersion3.0.1/currentVersion packageorg.apache.commons.httpclient/package organization - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 39538] - [collections] Support parametized classes with commons.collections.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=39538.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=39538
--- Additional Comments From [EMAIL PROTECTED] 2006-05-15 16:34 ---
(In reply to comment #3)
Someone has already ported it. There's a sourceforge project
(http://collections15.sourceforge.net/) out there that does it.
Yes, someone has attempted to port the commons.collections but the projects
seems dead. The current source code has many coding errors. The programmers
simply replaced the type E everywhere without forethought. That's wrong.
There is a document named generics-tutorial.pdf available from sun.java.com
website. It explains in great detail how parametized classes should be code.
The project was done without good technical knowledge of Java 1.5 parametized
classes.
THE TYPICAL ERROR:
class SetE {
void add(E d) {...} // that's wrong!!!
}
- the method add should read
void add(? extends E d) {...} // so any subclass of E is acceptable.
I don't see much motivation to pursue commons.collections15 which is a shame.
It's one of the most important Jakarta library!
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 39538] - [collections] Support parametized classes with commons.collections.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=39538. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=39538 --- Additional Comments From [EMAIL PROTECTED] 2006-05-15 16:59 --- I wouldn't go so far as to say that it's a lack of motivation. There aren't many folks actively working on collections right now that I know of. So, it could just be a matter of bandwidth. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] ClassUtils.getPublicMethod
Hi: I think ClassUtils is fine unless it gets to be a giant class. I think if asking a class for its methods, so asking a ClassUtils for this info makes sense. I could see a MethodUtils being useful if one needed to perform operations on a bunch of methods. For example: Method[] methods = ClassUtils.getMethods(...); Method[] publicMethods = MethodUtils.toPublicMethods(methods); Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Saturday, May 13, 2006 5:38 AM To: Jakarta Commons Developers List Subject: [lang] ClassUtils.getPublicMethod This is a new addition in this release. Should we be creating a MethodUtils instead? Stephen - 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]
[jira] Commented: (JELLY-230) Problem with default namespace in imported scripts
[
http://issues.apache.org/jira/browse/JELLY-230?page=comments#action_12402354 ]
Lukas Theussl commented on JELLY-230:
-
The replaceNamespace thingy doesn't work for me. I may be doing something wrong
or be missing something, but here is the beginning of the generated build.xml:
x:replaceNamespace xmlns:x=jelly:xml toURI= fromURI=dummy
project xmlns=dummy default=jar basedir=. name=test-maven-ant-plugin
ie the x:replaceNamespace gets translated verbatim, even though I have a
x:comment just before that which gets correctly translated into a comment. I
tried with jelly-tags-xml-1.1 and 1.2-SNAPSHOT from svn.
Anyway, Paul is right that my main concern is backwards compatibility: we would
have to adjust a number of plugins and they would all be incompatible with
older maven releases (the latest stable maven 1.0.2 in particular). Also I
don't think that this is specific to Maven (at least I am not aware of dummy
having any special treatment in maven). The problem is: how to generate a file
without namespace declaration from a template where I need to declare a default
namespace in order to distinguish it from the default namespace of the
application that parses the template?
Problem with default namespace in imported scripts
--
Key: JELLY-230
URL: http://issues.apache.org/jira/browse/JELLY-230
Project: Jelly
Type: Bug
Components: core / taglib.core
Versions: 1.1
Environment: jelly-1.1-SNAPSHOT
Reporter: Lukas Theussl
Assignee: james strachan
Priority: Critical
I am trying to build Maven with jelly-1.1-SNAPSHOT from svn trunk because it
contains a fix for a regression that has blocked us for a long time, see
http://jira.codehaus.org/browse/MAVEN-1691 (gee, I wish I'd checked the svn
archives earlier!).
However, even though jelly-1.1-SNAPSHOT solves the above issue, it also leads
to a whole bunch of test failures in several of our plugins.
After some investigation I found that they all turn out to be due to the same
cause, an apparent backwards incompatibility introduced in the fix for
JELLY-213.
I am not sure actually if this is a bug or the intended behavior, but it
certainly breaks backwards compatibility.
To illustrate the problem: in the ant plugin we use the following snippet to
generate an ant build.xml file from a template:
j:file name=build.xml prettyPrint=true
j:import file=templates/build.jelly inherit=true/
/j:file
where the template file build.jelly looks like this (simplified):
j:jelly
xmlns:ant=jelly:ant
xmlns:j=jelly:core
xmlns=dummy
project name=${pom.artifactId} default=jar basedir=.
target name=clean description=Clean up
delete dir=$${defaulttargetdir}/
delete dir=$${distdir}/
/target
/project
/j:jelly
Note the xmlns=dummy namespace declaration which is necessary to
distinguish the default namespace of the template script from Maven's default
namespace. Now with jelly-1.0, this works as expected, but with the current
jelly-1.1-SNAPSHOT, I get:
project xmlns=dummy name=test-maven-ant-plugin default=jar basedir=.
target description=Clean up name=clean
delete dir=${defaulttargetdir}
/delete
delete dir=${distdir}
/delete
/target
project
ie the dummy namespace declaration makes it into the top-level element of the
generated file. This makes ant very unhappy when invoked on this build file...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] ClassUtils.getPublicMethod
getPublicMethod() sounds to me like it belongs in MethodUtils. At least, if I saw two classes, MethodUtils and ClassUtils, I'd probably look in MethodUtils if I was looking for a method. -Original Message- From: Gary Gregory [mailto:[EMAIL PROTECTED] Sent: Monday, May 15, 2006 1:04 PM To: Jakarta Commons Developers List Subject: RE: [lang] ClassUtils.getPublicMethod Hi: I think ClassUtils is fine unless it gets to be a giant class. I think if asking a class for its methods, so asking a ClassUtils for this info makes sense. I could see a MethodUtils being useful if one needed to perform operations on a bunch of methods. For example: Method[] methods = ClassUtils.getMethods(...); Method[] publicMethods = MethodUtils.toPublicMethods(methods); Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Saturday, May 13, 2006 5:38 AM To: Jakarta Commons Developers List Subject: [lang] ClassUtils.getPublicMethod This is a new addition in this release. Should we be creating a MethodUtils instead? Stephen - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[logging] Maven 2 POM(s) for commons-logging [Was: RE : [ANNOUNCEMENT] Apache Jakarta Commons Logging 1.1 Released]
Olivier Lamy wrote: Hi,n Thanks it's great job which fixes some troubles. But I have a trouble concerning the pom published [1]. I have recorded an MEV issue [2] A commons-logging developper's can put a comment or approve it ? Thanks, - Olivier [1] http://www.ibiblio.org/maven2/commons-logging/commons-logging/1.1/commons-logging-1.1.pom [2] http://jira.codehaus.org/browse/MEV-392 snip/ I have written a comment in the JIRA issue about why the situation is the way it is. The question is how we should proceed? Should we try to tweak the POM that is currently deployed [1] or should we try to create a POM for commons-logging-api or perhaps both? Any thoughts? -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Maven 2 POM(s) for commons-logging [Was: RE : [ANNOUNCEMENT] Apache Jakarta Commons Logging 1.1 Released]
On Mon, 2006-05-15 at 20:51 +0200, Dennis Lundberg wrote: Olivier Lamy wrote: Hi,n Thanks it's great job which fixes some troubles. But I have a trouble concerning the pom published [1]. I have recorded an MEV issue [2] A commons-logging developper's can put a comment or approve it ? Thanks, - Olivier [1] http://www.ibiblio.org/maven2/commons-logging/commons-logging/1.1/commons-logging-1.1.pom [2] http://jira.codehaus.org/browse/MEV-392 snip/ I have written a comment in the JIRA issue about why the situation is the way it is. looks good :-) The question is how we should proceed? Should we try to tweak the POM that is currently deployed [1] i didn't deploy that POM and don't have karma: we'd need to talk the to maven team. it's too late for me to change the release POM deployed to the Apache repository: it's cut. the easiest approach would be for one of the maven team (who has karma) to apply appropriate modifications to the POM version in the maven 2 repository. or should we try to create a POM for commons-logging-api or perhaps both? not sure the API works best as a virtual dependency. it can be satisfied by JCL 1.0.x, 1.1.x, by ceki's adapter or by Torsten's null implementation. not sure whether maven 2 handles this ATM. but the API jar contains more than is necessary for this purpose. probably carlos is right that all the dependencies need to be marked as optional but the full JCL jar shipped. not sure... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
On Sun, 2006-05-14 at 12:32 -0700, Phil Steitz wrote: On 5/14/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Sat, 2006-05-13 at 15:21 -0700, Henri Yandell wrote:# snip I feel that we should be using ACL's on the maven repository on minotaur such that only a PMC can release their code onto the maven repository - but there hasn't seemed much interest in trying to do such. IMHO bit pointless ATM. need to remove shell from the distribution machine before changes like this are worthwhile. but definitely worth bringing up again in a month or two. i've been thinking about using subversion to manage distributions. in addition to better ACLs, this would allow scripts to be run that could verify signatures. be a good thing to move to henk's system of key management as well. What is that system? many months ago, henk penning presented a system for ASF OpenPGP key management but i can't find a reference right now. with a bit of luck i might be able to catch up with henk at apachecon europe... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] change group id? [WAS Re: [logging] RC on ibiblio ?]
On 5/15/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Sun, 2006-05-14 at 12:32 -0700, Phil Steitz wrote: On 5/14/06, robert burrell donkin [EMAIL PROTECTED] wrote: be a good thing to move to henk's system of key management as well. What is that system? many months ago, henk penning presented a system for ASF OpenPGP key management but i can't find a reference right now. with a bit of luck i might be able to catch up with henk at apachecon europe... Some of it is here: http://people.apache.org/~henkp/trust/ Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Maven 2 POM(s) for commons-logging [Was: RE : [ANNOUNCEMENT] Apache Jakarta Commons Logging 1.1 Released]
I'm gonna tweak the poms in the repository outside of apache, please add the optional property in the optional dependencies for future versions. I'll take a look to the other jars to make poms. On 5/15/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Mon, 2006-05-15 at 20:51 +0200, Dennis Lundberg wrote: Olivier Lamy wrote: Hi,n Thanks it's great job which fixes some troubles. But I have a trouble concerning the pom published [1]. I have recorded an MEV issue [2] A commons-logging developper's can put a comment or approve it ? Thanks, - Olivier [1] http://www.ibiblio.org/maven2/commons-logging/commons-logging/1.1/commons-logging-1.1.pom [2] http://jira.codehaus.org/browse/MEV-392 snip/ I have written a comment in the JIRA issue about why the situation is the way it is. looks good :-) The question is how we should proceed? Should we try to tweak the POM that is currently deployed [1] i didn't deploy that POM and don't have karma: we'd need to talk the to maven team. it's too late for me to change the release POM deployed to the Apache repository: it's cut. the easiest approach would be for one of the maven team (who has karma) to apply appropriate modifications to the POM version in the maven 2 repository. or should we try to create a POM for commons-logging-api or perhaps both? not sure the API works best as a virtual dependency. it can be satisfied by JCL 1.0.x, 1.1.x, by ceki's adapter or by Torsten's null implementation. not sure whether maven 2 handles this ATM. but the API jar contains more than is necessary for this purpose. probably carlos is right that all the dependencies need to be marked as optional but the full JCL jar shipped. not sure... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r406753 - /jakarta/commons/proper/logging/trunk/project.xml
Author: rdonkin Date: Mon May 15 15:07:29 2006 New Revision: 406753 URL: http://svn.apache.org/viewcvs?rev=406753view=rev Log: Added properties for Maven 2. Modified: jakarta/commons/proper/logging/trunk/project.xml Modified: jakarta/commons/proper/logging/trunk/project.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/project.xml?rev=406753r1=406752r2=406753view=diff == --- jakarta/commons/proper/logging/trunk/project.xml (original) +++ jakarta/commons/proper/logging/trunk/project.xml Mon May 15 15:07:29 2006 @@ -190,7 +190,9 @@ properties comment Runtime Optional. -1.2.12 required for compilation but 1.2.6 onwards supported at runtime./comment +1.2.12 required for compilation but 1.2.6 onwards supported at runtime. +/comment +optionaltrue/optional /properties /dependency @@ -201,6 +203,7 @@ urlhttp://avalon.apache.org/logkit//url properties commentRuntime Optional/comment +optionaltrue/optional /properties /dependency @@ -212,6 +215,7 @@ properties commentUsed for testing only./comment scopetest/scope +optionaltrue/optional /properties /dependency @@ -222,6 +226,7 @@ urlhttp://avalon.apache.org//url properties commentRuntime Optional/comment +optionaltrue/optional /properties /dependency @@ -232,6 +237,7 @@ urlhttp://java.sun.com/products/servlet//url properties commentUsed only by servlet filter. Not used by core logging implementation./comment +optionaltrue/optional /properties /dependency @@ -245,6 +251,7 @@ comment lt;stronggt;Site Onlylt;/stronggt; - v1.9.2 (minimum) /comment + optionaltrue/optional /properties /dependency /dependencies - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Maven 2 POM(s) for commons-logging
On Mon, 2006-05-15 at 14:21 -0700, Carlos Sanchez wrote: I'm gonna tweak the poms in the repository outside of apache, thanks please add the optional property in the optional dependencies for future versions. done do we need to roll this out for all commons projects? I'll take a look to the other jars to make poms. note that the api and adapters jars are not really modules: they are selections of the classes available in the main jar. they are used within containers (for example, tomcat) with complex hierarchical classloaders. whether api, adapter or full JCL should be used may depend on the particular container the application is targeted at. the api jar also doubles as a compilation time virtual dependency. so, a component listing the api jar as a dependency could have this dependency satisfied by the API jar, the full jar, ceki's bridging API, or Torsten's null implementation. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 39590] New: - [pool] GenericObjectPool not FIFO with respect to borrowing threads
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=39590. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=39590 Summary: [pool] GenericObjectPool not FIFO with respect to borrowing threads Product: Commons Version: 1.3 Final Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Pool AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] GenericObjectPool has recently been made FIFO with respect to the managed pool objects -- however, it is still not FIFO with respect to threads requesting those objects. Specifically, because standard non-fair Java synchronization monitors are used, later threads may barge ahead of earlier threads that are already waiting for a pool object to become available. At its extreme, some threads can cycle objects through the pool many times while others wait interminable. Not every application needs FIFO fairness with respect to threads, and such fairness implies an overhead, so it need not be the default behavior, but it would be a valuable option where many threads are sharing a smaller number of pool objects. I can submit a FairGenericObjectPool which achieves thread-fairness; it only requires small changes to GenericObjectPool which allow some subclass overriding. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 39590] - [pool] GenericObjectPool not FIFO with respect to borrowing threads
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=39590. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=39590 [EMAIL PROTECTED] changed: What|Removed |Added Severity|normal |enhancement Status|NEW |NEEDINFO OS/Version|other |All Priority|P2 |P3 Platform|Other |All Version|1.3 Final |Nightly Builds --- Additional Comments From [EMAIL PROTECTED] 2006-05-16 01:58 --- I'd be interested to see your FairGenericObjectPool implementation. Be aware that if it depends on features of the 1.5 JDK it may be a while before included in the Pool distribution. The next release I'm working on will use Java 1.4 as a baseline. If you have fair ordering working with only Java 1.4 features I'll probably add it to my to do list for Pool 2.0. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 39576] - [math] Function Fraction math.fraction.FractionFormat.parse(String, ParsePosition) does not handle parsing the numerater properly
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=39576. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=39576 --- Additional Comments From [EMAIL PROTECTED] 2006-05-16 03:56 --- Thank you for reporting this. I agree that the treatment of minus signs in the fractional parts of mixed fractions is not correct. I think, however, that the correct solution is to throw a ParseException when the fractional part is negative. If there are no objections, I will make that change. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bugzilla-Jira migration
Trying again tonight. I'm at the slow manual stage, but have done a full migration for Commons Attributes and it looks good. Martin's closed [EMAIL PROTECTED] to new issues again. Hen On 5/13/06, Henri Yandell [EMAIL PROTECTED] wrote: And giving up for the moment to regroup later. Hen On 5/13/06, Henri Yandell [EMAIL PROTECTED] wrote: Ack. I screwed up in my understanding of how the version-fixing script works. Should have taken a copy of Jira 3 hours ago. Starting again *wince*. Hen On 5/13/06, Henri Yandell [EMAIL PROTECTED] wrote: Issues are loaded into Jira. Bugzilla is 'closed' - which I think means that people can still work on the issues there but can't add new ones. Apparantly you can't get any more read-only than that. Currently I'm slowly moving the components from the imported Commons project into the newly created projects. Hen On 5/13/06, Henri Yandell [EMAIL PROTECTED] wrote: Attempting to do this now. Will take a good few hours I suspect. We'll figure out any issues that pop up in Bugzilla in the meantime after the fact. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r406847 - in /jakarta/commons/proper: attributes/trunk/ beanutils/trunk/ betwixt/trunk/ chain/trunk/ cli/trunk/ codec/trunk/ collections/trunk/ commons-build/trunk/ daemon/trunk/ dbcp/trun
Author: bayard
Date: Mon May 15 22:48:03 2006
New Revision: 406847
URL: http://svn.apache.org/viewcvs?rev=406847view=rev
Log:
Switched url from bugzilla to jira
Modified:
jakarta/commons/proper/attributes/trunk/project.xml
jakarta/commons/proper/beanutils/trunk/project.xml
jakarta/commons/proper/betwixt/trunk/project.xml
jakarta/commons/proper/chain/trunk/project.xml
jakarta/commons/proper/cli/trunk/project.xml
jakarta/commons/proper/codec/trunk/project.xml
jakarta/commons/proper/collections/trunk/project.xml
jakarta/commons/proper/commons-build/trunk/project.xml
jakarta/commons/proper/daemon/trunk/project.xml
jakarta/commons/proper/dbcp/trunk/project.xml
jakarta/commons/proper/dbutils/trunk/project.xml
jakarta/commons/proper/digester/trunk/project.xml
jakarta/commons/proper/discovery/trunk/project.xml
jakarta/commons/proper/el/trunk/project.xml
jakarta/commons/proper/email/trunk/project.xml
jakarta/commons/proper/fileupload/trunk/project.xml
jakarta/commons/proper/io/trunk/project.xml
jakarta/commons/proper/jexl/trunk/project.xml
jakarta/commons/proper/jxpath/trunk/project.xml
jakarta/commons/proper/lang/trunk/project.xml
jakarta/commons/proper/launcher/trunk/project.xml
jakarta/commons/proper/logging/trunk/project.xml
jakarta/commons/proper/math/trunk/project.xml
jakarta/commons/proper/modeler/trunk/project.xml
jakarta/commons/proper/net/trunk/project.xml
jakarta/commons/proper/pool/trunk/project.xml
jakarta/commons/proper/primitives/trunk/project.xml
jakarta/commons/proper/scxml/trunk/project.xml
jakarta/commons/proper/transaction/trunk/project.xml
jakarta/commons/proper/validator/trunk/project.xml
jakarta/commons/proper/vfs/trunk/project.xml
Modified: jakarta/commons/proper/attributes/trunk/project.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/attributes/trunk/project.xml?rev=406847r1=406846r2=406847view=diff
==
--- jakarta/commons/proper/attributes/trunk/project.xml (original)
+++ jakarta/commons/proper/attributes/trunk/project.xml Mon May 15 22:48:03 2006
@@ -60,7 +60,7 @@
/licenses
gumpRepositoryIdjakarta/gumpRepositoryId
-issueTrackingUrlhttp://issues.apache.org/bugzilla//issueTrackingUrl
+issueTrackingUrlhttp://issues.apache.org/jira//issueTrackingUrl
siteAddressjakarta.apache.org/siteAddress
siteDirectory/www/jakarta.apache.org/commons/${pom.artifactId.substring(8)}//siteDirectory
Modified: jakarta/commons/proper/beanutils/trunk/project.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/beanutils/trunk/project.xml?rev=406847r1=406846r2=406847view=diff
==
--- jakarta/commons/proper/beanutils/trunk/project.xml (original)
+++ jakarta/commons/proper/beanutils/trunk/project.xml Mon May 15 22:48:03 2006
@@ -43,7 +43,7 @@
/licenses
gumpRepositoryIdjakarta/gumpRepositoryId
- issueTrackingUrlhttp://issues.apache.org/bugzilla//issueTrackingUrl
+ issueTrackingUrlhttp://issues.apache.org/jira//issueTrackingUrl
siteAddresscvs.apache.org/siteAddress
siteDirectory/www/jakarta.apache.org/commons/${pom.artifactId.substring(8)}//siteDirectory
distributionDirectory/www/jakarta.apache.org/builds/jakarta-commons/${pom.artifactId.substring(8)}//distributionDirectory
Modified: jakarta/commons/proper/betwixt/trunk/project.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/betwixt/trunk/project.xml?rev=406847r1=406846r2=406847view=diff
==
--- jakarta/commons/proper/betwixt/trunk/project.xml (original)
+++ jakarta/commons/proper/betwixt/trunk/project.xml Mon May 15 22:48:03 2006
@@ -43,7 +43,7 @@
/licenses
gumpRepositoryIdjakarta/gumpRepositoryId
- issueTrackingUrlhttp://issues.apache.org/bugzilla//issueTrackingUrl
+ issueTrackingUrlhttp://issues.apache.org/jira//issueTrackingUrl
siteAddresscvs.apache.org/siteAddress
siteDirectory/www/jakarta.apache.org/commons/${pom.artifactId.substring(8)}//siteDirectory
distributionDirectory/www/jakarta.apache.org/builds/jakarta-commons/${pom.artifactId.substring(8)}//distributionDirectory
Modified: jakarta/commons/proper/chain/trunk/project.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/chain/trunk/project.xml?rev=406847r1=406846r2=406847view=diff
==
--- jakarta/commons/proper/chain/trunk/project.xml (original)
+++ jakarta/commons/proper/chain/trunk/project.xml Mon May 15 22:48:03 2006
@@ -32,7 +32,7 @@
gumpRepositoryIdjakarta/gumpRepositoryId
- issueTrackingUrlhttp://issues.apache.org/bugzilla//issueTrackingUrl
+ issueTrackingUrlhttp://issues.apache.org/jira//issueTrackingUrl
