Re: [VOTE] Release Commons Chain 1.2 based on RC1
On Wed, May 21, 2008 at 3:26 AM, sebb [EMAIL PROTECTED] wrote:
On 21/05/2008, Niall Pemberton [EMAIL PROTECTED] wrote:
I would like to do a bug fix release of Commons Chain - mainly to
release the fix for CHAIN-33[1] - which hit a Struts user recently
(see STR-3143[2]) - but there are a few other bug fixes as well
[1] http://issues.apache.org/jira/browse/CHAIN-33
[2] https://issues.apache.org/struts/browse/STR-3143
The artifacts are here:
http://people.apache.org/~niallp/chain_1_2_RC1/
Digests, hashes, NL all look OK.
And there are no .asc.md5 files either - how do you avoid those?
I just don't bother to upload them.
pom.xml contains a reference to ${basedir} - I notice that there were
some recent commits that removed this, citing a bug in M2.0.9 - is
this reference OK?
I've only had a problem with ${basedir} when its been used in the
checkstyle config - and I removed that for chain:
http://svn.apache.org/viewvc?view=revrevision=658353
SVN Tag:
http://svn.apache.org/viewvc/commons/proper/chain/tags/CHAIN_1_2_RC1/
Not a blocker, but some incorrect SVN props:
svn pd svn:executable build.properties.sample
svn pd svn:executable build.xml
svn ps svn:eol-style native
src/test/org/apache/commons/chain/web/ChainResourcesTestCase.java
Thanks - fixed in the trunk:
http://svn.apache.org/viewvc?view=revrevision=658574
Site:
http://people.apache.org/~niallp/chain_1_2_RC1/site/
(note m2 generates relative links, so some don't work - but the site
is for info and not included in the release artifacts)
Release Notes:
http://people.apache.org/~niallp/chain_1_2_RC1/RELEASE-NOTES.txt
http://people.apache.org/~niallp/chain_1_2_RC1/site/changes-report.html
RAT Report:
http://people.apache.org/~niallp/chain_1_2_RC1/site/rat-report.html
CLIRR Report:
http://people.apache.org/~niallp/chain_1_2_RC1/site/clirr-report.html
RC2 has been built with m2 - but m1 and ant builds are available - details
here:
http://people.apache.org/~niallp/chain_1_2_RC1/site/building.html
Note: Chain is targetted at JDK 1.3, but I built with JDK 1.5 because
of the issue with m2 and JDK 1.4 - but I have tested on JDK 1.3 and
JDK 1.4 using m1 and JDK 1.5 and JDK 1.6 using m2
Ant build works fine on Java 1.4.2, but using Java 1.3.1 I get
problems with Ant 1.6.0, 1.6.5 and 1.7.0.
M1 1.0.2 works OK on Java 1.3.1
So it looks like there is a problem with the Ant file.
OK, if I get time I'll dump the maven generated ant build and add a proper one.
It would be nice if this could be fixed, but if not, then the build
instructions should be updated to mention the restriction.
OK, but not a blocker for this release, right?
Thanks for the feedback.
Niall
Vote is open for 72 hours
Thanks in advance for your feedback/votes.
Niall
-
[ ] +1 I support this release
[ ] +0 I am OK with this release
[ ] -0 OK, but
[ ] -1 I do not support this release
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons Net 1.5 / 2.0 Releases
On Wed, May 21, 2008 at 12:48 AM, Rory Winston [EMAIL PROTECTED] wrote: We've had this discussion already (at great length). It's not going to test/src. Search through the archives, I managed to find a discussion on this very topic from March this year, however in the thread it seems like you agree on moving it to src/test: http://markmail.org/message/skzc77eccue7ukxx Maybe there has been additional discussions after that thread where there was a different conclusion? /niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Chain 1.2 based on RC1
On 21/05/2008, Niall Pemberton [EMAIL PROTECTED] wrote:
On Wed, May 21, 2008 at 3:26 AM, sebb [EMAIL PROTECTED] wrote:
On 21/05/2008, Niall Pemberton [EMAIL PROTECTED] wrote:
I would like to do a bug fix release of Commons Chain - mainly to
release the fix for CHAIN-33[1] - which hit a Struts user recently
(see STR-3143[2]) - but there are a few other bug fixes as well
[1] http://issues.apache.org/jira/browse/CHAIN-33
[2] https://issues.apache.org/struts/browse/STR-3143
The artifacts are here:
http://people.apache.org/~niallp/chain_1_2_RC1/
Digests, hashes, NL all look OK.
And there are no .asc.md5 files either - how do you avoid those?
I just don't bother to upload them.
pom.xml contains a reference to ${basedir} - I notice that there were
some recent commits that removed this, citing a bug in M2.0.9 - is
this reference OK?
I've only had a problem with ${basedir} when its been used in the
checkstyle config - and I removed that for chain:
http://svn.apache.org/viewvc?view=revrevision=658353
SVN Tag:
http://svn.apache.org/viewvc/commons/proper/chain/tags/CHAIN_1_2_RC1/
Not a blocker, but some incorrect SVN props:
svn pd svn:executable build.properties.sample
svn pd svn:executable build.xml
svn ps svn:eol-style native
src/test/org/apache/commons/chain/web/ChainResourcesTestCase.java
Thanks - fixed in the trunk:
http://svn.apache.org/viewvc?view=revrevision=658574
Site:
http://people.apache.org/~niallp/chain_1_2_RC1/site/
(note m2 generates relative links, so some don't work - but the site
is for info and not included in the release artifacts)
Release Notes:
http://people.apache.org/~niallp/chain_1_2_RC1/RELEASE-NOTES.txt
http://people.apache.org/~niallp/chain_1_2_RC1/site/changes-report.html
RAT Report:
http://people.apache.org/~niallp/chain_1_2_RC1/site/rat-report.html
CLIRR Report:
http://people.apache.org/~niallp/chain_1_2_RC1/site/clirr-report.html
RC2 has been built with m2 - but m1 and ant builds are available -
details here:
http://people.apache.org/~niallp/chain_1_2_RC1/site/building.html
Note: Chain is targetted at JDK 1.3, but I built with JDK 1.5 because
of the issue with m2 and JDK 1.4 - but I have tested on JDK 1.3 and
JDK 1.4 using m1 and JDK 1.5 and JDK 1.6 using m2
Ant build works fine on Java 1.4.2, but using Java 1.3.1 I get
problems with Ant 1.6.0, 1.6.5 and 1.7.0.
M1 1.0.2 works OK on Java 1.3.1
So it looks like there is a problem with the Ant file.
OK, if I get time I'll dump the maven generated ant build and add a proper
one.
It would be nice if this could be fixed, but if not, then the build
instructions should be updated to mention the restriction.
OK, but not a blocker for this release, right?
The Ant problem is not a blocker, so long as the build instructions
are updated accordingly.
Thanks for the feedback.
Niall
Vote is open for 72 hours
Thanks in advance for your feedback/votes.
Niall
-
[ ] +1 I support this release
[ ] +0 I am OK with this release
[ ] -0 OK, but
[ ] -1 I do not support this release
-
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]
[vfs] vfs2 or plain wrapper mode
Hi! Probably I find some time during the next weekend to fix a long standig bug in VFS regarding dealing with hidden or special files. The main problem I see is that VFS tries to act more like a real filesystem than a simple wrapper. VFS tries to determine the filetype (FILE, DIR, VIRTUAL) and then throws an exception if one tries to open a VIRTUAL file. VFS thinks such a file can not exist. I'd like to change that behavior from a fail fast to a fail lazy one, means, even on VIRTUAL files VFS tries to issue a getInputStream() on read. If the underlaying library then throws an exception about non-existent files this exception will be converted to a VFS exception. The internal file-type is then more like a guess and might change on e.g. getInputStream(). For example, a VIRTUAL file will become a FILE if getInputStream() succeeded. In the end I'd like to make VFS behave more like a wrapper than a real filesystem and VFS will pass down each file operation to the underlaying library as soon as possible and then normalize the thrown exceptions to VFS ones if possible. As a side-effect it could be possible to disable this filetype determination at all (or make it optional) and thus make VFS a lot faster e.g. with FTP connections where this operation is really really costly. As far as I can see this will lead to a somehow different behavior of VFS than it is today. It should not influence any existing applications, but it might. So, my questions are: * [ ] Do you agree that such an evolution might make sense * and if so, should I ** [ ] add a VFS-global (static) flag to enable this wrapper-like-mode or ** [ ] can I fork VFS to put the current head into maintainance (or more correct dormant) mode and start with e.g. VFS 2.0? I'd prefer VFS 2.0. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [vfs] vfs2 or plain wrapper mode
Hi Mario, Just wondering, how would a client of VFS enumerate Just the folders in a directory e.g. in order to Render a tree of files? He needs to know here what items are folders and What items are files (which gets more difficulte When symbolic links with file-flavor or folder-flavor Are involved, or archives like ZIP and TAR that Can present virtual subfolders). Thoughts? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm -Original Message- From: Mario Ivankovits [mailto:[EMAIL PROTECTED] Sent: Mittwoch, 21. Mai 2008 14:45 To: Jakarta Commons Developers List Subject: [vfs] vfs2 or plain wrapper mode Hi! Probably I find some time during the next weekend to fix a long standig bug in VFS regarding dealing with hidden or special files. The main problem I see is that VFS tries to act more like a real filesystem than a simple wrapper. VFS tries to determine the filetype (FILE, DIR, VIRTUAL) and then throws an exception if one tries to open a VIRTUAL file. VFS thinks such a file can not exist. I'd like to change that behavior from a fail fast to a fail lazy one, means, even on VIRTUAL files VFS tries to issue a getInputStream() on read. If the underlaying library then throws an exception about non-existent files this exception will be converted to a VFS exception. The internal file-type is then more like a guess and might change on e.g. getInputStream(). For example, a VIRTUAL file will become a FILE if getInputStream() succeeded. In the end I'd like to make VFS behave more like a wrapper than a real filesystem and VFS will pass down each file operation to the underlaying library as soon as possible and then normalize the thrown exceptions to VFS ones if possible. As a side-effect it could be possible to disable this filetype determination at all (or make it optional) and thus make VFS a lot faster e.g. with FTP connections where this operation is really really costly. As far as I can see this will lead to a somehow different behavior of VFS than it is today. It should not influence any existing applications, but it might. So, my questions are: * [ ] Do you agree that such an evolution might make sense * and if so, should I ** [ ] add a VFS-global (static) flag to enable this wrapper-like-mode or ** [ ] can I fork VFS to put the current head into maintainance (or more correct dormant) mode and start with e.g. VFS 2.0? I'd prefer VFS 2.0. Ciao, Mario - 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]
Re: [vfs] vfs2 or plain wrapper mode
Hi Mario, On 5/21/08, Mario Ivankovits [EMAIL PROTECTED] wrote: So, my questions are: * [ ] Do you agree that such an evolution might make sense * and if so, should I ** [ ] add a VFS-global (static) flag to enable this wrapper-like-mode or ** [ ] can I fork VFS to put the current head into maintainance (or more correct dormant) mode and start with e.g. VFS 2.0? This sounds great - I think what you're describing makes a lot of sense (and would actually solve some long standing bugs + performance issues). Since the behavior may drastically change, I'd suggest to fork and go for VFS 2.0 rather than a static flag. Cheers, - Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] vfs2 or plain wrapper mode
Hi Martin! Just wondering, how would a client of VFS enumerate Just the folders in a directory e.g. in order to Render a tree of files? As today. Disabling the file-type determination should be optional only and isn't something I'd change during the first development iteration. The difference to today is that VFS will allow you to try to enumerate even on files where it thinks it is a file or virtual. And only if the underlaying library throws an exception the operation will fail. What I'd like to open up is just to ignore what VFS thinks about a file and try to read it anyway. This should make it possible to also deal with special files and also hidden files which will look like a virtual file for VFS - and make VFS unable to handle them today. On filesystem level than (through our FileSystemOptions) it might be interesting to allow to disable the file-type determination at all which will make ftp access a lot faster, even if some file informations are missing then. But polling a ftp directory for new files will be as fast as when using plain ftp then. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] vfs2 or plain wrapper mode
We also have the situation where the directories are also hidden. So we need to be able to traverse hidden directories as well. Sounds like your solution would work for directories as well, if VFS didn't attempt to enumerate all the files in all the directories along the path? On Wed, May 21, 2008 at 7:45 AM, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! Probably I find some time during the next weekend to fix a long standig bug in VFS regarding dealing with hidden or special files. The main problem I see is that VFS tries to act more like a real filesystem than a simple wrapper. VFS tries to determine the filetype (FILE, DIR, VIRTUAL) and then throws an exception if one tries to open a VIRTUAL file. VFS thinks such a file can not exist. I'd like to change that behavior from a fail fast to a fail lazy one, means, even on VIRTUAL files VFS tries to issue a getInputStream() on read. If the underlaying library then throws an exception about non-existent files this exception will be converted to a VFS exception. The internal file-type is then more like a guess and might change on e.g. getInputStream(). For example, a VIRTUAL file will become a FILE if getInputStream() succeeded. In the end I'd like to make VFS behave more like a wrapper than a real filesystem and VFS will pass down each file operation to the underlaying library as soon as possible and then normalize the thrown exceptions to VFS ones if possible. As a side-effect it could be possible to disable this filetype determination at all (or make it optional) and thus make VFS a lot faster e.g. with FTP connections where this operation is really really costly. As far as I can see this will lead to a somehow different behavior of VFS than it is today. It should not influence any existing applications, but it might. So, my questions are: * [ ] Do you agree that such an evolution might make sense * and if so, should I ** [ ] add a VFS-global (static) flag to enable this wrapper-like-mode or ** [ ] can I fork VFS to put the current head into maintainance (or more correct dormant) mode and start with e.g. VFS 2.0? I'd prefer VFS 2.0. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jeffrey D. Brekke Wisconsin, USA brekke at apache dot org ekkerbj at gmail dot com jbrekke at wi dot rr dot com
Re: [vfs] vfs2 or plain wrapper mode
Hi! Sounds like your solution would work for directories as well, if VFS didn't attempt to enumerate all the files in all the directories along the path? Yes, that is the plan :-) What I wrote about files count for directories too, for me this attribute is just a different value ;-) Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
apache commons net
Hi all, I have a simple java applicatoion, that uploads a file in a computer server (aix). In the server another process checks for that file, processes it, and deletes it. Is there any possible way to set a lock in file that will be uploaded, because if the file size is big ex. 200 MB the process on server will delete my file before my application finished uploading. Thnx. -- View this message in context: http://www.nabble.com/apache-commons-net-tp17364248p17364248.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: apache commons net
Name it something different during upload. When it's finished, do a rename. For instance, while you're uploading, name the file myfile.uploading and then when it's done, just rename it to myfile. On Wed, May 21, 2008 at 9:57 AM, bperquku [EMAIL PROTECTED] wrote: Hi all, I have a simple java applicatoion, that uploads a file in a computer server (aix). In the server another process checks for that file, processes it, and deletes it. Is there any possible way to set a lock in file that will be uploaded, because if the file size is big ex. 200 MB the process on server will delete my file before my application finished uploading. Thnx. -- View this message in context: http://www.nabble.com/apache-commons-net-tp17364248p17364248.html Sent from the Commons - Dev mailing list archive at Nabble.com. - 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]
RE: [vfs] vfs2 or plain wrapper mode
Mario Ivankovits wrote: [snip] So, my questions are: * [X] Do you agree that such an evolution might make sense * and if so, should I ** [ ] add a VFS-global (static) flag to enable this wrapper-like-mode or ** [X] can I fork VFS to put the current head into maintainance (or more correct dormant) mode and start with e.g. VFS 2.0? I'd prefer VFS 2.0. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[math] Sparse Matrix Support
I noticed that support for sparse matrix computation was on the commons math wishlist. This is a project I would be interested in taking on. I would like to add a SparseMatrix interface which would support functionality analogous to the RealMatrix interface. I have worked with Tim Davis the author of the CSparse suite and would be using algorithms outlined in his book to base my code on. On the wishlist page there was a reference to a thread using the old archive url format. Does anyone know how to find that thread with the new format? Searches come up empty. Regards, John Iacona
RE: Commons Net 1.5 / 2.0 Releases
Hi Jörg,
Good point -- but in my environment (Eclipse), transitive
Deps are a non-issue since OSGi provides multiple classloaders
So I can live with ACN 1.5 and 2.0 at the same time even if
They have mutually incompatible implementations of the same
Class in the same namespace.
I'd rather like to have the ability to choose ACN 1.5 or
2.0 when my app happens to use only such parts of the lib
That happen to have changed in a non-breaking manner.
I cannot see why moving to Java5 forces binary breaking
Changes -- after all the Java5 collections can be called
From older Java too thanks to the concept of Erasures.
Of course I'm not talking about forced backward compatibility
In all cases. This is a major release, and it's one for good
Reason. I'm just talking about not breaking compatibility
Unless there is good reason for doing so.
And refactoring those small protocol impls into separate
Namespaces each is not a good reason IMHO. But perhaps
Somebody could argue to convince me why this is a good
And important thing?
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
-Original Message-
From: Jörg Schaible [mailto:[EMAIL PROTECTED]
Sent: Mittwoch, 21. Mai 2008 07:55
To: Commons Developers List
Subject: RE: Commons Net 1.5 / 2.0 Releases
Hi Martin,
Oberhuber, Martin wrote:
Hi Rory,
Thanks for your opinion -- but may I note that even if
It's a major releases, there may be (some|many) existing
Clients which are not broken even if they upgrade,
Depending on what APIs their client code currently uses.
Breaking clients for no good reason just isn't playing
Nice with the clients IMHO, although you are right that
You do have the chance doing so in a major release.
At any rate, I wouldn't call the discussion irrelevant.
It is relevant for clients picking up commons net when
They migrate from 1.x to 2.x, and depending on what
The clients do and how many different ones there are,
Even Eclipse Ctrl+Shift+O can sum up to a non-trivial
Amount of total work on behalf of the clients.
Basically there's no problem to deliver a
commons-net-2.0-legacy.jar that contains something along
package org.apache.commons.net;
class Echo extends org.apache.commons.net.echo.Echo { ... };
I'm all in favor of code cleanup and refactoring when
I see clear advantages, but not at any price.
For our FTP clients, I'd love to see customers being
Able to exchange net 1.5 against net 2.0 pre-compiled
Binaries in the final product if possible.
However, this implies that ACN 1.x is binary compatible to
ACN 2.0. However that is simply neither guaranteed nor
enforced. If ACN 2.x makes usage of Java 5 you will see some
API breakage that prohibits 2.x to be used as drop in
replacement. That was simply not the goal of this design.
However that's the reason why *I* always recommend to use a
different package name for major releases with API breakage,
simply to ensure that both versions can be used at the same
time. Not that a client wants to do this, but he might be
forced to do so because of transitive deps.
- Jörg
-
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]
Re: [vfs] vfs2 or plain wrapper mode
* [X ] Do you agree that such an evolution might make sense * and if so, should I ** [ ] add a VFS-global (static) flag to enable this wrapper-like-mode or ** [X ] can I fork VFS to put the current head into maintainance (or more correct dormant) mode and start with e.g. VFS 2.0? -- Jeffrey D. Brekke Wisconsin, USA brekke at apache dot org ekkerbj at gmail dot com jbrekke at wi dot rr dot com
[continuum] BUILD SUCCESSFUL: Commons - Commons IO - Build Def:
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=91682projectId=155 Build statistics: State: Ok Previous State: Failed Started at: Wed 21 May 2008 10:36:08 -0700 Finished at: Wed 21 May 2008 10:37:05 -0700 Total time: 56s Build Trigger: Schedule Build Number: 79 Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version 1.5.0_12 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing) Builder version : Maven version: 2.0.7 Java version: 1.5.0_12 OS name: linux version: 2.6.20-16-server arch: i386 SCM Changes: Changed: no author @ no date Comment: no comment Files changed: src/test/org/apache/commons/io/IOCaseTestCase.java ( no revision ) src/test/org/apache/commons/io/FileSystemUtilsTestCase.java ( no revision ) src/test/org/apache/commons/io/FileDeleteStrategyTestCase.java ( no revision ) src/test/org/apache/commons/io/FileUtilsCleanDirectoryTestCase.java ( no revision ) src/test/org/apache/commons/io/FileUtilsWaitForTestCase.java ( no revision ) src/test/org/apache/commons/io/FileCleaningTrackerTestCase.java ( no revision ) src/test/org/apache/commons/io/LineIteratorTestCase.java ( no revision ) src/java/org/apache/commons/io/LineIterator.java ( no revision ) src/java/org/apache/commons/io/IOCase.java ( no revision ) src/java/org/apache/commons/io/filefilter/WildcardFileFilter.java ( no revision ) src/java/org/apache/commons/io/filefilter/AgeFileFilter.java ( no revision ) src/java/org/apache/commons/io/filefilter/SizeFileFilter.java ( no revision ) src/java/org/apache/commons/io/filefilter/FileFileFilter.java ( no revision ) src/java/org/apache/commons/io/DirectoryWalker.java ( no revision ) src/java/org/apache/commons/io/input/package.html ( no revision ) src/java/org/apache/commons/io/output/package.html ( no revision ) src/java/org/apache/commons/io/FileDeleteStrategy.java ( no revision ) Dependencies Changes: No dependencies changed Build Defintion: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode -DaltDeploymentRepository=vmbuild.repo::default::file://localhost/home/continuum/data/commons -Pci Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: Java 5 Description: Test Summary: Tests: 500 Failures: 0 Total time: 31.885004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Chain 1.2 based on RC1
+0 We should upgrade all of our own dependencies to the latest ones when making releases, as far as possible. Especially the bottom tier ones like logging (in this case, to 1.1.1, which contains good number of fixes over 1.0.4). As indicated by my vote, I don't consider this to be a blocker. Everything else looks good to me (sigs, hashes, manifests -- bar one minor typo thats already fixed, built using ant, m1, m2 and JDK 1.6). -Rahul On 5/20/08, Niall Pemberton [EMAIL PROTECTED] wrote: I would like to do a bug fix release of Commons Chain - mainly to release the fix for CHAIN-33[1] - which hit a Struts user recently (see STR-3143[2]) - but there are a few other bug fixes as well [1] http://issues.apache.org/jira/browse/CHAIN-33 [2] https://issues.apache.org/struts/browse/STR-3143 The artifacts are here: http://people.apache.org/~niallp/chain_1_2_RC1/ SVN Tag: http://svn.apache.org/viewvc/commons/proper/chain/tags/CHAIN_1_2_RC1/ Site: http://people.apache.org/~niallp/chain_1_2_RC1/site/ (note m2 generates relative links, so some don't work - but the site is for info and not included in the release artifacts) Release Notes: http://people.apache.org/~niallp/chain_1_2_RC1/RELEASE-NOTES.txt http://people.apache.org/~niallp/chain_1_2_RC1/site/changes-report.html RAT Report: http://people.apache.org/~niallp/chain_1_2_RC1/site/rat-report.html CLIRR Report: http://people.apache.org/~niallp/chain_1_2_RC1/site/clirr-report.html RC2 has been built with m2 - but m1 and ant builds are available - details here: http://people.apache.org/~niallp/chain_1_2_RC1/site/building.html Note: Chain is targetted at JDK 1.3, but I built with JDK 1.5 because of the issue with m2 and JDK 1.4 - but I have tested on JDK 1.3 and JDK 1.4 using m1 and JDK 1.5 and JDK 1.6 using m2 Vote is open for 72 hours Thanks in advance for your feedback/votes. Niall - [ ] +1 I support this release [ ] +0 I am OK with this release [ ] -0 OK, but [ ] -1 I do not support this release - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Chain 1.2 based on RC1
On 21/05/2008, Niall Pemberton [EMAIL PROTECTED] wrote:
On Wed, May 21, 2008 at 11:05 AM, sebb [EMAIL PROTECTED] wrote:
On 21/05/2008, Niall Pemberton [EMAIL PROTECTED] wrote:
On Wed, May 21, 2008 at 3:26 AM, sebb [EMAIL PROTECTED] wrote:
On 21/05/2008, Niall Pemberton [EMAIL PROTECTED] wrote:
I would like to do a bug fix release of Commons Chain - mainly to
release the fix for CHAIN-33[1] - which hit a Struts user recently
(see STR-3143[2]) - but there are a few other bug fixes as well
[1] http://issues.apache.org/jira/browse/CHAIN-33
[2] https://issues.apache.org/struts/browse/STR-3143
The artifacts are here:
http://people.apache.org/~niallp/chain_1_2_RC1/
Digests, hashes, NL all look OK.
And there are no .asc.md5 files either - how do you avoid those?
I just don't bother to upload them.
pom.xml contains a reference to ${basedir} - I notice that there were
some recent commits that removed this, citing a bug in M2.0.9 - is
this reference OK?
I've only had a problem with ${basedir} when its been used in the
checkstyle config - and I removed that for chain:
http://svn.apache.org/viewvc?view=revrevision=658353
SVN Tag:
http://svn.apache.org/viewvc/commons/proper/chain/tags/CHAIN_1_2_RC1/
Not a blocker, but some incorrect SVN props:
svn pd svn:executable build.properties.sample
svn pd svn:executable build.xml
svn ps svn:eol-style native
src/test/org/apache/commons/chain/web/ChainResourcesTestCase.java
Thanks - fixed in the trunk:
http://svn.apache.org/viewvc?view=revrevision=658574
Site:
http://people.apache.org/~niallp/chain_1_2_RC1/site/
(note m2 generates relative links, so some don't work - but the site
is for info and not included in the release artifacts)
Release Notes:
http://people.apache.org/~niallp/chain_1_2_RC1/RELEASE-NOTES.txt
http://people.apache.org/~niallp/chain_1_2_RC1/site/changes-report.html
RAT Report:
http://people.apache.org/~niallp/chain_1_2_RC1/site/rat-report.html
CLIRR Report:
http://people.apache.org/~niallp/chain_1_2_RC1/site/clirr-report.html
RC2 has been built with m2 - but m1 and ant builds are available -
details here:
http://people.apache.org/~niallp/chain_1_2_RC1/site/building.html
Note: Chain is targetted at JDK 1.3, but I built with JDK 1.5 because
of the issue with m2 and JDK 1.4 - but I have tested on JDK 1.3 and
JDK 1.4 using m1 and JDK 1.5 and JDK 1.6 using m2
Ant build works fine on Java 1.4.2, but using Java 1.3.1 I get
problems with Ant 1.6.0, 1.6.5 and 1.7.0.
M1 1.0.2 works OK on Java 1.3.1
So it looks like there is a problem with the Ant file.
OK, if I get time I'll dump the maven generated ant build and add a
proper one.
It would be nice if this could be fixed, but if not, then the build
instructions should be updated to mention the restriction.
OK, but not a blocker for this release, right?
The Ant problem is not a blocker, so long as the build instructions
are updated accordingly.
OK well we disagree then.
I just meant that the website should be updated before it is published.
I think the site is not a formal part of the vote, so it can be
updated independently?
Niall
Thanks for the feedback.
Niall
Vote is open for 72 hours
Thanks in advance for your feedback/votes.
Niall
-
[ ] +1 I support this release
[ ] +0 I am OK with this release
[ ] -0 OK, but
[ ] -1 I do not support this release
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Chain 1.2 based on RC1
On Wed, May 21, 2008 at 7:42 PM, sebb [EMAIL PROTECTED] wrote:
On 21/05/2008, Niall Pemberton [EMAIL PROTECTED] wrote:
On Wed, May 21, 2008 at 11:05 AM, sebb [EMAIL PROTECTED] wrote:
On 21/05/2008, Niall Pemberton [EMAIL PROTECTED] wrote:
On Wed, May 21, 2008 at 3:26 AM, sebb [EMAIL PROTECTED] wrote:
On 21/05/2008, Niall Pemberton [EMAIL PROTECTED] wrote:
I would like to do a bug fix release of Commons Chain - mainly to
release the fix for CHAIN-33[1] - which hit a Struts user recently
(see STR-3143[2]) - but there are a few other bug fixes as well
[1] http://issues.apache.org/jira/browse/CHAIN-33
[2] https://issues.apache.org/struts/browse/STR-3143
The artifacts are here:
http://people.apache.org/~niallp/chain_1_2_RC1/
Digests, hashes, NL all look OK.
And there are no .asc.md5 files either - how do you avoid those?
I just don't bother to upload them.
pom.xml contains a reference to ${basedir} - I notice that there were
some recent commits that removed this, citing a bug in M2.0.9 - is
this reference OK?
I've only had a problem with ${basedir} when its been used in the
checkstyle config - and I removed that for chain:
http://svn.apache.org/viewvc?view=revrevision=658353
SVN Tag:
http://svn.apache.org/viewvc/commons/proper/chain/tags/CHAIN_1_2_RC1/
Not a blocker, but some incorrect SVN props:
svn pd svn:executable build.properties.sample
svn pd svn:executable build.xml
svn ps svn:eol-style native
src/test/org/apache/commons/chain/web/ChainResourcesTestCase.java
Thanks - fixed in the trunk:
http://svn.apache.org/viewvc?view=revrevision=658574
Site:
http://people.apache.org/~niallp/chain_1_2_RC1/site/
(note m2 generates relative links, so some don't work - but the site
is for info and not included in the release artifacts)
Release Notes:
http://people.apache.org/~niallp/chain_1_2_RC1/RELEASE-NOTES.txt
http://people.apache.org/~niallp/chain_1_2_RC1/site/changes-report.html
RAT Report:
http://people.apache.org/~niallp/chain_1_2_RC1/site/rat-report.html
CLIRR Report:
http://people.apache.org/~niallp/chain_1_2_RC1/site/clirr-report.html
RC2 has been built with m2 - but m1 and ant builds are available -
details here:
http://people.apache.org/~niallp/chain_1_2_RC1/site/building.html
Note: Chain is targetted at JDK 1.3, but I built with JDK 1.5
because
of the issue with m2 and JDK 1.4 - but I have tested on JDK 1.3 and
JDK 1.4 using m1 and JDK 1.5 and JDK 1.6 using m2
Ant build works fine on Java 1.4.2, but using Java 1.3.1 I get
problems with Ant 1.6.0, 1.6.5 and 1.7.0.
M1 1.0.2 works OK on Java 1.3.1
So it looks like there is a problem with the Ant file.
OK, if I get time I'll dump the maven generated ant build and add a
proper one.
It would be nice if this could be fixed, but if not, then the build
instructions should be updated to mention the restriction.
OK, but not a blocker for this release, right?
The Ant problem is not a blocker, so long as the build instructions
are updated accordingly.
OK well we disagree then.
I just meant that the website should be updated before it is published.
Ah OK - will do
I think the site is not a formal part of the vote, so it can be
updated independently?
Yes
Niall
Niall
Thanks for the feedback.
Niall
Vote is open for 72 hours
Thanks in advance for your feedback/votes.
Niall
-
[ ] +1 I support this release
[ ] +0 I am OK with this release
[ ] -0 OK, but
[ ] -1 I do not support this release
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[continuum] BUILD FAILURE: Commons - Commons IO - Build Def:
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=91734projectId=155 Build statistics: State: Failed Previous State: Ok Started at: Wed 21 May 2008 14:01:33 -0700 Finished at: Wed 21 May 2008 14:02:26 -0700 Total time: 52s Build Trigger: Schedule Build Number: 79 Exit code: 1 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version 1.5.0_12 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing) Builder version : Maven version: 2.0.7 Java version: 1.5.0_12 OS name: linux version: 2.6.20-16-server arch: i386 SCM Changes: Changed: niallp @ Wed 21 May 2008 12:56:46 -0700 Comment: Remove tabs Files changed: /commons/proper/io/trunk/src/test/org/apache/commons/io/filefilter/FileFilterTestCase.java ( 658831 ) /commons/proper/io/trunk/src/test/org/apache/commons/io/input/ClassLoaderObjectInputStreamTest.java ( 658831 ) Dependencies Changes: No dependencies changed Build Defintion: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode -DaltDeploymentRepository=vmbuild.repo::default::file://localhost/home/continuum/data/commons -Pci Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: Java 5 Description: Test Summary: Tests: 500 Failures: 1 Total time: 31.032001 Test Failures: FilesystemObserverTestCase testFileDelete : junit.framework.AssertionFailedError junit.framework.AssertionFailedError: F[0 0 0 0 0 1]: No. of directories changed expected:1 but was:0 at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:282) at junit.framework.Assert.assertEquals(Assert.java:64) at junit.framework.Assert.assertEquals(Assert.java:201) at org.apache.commons.io.monitor.FilesystemObserverTestCase.checkCollectionSizes(FilesystemObserverTestCase.java:424) at org.apache.commons.io.monitor.FilesystemObserverTestCase.testFileDelete(FilesystemObserverTestCase.java:332) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Sparse Matrix Support
Hey John Which book are you referring to? Also, take a look at the matrix classes in the Apache Mahout project - I believe (though dont quote me on it) that they may have some support for sparse matrices. Cheers Rory John Iacona wrote: I noticed that support for sparse matrix computation was on the commons math wishlist. This is a project I would be interested in taking on. I would like to add a SparseMatrix interface which would support functionality analogous to the RealMatrix interface. I have worked with Tim Davis the author of the CSparse suite and would be using algorithms outlined in his book to base my code on. On the wishlist page there was a reference to a thread using the old archive url format. Does anyone know how to find that thread with the new format? Searches come up empty. Regards, John Iacona - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons Net 1.5 / 2.0 Releases
Sorry Niklas I meant to say out of the project. It was moved to test/ after the discussion. Rory Niklas Gustavsson wrote: On Wed, May 21, 2008 at 12:48 AM, Rory Winston [EMAIL PROTECTED] wrote: We've had this discussion already (at great length). It's not going to test/src. Search through the archives, I managed to find a discussion on this very topic from March this year, however in the thread it seems like you agree on moving it to src/test: http://markmail.org/message/skzc77eccue7ukxx Maybe there has been additional discussions after that thread where there was a different conclusion? /niklas - 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]
Re: [VOTE] Release Commons Chain 1.2 based on RC1
On Wed, May 21, 2008 at 7:16 PM, Rahul Akolkar [EMAIL PROTECTED] wrote: +0 We should upgrade all of our own dependencies to the latest ones when making releases, as far as possible. Especially the bottom tier ones like logging (in this case, to 1.1.1, which contains good number of fixes over 1.0.4). As indicated by my vote, I don't consider this to be a blocker. OK, but its disappointing if thats the only thing that caused you to vote +0 rather than +1. I've updated the logging dependency in trunk so that if I have to cut another RC then it'll be sorted - but I'm still hoping this vote will pass. Niall Everything else looks good to me (sigs, hashes, manifests -- bar one minor typo thats already fixed, built using ant, m1, m2 and JDK 1.6). -Rahul On 5/20/08, Niall Pemberton [EMAIL PROTECTED] wrote: I would like to do a bug fix release of Commons Chain - mainly to release the fix for CHAIN-33[1] - which hit a Struts user recently (see STR-3143[2]) - but there are a few other bug fixes as well [1] http://issues.apache.org/jira/browse/CHAIN-33 [2] https://issues.apache.org/struts/browse/STR-3143 The artifacts are here: http://people.apache.org/~niallp/chain_1_2_RC1/ SVN Tag: http://svn.apache.org/viewvc/commons/proper/chain/tags/CHAIN_1_2_RC1/ Site: http://people.apache.org/~niallp/chain_1_2_RC1/site/ (note m2 generates relative links, so some don't work - but the site is for info and not included in the release artifacts) Release Notes: http://people.apache.org/~niallp/chain_1_2_RC1/RELEASE-NOTES.txt http://people.apache.org/~niallp/chain_1_2_RC1/site/changes-report.html RAT Report: http://people.apache.org/~niallp/chain_1_2_RC1/site/rat-report.html CLIRR Report: http://people.apache.org/~niallp/chain_1_2_RC1/site/clirr-report.html RC2 has been built with m2 - but m1 and ant builds are available - details here: http://people.apache.org/~niallp/chain_1_2_RC1/site/building.html Note: Chain is targetted at JDK 1.3, but I built with JDK 1.5 because of the issue with m2 and JDK 1.4 - but I have tested on JDK 1.3 and JDK 1.4 using m1 and JDK 1.5 and JDK 1.6 using m2 Vote is open for 72 hours Thanks in advance for your feedback/votes. Niall - [ ] +1 I support this release [ ] +0 I am OK with this release [ ] -0 OK, but [ ] -1 I do not support this release - - 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]
Re: [VOTE] Release Commons Chain 1.2 based on RC1
Not sure if this should be regarded as a problem or not, but I get a test failure when using IBM Java: java version 1.6.0 Java(TM) SE Runtime Environment (build pwi3260-20071123_01) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260-20071121_15015 (JIT enabled) J9VM - 20071121_015015_lHdSMR JIT - r9_20071121_1330 GC - 20071031_AA) JCL - 20071118_01 [junit] Caused an ERROR [junit] org.apache.commons.chain.impl.ContextBase$MapEntryImpl incompatible with java.util.HashMap$Entry [junit] java.lang.ClassCastException: org.apache.commons.chain.impl.ContextBase$MapEntryImpl incompatible with java.util.HashMap $Entry [junit] at java.util.HashMap.writeObject(Unknown Source) [junit] at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:957) [junit] at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1473) [junit] at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1404) [junit] at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1162) [junit] at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:338) [junit] at org.apache.commons.chain.impl.ContextBaseTestCase.testSeriaization(ContextBaseTestCase.java:368) [junit] Target 'internal-test' failed with message 'Test org.apache.commons.chain.impl.ContextBaseTestCase failed'. I've no idea why this error occurs, as the code in question says: private class MapEntryImpl implements Map.Entry There are some errors that Findbugs finds: org.apache.commons.chain.impl.ContextBase is Serializable; consider declaring a serialVersionUID Quite a few of these too: Non-serializable value stored into instance field of a serializable class: e.g. org.apache.commons.chain.web.portlet.PortletApplicationScopeMap stored into non-transient field PortletWebContext.applicationScope org.apache.commons.chain.web.portlet.PortletParamMap stored into non-transient field PortletWebContext.param Looks like the serialization tests are not picking these up. If no-one has reported any related problems then perhaps these particular classes are never serialized. These will probably be tricky to fix, so I guess they could be left for another release. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Chain 1.2 based on RC1
Perhaps the Serializations should be looked at. Most web app servers serialize all their info out when restarting. +1 on the release, btw Paul On Wed, May 21, 2008 at 7:52 PM, sebb [EMAIL PROTECTED] wrote: Not sure if this should be regarded as a problem or not, but I get a test failure when using IBM Java: java version 1.6.0 Java(TM) SE Runtime Environment (build pwi3260-20071123_01) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260-20071121_15015 (JIT enabled) J9VM - 20071121_015015_lHdSMR JIT - r9_20071121_1330 GC - 20071031_AA) JCL - 20071118_01 [junit] Caused an ERROR [junit] org.apache.commons.chain.impl.ContextBase$MapEntryImpl incompatible with java.util.HashMap$Entry [junit] java.lang.ClassCastException: org.apache.commons.chain.impl.ContextBase$MapEntryImpl incompatible with java.util.HashMap $Entry [junit] at java.util.HashMap.writeObject(Unknown Source) [junit] at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:957) [junit] at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1473) [junit] at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1404) [junit] at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1162) [junit] at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:338) [junit] at org.apache.commons.chain.impl.ContextBaseTestCase.testSeriaization(ContextBaseTestCase.java:368) [junit] Target 'internal-test' failed with message 'Test org.apache.commons.chain.impl.ContextBaseTestCase failed'. I've no idea why this error occurs, as the code in question says: private class MapEntryImpl implements Map.Entry There are some errors that Findbugs finds: org.apache.commons.chain.impl.ContextBase is Serializable; consider declaring a serialVersionUID Quite a few of these too: Non-serializable value stored into instance field of a serializable class: e.g. org.apache.commons.chain.web.portlet.PortletApplicationScopeMap stored into non-transient field PortletWebContext.applicationScope org.apache.commons.chain.web.portlet.PortletParamMap stored into non-transient field PortletWebContext.param Looks like the serialization tests are not picking these up. If no-one has reported any related problems then perhaps these particular classes are never serialized. These will probably be tricky to fix, so I guess they could be left for another release. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Chain 1.2 based on RC1
On Thu, May 22, 2008 at 1:52 AM, sebb [EMAIL PROTECTED] wrote: Not sure if this should be regarded as a problem or not, but I get a test failure when using IBM Java: java version 1.6.0 Java(TM) SE Runtime Environment (build pwi3260-20071123_01) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260-20071121_15015 (JIT enabled) J9VM - 20071121_015015_lHdSMR JIT - r9_20071121_1330 GC - 20071031_AA) JCL - 20071118_01 [junit] Caused an ERROR [junit] org.apache.commons.chain.impl.ContextBase$MapEntryImpl incompatible with java.util.HashMap$Entry [junit] java.lang.ClassCastException: org.apache.commons.chain.impl.ContextBase$MapEntryImpl incompatible with java.util.HashMap $Entry [junit] at java.util.HashMap.writeObject(Unknown Source) [junit] at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:957) [junit] at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1473) [junit] at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1404) [junit] at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1162) [junit] at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:338) [junit] at org.apache.commons.chain.impl.ContextBaseTestCase.testSeriaization(ContextBaseTestCase.java:368) [junit] Target 'internal-test' failed with message 'Test org.apache.commons.chain.impl.ContextBaseTestCase failed'. I've no idea why this error occurs, as the code in question says: private class MapEntryImpl implements Map.Entry :( There are some errors that Findbugs finds: org.apache.commons.chain.impl.ContextBase is Serializable; consider declaring a serialVersionUID Quite a few of these too: Non-serializable value stored into instance field of a serializable class: e.g. org.apache.commons.chain.web.portlet.PortletApplicationScopeMap stored into non-transient field PortletWebContext.applicationScope org.apache.commons.chain.web.portlet.PortletParamMap stored into non-transient field PortletWebContext.param Looks like the serialization tests are not picking these up. If no-one has reported any related problems then perhaps these particular classes are never serialized. It has been raised: http://issues.apache.org/jira/browse/CHAIN-12 they subclass ContextBase and inherit the implements Serializable contract, but they cannot in fact be serialized because they wrap container objects (request, response,context) that are not serializable ...and we don't have a solution for it - so no fix. Niall These will probably be tricky to fix, so I guess they could be left for another release. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Chain 1.2 based on RC1
On Thu, May 22, 2008 at 2:09 AM, Niall Pemberton [EMAIL PROTECTED] wrote: On Thu, May 22, 2008 at 1:52 AM, sebb [EMAIL PROTECTED] wrote: Not sure if this should be regarded as a problem or not, but I get a test failure when using IBM Java: java version 1.6.0 Java(TM) SE Runtime Environment (build pwi3260-20071123_01) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260-20071121_15015 (JIT enabled) J9VM - 20071121_015015_lHdSMR JIT - r9_20071121_1330 GC - 20071031_AA) JCL - 20071118_01 [junit] Caused an ERROR [junit] org.apache.commons.chain.impl.ContextBase$MapEntryImpl incompatible with java.util.HashMap$Entry [junit] java.lang.ClassCastException: org.apache.commons.chain.impl.ContextBase$MapEntryImpl incompatible with java.util.HashMap $Entry [junit] at java.util.HashMap.writeObject(Unknown Source) [junit] at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:957) [junit] at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1473) [junit] at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1404) [junit] at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1162) [junit] at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:338) [junit] at org.apache.commons.chain.impl.ContextBaseTestCase.testSeriaization(ContextBaseTestCase.java:368) [junit] Target 'internal-test' failed with message 'Test org.apache.commons.chain.impl.ContextBaseTestCase failed'. I've no idea why this error occurs, as the code in question says: private class MapEntryImpl implements Map.Entry :( There are some errors that Findbugs finds: org.apache.commons.chain.impl.ContextBase is Serializable; consider declaring a serialVersionUID Quite a few of these too: Non-serializable value stored into instance field of a serializable class: e.g. org.apache.commons.chain.web.portlet.PortletApplicationScopeMap stored into non-transient field PortletWebContext.applicationScope org.apache.commons.chain.web.portlet.PortletParamMap stored into non-transient field PortletWebContext.param Looks like the serialization tests are not picking these up. If no-one has reported any related problems then perhaps these particular classes are never serialized. It has been raised: http://issues.apache.org/jira/browse/CHAIN-12 they subclass ContextBase and inherit the implements Serializable contract, but they cannot in fact be serialized because they wrap container objects (request, response,context) that are not serializable ...and we don't have a solution for it - so no fix. btw Struts 1.3.x uses these, but they only exist for the lifespan of a request - which I assume is why we don't see loads of complaints about this. Niall Niall These will probably be tricky to fix, so I guess they could be left for another release. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Sparse Matrix Support
This is the book I was referring to http://www.ec-securehost.com/SIAM/FA02.html Regards, John On Wed, May 21, 2008 at 5:26 PM, Rory Winston [EMAIL PROTECTED] wrote: Hey John Which book are you referring to? Also, take a look at the matrix classes in the Apache Mahout project - I believe (though dont quote me on it) that they may have some support for sparse matrices. Cheers Rory John Iacona wrote: I noticed that support for sparse matrix computation was on the commons math wishlist. This is a project I would be interested in taking on. I would like to add a SparseMatrix interface which would support functionality analogous to the RealMatrix interface. I have worked with Tim Davis the author of the CSparse suite and would be using algorithms outlined in his book to base my code on. On the wishlist page there was a reference to a thread using the old archive url format. Does anyone know how to find that thread with the new format? Searches come up empty. Regards, John Iacona - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Chain 1.2 based on RC1
This vote is cancelled, I'll prepare an new RC shortly to fix some of the issues Rahul and Sebb raised. Thanks for the feedback Niall On Wed, May 21, 2008 at 1:55 AM, Niall Pemberton [EMAIL PROTECTED] wrote: I would like to do a bug fix release of Commons Chain - mainly to release the fix for CHAIN-33[1] - which hit a Struts user recently (see STR-3143[2]) - but there are a few other bug fixes as well [1] http://issues.apache.org/jira/browse/CHAIN-33 [2] https://issues.apache.org/struts/browse/STR-3143 The artifacts are here: http://people.apache.org/~niallp/chain_1_2_RC1/ SVN Tag: http://svn.apache.org/viewvc/commons/proper/chain/tags/CHAIN_1_2_RC1/ Site: http://people.apache.org/~niallp/chain_1_2_RC1/site/ (note m2 generates relative links, so some don't work - but the site is for info and not included in the release artifacts) Release Notes: http://people.apache.org/~niallp/chain_1_2_RC1/RELEASE-NOTES.txt http://people.apache.org/~niallp/chain_1_2_RC1/site/changes-report.html RAT Report: http://people.apache.org/~niallp/chain_1_2_RC1/site/rat-report.html CLIRR Report: http://people.apache.org/~niallp/chain_1_2_RC1/site/clirr-report.html RC2 has been built with m2 - but m1 and ant builds are available - details here: http://people.apache.org/~niallp/chain_1_2_RC1/site/building.html Note: Chain is targetted at JDK 1.3, but I built with JDK 1.5 because of the issue with m2 and JDK 1.4 - but I have tested on JDK 1.3 and JDK 1.4 using m1 and JDK 1.5 and JDK 1.6 using m2 Vote is open for 72 hours Thanks in advance for your feedback/votes. Niall - [ ] +1 I support this release [ ] +0 I am OK with this release [ ] -0 OK, but [ ] -1 I do not support this release - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release Commons Chain 1.2 based on RC2
The main changes since RC1 are that the ant build now works on JDK 1.3 and the Logging dependency has been upgraded to the latest 1.1.1 The artifacts are here: http://people.apache.org/~niallp/chain_1_2_RC2/ SVN Tag: http://svn.apache.org/viewvc/commons/proper/chain/tags/CHAIN_1_2_RC2/ Site: http://people.apache.org/~niallp/chain_1_2_RC2/site/ (note m2 generates relative links, so some don't work - but the site is for info and not included in the release artifacts) Release Notes: http://people.apache.org/~niallp/chain_1_2_RC2/RELEASE-NOTES.txt http://people.apache.org/~niallp/chain_1_2_RC2/site/changes-report.html RAT Report: http://people.apache.org/~niallp/chain_1_2_RC2/site/rat-report.html CLIRR Report: http://people.apache.org/~niallp/chain_1_2_RC2/site/clirr-report.html RC2 has been built with m2 - but m1 and ant builds are available - details here: http://people.apache.org/~niallp/chain_1_2_RC2/site/building.html Note: Chain is targetted at JDK 1.3, but I built with JDK 1.5 because of the issue with m2 and JDK 1.4 - but I have tested on JDK 1.3 and JDK 1.4 using m1 ant and JDK 1.5 and JDK 1.6 using m2 Vote is open for 72 hours Thanks in advance for your feedback/votes. Niall - [ ] +1 I support this release [ ] +0 I am OK with this release [ ] -0 OK, but [ ] -1 I do not support this release - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Chain 1.2 based on RC1
On 5/21/08, Niall Pemberton [EMAIL PROTECTED] wrote: On Wed, May 21, 2008 at 7:16 PM, Rahul Akolkar [EMAIL PROTECTED] wrote: +0 We should upgrade all of our own dependencies to the latest ones when making releases, as far as possible. Especially the bottom tier ones like logging (in this case, to 1.1.1, which contains good number of fixes over 1.0.4). As indicated by my vote, I don't consider this to be a blocker. OK, but its disappointing if thats the only thing that caused you to vote +0 rather than +1. snip/ Sigh, didn't mean to disappoint. FWIW, I've tried to say similar things for a while [1]. -Rahul [1] http://people.apache.org/~rahul/commons/DependencyCheck.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Chain 1.2 based on RC2
On 5/21/08, Niall Pemberton [EMAIL PROTECTED] wrote: snip/ [X] +1 I support this release [ ] +0 I am OK with this release [ ] -0 OK, but [ ] -1 I do not support this release snap/ Sigs, sums, manifests I checked are good. Tried all builds on JDK 1.6. -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
