Return-Path: Delivered-To: apmail-commons-issues-archive@locus.apache.org Received: (qmail 66054 invoked from network); 25 Nov 2008 20:38:06 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 25 Nov 2008 20:38:06 -0000 Received: (qmail 85358 invoked by uid 500); 25 Nov 2008 20:38:15 -0000 Delivered-To: apmail-commons-issues-archive@commons.apache.org Received: (qmail 85309 invoked by uid 500); 25 Nov 2008 20:38:15 -0000 Mailing-List: contact issues-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: issues@commons.apache.org Delivered-To: mailing list issues@commons.apache.org Received: (qmail 85298 invoked by uid 99); 25 Nov 2008 20:38:15 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 25 Nov 2008 12:38:15 -0800 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 25 Nov 2008 20:36:57 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 33EBB234C294 for ; Tue, 25 Nov 2008 12:37:44 -0800 (PST) Message-ID: <1074654194.1227645464210.JavaMail.jira@brutus> Date: Tue, 25 Nov 2008 12:37:44 -0800 (PST) From: "Rahul Akolkar (JIRA)" To: issues@commons.apache.org Subject: [jira] Resolved: (SCXML-93) SCXMLTestHelper generates a lot of serialisation files which are not tidied up In-Reply-To: <2013946326.1227609464358.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/SCXML-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rahul Akolkar resolved SCXML-93. -------------------------------- Resolution: Won't Fix I think the aspect of tidying up here is no different from what folks using any of the builds should expect -- to elaborate, lets say you execute this command: mvn test (or 'maven test', or 'ant'), you'll find a bunch of artifacts created in the target directory. These persist until you clean the build, so in the above case a: mvn clean will do the trick. The serialization files follow a similar pattern, they can be cleaned using the corresponding clean command. A useful advantage of using File I/O is that the artifacts can be introspected once you run the tests and you can observe how certain changes to the datamodel or history affect size on disk etc. You are right that this can be replaced by using ByteArray I/O instead, but at this point its unclear we should (its much harder to introspect serializations or track serialization timelines that way). Resolving as Won't Fix. > SCXMLTestHelper generates a lot of serialisation files which are not tidied up > ------------------------------------------------------------------------------ > > Key: SCXML-93 > URL: https://issues.apache.org/jira/browse/SCXML-93 > Project: Commons SCXML > Issue Type: Bug > Reporter: Sebb > Priority: Minor > > SCXMLTestHelper generates files to test serialisation of classes in testExecutorSerializability() and testModelSerializability(). > These files are only used temporarily, but are not cleared up at the end of a run. > They can be replaced by using ByteArray classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.