On Sat, 14 Jun 2003, David Graham wrote:
Date: Sat, 14 Jun 2003 17:02:35 -0600
From: David Graham [EMAIL PROTECTED]
Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [math] @throws IllegalArgumentException
I am dutifully cleaning up the
On Mon, 16 Jun 2003, Nicolas Mailhot wrote:
Date: 16 Jun 2003 20:50:45 +0200
From: Nicolas Mailhot [EMAIL PROTECTED]
Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED],
[EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Logging
--- Mark R. Diggory [EMAIL PROTECTED] wrote:
Al Chou wrote:
--- Mark R. Diggory [EMAIL PROTECTED] wrote:
I appear to occasionally get JUnit test failures from ValueServer and
RandomData Tests. This would appear to be because the mean sampled
values can sometimes deviate from the
--- Craig R. McClanahan [EMAIL PROTECTED] wrote:
On Sat, 14 Jun 2003, David Graham wrote:
Date: Sat, 14 Jun 2003 17:02:35 -0600
From: David Graham [EMAIL PROTECTED]
Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [math] @throws
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20774.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
From: Michael Heuer [EMAIL PROTECTED]
On Sat, 7 Jun 2003, Stephen Colebourne wrote:
Proposal #3 (Colebourne - merged from #1 and #2):
--
public boolean addAll(int index, Collection c){
if (preAddAll(index, c)) {
result = backingList.addAll(index, c);
--- Mark R. Diggory [EMAIL PROTECTED] wrote:
I've got a design decision to make that I'd like to get others opinion
on. Currently, the strategy in UnivariateImpl is to calculate the
rudimentary building blocks of the statistics and then calculate the
statistics in the getters (getVariance,
I would like to request that these changes be rolled back. I would like to
keep UnivariateImpl separate and lightweight, with improved updating formulas
and good array-based computations when the window in finite. I see the full
stored versions (as I thought Tim did when he defined them) as
--- Tim O'Brien [EMAIL PROTECTED] wrote:
+1, on package structure
(and if the hotel I'm in bothers to install an
ethernet in my room this after, I'll execute this plan barring any binding
-1s)
Thanks.
Also, don't both submitting a patch for this, I'm going to submit to the
power
Hi all,
The HttpClient team is looking to set up clover to get test coverage
reports. I recall a discussion about what the procedure is for Apache
projects to request a clover license but haven't been able to find the
resolution of that discussion.
Does anyone know what the correct procedure is
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-06-17/commons-codec.html
Buildfile: build.xml
init:
[mkdir] Created dir:
Victor,
Alternatively, you could write a custom Clazz for you class, which
would recognize getDeclaredFields() as the read method for the property
fields.
Are you seriously thinking about using Clazz? Do you think it deserves
to have a release? I am morally ready to do a release as long as
As a very-very-very long time Java developer, and a primary contributor to
many Apache projects (including Tomcat and Struts), I strongly suggest
that you push back on the users asking for this -- they're not
understanding the real issues involved. If we did what they want, it's
not really going
Ted,
I appologize it took me so long to look into the problem with the jxpath
build, but finally yesterday I committed a temporary patch for the build
problem. I am actually surprised that the incompatible change in JDOM did
not break much more stuff (it still affects Jaxen - it has not been
Craig R. McClanahan wrote:
1. we absolutely need removal of the log4j classpath entries
The Log4J classpath entries were remnoved prior to the 1.0.3 release of
Commons Logging. What version are you working with?
Looks like we are working with 1.0.3, which was released on April the 7th;
Howdy,
+1, we should recognize someone who spent hours on tomcat-users list
and
who know that a 10 minutes developper fix, could produce days and days
of question on user lists.
While I don't have nearly Craig's tenure, nor nearly as many
contributions to the code, I spend a lot of time on both
Hi Dmitri,
not yet sure, for me it is still a bit too complicated.
If I have the *fealing* that I understand it and
I can retain my higher level interfaces (to invoke
the get/set/add methods) I really think about switching,
because my own code became quite a mess in the
meantime and I like the
--- Phil Steitz [EMAIL PROTECTED] wrote:
--- Mark R. Diggory [EMAIL PROTECTED] wrote:
Al Chou wrote:
--- [EMAIL PROTECTED] wrote:
mdiggory2003/06/16 07:29:31
Modified:math/xdocs developers.xml
math/src/java/org/apache/commons/math/stat
I've had a little look into implementing Commands as I described but wasn't sure how
I'd get them in without adding spaghetti to the
code. While looking around I was reminded of a few things that feel slightly wrong
and began to wonder whether the model might be
wrong. I'll outline the
-1 on that specific commit.
As the originial contributor, I believe you have voting rights for this.
I'd concur on this one. UnivariateImpl is an optimized, performance
oriented storage-less implementation, StoreUnivariate captures another
set of requirements entirely.
Tim
On Tue, 17 Jun
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20836.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20836.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20836.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Phil Steitz wrote:
--- Mark R. Diggory [EMAIL PROTECTED] wrote:
(1) Bean etiquette suggests getters are for bean properties, its
usually recommended that this means that they do nothing more than
return the value for a property.
This is certainly not specified anywhere in the Javabeans spec.
-1,
Lets be clear here, your telling me that you think that
AbstractStoreUnivariate is a Heavy Implementation and that somehow
implementing the entire implementation and interface again in
UnivariateImpl to support the same functionality there is somehow
lighter? I entirely disagree with
On Tue, 17 Jun 2003, Mark R. Diggory wrote:
Phil Steitz wrote:
--- Mark R. Diggory [EMAIL PROTECTED] wrote:
I'm sorry, I'm not really talking about the spec, just a general trend
in design of Java Beans that I've observed and kinda been trained to
do. So, if its against the spec even, I
Phil Steitz wrote:
--- Mark R. Diggory [EMAIL PROTECTED] wrote:
Tim O'Brien wrote:
On Tue, 17 Jun 2003, Mark R. Diggory wrote:
Phil Steitz wrote:
--- Mark R. Diggory [EMAIL PROTECTED] wrote:
I'm sorry, I'm not really talking about the spec, just a
Mark R. Diggory wrote:
Lastly, if the above approach is rejected by the group, then I highly
recommend that there be separate implementations of the storageless
RollingUnivariate and storage based RollingStoreUnivariate to
reduce the both interface confusion that is currently observable in
mdiggory2003/06/17 10:10:15
Modified:math/src/java/org/apache/commons/math/stat
UnivariateImpl.java
Log:
Rolling back to version 1.5 to provide for group discussion on the subject
Revision ChangesPath
1.9 +309 -343
Please be more verbose, are you voting -1 on everything in this message,
there is more than one recommendation in the proposal. Also, I was using
this message to formalize and clarify the changes that I an
recommending, as such I'm trying to make this the point from which more
formal
-1, see previous discussion
On Tue, 17 Jun 2003, Mark R. Diggory wrote:
Proposal:
The deligation of UnivariateImpl to AbstractStoreUnivariate and
refactoring of Univariate Interfaces.
Goals:
(1) I propose that UnivariateImpl should deligate to either a full
implmentation of
Phil Steitz wrote:
--- Craig R. McClanahan [EMAIL PROTECTED] wrote:
On Sat, 14 Jun 2003, David Graham wrote:
Date: Sat, 14 Jun 2003 17:02:35 -0600
From: David Graham [EMAIL PROTECTED]
Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [math]
jfclere 2003/06/17 09:46:24
Modified:daemon/src/native/nt/procrun procrun.c
Log:
Arrange the win9x support.
Revision ChangesPath
1.24 +150 -8jakarta-commons-sandbox/daemon/src/native/nt/procrun/procrun.c
Index: procrun.c
On Tue, 17 Jun 2003, Mark R. Diggory wrote:
Please be more verbose, are you voting -1 on everything in this message,
there is more than one recommendation in the proposal.
-1, on Unifying Univariate and StoreUnivariate. I see no need for this,
as there are measures which are impossible to
Phil Steitz wrote:
--- Mark R. Diggory [EMAIL PROTECTED] wrote:
(1) I propose that UnivariateImpl should deligate to either a full
implmentation of StoreUnivariate or it should extend the
AbstractStoreUnivariate instead of supporting multiple implementations
of the Statistical Methods for
I've roughed out the beginnings of StatUtils (based on implementations
found in AbstractStoreUnivariate). I will add this if all seem to agree
on its usage.
-Mark
Index: StatUtils.java
===
RCS file: StatUtils.java
diff -N
+1
On Tue, 17 Jun 2003, Mark R. Diggory wrote:
I've roughed out the beginnings of StatUtils (based on implementations
found in AbstractStoreUnivariate). I will add this if all seem to agree
on its usage.
-Mark
--
--
Tim O'Brien
Evanston, IL
(847) 863-7045
[EMAIL
Hi,
some nitpicking from me (currently trying to write a user guide for me):
why is
ReflectedPropertyIntrospector
not called
ReflectionPropertyInspector?
Would be a little bit clearer from my point of view, that objects of this
class are actively
doing something.
I do not like
luehe 2003/06/17 13:18:11
Modified:el/src/java/org/apache/commons/el ArithmeticOperator.java
Coercions.java DivideOperator.java
GreaterThanOperator.java
GreaterThanOrEqualsOperator.java
Morten Primdahl wrote:
Hi,
I'm wondering what the rationale behind not having the close()
method on the interface is? The DefaulFileSystemManager has
the implementation of this method, and it would make working
with VFS.getManager() a little nicer.
What's the status on this project BTW? I've
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20844.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20844.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
some nitpicking from me (currently trying to write a user guide for me):
why is
ReflectedPropertyIntrospector
not called
ReflectionPropertyInspector?
Would be a little bit clearer from my point of view, that objects of this
class are actively
doing something.
Introspection is an
hlship 2003/06/17 14:12:57
jakarta-commons-sandbox/hivemind/src/xsl - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
hlship 2003/06/17 14:12:57
jakarta-commons-sandbox/hivemind/src/test-data/sample - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
hlship 2003/06/17 14:13:07
Modified:hivemind/xdocs/images InterceptorStack.png
hivemind/src/java/org/apache/commons/hivemind/parse
HiveMind_1.0.xsd
hivemind/xdocs navigation.xml
hivemind maven.xml
Thanks, good points.
- Dmitri
--- Victor Volle [EMAIL PROTECTED] wrote:
Hi,
some nitpicking from me (currently trying to write a user guide for
me):
why is
ReflectedPropertyIntrospector
not called
ReflectionPropertyInspector?
Would be a little bit clearer from my
tobrien 2003/06/17 14:16:08
Added: math/src/java/org/apache/commons/math BrentSolver.java
MathConfigurationException.java MathException.java
SecantSolver.java UnivariateRealFunction.java
UnivariateRealSolver.java
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20844.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On Tuesday, June 17, 2003, at 06:33 AM, Craig R. McClanahan wrote:
On Sat, 14 Jun 2003, robert burrell donkin wrote:
maybe it's time to think about adding an optional package
(org.apache.commons.beantuils.optional?) and a build for a
beanutils-optional.jar inspired by the way that ant manages
--- Mark R. Diggory [EMAIL PROTECTED] wrote:
I've roughed out the beginnings of StatUtils (based on implementations
found in AbstractStoreUnivariate). I will add this if all seem to agree
on its usage.
+1 for this approach, rolling back previous changes and having
AbstractStoreUnivariate
Hi!
I have uploaded the first few paragraphs of my User Guide to
http://www.artive.de/clazz/docs/userguide.html
I am not promising to finish it, but if not, you can use it (put it under
the
Apache license) and change it anyway you want.
I am (for now) very willing to make corrections,
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10319.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
hi eric
i've taken a quick look and i quite like the sound of this solution. the
problem is that i'd have analysis the patch in depth (due to it's size and
complexity) before i could commit it. i can't speak for the others but i'm
don't have the cycles right now for this. maybe someone else
I do not like the names of ~Support classes. ~Support or ~Helper indicate
(for me)
that these are Helper classes with (often static) utility functions. In
the
Java API I think
I have found the usage of Abstract~ or Base~ much more often for classes
You've missed an important difference
as i understand, infrastructure will provide access if that the jakarta
pmc actively approves the apache committer (whether from jakarta or not).
the process now (whether you're a jakarta committer or from elsewhere in
apache) is that you need to post a request to the pmc including an
outlined
IIRC it was one of those threads that died down without any real
conclusion. you could try asking on community or asking the jakarta pmc.
- robert
On Tuesday, June 17, 2003, at 10:25 AM, Adrian Sutton wrote:
Hi all,
The HttpClient team is looking to set up clover to get test coverage
reports.
I typically use the suffix Support for non-required, non-abstract
convenience base classes. The word comes from the JDK. See for
example java.beans.PropertyChangeSupport.
I don't have any problem with renaming them to Base* classes.
- Dmitri
--- [EMAIL PROTECTED] wrote:
I do not like the
I have commons-math and commons-codec clover licenses which are available
to any commons committer who asks, and are housed on apache
infrastructure.
I think it would be cleaner from a legal standpoint if someone like Robert
asked for a commons-wide license, or better yet if the PMC asked for
Hm, have never recognized these ...
and ~Support is only used in the java.beans... packages.
and Abstract~ is used in the java.util.* and in javax.swing...
Victor
I typically use the suffix Support for non-required, non-abstract
convenience base classes. The word comes from the JDK. See for
Phil Steitz wrote:
--- Mark R. Diggory [EMAIL PROTECTED] wrote:
I've roughed out the beginnings of StatUtils (based on implementations
found in AbstractStoreUnivariate). I will add this if all seem to agree
on its usage.
+1 for this approach, rolling back previous changes and having
jkeyes 2003/06/17 15:39:03
Modified:cli/src/test/org/apache/commons/cli Tag: cli_1_x
BugzillaTest.java GnuParseTest.java
cli/src/java/org/apache/commons/cli Tag: cli_1_x
CommandLineParser.java
Log:
- CommandLineParser
mdiggory2003/06/17 15:55:39
Added: math/src/java/org/apache/commons/math/stat StatUtils.java
Log:
Initial Addition of StatUtils. Some methods need review, implementation and possibly
debugging
Revision ChangesPath
1.1
mdiggory2003/06/17 16:00:18
Modified:math/src/java/org/apache/commons/math/stat StatUtils.java
Log:
Missed two static signatures in the methods
Revision ChangesPath
1.2 +2 -2
jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/StatUtils.java
Hello,
I have been investigating commons-attributes for use with XML-RPC,
specifically to denote which methods on a given class should be exposed
via an XML-RPC server. I have done some reading on the web about
metadata, including JSR175.
I would like to get feedback from some more
Hi all,
As this is now a sensitive subject, I'm not going to commit this until I
receive +/- input from the group. Please review the following
UnivariateImpl and submit your opinion, This version of UnivariateImpl
no longer extends AbstractStoredUnivariate to accomplish delegation, but
does
mdiggory2003/06/17 16:23:07
Modified:math/src/java/org/apache/commons/math/stat StatUtils.java
Log:
Addition of product and geometericMean.
Revision ChangesPath
1.3 +26 -0
jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/StatUtils.java
I do not like the names of ~Support classes. ~Support or ~Helper
indicate
(for me)
that these are Helper classes with (often static) utility functions. In
the
Java API I think
I have found the usage of Abstract~ or Base~ much more often for
classes
You've missed an important difference
For what it's worth, I've always used ~Support to indicate a class that is
used via delegation to fulfill the contract of an interface.
e.g.
interface XxxInterface
{
public void a();
}
abstract class AbstractXxx
implements XxxInterface
{
public void a() { ...; }
}
class XxxSupport
//
--- Mark R. Diggory [EMAIL PROTECTED] wrote:
Hi all,
As this is now a sensitive subject, I'm not going to commit this until I
receive +/- input from the group. Please review the following
UnivariateImpl and submit your opinion, This version of UnivariateImpl
no longer extends
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20826.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10816.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Kalnichevski, Oleg wrote:
Sung-Gu and all,
I must confess I have had a change of heart on this issue. I am no more convinced that URI URIUtil classes should be spun off into a Commons project of its own.
1) URL encoding logic that constitutes almost a half of the reusable code in URI related
Kalnichevski, Oleg wrote:
1) URL encoding logic that constitutes almost a half of the reusable
code in URI related classes clearly belongs to Commons-Codec package.
URL encoding decoding functions should be merged with Commons-Codec
rather than spun off. HttpClient will introduce Commons-Codec as
Adrian Sutton wrote:
Sounds quite reasonable. The other thing to consider is exactly how
much the URI classes are likely to change anyway. They pretty much do
what's required now and I find it hard to imagine there'd be too many
changes that need to be made.
Code can always be nicer and more
75 matches
Mail list logo
