cvs commit: jakarta-commons/fileupload/src/java/org/apache/commons/fileupload FileUploadBase.java

martinc 2004/01/22 22:51:10 Modified:fileupload/src/java/org/apache/commons/fileupload FileUploadBase.java Log: Collapse some all but duplicated code. Revision ChangesPath 1.5 +12 -30 jakarta-commons/fileupload/src/java/org/apache/commons

Re: [PATCH] codec: Binary encoder/decoder addition

When I create release notes I usually look at cvs log for the entire project. Having a Bugzilla issue isn't a requirement for every change. It was refreshing to have a substantial patch for a change thanks to Alex. At least someone is paying attention to the software in the middle of all the

Re: [net] JDK 1.1 question

On Thursday 22 January 2004 6:02 am, Steve Cohen wrote: > On Thursday 22 January 2004 12:04 am, Steve Cohen wrote: > > I have built a candidate release for 1.1.1. > > > > Testing it is has proven a bit problematical. I found an old Blackdown > > port of java 1.1.8 for Linux. I don't believe Sun e

RE: FeedParser in CVS with Atom Support (migrate to Jakarta Commons)

Kevin A. Burton wrote: > Looking at the incubator documentation scares me. Seems like a lot of > work. I've been doing the OSS thing for a while now... not sure if I > need that. The docs are probably still out of date. We just moved code through the Incubator in something over a week, most of

DO NOT REPLY [Bug 25050] - getValue() and iterate() are not consistent

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

cvs commit: jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/model/beans PropertyOwnerPointer.java NullPropertyPointer.java

dmitri 2004/01/22 17:10:21 Modified:jxpath/src/java/org/apache/commons/jxpath/ri/model/dynamic DynamicPropertyIterator.java DynamicPointer.java jxpath/src/java/org/apache/commons/jxpath/ri/axes SimplePathInterpreter.java

Re: Jxpath vs. Jaxen?

Matthew, If you have the need to traverse through Java Beans, Maps, Collections etc, JXPath does all of that out of the box. Plus it supports mixed models, e.g. a map containing DOM documents or a Java Bean that has a JDOM document as the value of some property. Jaxen is better suited for homogen

Re: [codec] More thoughts on CharSets and Encoders (references: R E: [codec] Streamable Codec Framework)

Quoting Oleg Kalnichevski <[EMAIL PROTECTED]>: > > The most important phrase in Craig's email was: "As such, I'm > > personally not interested in working on any revolutionary Struts or > > Commons designs that do not presume at least J2SE 1.4 / J2EE 1.4 as the > > base platform as the minimum

[RESULT][VOTE] Release Commons Collections 3.0

Jakarta-Commons has voted in favour of releasing Commons-Collections-3.0 +1s Stephen Colebourne Matthew Hawthorne Gary Gregory Arun M Thomas Henri Yandell Yoav Shapira Phil Steitz Noel Bergman No other votes The release process will begin from 2004-01-23T22:00Z unless the PMC objects :-) Stephen

Re: FeedParser in CVS with Atom Support (migrate to Jakarta Commons)

robert burrell donkin wrote: AFAIK since it needs a donation document signing it should probably go through the incubator. in theory since you're already a jakarta committer (burton at apache.org, right?), it should just be a case of being nodded through (but also ensuring that all the legal

Re: FeedParser in CVS with Atom Support (migrate to Jakarta Commons)

Noel J. Bergman wrote: Kevin, are you the sole author of the code? Was it a work-for-hire? You wrote that "Our lawyers have finally had a chance to review the Apache Public License and contributors documents (long story short they had no problems)." Who is "Our"? "Our" is a company

cvs commit: jakarta-commons/cli/src/java/org/apache/commons/cli2 UnexpectedValueException.java MissingOptionException.java

jkeyes 2004/01/22 16:18:07 Modified:cli/src/test/org/apache/commons/cli2 Tag: RESEARCH_CLI_2_ROXSPRING PropertyOptionTest.java cli/src/java/org/apache/commons/cli2/defaults/impl Tag: RESEARCH_CLI_2_ROXSPRING PropertiesImpl.j

cvs commit: jakarta-commons/cli/src/java/org/apache/commons/cli2/resources ResourceHelper.java

jkeyes 2004/01/22 16:17:35 Modified:cli/src/java/org/apache/commons/cli2/resources Tag: RESEARCH_CLI_2_ROXSPRING ResourceHelper.java Added: cli/src/java/org/apache/commons/cli2/validation Tag: RESEARCH_CLI_2_ROXSPRING messages.prop

Re: new project proposal: XML based glue language/component assembly

From: "Todd V. Jonker" <[EMAIL PROTECTED]> >You might want to check out HiveMind in the commons sandbox. Sadly, Hivemind is unavailable at present for legal reasons. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For addi

Re: Jxpath vs. Jaxen?

From: "__matthewHawthorne" <[EMAIL PROTECTED]> > I'm frequently finding myself needing a "Bean query language", and then > I remembered that Jxpath can do this easily. I have only used Jaxen, and found it easy to work with, however I had to add my own code for navigating JavaBeans. Stephen -

cvs commit: jakarta-commons/cli LICENSE.txt

jkeyes 2004/01/22 15:08:16 Modified:cli Tag: RESEARCH_CLI_2_ROXSPRING LICENSE.txt Log: - use license header from website Revision ChangesPath No revision No revision 1.2.2.1 +11 -15jakarta-commons/cli/LICENSE.txt In

RE: FeedParser in CVS with Atom Support (migrate to Jakarta Commons)

robert burrell donkin wrote: > Kevin A. Burton wrote: > I've sent a few emails off to [EMAIL PROTECTED] about this... > had a bunch of +1s... > > You can view the history here: > > http://www.peerfear.org/rss/permalink/2004/01/11/FeedParserAPIForJavaSourceA vailable (and here: http://marc.theaim

cvs commit: jakarta-commons/betwixt/src/resources dotbetwixt.dtd

rdonkin 2004/01/22 14:48:18 Modified:betwixt/src/resources Tag: REFACTORING-BRANCH_2004-01-13 dotbetwixt.dtd Log: Added addDefault attributes to DTD. Revision ChangesPath No revision No revision 1.7.2.1 +6

Re: commons-logging log4j trace support

On 22 Jan 2004, at 22:14, Glen wrote: Great Good news, my change is already implemented as a new log4j bridge (the existing log4j bridge is final so I couldn't extend it). So that part is already done. In essence I copied the original bridge, factory and logger, into Log4jTraceFactory an

cvs commit: jakarta-commons/cli/src/test/org/apache/commons/cli2/defaults/impl PreferencesImplTest.java PreferencesFactoryImpl.java PropertiesImplTest.java PropertiesBackedPreferences.java

jkeyes 2004/01/22 14:40:53 Modified:cli/src/test/org/apache/commons/cli2 Tag: RESEARCH_CLI_2_ROXSPRING ArgumentTestCase.java PrecedenceTest.java SwitchTest.java ArgumentTest.java DocumentationTest.java

Re: commons-logging log4j trace support

Great Good news, my change is already implemented as a new log4j bridge (the existing log4j bridge is final so I couldn't extend it). So that part is already done. In essence I copied the original bridge, factory and logger, into Log4jTraceFactory and Log4jTraceLogger. Then made minor

Re: [codec] More thoughts on CharSets and Encoders (references: R E: [codec] Streamable Codec Framework)

Oleg Kalnichevski wrote: The most important phrase in Craig's email was: "As such, I'm personally not interested in working on any revolutionary Struts or Commons designs that do not presume at least J2SE 1.4 / J2EE 1.4 as the base platform as the minimum requirement." Tim & Craig, I wish I

Re: Allow anonymous issue creation in JIRA? (Re: [PROPOSAL] Jakarta Commons moving to JIRA)

> -Original Message- > From: Noel J. Bergman [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 22, 2004 03:10 AM > To: 'Jakarta Commons Developers List' > Cc: [EMAIL PROTECTED] > Subject: RE: Allow anonymous issue creation in JIRA? (Re: [PROPOSAL] Jakarta > Commons moving to JIRA) >

DO NOT REPLY [Bug 25598] - MultipartStream\IE 5.5 error.

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 25598] - MultipartStream\IE 5.5 error.

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

RE: [Configuration] Throws ConfigurationException?

I agree that it would be nice to have for 1.0, on the otherhand, don't want to rush it in! The subclassing was only done to continue to support pre 1.4 jdk's. We actually used a jdk1.4 specific method call at one point and broke some of our users code! Until we are ready to say 1.4 or better, I'

[jira] Created: (JELLY-104) jelly-tags-define: testSuper failing

Message: A new issue has been created in JIRA. - View the issue: http://nagoya.apache.org/jira/secure/ViewIssue.jspa?key=JELLY-104 Here is an overview of the issue: ---

DO NOT REPLY [Bug 25598] - MultipartStream\IE 5.5 error.

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: [Configuration] Throws ConfigurationException?

Eric Pugh wrote: > Or, if we aren't really sure what the Exception handling of the 1.0 > version should be, then skip it (since what we have is "good enuf"), > and move to a release of 1.0 so we can really think about what we > want. I think just throwing a ConfigurationException on everything > t

RE: [commons] archives assistance

Howdy, >> 2. (More importantly) I can't find a means to search the archives by >project. >> For example, searching on "[Configuration]" in mail subjects at >> http://marc.theaimsgroup.com results in (a) the brackets being removed >from >> the search criteria and (b) all mailing lists (not just ja

RE: [Configuration] Throws ConfigurationException?

Howdy, Long message, short comments: - A runtime exception, yes, not a checked exception. - Good to have for release 1.0: you wouldn't want to introduce this kind of behavior change from 1.0 to 1.1. - Why subclassing a commons-lang exception as opposed to the normal java RuntimeException? For p

Re: [codec] More thoughts on CharSets and Encoders (references: R E: [codec] Streamable Codec Framework)

A +1 for Craig's comments. If there are users who still have 1.2 requirements going forward, I say should say to them, you need to take it upon yourself to make the case for an upgrade, or work actively in this community to write components that work with 1.2. The most important phrase in Crai

Re: FeedParser in CVS with Atom Support (migrate to Jakarta Commons)

hi kevin On 22 Jan 2004, at 00:12, Kevin A. Burton wrote: I've sent a few emails off to [EMAIL PROTECTED] about this... had a bunch of +1s... You can view the history here: http://www.peerfear.org/rss/permalink/2004/01/11/ FeedParserAPIForJavaSourceAvailable (and here: http://marc.theaimsgr

Re: [Configuration] Throws ConfigurationException?

Eric Pugh wrote: Hi all, A while ago we discussed 1.0 requirements that are left. And at this point, all have been finished except changing the api to throw a ConfigurationException. Now, I am thinking about how to implement this, and am not too keen on the idea of ConfigurationException being a

RE: [id] UUID sending more code and a question or two

--- Tim Reilly <[EMAIL PROTECTED]> wrote: > > I agree the JNI will be a PITA for me, especially since I'm re-learning > C. I > have a simple program working on Win2K and RH8. I'm not sure if the code > would need to be recompiled for each target platform (at least making it > an > optional test

Re: [net] JDK 1.1 question

On Thursday 22 January 2004 12:04 am, Steve Cohen wrote: > I have built a candidate release for 1.1.1. > > Testing it is has proven a bit problematical. I found an old Blackdown > port of java 1.1.8 for Linux. I don't believe Sun ever released a port of > Java 1.1 for Linux. Whether this has eve

[Configuration] Throws ConfigurationException?

Hi all, A while ago we discussed 1.0 requirements that are left. And at this point, all have been finished except changing the api to throw a ConfigurationException. Now, I am thinking about how to implement this, and am not too keen on the idea of ConfigurationException being a non runtime expl

Re: [net] release question

Hmm, thanks, Robert. The Sun docs' example makes a better case for their way of doing it than the Apache example does. In particular "Implementation-Version" boils down to basically a build number which is not clearly shown in the Apache example. Of course we don't use these in Commons-net an

cvs commit: jakarta-commons/configuration project.xml

epugh 2004/01/22 03:41:23 Modified:configuration/src/test/org/apache/commons/configuration TestDatabaseConfiguration.java configuration project.xml Log: Fix tests so that testdb.script not regenerated constantly. fixs cvs wanting to chck tes

cvs commit: jakarta-commons-sandbox/attributes/compiler/src/java/org/apache/commons/attributes/compiler AttributeCompiler.java

leosutic2004/01/22 03:00:13 Modified:attributes/compiler/src/java/org/apache/commons/attributes/compiler AttributeCompiler.java Log: Need to erase type information to keep the compiler from signalling an error if the instanceof test can not possibly be true

cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/introspection TestDeclarativeIntrospection.java

rdonkin 2004/01/22 03:00:03 Modified:betwixt/src/java/org/apache/commons/betwixt Tag: REFACTORING-BRANCH_2004-01-13 BeanProperty.java ElementDescriptor.java betwixt/src/test/org/apache/commons/betwixt/introspection

cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/introspection CompanyBean.java

rdonkin 2004/01/22 02:59:30 Added: betwixt/src/test/org/apache/commons/betwixt/introspection Tag: REFACTORING-BRANCH_2004-01-13 CompanyBean.java Log: Used in testing isHollow implementation Revision ChangesPath No revision No

Re: [net] release question

On 22 Jan 2004, at 06:07, Steve Cohen wrote: I see. After looking further into this matter, I begin to doubt the correctness of the http://jakarta.apache.org/commons/releases/prepare.html instructions. hi steve IIRC this point has been talked about at a little length in the past. i see to re

Re: Re[2]: new project proposal: Type Conversion Library

On 22 Jan 2004, at 10:21, Paul Libbrecht wrote: I'm sorry I'm coming so late on this but I wanted to point out one interest into this library: Jelly is currently using BeanUtils with a few registred additional converters (for example Jelly-Swing with Dimensions, Rectangles, Colors, Fonts, ...).

Re: Re[2]: new project proposal: Type Conversion Library

I'm sorry I'm coming so late on this but I wanted to point out one interest into this library: Jelly is currently using BeanUtils with a few registred additional converters (for example Jelly-Swing with Dimensions, Rectangles, Colors, Fonts, ...). However the way these converters are registred

Re: Re[2]: new project proposal: Type Conversion Library

From: "Ron Blaschke" <[EMAIL PROTECTED]> > Thanks a lot for the pointers to convert and how to get involved. I > glanced over convert and it seems the right place to start. I am also willing to help push forward the [convert] project and am willing to apply patches etc. Stephen ---

RE: [codec] More thoughts on CharSets and Encoders (references: R E: [codec] Streamable Codec Framework)

Quoting Gary Gregory <[EMAIL PROTECTED]>: > (1) "eventually" is, sadly I think, a ways off in the future. See > discussions on this list WRT J2ee containers, WebSphere, most common > installed base of such containers, etc. > As a major proponent of long-term support for existing packages that

Re: [io] [PROPOSAL] IO Operations

I think that code like this would be a great addition to [io]. There has been a pattern in a number of commons utilities where code starts as static utilities and then becomes beans/classes underneath. One thing to consider at this point is whether to match the names of the Utils classes to the Op

Re: [commons] archives assistance

Quoting "Jung, Eric (Contractor)" <[EMAIL PROTECTED]>: > Hi, > This is a general question for all commons projects, since they share the > same mailing list: > > 1. Why do they all share the same mailing list? > I know you got your specific technical concerns addressed later in this thread, but

RE: [id] UUID sending more code and a question or two

> > That sounds like a PITA and I wonder if we are really thinking > about this > > correctly. Interleaving JNI calls and comparing timestamps will be hard > > and ultimately inconclusive, IIUC. What exactly did you have in mind > here? > > Why not run the native code, capture the output, and com