Inlline (Sorry, on plane and have to use Outlook)
--
Geir Magnusson Jr
[EMAIL PROTECTED]
SSG/MPD
+1 203 665 6437
> -Original Message-
> From: Tim Ellison [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 12, 2006 5:43 AM
> To: harmony-dev@incubator.apache.org
> Subject: Publishing
Well, I'll try to summarize what we have
There are three types of methods:
1. Methods that are part of the API, they are specified, they follow the
Sun's spec and we have nothing to add.
2. Methods that are part of the API and we have something to add (ex.:
the spec allows multiple behaviors).
3.
Geir Magnusson Jr wrote:
Tim Ellison wrote:
What we've tended to do, internally, is to name the testcases after the
type they are testing, so all unit tests for java.io.File are put into a
tests package ending with java.io in a type called FileTest that extends
the junit.framework.TestCase.
Hi,
I have been looking into running the JUnit tests included in HARMONY-16 in
my private sandbox. From what I have seen so far most (all ?) of the test
cases inherit from a base class PerformanceTest in the
com.openintel.drl.security.test package. What is the purpose of this base
class ?
B
Geir Magnusson Jr wrote:
Ok - lets do this.
Lets make this "repeatable" - I put that in quotes becuase our toolchain
configs are tough right now, but we do want to be working towards
repeatability.
So lets write down how we do it, make sure it's scripted, and do it - so
Tim does it for the
FYI I just tried using the Harmony classlib code (and IBM VM) to build
'security2' with the existing security2 build scripts.
With a minor tweak(*) to the security2/make/build.xml to reflect the
layout of our deployment, I was able to successfully build security2
using only the class library code
Geir Magnusson Jr wrote:
> (As for security2, can you just remove that via the build script for now?)
Yep, it isn't referenced from the build script, which is why it is a
shame to wait for it to download when doing a source build of the
snapshot. It's a temporary removal from the snapshot tag, b
Mishura, Stepan M wrote:
> Tim Ellison wrote:
>
>>We would have written it as java.io.tests, but the java.
>>namespace is reserved, so the formula is simply
>>
>>. -> org.apache.harmony.tests..Test
>
> Placing classes and tests for them in different packages won't allow
> testing package acce
Geir Magnusson Jr wrote:
> Tim Ellison wrote:
>> We would have written it as java.io.tests, but the java.
>> namespace is reserved, so the formula is simply
>>
>> . -> org.apache.harmony.tests..Test
>
>
> Ug - then you have the problem of not being in the namespace as what you
> are testing.
12, 2006, at 7:31 AM, [EMAIL PROTECTED] wrote:
Author: tellison
Date: Thu Jan 12 04:30:52 2006
New Revision: 368355
URL: http://svn.apache.org/viewcvs?rev=368355&view=rev
Log:
Creating work-in-progress snapshot
Added:
incubator/harmony/enhanced/classlib/tags/SNAP-20060112/
-
:30:52 2006
>> New Revision: 368355
>>
>> URL: http://svn.apache.org/viewcvs?rev=368355&view=rev
>> Log:
>> Creating work-in-progress snapshot
>>
>> Added:
>> incubator/harmony/enhanced/classlib/tags/SNAP-20060112/
>> - copied from r368354
Ok, I have written a simple guide to building the classlib code, and
have left place-holders for links to binary snapshots when I can upload
them.
See:
http://people.apache.org/~tellison/building_classlib.html
Did you create svn.apache.org/snapshots/incubator-harmony/ already? I
can't ch
-progress snapshot
Added:
incubator/harmony/enhanced/classlib/tags/SNAP-20060112/
- copied from r368354, incubator/harmony/enhanced/classlib/
trunk/
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
Tim Ellison wrote:
>
>We would have written it as java.io.tests, but the java.
>namespace is reserved, so the formula is simply
>
>. -> org.apache.harmony.tests..Test
>
Placing classes and tests for them in different packages won't allow
testing package access functionality.
>
>Then within th
Tim Ellison wrote:
What we've tended to do, internally, is to name the testcases after the
type they are testing, so all unit tests for java.io.File are put into a
tests package ending with java.io in a type called FileTest that extends
the junit.framework.TestCase.
Yes - that's the canonical
George Harley1 wrote:
Hi,
I think that regression tests should be marked in some way.
Agreed. But can we please *resist* the temptation to do this by
incorporating JIRA issue numbers into test case names (e.g. calling unit
test methods test_26() or test_JIRA_26()). I've seen this kind
What we've tended to do, internally, is to name the testcases after the
type they are testing, so all unit tests for java.io.File are put into a
tests package ending with java.io in a type called FileTest that extends
the junit.framework.TestCase.
We would have written it as java.io.tests, but the
The network related channels in java.nio.channels are not implemented
--
Key: HARMONY-27
URL: http://issues.apache.org/jira/browse/HARMONY-27
Project: Harmony
Type: Bug
Components: Classlib
Hi, everybody
I'm Paulex of China Software Development Lab, IBM, and I'm working with
Richard on the nio improvement. I found that the network related
channels in java.nio.channels are not implemented in the class library
code, so I will raise a JIRA request on this today. and we will start to
Hi,
> I think that regression tests should be marked in some way.
Agreed. But can we please *resist* the temptation to do this by
incorporating JIRA issue numbers into test case names (e.g. calling unit
test methods test_26() or test_JIRA_26()). I've seen this kind of approach
adopted in a c
20 matches
Mail list logo
