lass() });
m.invoke(null, new Object[] { realClassArgs });
}
-Original Message-
From: Tomasz Pik [mailto:[EMAIL PROTECTED]
Sent: Monday, November 17, 2003 12:03 PM
To: Jakarta Commons Developers List
Subject: Re: [Math] common-math and bloated 3rd party libraries
Mark R. Diggory wrote
);
}
-Original Message-
From: Tomasz Pik [mailto:[EMAIL PROTECTED]
Sent: Monday, November 17, 2003 12:03 PM
To: Jakarta Commons Developers List
Subject: Re: [Math] common-math and bloated 3rd party libraries
Mark R. Diggory wrote:
I know there were a means to setup logging for debugging wi
Paul Libbrecht wrote:
Mark R. Diggory wrote:
Paul Libbrecht wrote:
Mark R. Diggory wrote:
I removed instances of this Logging entry in an earlier commit. I
think awhile back there was allot of discussion about if this should
throw an exception or return NaN. The origin of this exception i
Mark R. Diggory wrote:
Paul Libbrecht wrote:
Mark R. Diggory wrote:
I removed instances of this Logging entry in an earlier commit. I
think awhile back there was allot of discussion about if this should
throw an exception or return NaN. The origin of this exception is a
Convergence Exception
Paul Libbrecht wrote:
Mark R. Diggory wrote:
I removed instances of this Logging entry in an earlier commit. I
think awhile back there was allot of discussion about if this should
throw an exception or return NaN. The origin of this exception is a
Convergence Exception in ContinuedFraction. T
Mark R. Diggory wrote:
I removed instances of this Logging entry in an earlier commit. I think
awhile back there was allot of discussion about if this should throw an
exception or return NaN. The origin of this exception is a Convergence
Exception in ContinuedFraction. The big question is the sa
J.Pietschmann wrote:
Paul Libbrecht wrote:
a.) logging:
I don't really agree here. I do think it is very useful for any system
to be able to raise a logging verbosity at any-time so that bugs and
misunderstandings can be tracked.
It depends on the complexity of the stuff potentially being p
Al Chou wrote:
a.) logging: It sounds like a good idea to make logging a
runtime/compile time dependency on only the test cases and not the main
+1
I don't really agree here. I do think it is very useful for any system
to be able to raise a logging verbosity at any-time so that bugs and
misun
--- "Mark R. Diggory" <[EMAIL PROTECTED]> wrote:
> I'm trying organize this thread a little bit more than was accomplished
> in the discussion.
Thanks, Mark. Good job.
> 1.) Argument exists concerning the dependency requirements of Commons
> Math. To in fact be "modular" and "easily integrate
On Wed, 5 Nov 2003, Mark R. Diggory wrote:
>
> Hmm, not to be critical, but 5.1 is almost at the end of its product
> lifecycle. Weblogic has had several releases since 5.1 that solve many
> of these issues do they not? I say this mostly to "identify" that there
> is a limitation as to how far ba
Phil Steitz wrote:
I agree with your assessment of that platform; but your comment raises
an interesting question: to what extent should commons component design
decisions be influenced by characteristics of the user base. My opinion
is "lots." "Lame and broken" as it may be, WebLogic 5 on N
--- Phil Steitz <[EMAIL PROTECTED]> wrote:
> David Graham wrote:
> > --- Charles Hudak <[EMAIL PROTECTED]> wrote:
> >
> >>>Mark wrote:
> >>>
> Eric Pugh wrote:
> This backlash against multiple commons jars is happening in a lot of
> >>>
> >>places.
> >>
> However, I think it is a bit
David Graham wrote:
--- Charles Hudak <[EMAIL PROTECTED]> wrote:
Mark wrote:
Eric Pugh wrote:
This backlash against multiple commons jars is happening in a lot of
places.
However, I think it is a bit shortsighted. If you are in a non
server
environment, I understand the problem, but in a ser
Charles Hudak wrote:
Mark wrote:
Eric Pugh wrote:
This backlash against multiple commons jars is happening in a lot of
places.
However, I think it is a bit shortsighted. If you are in a non server
environment, I understand the problem, but in a server environment with
lots
of harddrive space,
Sorry for a little offtopic post.
Charles Hudak wrote:
I think that this comment is a little shortsighted. We are still using
weblogic 5.1 and constantly have problems with the multitude of third party
libraries that we are using. WL 5.1 does not seem to find libraries in the
WEB-INF/lib director
--- Charles Hudak <[EMAIL PROTECTED]> wrote:
> >Mark wrote:
> >> Eric Pugh wrote:
> >> This backlash against multiple commons jars is happening in a lot of
> places.
> >> However, I think it is a bit shortsighted. If you are in a non
> server
> >> environment, I understand the problem, but in a s
>Mark wrote:
>> Eric Pugh wrote:
>> This backlash against multiple commons jars is happening in a lot of
places.
>> However, I think it is a bit shortsighted. If you are in a non server
>> environment, I understand the problem, but in a server environment with
lots
>> of harddrive space, I don't.
I'm trying organize this thread a little bit more than was accomplished
in the discussion.
1.) Argument exists concerning the dependency requirements of Commons
Math. To in fact be "modular" and "easily integrated" some discrepancy
arises concerning interdependency with other commons components
FWIW the math proposal actually says:
"Emphasis on small, easily integrated components rather than large
libraries with c
On Wed, 5 Nov 2003 06:54:14 -0800 (PST), "David Graham"
<[EMAIL PROTECTED]> said:
> Agreed, especially because Jakarta's mission is to create *server*
> side libraries.
[...]
> The need to support 1.3 is diminishing over time. Java 1.4 is
> available and runs well on all the major platforms I ca
ble components. Suns Logging should have been a
logically separate component that one should be able to add onto 1.3.1
-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 05, 2003 06:54
To: Jakarta Commons Developers List
Subject: RE: [Math] common-
ROTECTED]
> Sent: Wednesday, November 05, 2003 06:27
> To: Jakarta Commons Developers List
> Subject: Re: [Math] common-math and bloated 3rd party libraries
>
> I, for one, like the idea of commons projects depending on each other
> when necessary. There is always a lot of controversy wi
.3. I should not be forced to do that.
Gary
> -Original Message-
> From: David Graham [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 05, 2003 06:54
> To: Jakarta Commons Developers List
> Subject: RE: [Math] common-math and bloated 3rd party libraries
>
>
>
David Graham wrote:
In this case, it looks like commons-lang and commons-logging are only
needed because math doesn't use Java 1.4 as the base level. Moving to
Java 1.4 has the advantage of providing exception chaining and logging in
the Java core and eliminates 2 jars. Obviously, the disadvant
--- Eric Pugh <[EMAIL PROTECTED]> wrote:
> This backlash against multiple commons jars is happening in a lot of
> places.
> However, I think it is a bit shortsighted. If you are in a non server
> environment, I understand the problem, but in a server environment with
> lots
> of harddrive space,
Brian McCallister wrote:
On Wednesday, November 5, 2003, at 09:26 AM, __matthewHawthorne wrote:
Why does a math module depend on a logging module for deployment? Have
the unit tests log, not the math functions.
=)
> -Brian
Bright Idea...I hadn't really thought about that. :-)
--
Mark Diggo
Hehehe, thats a novel idea. Ok to be devils advocate...
Your coming at this from "one jar" perspective. Which leads me to
wonder why having math be "one jar" is important to you? Can you please
elaborate on this?
And to the rest of the community I postulate: Is this a critical usage case?
The
This backlash against multiple commons jars is happening in a lot of places.
However, I think it is a bit shortsighted. If you are in a non server
environment, I understand the problem, but in a server environment with lots
of harddrive space, I don't. Additionally, since in a server app you are
On Wednesday, November 5, 2003, at 09:26 AM, __matthewHawthorne wrote:
I, for one, like the idea of commons projects depending on each other
when necessary. There is always a lot of controversy with regards to
"including another jar" that I don't quite understand. I agree that
if there are on
I, for one, like the idea of commons projects depending on each other
when necessary. There is always a lot of controversy with regards to
"including another jar" that I don't quite understand. I agree that if
there are only 1 or 2 references, it may be reasonable to include the
dependencies
30 matches
Mail list logo
