I see, yes that did work correctly, thank you. I thought the password
was going to be sent in the email. But as you said, follow the link and
your logged in.
-Mark
Rahul Akolkar wrote:
On 12/30/05, Mark Diggory [EMAIL PROTECTED] wrote:
I've been trying to get around the wiki to fix a typo
Simon Kitching wrote:
On Sat, 2005-03-19 at 10:11 +, Stephen Colebourne wrote:
For the record, were someone to propose a Commons TLP and offer to be Chair
I would probably now vote +1.
(2) maintainer numbers and PMC membership
I've been rather concerned recently by the number of
After some gooogling, I found a LGPL implementation...
http://www.jnode.org
http://cvs.sourceforge.net/viewcvs.py/jnode/jnode/fs/src/fs/org/jnode/fs/iso9660/
-Mark
[EMAIL PROTECTED] wrote:
Yep, this would be really great! Esp. if it could
be used to create a ISO 9660 file system.
- Filip
Yes,
+1
-Mark Diggory
Jerome Jar wrote:
+1
On Sat, 22 Jan 2005 13:31:17 -0500, Tim O'Brien [EMAIL PROTECTED] wrote:
Alright a sufficient amount of time has passed for public comments and
testing.
This is a vote thread for migrating commons to SVN. If this vote
passes, I'll contact Justin and schedule
I've been lurking on this discussion.
+1
PGP Signing files needs to be just like the current md5 signing that
maven supplies on artifacts. You should be able to supply signing Keys
and get artifacts signed.
I initially was working on libraries to do this in Ant/Maven using
BouncyCastle. But
the signing and call the application externally. Which would be
logical in that the Ant task would be generic and there would be
build.properties the user could define to establish which implementation
did the signing.
-Mark
Martin Cooper wrote:
On Fri, 07 Jan 2005 12:47:06 -0500, Mark R. Diggory
Henning P. Schmiedehausen wrote:
Checking out the whole trunk is not the norm.
Folks, this is not CVS. You are not bound to a rigid structure as with
CVS. But you _want_ to be able to check out multiple projects side by
side. Because some of the depend on each other (or on the commons-site
Sounds like we really all agree that the structure of the Commons is
separate components. I think the big argument is that developers think
that somehow it will be difficult to check everything out if the svn is
organized in the same appropriate manner.
I'll argue that even in the cvs case, it
Martin Cooper wrote:
That's fine and dandy if you're using an IDE such as Eclipse, but if
you don't use an IDE, it does make sense to just check out the whole
enchilada in one go. Or at least _I_ think it does. ;-)
--
Martin Cooper
You've got me thinking...
The more I study SVN (and I'm pretty
Paul Libbrecht wrote:
Le 19 déc. 04, à 00:25, Brett Porter a écrit :
SNAPSHOT actually shouldn't be there. As far as the ASF repo goes, it
has been recommended to use http://cvs.apache.org/repository for
SNAPSHOTs and http://www.apache.org/dist/java-repository/ for
releases (Which is
Brett Porter wrote:
(continuing the trend of answering two messages in one :)
Sigh, we really suffer with this misnomer over and over again. In Maven
SNAPSHOT is just a reference to the latest version of an artifact. So,
yes, SNAPSHOT's are allowed in the ASF repository. What are not
allowed
Dion Gillard wrote:
Uh, that's what we're doing with Jelly. We're almost at 1.0. We've had
a release candidate, have one open issue to go before claiming a 1.0
release.
[Embarrassed] Please forgive me, yes.
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
I tend to agree. I only work with a few commons components at a time.
And when using something like Eclipse one can checkout multiple projects
by selecting them all. its not that big a deal. Plus from a management
standpoint, the component is the atomic unit of the commons, organizing
around
There actually isn't an extend. All projects are dependent only on
commons-site.jsl and the menu includes. There actually isn't any
inheritance of the project.xml because there were issues with users
building distributions with maven when the dependency (commons-build)
wasn't present there.
One option you might consider using ant on the client side, They just
implemented a feature I requested into the pgp signature task that
allows for gpg formating. It could be integrated into maven.xml and/or
build.xml
Phil Steitz wrote:
One more general comment that I did not know what to do
. It much easier if every component only
has dependencies required for compilation, not for generation of
documentation.
-Mark
TIA.
--
Martin Cooper
On Mon, 13 Dec 2004 09:42:22 -0500, Mark R. Diggory
[EMAIL PROTECTED] wrote:
There actually isn't an extend. All projects are dependent only on
commons
Sounds fine
Al Chou wrote:
--- Phil Steitz [EMAIL PROTECTED] wrote:
I just discovered that we have some JDK 1.4 dependencies in the 1.0
release code. I would like to make the following changes to allow
compilation on 1.3. Diffs showing the changes are at the bottom of this
message:
1)
You Rock!
My opinion is yes, we can move forward and continue the release. Finding
and correcting bugs is part of the process. Expect to see minor releases
next year, expect issues we can't see right now. This current phase of
stability needs to be captured in a release.
Release often, release
+1
Brent Worden wrote:
+1
Brent Worden
-Original Message-
From: Phil Steitz [mailto:[EMAIL PROTECTED]
Sent: Saturday, November 27, 2004 10:32 AM
To: Jakarta Commons Developers List
Subject: [vote][math] Release Math 1.0
There have been no bug reports against commons-math-1.0-RC2,
uploaded a snapshot of math to display these quirks:
http://www.apache.org/~brentworden/math/index.html
Can someone in the know look into this and offer suggestions for a
resolution?
Brent Worden
-Original Message-
From: Mark R. Diggory [mailto:[EMAIL PROTECTED]
Sent: Saturday, November 27
Eric,
If you could change the group permissions recursively on the email site
so that it can be updated by others that would be great. Afterwards,
I'll be glad to run the site generation to cleanup the existing site.
[EMAIL PROTECTED]:/www/jakarta.apache.org/commons/email ls -a -l
total 390
You'll need to change the `email` directory as well
drwxr-xr-x 8 epughjakarta 1024 Nov 25 04:21 email
thnx again,
Mark
Eric Pugh wrote:
Mark,
I think I did the right chmod. Can you just double check?
Eric
-Original Message-
From: Mark R. Diggory [mailto:[EMAIL PROTECTED
Actually, I was asking earlier to have the permissions adjusted on the
/www/jakarta.apache.org/commons/email directory so I could update the
site generation. Steps for building the site are simple.
1.) checkout email
2.) checkout commons-build
3.) go into email and run `maven site:deploy`
Best
For one, email is overriding the default Jakarta Commons Style, we would
prefer it to maintain the style of the rest of the commons. There are
some simple rules to accomplish this. I'll take a look at whats
currently there.
This is probably why the style is breaking when it was moved the
Eric,
I made some adjustments to the email site generation to correct some
problems. You have all the permissions on
/www/jakarta.apache.org/commons/email/.. can you either regenerate the
site or chmod the permissions so I can.
-Mark
Mark R. Diggory wrote:
For one, email is overriding
Martin,
As well, I've done some minor changes to resources. The same
permissions issue exists in the
/www/jakarta.apache.org/commons/resources/.. under your name. can you
either regenerate the site or chmod the permissions so I can.
-Mark
Mark R. Diggory wrote:
Eric,
I made some adjustments
Thanks, resources is now updated.
-Mark
Martin Cooper wrote:
Sorry about that. I've chmod'ed the files.
Thanks!
--
Martin Cooper
On Sat, 27 Nov 2004 12:38:33 -0500, Mark R. Diggory [EMAIL PROTECTED]
wrote:
Martin,
As well, I've done some minor changes to resources. The same
permissions issue
Martin Cooper wrote:
On Thu, 25 Nov 2004 22:17:04 -0500, Mark R. Diggory
[EMAIL PROTECTED] wrote:
I'd verify that if you upload the tar.gz file to minotaur, tar -zxvf it
and see if it expands properly. Theres no requirement in the site:deploy
method that the file open in Winzip.
Yes, I realise
The IDEAL situation would be to convert Jakarta Commons to SVN. Can we
PLEASE consider doing so?
A lot of projects, including the HTTP Server project, have been
migrating,
as can be seen from http://svn.apache.org/viewcvs. Jakarta and XML are
definitely the laggards now.
--- Noel
+1
If the
I ended up updating the site while I was testing ssh keys on my
workstation. please review the site and make sure its what you wanted to
see updated.
-Mark
Mark R. Diggory wrote:
Martin Cooper wrote:
On Thu, 25 Nov 2004 22:17:04 -0500, Mark R. Diggory
[EMAIL PROTECTED] wrote:
I'd verify
Thnx...
Eric Pugh wrote:
This looks better, more consistent!
-Original Message-
From: Mark R. Diggory [mailto:[EMAIL PROTECTED]
Sent: Friday, November 26, 2004 5:16 PM
To: Jakarta Commons Developers List
Subject: Re: [general] Updating the Commons common web site
I ended up updating
As well, this was a successful test of Maven 1.0.1 to build the top
level site.
-Mark
Mark R. Diggory wrote:
Thnx...
Eric Pugh wrote:
This looks better, more consistent!
-Original Message-
From: Mark R. Diggory [mailto:[EMAIL PROTECTED]
Sent: Friday, November 26, 2004 5:16 PM
Its been very quiet, this may be a good sign. Are we ready to roll on 1.0?
-Mark
Phil Steitz wrote:
The Commons Math team is pleased to announce the release of Commons Math
1.0-RC2. Commons Math is a library of lightweight, self-contained
mathematics and statistics components. This release
I'd verify that if you upload the tar.gz file to minotaur, tar -zxvf it
and see if it expands properly. Theres no requirement in the site:deploy
method that the file open in Winzip.
`maven site:deploy` will publish the tar to the site on minotaur
appropriately, you do not have to upload it by
hey, you talkn to me!/
[+1]
Phil Steitz wrote:
nudge/
-Original Message-
From: Phil Steitz
Sent: Sun 11/7/2004 6:06 PM
To: Jakarta Commons Developers List
Cc:
Subject: [math][vote] Release 1.0-RC2
This vote is to approve the public release of commons math 1.0-RC2.
Hen and all,
We put allot of work over the summer into getting the top level site to
its current state. Having it be modular and easily updatable. Why is
this coming across as difficult to maintain?
jakarta-commons/commons-build/ `maven site:deploy` updates the top level.
.
Cheers,
Mark
Mark R. Diggory wrote:
F Norin wrote:
Yes you're right, with the parametrization model you're using it would
probably be confusing to simply let the exponential and chisquared
distributions be instances of a gammadistribution. However, this
indicates that there may be something
F Norin wrote:
Yes you're right, with the parametrization model you're using it would
probably be confusing to simply let the exponential and chisquared
distributions be instances of a gammadistribution. However, this indicates
that there may be something flawed here. Remember, the chisquared
[EMAIL PROTECTED] wrote:
4. Since the chi-squared and exponential distributions are just special
cases of the gamma distribution, there is no need to have separate
implementation classes for these. In my opinion, one should avoid having
multiple implementations of the same distribution unless
I definitely against removing these implementations. These
interfaces/implementations provide a a unique set of methods on that
specific species of Gamma distribution that are required to configure
and maintain that species of Gamma distribution.
Removing the underlying implementations and
Phil,
I think we wanted to maintain the existence of setEntry/getDataRef API
of the RealMatrixImpl without having it in the RealMatrix Interface. At
least until we come up with a strategy for mutability that made more
sense then these methods. This last change removed it from both.
Michael,
We
Phil Steitz wrote:
Mark R. Diggory wrote:
Phil,
I think we wanted to maintain the existence of setEntry/getDataRef API
of the RealMatrixImpl without having it in the RealMatrix Interface.
At least until we come up with a strategy for mutability that made
more sense then these methods
Michael Heuer wrote:
This is similar to how colt matrix views (viewRow, viewColumn,
viewSelection, etc.) are implemented (disclaimer: I use colt all the
time).
michael
Yes, a good reason why we are looking at its implementation to enhance
the Matrix API. :-)
-Mark
--
Mark Diggory
Software
Hey Phil,
Thanks for working on the RealMatrixImpl, it really gets things rolling.
I was working on some things offline to support it further. One point of
concern I have is that I thought we were going to make RealMatrixImpl
immutable and allow the submatrix accessors return implementations
what you are proposing.
Phil
-Original Message-
From: Phil Steitz
Sent: Mon 10/11/2004 10:16 AM
To: Jakarta Commons Developers List
Cc:
Subject: Re: cvs commit: jakarta-commons/math/src/test/org/apache/commons/math/linear RealMatrixImplTest.java
Mark R. Diggory
Phil,
Heres a patch that shows the changes which would solve this copying
issue in the current RealMatrixImpl.
Index: RealMatrixImpl.java
===
RCS file:
Yes, your right, We should rather use just getEntry(x,y) and
getRowDimension/getColumnDimension shouldn't we.
Phil Steitz wrote:
I understand what you are trying to do here and support the basic
idea, but I don't know if this will work in general. What happens
when we want to add a sparse
Brain and Wolfgang,
This sort of clarification is exactly what we needed to hear. It sounds
like we can begin working portions of Colt now.
My question to Wolfgang is, to avoid fracturing Colt into multiple
implementations, we could decided between two possible approaches.
A.) Refer to the
now.
Is http://dsd.lbl.gov/~hoschek/colt/index.html the right project page for the current development in Colt? Is the mailing list referenced there active?
Yes, I am on the list currently, there is some activity.
Phil
-Original Message-
From: Mark R. Diggory [mailto:[EMAIL
Wolfgang Hoschek wrote:
Mark,
I am not worried about fracturing. My understanding is that you
wouldn't start doing colt releases build by apache, right? You'd rather
take some parts or derivatives of the code and add them to commons-math
CVS as you see fit (probably in a significantly
Al Chou wrote:
I agree we should not be releasing Apache versions of the whole Colt library
(which technically wouldn't even be possible, as the hep.aida.* packages are
LGPL'd, not under the the new CERN license). In any case, the question of the
scope of Commons-Math continually comes up, and
Hi Brian,
After being reminded by Wolfgang that he had previously given me a
contact at CERN to discuss these issues with, I emailed that contact. He
forwarded me to the Technology Transfer officer for CERN. I just
finished emailing a request to that individual to comment on the
position CERN
Now that I'm back I'll try to catch up on this thread quickly
Phil Steitz wrote:
Kim van der Linde wrote:
Hi Phil,
I have been thinking for a few days on the Matrix classes.
I think the Matrix class itself should contain all those methods that
do matrix calculations (add, subtract, multiply) that
I am posting this to the Licensing list as well because it is very
unclear how to proceed and we dearly need their advice on this subject.
Licensing, the issue has to do with policy for adding code from a
external project, which the author has approved our usage of via email.
Hello Wolfgang,
You jogged my memory concerning our discussion on this subject some time
ago. You had given me a contact (James Casey) at CERN to discuss this
subject further and I think the subject slipped off the radar at that
point. Here was that old thread. I've cc'd him on this message to
Can you give us an example of your solution?
-Mark
Kim van der Linde wrote:
Kim van der Linde wrote:
Mark R. Diggory wrote:
This is the sort of thing that defeats the purpose of having the
RealMatrix package. Such computations could be used to abuse the
contents of the internal data structure
This is the sort of thing that defeats the purpose of having the
RealMatrix package. Such computations could be used to abuse the
contents of the internal data structure effectively breaking the
original Matrix.
We need a more OO strategy for capturing the requirements of your
example. I
Phil Steitz wrote:
The following changes have been suggested recently. Before cutting 1.0
final, we should make sure we are all OK postponing or forgoing these:
1) Eliminate the univariate/multivariate distinction in the stat
package, because this seems confusing to some. Change .univariate
Phil Steitz wrote:
Mark R. Diggory wrote:
1) Eliminate the univariate/multivariate distinction in the stat
package, because this seems confusing to some. Change .univariate to
.descriptive and .multivariate to .regression
Univariate and Multivariate are just classifications
a nightly build gives us a
predictable load at a known time.
--
Martin Cooper
Cheers,
Brett
Mark R. Diggory wrote:
At least in Maven, the version of the dependency is captured in the
metadata of the project.xml file. When the ant build file is generated
off the project.xml file, these dependencies
I think c) covers most everything. +1 for path c).
-Mark
Phil Steitz wrote:
There were not enough +1 votes to proceed with the release. Bug fixes
were also applied during the vote. Therefore, we cannot proceed with
the release at this time.
Three issues were reported with the release package:
Kim van der Linde wrote:
Hi Mark,
Mark R. Diggory wrote:
In my design of the Univariate package, the plan is to apply OO
strategies to implement a statistic, this means that
statistic=class.
The difference of opinion is about this aspect. Are population and
sample variances essential different
I recommend maintain ant support. And for projects that are using Maven,
I highly recommend they generate default build.xml files using the maven
ant task. I also recommend that we not be dependent on anything for
automated builds that is not already in this generated build file (not
that you
I wouldn't sweat it too much, its a RC candidate, not a full release. I
say we just get it out there... :-)
-Mark
Phil Steitz wrote:
7 binding +1 (Tim O'Brien, Mark Diggory, Al Chou, J. Pietschmann. Brent
Worden, Phil Steitz)
No other binding votes. Kim Van Der Linde voted +1, then changed to
Like I said in the past, I highly recommend working with Paul Houle
(http://www.honeylocust.com/RngPack/) to get these random number
generators integrated into the math library. He has stated to me in the
past that he is willing to relicense them under the Apache license. As
well I beleive
--
Mark Diggory
Open Source Software Developer
Apache Jakarta Project
http://jakarta.apache.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I can give a couple other examples of matrices in java using 0 to n-1.
Colt:
http://dsd.lbl.gov/~hoschek/colt/api/cern/colt/matrix/DoubleMatrix2D.html
A matrix has a number of rows and columns, which are assigned upon
instance construction - The matrix's size is then rows()*columns().
Elements
Al Chou wrote:
My personal preference would originally have been to use 1-based indexing
(actually, I really prefer Fortran's ability to let the user define the lower
bound index value in each array dimension if they so choose, even though that
facility is not that often used), but that was based
I agree entirely with your argument. I would feel more comfortable with
0 to n-1.
-Mark
Kim van der Linde wrote:
Hi All,
I ran into a problem with the RealMatrixImpl class. The class is
designed such that it uses the default 1 to n counting for the rows and
columns. However, JAVA has as a
Linde wrote:
Mark R. Diggory wrote:
I agree entirely with your argument. I would feel more comfortable
with 0 to n-1.
Ok, how do I update the inproved class, as I did that already
yesterday evening. I would also like to add several new methods:
RealMatrix getSubMatrix (int startRow, int endRow
[X] +1 Go ahead and release 1.0-RC1
[ ] +0
[ ] -0
[ ] -1 Don't release 1.0-RC1, because...
-Mark
Phil Steitz wrote:
This vote is to approve the public release of commons math 1.0-RC1.
This will be a publicly announced RC to enable full feedback for a final
release in about two weeks if all is
I've modified the site jsl to support relative css links again. I need
to go through the maven.xml documents for all the projects and add the
postGoal to copy the stylesheets (The same way as I have for the math
project.
!-- [Commons-Build] Required: Look and Feel for distributions --
Phil Steitz wrote:
Mark R. Diggory wrote:
Yes, at the UnivariateStatistic level, these would need to be new
classes. My question as well is Does it apply as well to higher order
moments?
In theory, yes, though I have never seen non-bias-corrected versions of
Skewness and Kurtosis used
Yes, at the UnivariateStatistic level, these would need to be new
classes. My question as well is Does it apply as well to higher order
moments?
Maybe we should place everything into the following packages:
o.a.c.m.stat.univariate.moment.sample
o.a.c.m.stat.univariate.moment.population
-Mark
providers!
http://promotions.yahoo.com/new_mail
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mark R. Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mark R. Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
list for users to discuss these sort of math issues.
-Mark
--
Mark R. Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail
list specific for math users? I'm not sure what would
be the best approach.
-Mark
On Fri, 13 Aug 2004, Mark R. Diggory wrote:
Hello all,
After some thought, I've come to the conclusion that Commons should
setup a separate user lists for the Math group. While I am in agreement
that the Commons
On Fri, 13 Aug 2004, Mark R. Diggory wrote:
Would it be wise to establish a Jakarta Math project outside of commons
to support these sort of listserv interactions with users, even though
its unclear what code would be housed there? Or should we only start a
parent project if we have non
a news list is? ;-)
Gmane is cool, I might start using it as well now that I've looked at a
few apache lists in it. I think ultimately though, the simplest solution
is a user email list, then other tools like Gmane etc could be used on
it as well.
-Mark
--
Mark R. Diggory
Software Developer
a large community who comment / make suggestions on multiple components. I am opposed to splitting j-c components into separate lists / projects unless the traffic reaches the bothersome level.
-Original Message-
From: Mark R. Diggory [mailto:[EMAIL PROTECTED]
Sent: Fri 8/13/2004 11
as a
valuable commons component.
I agree with Phil.
So, consider me -0 to a commons-math-user at the moment.
Stephen
- Original Message -
From: Mark R. Diggory [EMAIL PROTECTED]
Do you get my argument though?
I get the argument, but I disagree with it. As Brent points out below,
there are plenty
a couple people posting on the users list. Has
anyone asked them how difficult it is to use and filter the mailing
list? Do they see the multi-topic list as a burden?
For one, Kim posted a response in this thread.
--
Mark R. Diggory
Software Developer
Harvard MIT Data Center
http
in the sandbox for the code
you wish to transfer.
-Mark
--
Mark R. Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
project so I can play there?
Most of what I've got from JMeter fits into existing released commons
packages. I don't want to start new packages.
-Mike
On Thu, 2004-08-12 at 12:16, Mark R. Diggory wrote:
Michael Stover wrote:
Hi Commons Developers,
I'm currently the maintainer
I've never looked at it. What
JMeter has is a number collection class that seems very similar to
StatUtils.
-Mike
On Thu, 2004-08-12 at 12:12, Mark R. Diggory wrote:
I think he should (and did already), but I know we are going to be very
interesteed in whatever JMeter has to offer expecially
Hi Kim,
I think we have a bit of work to complete in extending the api into
areas of multivariate analysis/statistics and would be interested in
implementations in that area. I think the big thing is that we would
like to see implementation be based on the existing library architecture
as
Hey Phil,
I notice your moving much of the extended functionality out of the
Univariates and into a private field instead. I'm just curious what your
logic is behind it? I had considered wrapping vs extending initially
when I was building the implementation. Now that I look back, my reasons
The strategy is to use the maven site goal in the
/jakarta-commons/commons-build project to build an deploy a new copy of
the site. Usually it is wise to run 'site:generate' first and verify the
local copy was built properly.
-Mark
Rodney Waldhoff wrote:
Is there documentation somewhere for
their site uptodate by running 'maven site' in
thier project directory.
-Mark
On Wed, 14 Jul 2004, Mark R. Diggory wrote:
The strategy is to use the maven site goal in the
/jakarta-commons/commons-build project to build an deploy a new copy
of the site. Usually it is wise to run 'site:generate' first
, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mark R. Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
.
This probably didn't need to be said...
Cheers,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mark R. Diggory
Software Developer
Harvard MIT Data Center
http
, then compatability
will become more stable and it will be easier to up our efforts in
maintaining it.
I will gladly begin some efforts to review Collections serialization
testing and work to implement something similar for math.
-Mark
--
Mark R. Diggory
Software Developer
Harvard MIT Data
Phil Steitz wrote:
[mark] I feel that you think that just because we happen to include
the Serialization Interfaces to these classes, that somehow we have
to guarantee that they are serializable across releases and the
somehow we are stuck with the current implementation. I do not
believe we are
Phil,
I really like that static test flag for if the JDK support of Nested
Exceptions in MathException, very cool, I was trying to do something
like that earlier but couldn't quite deal with reflection the way I
wanted to.
-Mark
--
Mark Diggory
Software Developer
Harvard MIT Data Center
Mark R. Diggory wrote:
[phil]
* Either drop or customize serialization for all classes in the
univariate package (other than StatisticalSummaryValues),
especially those in the moment subpackage. Default serialization
ties us to the current physical implementation, which may well
change as we
This really reflects how much our project naming needs to be made more
consistent. Those Project names are just all over the board:
Projects
Bean Introspection Utilities (Version 1.6.1)
org.apache.commons.cli
Codec 1.2
Collections 3.1 release
Daemon 1.0
Commons DBCP 1.2.1
Digester - XML to Java
Phil,
I feel that you think that just because we happen to include the
Serialization Interfaces to these classes, that somehow we have to
guarantee that they are serializable across releases and the somehow we
are stuck with the current implementation. I do not believe we are
required to
I'm usure how we are controlling it, if we even are. I suspect there is
a propert in the project.properties which can be set to control what
images are used for this. I also suspect the default could change across
versions of Maven. I would look in the project.properties for any
settings
Yet, consider the case; To make a modification to documentation for a
previous version that was taged in the CVS, you would need to branch and
commit you changes to the branch, this would mean that if you wanted to
publish these changes using maven, you would need it to checkout the
latest
1 - 100 of 667 matches
Mail list logo
