Re: [jira] Assigned: (HARMONY-237) PropertyDescriptor constructors throws incorrect (or no) exception
Not at all. -Mark. On 4/21/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > Ok I see :) > Would you mind if I integrate your testcase into the current test? > > Thanks, > Mikhail > > 2006/4/21, Mark Hindess <[EMAIL PROTECTED]>: > > On 4/21/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > > Mark > > > > > > Is there some reason why you are not putting new regression tests into an > > > existing PropertyDescriptorTest? > > > > Yes. I opened the JIRA on 22nd March almost a month before the > > current test was integrated. ;-) > > > > -Mark. > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Mark Hindess <[EMAIL PROTECTED]> IBM Java Technology Centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Assigned: (HARMONY-237) PropertyDescriptor constructors throws incorrect (or no) exception
Ok I see :) Would you mind if I integrate your testcase into the current test? Thanks, Mikhail 2006/4/21, Mark Hindess <[EMAIL PROTECTED]>: > On 4/21/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > Mark > > > > Is there some reason why you are not putting new regression tests into an > > existing PropertyDescriptorTest? > > Yes. I opened the JIRA on 22nd March almost a month before the > current test was integrated. ;-) > > -Mark. > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] String is special
Why not put all the tests that control String's behavior to the suite? Are there any possible harmful differences that are untestable? Thanks, Mikhail 2006/4/21, bootjvm <[EMAIL PROTECTED]>: > > I have been watching this issue closely because it will directly > affect my work on BootJVM with the (minimal) native part > of java.lang.String . I am in favor of a stricter control on this > class in the interest of making sure we do not make mistakes > such as what you anticipate that 'svn:needs-lock' can help > out on. > > Dan Lydick > > > > [Original Message] > > From: Tim Ellison <[EMAIL PROTECTED]> > > To: harmony-dev > > Date: 4/20/06 8:12:34 AM > > Subject: [classlib] String is special > > > > You'll recall a while ago when we were discussing moving j.l.String out > > from KERNEL to LUNI [1] that the shape of String is something we would > > expect VMs & JITs to be sensitive to (like all our KERNEL classes), but > > that there is significant shared behavior that it is worth sharing > > (which is why we moved it into LUNI). > > > > I suggested that we could deal with this by ensuring changes to String > > were closely monitored, and any such changes agreed on the list first > > (thereby acquiring a 'golden ticket'). There have been a few changes to > > String recently (I have reviewed them, and they look benign) but I'd > > like to reiterate that call. > > > > To ensure that all committers can continue to update String, but that > > they do so 'knowingly' (i.e. after considering the consequences) I'd > > like to impose a 'positive action' pre-commit step by setting the > > "svn:needs-lock" property on String.java. > > > > That will ensure that committers do not inadvertently (despite their > > thorough diff review) apply a patch that modifies String.java. The > > extra step required would simply be to acquire a lock on String.java > > first and that should be enough to remind people that they are modifying > > this class. > > > > (This is for my benefit as much as anyone else's) > > > > If there are no objections I'll go ahead and do this. > > > > Regards, > > Tim > > > > [1] > > > http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/% > [EMAIL PROTECTED] > > > > -- > > > > Tim Ellison ([EMAIL PROTECTED]) > > IBM Java technology centre, UK. > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r395541 - /incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml
Oh, I see - thanks! - Stepan. On 4/21/06, Mark Hindess wrote: > > But I can't see how. It is a tirvial fix though changing cipherText > on line 554 to 'ciphertext' to match the case of the checked in file > name. > > -Mark. > > > On 4/21/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > > It did when I submitted the patch. > > -Mark. > > > > On 4/21/06, Stepan Mishura <[EMAIL PROTECTED]> wrote: > > > Hi Mark, > > > > > > Do you mean that the test tests/api/javax/crypto/CipherTest.java > passes on > > > you linux without classpath modification? > > > > > > Thanks, > > > Stepan. > > > > > > On 4/20/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > > > > > > > > Without the classpath modifications then it works for me on linux. > > > > -Mark. > > > > > > > > > > > > On 4/20/06, Stepan Mishura <[EMAIL PROTECTED]> wrote: > > > > > On 4/20/06, Mark Hindess wrote: > > > > > > > > > > > > Stepan, > > > > > > > > > > > > In your original commit for HARMONY-315, you made this change: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm not sure how this relates to this JIRA > > > > > > > > > > > > > > > Right, it was better to separate updates. > > > > > > > > > > but it is this that breaks > > > > > > the test. Why not remove/fix this unrelated change rather than > > > > > > comment out the otherwise working test? > > > > > > > > > > > > > > > It is not quite correct. The tests passes on Windows but fails on > Linux > > > > - > > > > > I'm going to investigate the difference. But if I remove these > lines > > > > then it > > > > > will fail on Windows too. > > > > > > > > > > IMHO, we should avoid making unrelated changes in a single commit. > > > > > > > > > > > > > > < SNIP> > > > > > > > > -- > > > > Mark Hindess <[EMAIL PROTECTED]> > > > > IBM Java Technology Centre, UK. > > > > > > > > > - > > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > -- > > > Thanks, > > > Stepan Mishura > > > Intel Middleware Products Division > > > > > > -- > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > Mark Hindess <[EMAIL PROTECTED]> > > IBM Java Technology Centre, UK. > > > > > -- > Mark Hindess <[EMAIL PROTECTED]> > IBM Java Technology Centre, UK. > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Thanks, Stepan Mishura Intel Middleware Products Division -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [classlib] String is special
I have been watching this issue closely because it will directly affect my work on BootJVM with the (minimal) native part of java.lang.String . I am in favor of a stricter control on this class in the interest of making sure we do not make mistakes such as what you anticipate that 'svn:needs-lock' can help out on. Dan Lydick > [Original Message] > From: Tim Ellison <[EMAIL PROTECTED]> > To: harmony-dev > Date: 4/20/06 8:12:34 AM > Subject: [classlib] String is special > > You'll recall a while ago when we were discussing moving j.l.String out > from KERNEL to LUNI [1] that the shape of String is something we would > expect VMs & JITs to be sensitive to (like all our KERNEL classes), but > that there is significant shared behavior that it is worth sharing > (which is why we moved it into LUNI). > > I suggested that we could deal with this by ensuring changes to String > were closely monitored, and any such changes agreed on the list first > (thereby acquiring a 'golden ticket'). There have been a few changes to > String recently (I have reviewed them, and they look benign) but I'd > like to reiterate that call. > > To ensure that all committers can continue to update String, but that > they do so 'knowingly' (i.e. after considering the consequences) I'd > like to impose a 'positive action' pre-commit step by setting the > "svn:needs-lock" property on String.java. > > That will ensure that committers do not inadvertently (despite their > thorough diff review) apply a patch that modifies String.java. The > extra step required would simply be to acquire a lock on String.java > first and that should be enough to remind people that they are modifying > this class. > > (This is for my benefit as much as anyone else's) > > If there are no objections I'll go ahead and do this. > > Regards, > Tim > > [1] > http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/% [EMAIL PROTECTED] > > -- > > Tim Ellison ([EMAIL PROTECTED]) > IBM Java technology centre, UK. > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r395541 - /incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml
But I can't see how. It is a tirvial fix though changing cipherText on line 554 to 'ciphertext' to match the case of the checked in file name. -Mark. On 4/21/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > It did when I submitted the patch. > -Mark. > > On 4/21/06, Stepan Mishura <[EMAIL PROTECTED]> wrote: > > Hi Mark, > > > > Do you mean that the test tests/api/javax/crypto/CipherTest.java passes on > > you linux without classpath modification? > > > > Thanks, > > Stepan. > > > > On 4/20/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > > > > > > Without the classpath modifications then it works for me on linux. > > > -Mark. > > > > > > > > > On 4/20/06, Stepan Mishura <[EMAIL PROTECTED]> wrote: > > > > On 4/20/06, Mark Hindess wrote: > > > > > > > > > > Stepan, > > > > > > > > > > In your original commit for HARMONY-315, you made this change: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm not sure how this relates to this JIRA > > > > > > > > > > > > Right, it was better to separate updates. > > > > > > > > but it is this that breaks > > > > > the test. Why not remove/fix this unrelated change rather than > > > > > comment out the otherwise working test? > > > > > > > > > > > > It is not quite correct. The tests passes on Windows but fails on Linux > > > - > > > > I'm going to investigate the difference. But if I remove these lines > > > then it > > > > will fail on Windows too. > > > > > > > > IMHO, we should avoid making unrelated changes in a single commit. > > > > > > > > > > > < SNIP> > > > > > > -- > > > Mark Hindess <[EMAIL PROTECTED]> > > > IBM Java Technology Centre, UK. > > > > > > - > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > Thanks, > > Stepan Mishura > > Intel Middleware Products Division > > > > -- > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Mark Hindess <[EMAIL PROTECTED]> > IBM Java Technology Centre, UK. > -- Mark Hindess <[EMAIL PROTECTED]> IBM Java Technology Centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r395541 - /incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml
It did when I submitted the patch. -Mark. On 4/21/06, Stepan Mishura <[EMAIL PROTECTED]> wrote: > Hi Mark, > > Do you mean that the test tests/api/javax/crypto/CipherTest.java passes on > you linux without classpath modification? > > Thanks, > Stepan. > > On 4/20/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > > > > Without the classpath modifications then it works for me on linux. > > -Mark. > > > > > > On 4/20/06, Stepan Mishura <[EMAIL PROTECTED]> wrote: > > > On 4/20/06, Mark Hindess wrote: > > > > > > > > Stepan, > > > > > > > > In your original commit for HARMONY-315, you made this change: > > > > > > > > > > > > > > > > > > > > > > > > I'm not sure how this relates to this JIRA > > > > > > > > > Right, it was better to separate updates. > > > > > > but it is this that breaks > > > > the test. Why not remove/fix this unrelated change rather than > > > > comment out the otherwise working test? > > > > > > > > > It is not quite correct. The tests passes on Windows but fails on Linux > > - > > > I'm going to investigate the difference. But if I remove these lines > > then it > > > will fail on Windows too. > > > > > > IMHO, we should avoid making unrelated changes in a single commit. > > > > > > > > < SNIP> > > > > -- > > Mark Hindess <[EMAIL PROTECTED]> > > IBM Java Technology Centre, UK. > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Thanks, > Stepan Mishura > Intel Middleware Products Division > > -- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Mark Hindess <[EMAIL PROTECTED]> IBM Java Technology Centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Assigned: (HARMONY-237) PropertyDescriptor constructors throws incorrect (or no) exception
On 4/21/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > Mark > > Is there some reason why you are not putting new regression tests into an > existing PropertyDescriptorTest? Yes. I opened the JIRA on 22nd March almost a month before the current test was integrated. ;-) -Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jira] Assigned: (HARMONY-237) PropertyDescriptor constructors throws incorrect (or no) exception
Mark Is there some reason why you are not putting new regression tests into an existing PropertyDescriptorTest? Thanks, Mikhail > [ http://issues.apache.org/jira/browse/HARMONY-237?page=all ] > >Mikhail Loenko reassigned HARMONY-237: >-- > >Assign To: Mikhail Loenko > >> PropertyDescriptor constructors throws incorrect (or no) exception >> -- >> >> Key: HARMONY-237 >> URL: http://issues.apache.org/jira/browse/HARMONY-237 >> Project: Harmony >> Type: Bug > >> Components: Classlib >> Reporter: Mark Hindess >> Assignee: Mikhail Loenko >> Priority: Minor >> Attachments: 02.propertydescriptor.empty.propery.name.diff, propertydescriptor.npe.diff >> >> Passing all null arguments to these constructors gives incorrect behaviour. >> j.beans.PropertyDescriptor(j.l.String,j.l.Class): >> RI throws j.beans.IntrospectionException but >> Harmony throws j.l.NullPointerException >> j.beans.PropertyDescriptor(j.l.String,j.l.Class,j.l.String,j.l.String): >> RI throws j.beans.IntrospectionException but >> Harmony throws j.l.NullPointerException >> j.beans.PropertyDescriptor(j.l.String,j.l.reflect.Method,j.l.reflect.Method): >> RI throws j.beans.IntrospectionException but >> Harmony doesn't throw an exception >> Will attach a patch. > >-- >This message is automatically generated by JIRA. >- >If you think it was sent incorrectly contact one of the administrators: > http://issues.apache.org/jira/secure/Administrators.jspa >- >For more information on JIRA, see: > http://www.atlassian.com/software/jira - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Java 5 String APIs (code points, StringBuilder, etc) RE: [classlib] String is special
BTW: Here's a direct link to the patch - http://issues.apache.org/jira/secure/attachment/12325649/String_java_5_metho ds3.txt > -Original Message- > From: Nathan Beyer [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 20, 2006 9:30 PM > To: harmony-dev@incubator.apache.org > Subject: Java 5 String APIs (code points, StringBuilder, etc) RE: > [classlib] String is special > > Since I probably share some responsibility in the "String is special" > topic > being brought up, I wanted to try out the "golden ticket" bit for some > further enhancements. > > I've made some changes to String to add the new Java 5 APIs related to > code > points, StringBuilder, etc. > > I've posted a proposed patch on this issue [1]. I'd already opened this > bug. > The patch contains updates to String and StringTest. > > There is one concern that I have about the code and the test (and all > String > tests we have in general). There's the possibility of a String being > constructed with a non-zero offset; there's a package-private constructor > String(int start, int len, char[] data). I haven't found any other way to > setup this variant and I'd like to test all of the methods when the offset > is greater than 0, but this requires the test case to be in the > "java.lang" > package. I know this has been an issue that been discussed on and off, but > didn't think any concrete solution had been arrived at for doing this and > I > haven't seen any test cases in the java package spaces. > > Please let me know if there are any questions or if any more information > is > needed. Thanks. > > -Nathan > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Java 5 String APIs (code points, StringBuilder, etc) RE: [classlib] String is special
Since I probably share some responsibility in the "String is special" topic being brought up, I wanted to try out the "golden ticket" bit for some further enhancements. I've made some changes to String to add the new Java 5 APIs related to code points, StringBuilder, etc. I've posted a proposed patch on this issue [1]. I'd already opened this bug. The patch contains updates to String and StringTest. There is one concern that I have about the code and the test (and all String tests we have in general). There's the possibility of a String being constructed with a non-zero offset; there's a package-private constructor String(int start, int len, char[] data). I haven't found any other way to setup this variant and I'd like to test all of the methods when the offset is greater than 0, but this requires the test case to be in the "java.lang" package. I know this has been an issue that been discussed on and off, but didn't think any concrete solution had been arrived at for doing this and I haven't seen any test cases in the java package spaces. Please let me know if there are any questions or if any more information is needed. Thanks. -Nathan - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r395541 - /incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml
Hi Mark, Do you mean that the test tests/api/javax/crypto/CipherTest.java passes on you linux without classpath modification? Thanks, Stepan. On 4/20/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > > Without the classpath modifications then it works for me on linux. > -Mark. > > > On 4/20/06, Stepan Mishura <[EMAIL PROTECTED]> wrote: > > On 4/20/06, Mark Hindess wrote: > > > > > > Stepan, > > > > > > In your original commit for HARMONY-315, you made this change: > > > > > > > > > > > > > > > > > > I'm not sure how this relates to this JIRA > > > > > > Right, it was better to separate updates. > > > > but it is this that breaks > > > the test. Why not remove/fix this unrelated change rather than > > > comment out the otherwise working test? > > > > > > It is not quite correct. The tests passes on Windows but fails on Linux > - > > I'm going to investigate the difference. But if I remove these lines > then it > > will fail on Windows too. > > > > IMHO, we should avoid making unrelated changes in a single commit. > > > > > < SNIP> > > -- > Mark Hindess <[EMAIL PROTECTED]> > IBM Java Technology Centre, UK. > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Thanks, Stepan Mishura Intel Middleware Products Division -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ITC's java.math package contribution
Hi Daniel, indeed it makes sense to compare the performance both implementations of java.math package using the real applications. If you have any results could you plase to make them public? I want to look at them. Besides I'd pefer to slightly correct you about the SVN repository already contains full implemenation of the java.math package for Java 1.5 (please look at the HARMONY-380 issue for details). Thanks, Vladimir Gorr Intel Middleware Products Division. On 4/21/06, Daniel Fridlender <[EMAIL PROTECTED]> wrote: > > Dear all, > > on behalf of ITC I have updated our contribution of the package > java.math including some recent optimizations (HARMONY-199). I think > it would be interesting to compare our implementation with the one > donated by Intel (HARMONY-39). In order to do that, it would be nice > to have a collection of applications were the package is used. > > So far, we have tried both implementations with a realistic > application (RSA key generation) and our implementation turned out to > have a significantly better performance. > > Another point is that we implemented the full 1.5 API functionality, > which in the case of BigDecimal amounts to having about twice as many > methods as in the 1.4.2 API. This may have little significance now, > but it will definitely be important when Harmony moves to 1.5 > > Our implementation uses 1.5 syntax since the 1.5 API includes an Enum > (RoundingMode). > It should be easy to obtain a 1.4.2 implementation of the 1.4.2 API from > it. > > Some more information about our development can be found at > http://www.fitc.unc.edu.ar/javadev/math/ > > Daniel Fridlender > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [classlib] String is special
Etienne Gagnon wrote: Hi Tim, I have an objection. Locking has nothing to do with "commit control". Allowing for svn locking functionality is opening a can of worms. What if somebody aquires a lock and loses network connectivity for a week (because of a Hurricane, because he forgot and went on vacation, etc.)? The whole svn philosophy is to allow for parrallel development, instead of the serialized development imposed by locking based repositories (Visual Source Safe, RCS, etc). I would sugget, instead, to put a BIG WARNING at the top of String.java, indicating that any change must first be approved on [EMAIL PROTECTED] I think that this would accomplish your goal in a more appropriate manner. Etienne Tim Ellison wrote: To ensure that all committers can continue to update String, but that they do so 'knowingly' (i.e. after considering the consequences) I'd like to impose a 'positive action' pre-commit step by setting the "svn:needs-lock" property on String.java. ... If there are no objections I'll go ahead and do this. I'm with Etienne here, *big* -1 on locking. -- Stefano. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [rmi] package comparison (was Re: Contribution of RMI framework)
Zakharov, Vasily M wrote Daniel, We started our development as a clean room implementation of the package following the spec; and we found it -the spec (JRMP included)- to be vague and incomplete making it impossible for us to get interoperability without doing "code inspection" or "reverse engineering", which was not allowed by the imposed clean-room restriction. I believe you faced the same situation, and it will be good to know how you tackle it without compromising your development. Of course, we also followed the clean-room restrictions, but we struggled to be compatible with reference implementation and used a lot of black-box testing to find out what goes on in the reference implementation data exchange. black-box testing (reverse engineering I would call the complete procedure) is an approach, but, can you be sure you are 100% compatible? what about other providers? Having said that, I believe comparision between packages should be done based on functionality and NOT on interoperability since it is -at least- underspecified and it can be acomplished with further wire protocol information. Regretfully, I can't agree with this approach. Our target is providing the end users out there with a free open source Java implementation they can really use in their applications. I completelly agree with you on the ultimate goal; but now I believe we should compare, comparable things... it is clear that "interoperability" is a feature you have worked and acomplished, in the other hand we have worked and acomplished on 5.0; so we should now move on comparing what is comparable between the packages: its functionality. And users generally don't care about quality of specifications what they need is the tool they can take and use, and that will work and satisfy their needs. That's why I think it's very important to not let the poor quality of the specification stop us from giving the community an effective and compatible implementation. I see two different issues here, so I'll comment each: a) end users " And users generally don't care about quality of specifications what they need is the tool they can take and use ..." That is true, but black-box inspecting method is not good enough, I mean, you can provide compatibility with reference implementation (let's say provider A), but what about users working with provider B? or C? are you assuming all providers do the same black-boxing? and if so, all of them arrived to the same conclusion about how the wire protocol behaves? b) the spec "... not let the poor quality of the specification stop us from giving the community an effective and compatible implementation ..." Standards and specifications are what interoperability is all about! there is no way in which you can provide compatibility if there is no standard; so I strongly believe that having a better quality spec is the way we can really benefit the community ... if not, you -and I and other providers too- will always be one step behind the "reference" implementation, spending lots of hours and resources finding out how things are being done inside the black box. If that be the case then we should no longer talk about "specification" for rmi, instead we should talk about rmi as a "product" we try to emulate... Needeless to say, I'm aware of the critical impact interoperability has and we are currently working on that. By the way, one of the very important interoperability issues is the 1.1 protocol version. It's really obsolete, and there's a great temptation to give up on implementing it, but the reference implementation strictly adhers to 1.1 protocol in Distributed Garbage Collection, so we must have 1.1 protocol operational in order to be practically compatible with reference implementation. Yes that's true and there is a big challenge to be 100% compatible supporting different reference implementation's evolutions. BTW: it will be great if you contribute what you have conclude about the protocol. Daniel Vasily Zakharov Intel Middleware Products Division -Original Message- From: Daniel Gandara [mailto:[EMAIL PROTECTED] Sent: Thursday, April 20, 2006 1:17 AM To: harmony-dev@incubator.apache.org Subject: Re: [rmi] package comparison (was Re: Contribution of RMI framework) Vasily, You are not missing anything, our package does not allow interoperability simply because you cannot derive it from the spec. We started our development as a clean room implementation of the package following the spec; and we found it -the spec (JRMP included)- to be vague and incomplete making it impossible for us to get interoperability without doing "code inspection" or "reverse engineering", which was not allowed by the imposed clean-room restriction. I believe you faced the same situation, and it will be good to know how you tackle it without compromising your development. Our strategic decision at that moment was to move forward on the development being sure about the
Re: Contribution of RMI framework
Vasily, I was not looking for public "general" designs of RMI, I do know them very well :) thanks anyway... I asked about specific design docs of your implementation and the architecture behind it; I'm sure you did it in order to "design" the package before coding it, but its ok if you do not have them handy. Daniel - Original Message - From: "Zakharov, Vasily M" <[EMAIL PROTECTED]> To: Sent: Thursday, April 20, 2006 10:46 AM Subject: RE: Contribution of RMI framework Daniel, Regretfully, we have no specific top level design documentation. However, the general design of the RMI package is described rather well in public sources. For example, you could check the "Java RMI: Remote Method Invocation" book by Troy Bryan Downing or Sun's jGuru RMI course at http://java.sun.com/developer/onlineTraining/rmi/RMI.html Vasily -Original Message- From: Daniel Gandara [mailto:[EMAIL PROTECTED] Sent: Thursday, April 20, 2006 1:17 AM To: harmony-dev@incubator.apache.org Subject: Re: Contribution of RMI framework Vasily, I'm reviewing your implementation, I believe there is a lot to learn about other's solution to the same problem :) and I'm wondering if you can send me some top level design documentation about your package. Thanks, Daniel PS: if you happen to need it you can find more info about our design here http://www.itc.unc.edu.ar/javadev/rmi/architecture.html - Original Message - From: "Daniel Gandara" <[EMAIL PROTECTED]> To: Sent: Monday, April 17, 2006 12:05 PM Subject: Re: Contribution of RMI framework I completelly agree with Vasily, doing test and performance analysis on RMI is not a trivial task; I'll coordinate with him the best way to compare the packages. Daniel - Original Message - From: "Zakharov, Vasily M" <[EMAIL PROTECTED]> To: Sent: Friday, April 14, 2006 1:17 PM Subject: RE: Contribution of RMI framework Hi, Mikhail, Regretfully, the method-to-method comparison would hardly be effective with RMI, as it's a highly integrated component. 80% of implementation is hidden in non-public API, and some components (e. g. RMIC) have no public API at all. So it's hard to plug just one public method from one implementation to another without modifying non-public code - and non-public code could have (and probably does have) very different structure in different implementations. What we really can do is try to run both these implementations and compare them for conformance to the specification, compatibility with reference implementation, maybe stability, performance, visual code quality etc. I'm now planning to do some of these, so we'd get some results pretty soon. Vasily -Original Message- From: Mikhail Loenko [mailto:[EMAIL PROTECTED] Sent: Friday, April 14, 2006 7:53 AM To: harmony-dev@incubator.apache.org Subject: Re: Contribution of RMI framework I think we need compare contributions method by method to assemble the best classlib Thanks, Mikhail 2006/4/14, Daniel Gandara <[EMAIL PROTECTED]>: Vasily, good to know that there is someone out there who has also been working on rmi; I believe we'll have a lot to share and discuss about it. Thanks, Daniel - Original Message - From: "Zakharov, Vasily M" <[EMAIL PROTECTED]> To: Sent: Wednesday, April 12, 2006 9:53 PM Subject: Contribution of RMI framework Hi, all, I would like to announce the next code contribution to Harmony project on behalf of Intel corporation. This contribution contains the implementation of RMI framework. The archive with this contribution can be found at: http://issues.apache.org/jira/browse/HARMONY-337 The Remote Method Invocation (RMI) framework enables an object in one virtual machine to call methods of an object in another one, to create applications distributed on various Java virtual machines on the same or different hosts. For more information please see the documentation contained in the bundle. The code is a result of efforts of Intel Middleware Product Division team. One should be able to run this code with a 1.4+ compatible JRE/VM (was tested using commercial VMs). No classes require special support from the VM. All code is pure Java. The implementation is done according to Java 1.4 specification of RMI. The archive contains the README file that explains the building and running process for this code. If any additional comments or clarifications are needed, feel free to contact me. I will be happy to answer all questions about this contribution and to participate in its further development/maintenance and integration into Harmony. Vasily Zakharov Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms
43% of all statistics are totally worthless
To celebrate the opening of my 100th JIRA earlier today, I thought I'd produce some simple statistics - using 138 lines of ugly Perl - for the HARMONY JIRAs. The columns are "key", percentage, count. The letters in the "bars" are the first characters of the "Resolutions" from the first table. Not really sure that they say anything useful, since they only measure quantity not quality. However, one think they certainly do show is just what a brilliant job Tim has been doing keeping up with JIRAs. I shall make sure I buy Tim a beer next time the opportunity arises. Regards, Mark. Now would be a good time to switch to a fixed-width font if you haven't already... Resolution Fixed 67% 256 Unresolved 25% 97 Duplicate 4% 16 ### Invalid 1% 6 # Cannot Reproduce 1% 4 # Won't Fix 0% 3 # Type Bug 55% 212 CFIDDDU Improvement 32% 123 FFFUUU New Feature 9% 38 F Test 1% 5 F Task 0% 3 F Wish 0% 1 Priority Major 48% 186 CIDDU Minor 31% 122 FFIWDDD Trivial 18% 71 FFUU Critical 0% 3 F Status Closed 67% 259 CFFFIDDD Open 25% 96 UUU Resolved 6% 26 In Progress 0% 1 Closed By Week 2006-04-16 13% 36 FFFIIIDD 2006-04-09 9% 24 FW 2006-04-02 8% 23 FIDDD 2006-03-26 12% 32 FD 2006-03-19 3% 8 FFI 2006-03-12 10% 28 CFFF 2006-03-05 6% 17 FFFC 2006-02-26 12% 33 CFFFIW 2006-02-19 2% 7 FD 2006-02-12 5% 13 FFF 2006-02-05 3% 9 F 2006-01-29 1% 5 FFF 2006-01-22 2% 6 F 2006-01-15 2% 7 FF 2005-11-27 1% 4 FF 2005-11-13 0% 1 F 2005-10-30 0% 1 F 2005-10-02 0% 1 F 2005-09-25 0% 2 FFF 2005-06-19 0% 2 FFF Closed By Assignee tellison 62% 161 CFFF mloenko 8% 23 FDDD georgeharley 8% 21 FF smm 7% 19 FF geir 6% 18 FF Unassigned 6% 17 FFIDD Closed By Reporter hindessm 27% 72 FFID richard_liang 11% 29 FFID paulex 10% 26 FFD svetlana 8% 23 CFFF nbeyer 7% 20 FF kdmix 4% 11 FFDD smm 3% 10 FFF sva 3% 9 CFW georgeharley 3% 8 FF vladimir 2% 7 D mloenko 2% 6 tellison 2% 6 t.v.doubtsova 1% 5 odeakin 1% 5 FFFD geir 1% 4 FFF vmz 1% 3 FF zoe 1% 3 FF elena 0% 2 F aavtamon 0% 1 F archie172 0% 1 F v.v.aristova 0% 1 F nikolay 0% 1 W dlydick 0% 1 F jfclere 0% 1 F n.kuznetsov 0% 1 F karan_malhi 0% 1 I theuserbl 0% 1 F struppi 0% 1 F Created By Week 2006-04-16 7% 29 CFDDDUUU 2006-04-09 8% 31 FFF 2006-04-02 8% 33 IWDDD 2006-03-26 9% 37 DUU 2006-03-19 10% 41 IIIDU 2006-03-12 4% 19 FFIU 2006-03-05 6% 23 FFDUU 2006-02-26 10% 39 FFFIW 2006-02-19 7% 28 DUU 2006-02-12 3% 15 CFFIUUU 2006-02-05 3% 12 FFU 2006-01-29 5% 22 CDU 2006-01-22 4% 16 CUUU 2006-01-15 2% 8 WU 2006-01-08 1% 4 F 2005-12-25 0% 2 FFF 2005-12-11 0% 1 F 2005-11-27 1% 4 F 2005-11-20 0% 2 FFF 2005-11-13 0% 2 FFF 2005-11-06 0% 1 F 2005-10-30 0% 3 FFFU 2005-10-23 0% 1 U 2005-10-09 0% 3 2005-09-25 1% 4 F 2005-06-19 0% 1 F 2005-06-12 0% 1 F Create
Re: [classlib] String is special
Geir Magnusson Jr wrote: > 3) Lock down function and behavior tightly with tests - that if > modified, tests will break, and that should raise an alarm to the > committer. One easy way would be to add a test that compares the String.java source code with a saved version, and that fails if unequal. This way, any change will trigger a test failure. To get past this failure, one will have to change both String.java and the saved test version. Just an idea... Etienne -- Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ signature.asc Description: OpenPGP digital signature
ITC's java.math package contribution
Dear all, on behalf of ITC I have updated our contribution of the package java.math including some recent optimizations (HARMONY-199). I think it would be interesting to compare our implementation with the one donated by Intel (HARMONY-39). In order to do that, it would be nice to have a collection of applications were the package is used. So far, we have tried both implementations with a realistic application (RSA key generation) and our implementation turned out to have a significantly better performance. Another point is that we implemented the full 1.5 API functionality, which in the case of BigDecimal amounts to having about twice as many methods as in the 1.4.2 API. This may have little significance now, but it will definitely be important when Harmony moves to 1.5 Our implementation uses 1.5 syntax since the 1.5 API includes an Enum (RoundingMode). It should be easy to obtain a 1.4.2 implementation of the 1.4.2 API from it. Some more information about our development can be found at http://www.fitc.unc.edu.ar/javadev/math/ Daniel Fridlender - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] String is special
Archie Cobbs wrote: Etienne Gagnon wrote: Tim Ellison wrote: Not really. I can add the warning, but I was looking for a way to ensure people did not mistakenly change String or did not read the doc/dev list. By failing people's commit and making them explicitly acquire the token first they have to know what they are doing. So, you should investigate a pre-commit script based approach. For example, you could require a harmony:string-revision property on the String.java file. The pre-commit script would check that any commit increases this revision by one; if not, then an explicit (custom) error message can be given. I kindof agree with Etienne.. it seems like you are preemptively trying to solve a problem that hasn't occurred yet (which is another one of those root-of-all-evil kind of things). Why not just put a warning in String.java, and then, if people turn out to be too hard-headed to heed it, bring in harder enforcement later. As with all open-source projects, if people aren't already being reasonable and communicating in the first place, then we'll have larger problems. While I understand Tim's motivation, and I'm scared of the same thing, I'm also not a fan of this, although I'm tired and want to give it more consideration. The warning won't won't solve the issue that Tim's trying to solve (as I understand it) That someone might *accidentally* patch String, a problem a warning won't help with. It will serve as a useful reminder for those of us that are 'recall challenged' like me. Again, I'll think more, but my first reaction is to 1) Remind people 2) put a warning 3) Lock down function and behavior tightly with tests - that if modified, tests will break, and that should raise an alarm to the committer. Being able to grok and agree to this is a requirement around here, and will be more so in the future. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Summer Of Code 2006 - Lets get Harmony involved
Performance analysis sounds interesting... Any links/pointers to get started? And hey, who was to put the source code tar on the web x-( ? Are you guys posting this project on Summer of code?? Regards, Sanket > -Original Message- > From: Tim Ellison [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 20, 2006 6:58 PM > To: harmony-dev@incubator.apache.org > Subject: Re: Summer Of Code 2006 - Lets get Harmony involved > > Lots of potential projects in the tools area too: > > javadoc is still out there as a juicy project > we discussed a while ago, > > rmic/d/registry, jar, policytool, jconsole, etc. > something for everyone and a good variety of effort > required for these. > > Performance analysis, as broad or narrow as you choose, > > Some well-defined development tasks, such as JNDI providers, PRNG for > validating signed JARs, pack200 algorithm, etc. > > > There is a long list of things we could suggest. > > Regards, > Tim > > Geir Magnusson Jr wrote: > > Google again is running their "Summer Of Code" > > http://code.google.com/summerofcode.html program, and I think it would > > be great for the Harmony project to take advantage of it, assuming we > > can find willing students. > > > > If you are unfamiliar with the program, the goal is to allow computer > > science students to work in their chosen field during the summer while > > at the same time assisting open source organizations and projcets. The > > idea is that students and mentors propose and deliver completed projects > > in open source. For this, the student is paid a stipend. Additionally, > > the mentor receives a small stipend as well. > > > > In our case, the official mentor will be the ASF. > > > > There is an ASF wiki site for this : > > > > http://wiki.apache.org/general/SummerOfCode2006 > > > > Lets agree on projects here first. > > > > Ideas? > > > > geir > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -- > > Tim Ellison ([EMAIL PROTECTED]) > IBM Java technology centre, UK. > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] This email may contain confidential or privileged information for the intended recipient(s) and the views expressed in the same are not necessarily the views of Zensar Technologies Ltd. If you are not the intended recipient or have received this e-mail by error, its use is strictly prohibited, please delete the e-mail and notify the sender. Zensar Technologies Ltd. does not accept any liability for virus infected mails. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] String is special
Etienne Gagnon wrote: Tim Ellison wrote: Not really. I can add the warning, but I was looking for a way to ensure people did not mistakenly change String or did not read the doc/dev list. By failing people's commit and making them explicitly acquire the token first they have to know what they are doing. So, you should investigate a pre-commit script based approach. For example, you could require a harmony:string-revision property on the String.java file. The pre-commit script would check that any commit increases this revision by one; if not, then an explicit (custom) error message can be given. I kindof agree with Etienne.. it seems like you are preemptively trying to solve a problem that hasn't occurred yet (which is another one of those root-of-all-evil kind of things). Why not just put a warning in String.java, and then, if people turn out to be too hard-headed to heed it, bring in harder enforcement later. As with all open-source projects, if people aren't already being reasonable and communicating in the first place, then we'll have larger problems. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Internationalized messages (was: Re: svn commit: r395576 - /incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/RandomAccessFile.java)
Well, the reason is we did not discuss the topic here
2006/4/20, Tim Ellison <[EMAIL PROTECTED]>:
> Is there some reason why you are not using the message catalog for these
> exception messages like we do for others? These are intended to be read
> by users so we want them to the NLS-enabled.
>
> Take a look at Msg.java and ExternalMessages.properties in
> org.apache.harmony.luni.util.
Sure I will. Do they work right now? I've saw test failures with
messages like "K000"
Thanks,
Mikhail
>
> There are examples of their usage in the source file you modified.
>
> Regards,
> Tim
>
> [EMAIL PROTECTED] wrote:
> > Author: mloenko
> > Date: Thu Apr 20 05:46:47 2006
> > New Revision: 395576
> >
> > URL: http://svn.apache.org/viewcvs?rev=395576&view=rev
> > Log:
> > fixes for HARMONY-374
> > java.io.RandomAccessFile.seek(int pos) does not throw IOException if pos < 0
> >
> > Modified:
> >
> > incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/RandomAccessFile.java
> >
> > Modified:
> > incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/RandomAccessFile.java
> > URL:
> > http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/RandomAccessFile.java?rev=395576&r1=395575&r2=395576&view=diff
> > ==
> > ---
> > incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/RandomAccessFile.java
> > (original)
> > +++
> > incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/RandomAccessFile.java
> > Thu Apr 20 05:46:47 2006
> > @@ -614,6 +614,9 @@
> >* occurs.
> >*/
> > public void seek(long pos) throws IOException {
> > +if (pos < 0) {
> > +throw new IOException("seek position is negative");
> > +}
> > openCheck();
> > synchronized (repositionLock) {
> > fileSystem.seek(fd.descriptor, pos, IFileSystem.SEEK_SET);
> >
> >
> >
>
> --
>
> Tim Ellison ([EMAIL PROTECTED])
> IBM Java technology centre, UK.
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] String is special
Tim Ellison wrote: > Yes it does, your commit will fail if I have the lock; but I am abusing > it to achieve a somewhat different goal of 'inadvertent modification'. OK, we both agree on the "abuse" part. ;-P > If we cannot contact the lock holder we simply break/steal the lock. Right. But, locks should only be used for files which require serialized modifications, such as binary blobs. Other commit control should be made through pre-commit scripts. > Not really. I can add the warning, but I was looking for a way to > ensure people did not mistakenly change String or did not read the > doc/dev list. By failing people's commit and making them explicitly > acquire the token first they have to know what they are doing. So, you should investigate a pre-commit script based approach. For example, you could require a harmony:string-revision property on the String.java file. The pre-commit script would check that any commit increases this revision by one; if not, then an explicit (custom) error message can be given. Quite easy to achiev with svnlook, etc. What do you think? Etienne -- Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ signature.asc Description: OpenPGP digital signature
RE: [rmi] package comparison (was Re: Contribution of RMI framework)
Daniel,
> We started our development as a clean room implementation
> of the package following the spec; and we found it -the spec
> (JRMP included)- to be vague and incomplete making it impossible
> for us to get interoperability without doing "code inspection"
> or "reverse engineering", which was not allowed by the imposed
> clean-room restriction. I believe you faced the same situation,
> and it will be good to know how you tackle it without compromising
> your development.
Of course, we also followed the clean-room restrictions, but we
struggled to be compatible with reference implementation and used
a lot of black-box testing to find out what goes on in the reference
implementation data exchange.
> Having said that, I believe comparision between packages should
> be done based on functionality and NOT on interoperability since
> it is -at least- underspecified and it can be acomplished with further
> wire protocol information.
Regretfully, I can't agree with this approach. Our target is providing
the end users out there with a free open source Java implementation
they can really use in their applications. And users generally don't
care about quality of specifications - what they need is the tool
they can take and use, and that will work and satisfy their needs.
That's why I think it's very important to not let the poor quality
of the specification stop us from giving the community an effective
and compatible implementation.
> Needeless to say, I'm aware of the critical impact interoperability
> has and we are currently working on that.
By the way, one of the very important interoperability issues is the
1.1 protocol version. It's really obsolete, and there's a great
temptation
to give up on implementing it, but the reference implementation strictly
adhers to 1.1 protocol in Distributed Garbage Collection, so we must
have 1.1 protocol operational in order to be practically compatible with
reference implementation.
Vasily Zakharov
Intel Middleware Products Division
-Original Message-
From: Daniel Gandara [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 20, 2006 1:17 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [rmi] package comparison (was Re: Contribution of RMI
framework)
Vasily,
You are not missing anything, our package does not allow
interoperability simply because you cannot derive it from the
spec. We started our development as a clean room implementation
of the package following the spec; and we found it -the spec (JRMP
included)- to be vague and incomplete making it impossible for us to
get interoperability without doing "code inspection" or "reverse
engineering", which was not allowed by the imposed clean-room
restriction. I believe you faced the same situation, and it will be
good to know how you tackle it without compromising your development.
Our strategic decision at that moment was to move forward on the
development being sure about the "cleanliness" and left the reverse
engineering of the wire protocol to be done later after the package
is complete. This is the main reasons why I sent the "[rmi] spec
issues"
post presenting the problems we found on the spec; which I believe are
strong enough to ask for a JSR or at least a clarification on the spec.
For a detailed list of the issues we found on the spec please go to
http://www.itc.unc.edu.ar/javadev/rmi/specissues.html .
Having said that, I believe comparision between packages should
be done based on functionality and NOT on interoperability since it
is -at least- underspecified and it can be acomplished with further wire
protocol information. Needeless to say, I'm aware of the critical
impact
interoperability has and we are currently working on that.
Daniel
PS: if you do have further information/description of the JRMP protocol
please send it ot me, since it will be very usefull.
- Original Message -
From: "Zakharov, Vasily M" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, April 18, 2006 2:57 PM
Subject: RE: [rmi] package comparison (was Re: Contribution of RMI
framework)
Daniel,
I've been trying to do some comparisons, as I promised, and I believe
I'm missing something.
I was testing the interoperability, and when I tried to use an "Intel"
RMI client against an "ITC" server, it failed, although it worked
against a "Sun" server. Changing client and server produces the same
result. Here're the stack traces I get, the test code and the config.
Any idea, what I'm
doing wrong?
Vasily Zakharov
Intel Middleware Products Division
Stack trace 1 ("ITC" client, "Sun" or "Intel" server):
java.rmi.ConnectIOException: I/O exception Creating Connection; nested
exception is:
java.rmi.MarshalException: Exception marshaling JRMP Header;
nested exception is:
java.rmi.UnmarshalException: Exception reading the Header
response; nested exception is:
java.io.EOFException
at
ar.org.fitc.rmi.transport.ConnectionPool.getClientConnection(Unknown
Source)
at ar.org.f
RE: Contribution of RMI framework
Daniel, Regretfully, we have no specific top level design documentation. However, the general design of the RMI package is described rather well in public sources. For example, you could check the "Java RMI: Remote Method Invocation" book by Troy Bryan Downing or Sun's jGuru RMI course at http://java.sun.com/developer/onlineTraining/rmi/RMI.html Vasily -Original Message- From: Daniel Gandara [mailto:[EMAIL PROTECTED] Sent: Thursday, April 20, 2006 1:17 AM To: harmony-dev@incubator.apache.org Subject: Re: Contribution of RMI framework Vasily, I'm reviewing your implementation, I believe there is a lot to learn about other's solution to the same problem :) and I'm wondering if you can send me some top level design documentation about your package. Thanks, Daniel PS: if you happen to need it you can find more info about our design here http://www.itc.unc.edu.ar/javadev/rmi/architecture.html - Original Message - From: "Daniel Gandara" <[EMAIL PROTECTED]> To: Sent: Monday, April 17, 2006 12:05 PM Subject: Re: Contribution of RMI framework >I completelly agree with Vasily, doing test and performance analysis > on RMI is not a trivial task; I'll coordinate with him the best way to > compare the packages. > > Daniel > > - Original Message - > From: "Zakharov, Vasily M" <[EMAIL PROTECTED]> > To: > Sent: Friday, April 14, 2006 1:17 PM > Subject: RE: Contribution of RMI framework > > > Hi, Mikhail, > > Regretfully, the method-to-method comparison would hardly be effective > with RMI, as it's a highly integrated component. > > 80% of implementation is hidden in non-public API, and some components > (e. g. RMIC) have no public API at all. So it's hard to plug just one > public method from one implementation to another without modifying > non-public code - and non-public code could have (and probably does > have) very different structure in different implementations. > > What we really can do is try to run both these implementations and > compare them for conformance to the specification, compatibility with > reference implementation, maybe stability, performance, visual code > quality etc. I'm now planning to do some of these, so we'd get some > results pretty soon. > > Vasily > > > -Original Message- > From: Mikhail Loenko [mailto:[EMAIL PROTECTED] > Sent: Friday, April 14, 2006 7:53 AM > To: harmony-dev@incubator.apache.org > Subject: Re: Contribution of RMI framework > > I think we need compare contributions method by method to assemble > the best classlib > > Thanks, > Mikhail > > 2006/4/14, Daniel Gandara <[EMAIL PROTECTED]>: >> Vasily, >>good to know that there is someone out there who has also >> been working on rmi; I believe we'll have a lot to share and discuss >> about it. >> >> Thanks, >> >> Daniel >> >> - Original Message - >> From: "Zakharov, Vasily M" <[EMAIL PROTECTED]> >> To: >> Sent: Wednesday, April 12, 2006 9:53 PM >> Subject: Contribution of RMI framework >> >> >> Hi, all, >> >> I would like to announce the next code contribution to Harmony project >> on >> behalf of Intel corporation. This contribution contains the >> implementation >> of RMI framework. >> >> The archive with this contribution can be found at: >> >> http://issues.apache.org/jira/browse/HARMONY-337 >> >> The Remote Method Invocation (RMI) framework enables an object in one >> virtual machine to call methods of an object in another one, to create >> applications distributed on various Java virtual machines on the same >> or different hosts. >> >> For more information please see the documentation contained in the >> bundle. >> >> The code is a result of efforts of Intel Middleware Product Division >> team. >> One should be able to run this code with a 1.4+ compatible JRE/VM (was >> tested using commercial VMs). No classes require special support from >> the VM. >> All code is pure Java. The implementation is done according to Java > 1.4 >> specification of RMI. >> >> The archive contains the README file that explains the building and >> running >> process for this code. If any additional comments or clarifications > are >> needed, feel free to contact me. I will be happy to answer all > questions >> about this contribution and to participate in its further >> development/maintenance and integration into Harmony. >> >> Vasily Zakharov >> Intel Middleware Product Division >> > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://i
Re: [classlib] String is special
Etienne Gagnon wrote: > Hi Tim, > > I have an objection. Sure, that's why I asked! > Locking has nothing to do with "commit control". Yes it does, your commit will fail if I have the lock; but I am abusing it to achieve a somewhat different goal of 'inadvertent modification'. > Allowing for svn > locking functionality is opening a can of worms. What if somebody > aquires a lock and loses network connectivity for a week (because of a > Hurricane, because he forgot and went on vacation, etc.)? If we cannot contact the lock holder we simply break/steal the lock. I'm not proposing that the lock is used to prevent people from making agreed upon change. > The whole svn > philosophy is to allow for parrallel development, instead of the > serialized development imposed by locking based repositories (Visual > Source Safe, RCS, etc). I know. > I would sugget, instead, to put a BIG WARNING at the top of String.java, > indicating that any change must first be approved on [EMAIL PROTECTED] I > think that this would accomplish your goal in a more appropriate manner. Not really. I can add the warning, but I was looking for a way to ensure people did not mistakenly change String or did not read the doc/dev list. By failing people's commit and making them explicitly acquire the token first they have to know what they are doing. If people think that committers will remember to do the right thing then I'm fine with that. Unfortunately it hasn't happened to date and String has only been in LUNI for two weeks. Regards, Tim > Etienne > > Tim Ellison wrote: >> To ensure that all committers can continue to update String, but that >> they do so 'knowingly' (i.e. after considering the consequences) I'd >> like to impose a 'positive action' pre-commit step by setting the >> "svn:needs-lock" property on String.java. >> ... >> If there are no objections I'll go ahead and do this. > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Internationalized messages (was: Re: svn commit: r395576 - /incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/RandomAccessFile.java)
Is there some reason why you are not using the message catalog for these
exception messages like we do for others? These are intended to be read
by users so we want them to the NLS-enabled.
Take a look at Msg.java and ExternalMessages.properties in
org.apache.harmony.luni.util.
There are examples of their usage in the source file you modified.
Regards,
Tim
[EMAIL PROTECTED] wrote:
> Author: mloenko
> Date: Thu Apr 20 05:46:47 2006
> New Revision: 395576
>
> URL: http://svn.apache.org/viewcvs?rev=395576&view=rev
> Log:
> fixes for HARMONY-374
> java.io.RandomAccessFile.seek(int pos) does not throw IOException if pos < 0
>
> Modified:
>
> incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/RandomAccessFile.java
>
> Modified:
> incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/RandomAccessFile.java
> URL:
> http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/RandomAccessFile.java?rev=395576&r1=395575&r2=395576&view=diff
> ==
> ---
> incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/RandomAccessFile.java
> (original)
> +++
> incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/io/RandomAccessFile.java
> Thu Apr 20 05:46:47 2006
> @@ -614,6 +614,9 @@
>* occurs.
>*/
> public void seek(long pos) throws IOException {
> +if (pos < 0) {
> +throw new IOException("seek position is negative");
> +}
> openCheck();
> synchronized (repositionLock) {
> fileSystem.seek(fd.descriptor, pos, IFileSystem.SEEK_SET);
>
>
>
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Summer Of Code 2006 - Lets get Harmony involved
Lots of potential projects in the tools area too: javadoc is still out there as a juicy project we discussed a while ago, rmic/d/registry, jar, policytool, jconsole, etc. something for everyone and a good variety of effort required for these. Performance analysis, as broad or narrow as you choose, Some well-defined development tasks, such as JNDI providers, PRNG for validating signed JARs, pack200 algorithm, etc. There is a long list of things we could suggest. Regards, Tim Geir Magnusson Jr wrote: > Google again is running their "Summer Of Code" > http://code.google.com/summerofcode.html program, and I think it would > be great for the Harmony project to take advantage of it, assuming we > can find willing students. > > If you are unfamiliar with the program, the goal is to allow computer > science students to work in their chosen field during the summer while > at the same time assisting open source organizations and projcets. The > idea is that students and mentors propose and deliver completed projects > in open source. For this, the student is paid a stipend. Additionally, > the mentor receives a small stipend as well. > > In our case, the official mentor will be the ASF. > > There is an ASF wiki site for this : > > http://wiki.apache.org/general/SummerOfCode2006 > > Lets agree on projects here first. > > Ideas? > > geir > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] String is special
Hi Tim, I have an objection. Locking has nothing to do with "commit control". Allowing for svn locking functionality is opening a can of worms. What if somebody aquires a lock and loses network connectivity for a week (because of a Hurricane, because he forgot and went on vacation, etc.)? The whole svn philosophy is to allow for parrallel development, instead of the serialized development imposed by locking based repositories (Visual Source Safe, RCS, etc). I would sugget, instead, to put a BIG WARNING at the top of String.java, indicating that any change must first be approved on [EMAIL PROTECTED] I think that this would accomplish your goal in a more appropriate manner. Etienne Tim Ellison wrote: > To ensure that all committers can continue to update String, but that > they do so 'knowingly' (i.e. after considering the consequences) I'd > like to impose a 'positive action' pre-commit step by setting the > "svn:needs-lock" property on String.java. >... > If there are no objections I'll go ahead and do this. -- Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ signature.asc Description: OpenPGP digital signature
[classlib] String is special
You'll recall a while ago when we were discussing moving j.l.String out from KERNEL to LUNI [1] that the shape of String is something we would expect VMs & JITs to be sensitive to (like all our KERNEL classes), but that there is significant shared behavior that it is worth sharing (which is why we moved it into LUNI). I suggested that we could deal with this by ensuring changes to String were closely monitored, and any such changes agreed on the list first (thereby acquiring a 'golden ticket'). There have been a few changes to String recently (I have reviewed them, and they look benign) but I'd like to reiterate that call. To ensure that all committers can continue to update String, but that they do so 'knowingly' (i.e. after considering the consequences) I'd like to impose a 'positive action' pre-commit step by setting the "svn:needs-lock" property on String.java. That will ensure that committers do not inadvertently (despite their thorough diff review) apply a patch that modifies String.java. The extra step required would simply be to acquire a lock on String.java first and that should be enough to remind people that they are modifying this class. (This is for my benefit as much as anyone else's) If there are no objections I'll go ahead and do this. Regards, Tim [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/[EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r395541 - /incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml
But doesn't work for me. -Stepan On 4/20/06, Mark Hindess wrote: > > Without the classpath modifications then it works for me on linux. > -Mark. > > > On 4/20/06, Stepan Mishura <[EMAIL PROTECTED]> wrote: > > On 4/20/06, Mark Hindess wrote: > > > > > > Stepan, > > > > > > In your original commit for HARMONY-315, you made this change: > > > > > > > > > > > > > > > > > > I'm not sure how this relates to this JIRA > > > > > > Right, it was better to separate updates. > > > > but it is this that breaks > > > the test. Why not remove/fix this unrelated change rather than > > > comment out the otherwise working test? > > > > > > It is not quite correct. The tests passes on Windows but fails on Linux > - > > I'm going to investigate the difference. But if I remove these lines > then it > > will fail on Windows too. > > > > IMHO, we should avoid making unrelated changes in a single commit. > > > > > > Agreed. > > > > Thanks, > > Stepan. > > > > Regards, > > > Mark. > > > > > > On 4/20/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > Author: smishura > > > > Date: Thu Apr 20 02:05:28 2006 > > > > New Revision: 395541 > > > > > > > > URL: http://svn.apache.org/viewcvs?rev=395541&view=rev > > > > Log: > > > > tests/api/javax/crypto/CipherTest.java back to exclude test to make > test > > > suite pass on Linux > > > > > > > > Modified: > > > > > > > > incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml > > > > > > > > Modified: > > > > incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml > > > > URL: > > > > http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml?rev=395541&r1=395540&r2=395541&view=diff > > > > > > > > == > > > > --- > > > > incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml > > > (original) > > > > +++ > > > > incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml > > > Thu Apr 20 02:05:28 2006 > > > > @@ -118,6 +118,9 @@ > > > > haltonfailure="no"> > > > > > > > > > > > > + > > > > + > > > > + > > name="tests/api/javax/crypto/CipherTest.java"/> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Mark Hindess <[EMAIL PROTECTED]> > > > IBM Java Technology Centre, UK. > > > > > > - > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > Thanks, > > Stepan Mishura > > Intel Middleware Products Division > > > > -- > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Mark Hindess <[EMAIL PROTECTED]> > IBM Java Technology Centre, UK. > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Thanks, Stepan Mishura Intel Middleware Products Division -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r395541 - /incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml
Without the classpath modifications then it works for me on linux. -Mark. On 4/20/06, Stepan Mishura <[EMAIL PROTECTED]> wrote: > On 4/20/06, Mark Hindess wrote: > > > > Stepan, > > > > In your original commit for HARMONY-315, you made this change: > > > > > > > > > > > > I'm not sure how this relates to this JIRA > > > Right, it was better to separate updates. > > but it is this that breaks > > the test. Why not remove/fix this unrelated change rather than > > comment out the otherwise working test? > > > It is not quite correct. The tests passes on Windows but fails on Linux - > I'm going to investigate the difference. But if I remove these lines then it > will fail on Windows too. > > IMHO, we should avoid making unrelated changes in a single commit. > > > Agreed. > > Thanks, > Stepan. > > Regards, > > Mark. > > > > On 4/20/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > Author: smishura > > > Date: Thu Apr 20 02:05:28 2006 > > > New Revision: 395541 > > > > > > URL: http://svn.apache.org/viewcvs?rev=395541&view=rev > > > Log: > > > tests/api/javax/crypto/CipherTest.java back to exclude test to make test > > suite pass on Linux > > > > > > Modified: > > > > > incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml > > > > > > Modified: > > incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml > > > URL: > > http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml?rev=395541&r1=395540&r2=395541&view=diff > > > > > == > > > --- > > incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml > > (original) > > > +++ > > incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml > > Thu Apr 20 02:05:28 2006 > > > @@ -118,6 +118,9 @@ > > > > > > > > > > > > + > > > + > > > + > name="tests/api/javax/crypto/CipherTest.java"/> > > > > > > > > > > > > > > > > > > > > > > > > -- > > Mark Hindess <[EMAIL PROTECTED]> > > IBM Java Technology Centre, UK. > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Thanks, > Stepan Mishura > Intel Middleware Products Division > > -- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Mark Hindess <[EMAIL PROTECTED]> IBM Java Technology Centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: duplicate tests (was: RE: svn commit: r395188 - in /incuba...)
OK, I'll remove duplicate tests then
Thanks,
Mikhail
2006/4/20, Stepan Mishura <[EMAIL PROTECTED]>:
> IMHO, we should avoid creating duplicate tests. I guess that in this case
> the second test was created just only mark that we tested both methods
> (readBoolean and writeBoolean).
>
> I think that if there is no unique (different from other scenarios used to
> check class implementation) testing scenario for a class's method then we
> should mark that the method was tested with others methods. For example, for
> our case:
>
> /**
> * @tests java.io.RandomAccessFile#readBoolean()
> * @tests java.io.RandomAccessFile#writeBoolean()
> */
> public void test_readBoolean_AND_writeBoolean() throws IOException {
>// Test for method boolean java.io.RandomAccessFile.readBoolean()
>RandomAccessFile raf = new java.io.RandomAccessFile(fileName, "rw");
>raf.writeBoolean(true);
>raf.seek(0);
>assertTrue("Incorrect boolean read/written", raf.readBoolean());
>raf.close();
> }
>
> Thanks,
> Stepan.
>
> On 4/19/06, Mikhail Loenko wrote:
> >
> > Hello
> >
> > I've added a couple of regression tests to
> > test/java/tests/api/java/io/RandomAccessFileTest.java
> > and a bit reorganized remaining tests to get them close to conventions
> > we discussed somewhere here recently.
> >
> > I've noticed that there are tests that are looking very similar, for
> > example:
> >
> > /**
> > * @tests java.io.RandomAccessFile#readBoolean()
> > */
> > public void test_readBoolean() throws IOException {
> >// Test for method boolean java.io.RandomAccessFile.readBoolean()
> >RandomAccessFile raf = new java.io.RandomAccessFile(fileName, "rw");
> >raf.writeBoolean(true);
> >raf.seek(0);
> >assertTrue("Incorrect boolean read/written", raf.readBoolean());
> >raf.close();
> > }
> >
> > and
> >
> >
> > /**
> > * @tests java.io.RandomAccessFile#writeBoolean(boolean)
> > */
> > public void test_writeBooleanZ() throws IOException {
> >// Test for method void java.io.RandomAccessFile.writeBoolean(boolean)
> >RandomAccessFile raf = new java.io.RandomAccessFile(fileName, "rw");
> >raf.writeBoolean(true);
> >raf.seek(0);
> >assertTrue("Incorrect boolean read/written", raf.readBoolean());
> >raf.close();
> > }
> >
> > I understand that in general we might have couples of equivalent tests
> > that
> > designed to test different scenarios (because when we change one of those
> > tests
> > the second one still cover the second scenario...), but do we need this
> > kind of
> > duplication here?
> >
> > Thanks,
> > Mikhail
> >
> > -
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> ---
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
>
>
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r395541 - /incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml
On 4/20/06, Mark Hindess wrote: > > Stepan, > > In your original commit for HARMONY-315, you made this change: > > > > > > I'm not sure how this relates to this JIRA Right, it was better to separate updates. but it is this that breaks > the test. Why not remove/fix this unrelated change rather than > comment out the otherwise working test? It is not quite correct. The tests passes on Windows but fails on Linux - I'm going to investigate the difference. But if I remove these lines then it will fail on Windows too. IMHO, we should avoid making unrelated changes in a single commit. Agreed. Thanks, Stepan. Regards, > Mark. > > On 4/20/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Author: smishura > > Date: Thu Apr 20 02:05:28 2006 > > New Revision: 395541 > > > > URL: http://svn.apache.org/viewcvs?rev=395541&view=rev > > Log: > > tests/api/javax/crypto/CipherTest.java back to exclude test to make test > suite pass on Linux > > > > Modified: > > > incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml > > > > Modified: > incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml > > URL: > http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml?rev=395541&r1=395540&r2=395541&view=diff > > > == > > --- > incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml > (original) > > +++ > incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml > Thu Apr 20 02:05:28 2006 > > @@ -118,6 +118,9 @@ > > > > > > > > + > > + > > + name="tests/api/javax/crypto/CipherTest.java"/> > > > > > > > > > > > > > > > -- > Mark Hindess <[EMAIL PROTECTED]> > IBM Java Technology Centre, UK. > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Thanks, Stepan Mishura Intel Middleware Products Division -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Copying resource files - what for?
On 4/20/06, George Harley wrote: > Stepan Mishura wrote: > > On 4/20/06, George Harley wrote: > > > >> Hi Stepan, > >> > >> As I recall it ( I've not my morning coffee yet so it could get a bit > >> unreliable here :-) ) the motivation for wanting resource files on the > >> classpath was to enable serialization data files to be read in by test > >> programs without depending on specific file locations. Copying such > >> serialization data files to a bin location prior to running the tests > >> obviously gets them on the classpath in a very simple way. > >> > > > > > > Yes, but we get the same if we just add resource directory to classpath > - > > that is simpler then copying. > > > > Hi Stepan, > > You are saying that the source folder containing the resources should be > added as an extra classpath entry when running the tests. Yes. > I prefer only > having "output folders" (e.g. bin folders) on the classpath so I copy > the resources across. Both approaches seem fine to me. At least one > popular Java IDE gives developers the option to send compiler output to > either the source directory or to a separate output folder. I just tried to understand why you choose "copying apporoach". What are reasons to copy resource files instead of "adding extra classpath entry"? > > The documentation for the Ant copy task states that that "files are only > > > >> copied if the source file is newer than the destination file". I > >> interpret that as meaning that we should not expect to see the copying > >> of thousands of files each time we run the tests. > >> > > > > > > But the build removes 'bin' directory during clean up so all copied > resource > > files are removed too. > > > > What bin directory do you mean here ? /bin/main and /bin/test Thanks, Stepan. > > Thanks, > > Stepan. > > > > Best regards, > > > >> George > >> > >> Stepan Mishura wrote: > >> > >>> Hi George, > >>> > >>> Some time ago we agreed to copy resource files to classpath (i.e. > >>> > >> bin/test > >> > >>> directory). I saw that you added corresponing targets to build files. > >>> > >> But > >> > >>> now I realized that I don't understand why we should copy them instead > >>> > >> of > >> > >>> simply adding resource directory (i.e. src/test/resources) to > classpath. > >>> > >> May > >> > >>> be there are simple reasons to do this that I don't know but anyway > ... > >>> > >> so > >> > >>> why we have to copy thousands of files (there is no doubt that in > future > >>> > >> we > >> > >>> will have thousands of resource files) each time we run tests? > >>> Thanks, > >>> Stepan Mishura > >>> Intel Middleware Products Division > >>> --- > >>> Terms of use : http://incubator.apache.org/harmony/mailing.html > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >>> > >> - > >> Terms of use : http://incubator.apache.org/harmony/mailing.html > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > >> > > > > > > -- > > Thanks, > > Stepan Mishura > > Intel Middleware Products Division > > > > -- > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Thanks, Stepan Mishura Intel Middleware Products Division -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Classpath setting for Eclipse(was Re: [jira] Resolved: (HARMONY-349) The currency field of DecimalFormatSymbols is not deserialized properly)
George Harley wrote:
Paulex Yang wrote:
George Harley wrote:
Hi Paulex,
I pressed "send" a bit too soon there. This is the sort of classpath
set up I was referring to in the previous message. Please note the
bottom "classpathentry" element which I think specifies the default
output folder for a project.
path="src/test/resources"/>
path="src/main/resources"/>
I pressed too soon, too;)
It's exactly what my .classpath now looks like, it works well for me.
That's great ! I'll move to close out the JIRA issues related to this
now (that's 334, 338 and 339).
Well, how about update all the .classpath in SVN, too? ;-)
Best regards,
George
Please let us know how it goes.
Best regards,
George
George Harley wrote:
Paulex Yang wrote:
Well, George, you caught me;)
I tried your solution on TEXT module at first, but for some
unknown reasons, Eclipse refused to compile according to the
modification and outputs:
"Cannot nest output folder 'text/bin/main' inside output folder
'text/bin' "
Hi Paulex,
Just a hunch, but is "text/bin" the default output folder for your
Eclipse project ? If so then could you change that default value to
be "text/bin/main" and see if the Eclipse compile error is still
there ?
Thanks,
George
I have no idea what happened, so I took a shortcut to walk
around. My environment is Eclipse 3.2 M5 on WinXP
If this issue can be resolved, I'm fine to output them directly to
existing bin/test directory.
George Harley wrote:
Hi Paulex,
Adding new Eclipse source folders to a module to cater for the
resources sounds good to me, but I don't understand the need to
have their output go to new sub-folders under bin. Why not just
have test resources go under the existing bin/test and main
resources go under bin/main like this ...
path="src/test/resources"/>
path="src/main/resources"/>
Best regards,
George
Paulex Yang wrote:
Recently we have agreed to put the serialization data file to
the /test/resources/serialization directory, but which
requires Eclipse user additional setting to run serialization
tests. To handle this issue, I propose to add the following
lines to .classpath file of each module as below, so that the
files in resources directory can be built into default
classpath. Comments?
path="src/test/resources"/>
path="src/main/resources"/>
George Harley (JIRA) wrote:
[ http://issues.apache.org/jira/browse/HARMONY-349?page=all ]
George Harley resolved HARMONY-349:
---
Resolution: Fixed
Hi Paulex,
Changes committed in revision 395251. I made a couple of
modifications to the supplied test case to enable it to load
the .ser file from the system classloader. In addition I put
the .ser into the
modules/text/src/test/resources/serialization/java/text
location and updated the build.xml with a new
copy.test.resources target so that this .ser file (and
eventually others like it) make it onto the runtime classpath.
Please could you confirm if this version of your patch has been
applied to your satisfaction.
Thanks for this enhancement, George
The currency field of DecimalFormatSymbols is not
deserialized properly
Key: HARMONY-349
URL: http://issues.apache.org/jira/browse/HARMONY-349
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Paulex Yang
Assignee: George Harley
Attachments: 02.JIRA349_text.zip
According to the serialized form of DecimalFormatSymbols, the
DecimalFormatSymbols itself should be responsible for
initializing the currency from the intlCurrencySymbol field.
But Harmony only leave it as null. The following test case
reproduces this bug:
public void test_serialization() {
DecimalFormatSymbols symbols = new
DecimalFormatSymbols(Locale.FRANCE);
Currency currency = symbols.getCurrency();
assertNotNull(currency);
try {
// serialize
ByteArrayOutputStream byteOStream = new
ByteArrayOutputStream();
ObjectOutputStream objectOStream = new
ObjectOutputStream(
byteOStream);
objectOStream.writeObject(symbols);
// and deserialize
ObjectInputStream objectIStream = new
ObjectInputStream(
new
ByteArrayInputStream(byteOStream.toByteArray()));
DecimalFormatSymbols symbolsD =
(DecimalFormatSymbols) objectIStream
.readObject();
// The associated currency will not
persist
currency = symbolsD.getCurrency();
} catch (Exception e1) {
fail("Errors occur during serialization");
}
try {
assertNotNull(currency);
} catch (Exception e) {
fail("currency should not be null");
}
}
Pass on RI(Sun JDK1.5.0_06)
Rail on Harmony
RE: Summer Of Code 2006 - Lets get Harmony involved
Hi.. I spent some time looking for open projects.. I would prefer contributing to VM /Compiler code..but I'm open to any other suggestions... Can you guys please suggest something ??? Regards, Sanket > -Original Message- > From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 18, 2006 9:08 PM > To: harmony-dev@incubator.apache.org > Subject: Re: Summer Of Code 2006 - Lets get Harmony involved > > Excellent! Now we need a project. Have anything you'd like to propose? >What interests you? > > geir > > > Sanket Sharma wrote: > > Hey... > > > > I'm a final sem student doing my internship > > > > Get me in.. I wann get involved with harmony! > > > > > > Awaiting reply, > > Sanket > >> -Original Message- > >> From: Archie Cobbs [mailto:[EMAIL PROTECTED] > >> Sent: Tuesday, April 18, 2006 7:50 PM > >> To: harmony-dev@incubator.apache.org > >> Subject: Re: Summer Of Code 2006 - Lets get Harmony involved > >> > >> Geir Magnusson Jr wrote: > >>> Google again is running their "Summer Of Code" > >>> http://code.google.com/summerofcode.html program, and I think it would > >>> be great for the Harmony project to take advantage of it, assuming we > >>> can find willing students. > >>> ... > >>> Lets agree on projects here first. > >> Great idea.. certainly one project that seems suitable is completing > >> the gnuclasspathadapter stuff started by Weldon. > >> > >> -Archie > >> > >> > __ > >> Archie Cobbs *CTO, Awarix* > http://www.awarix.com > >> > >> - > >> Terms of use : http://incubator.apache.org/harmony/mailing.html > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > This email may contain confidential or privileged information for the > > intended recipient(s) and the views expressed in the same are not > > necessarily the views of Zensar Technologies Ltd. If you are not the > intended > > recipient or have received this e-mail by error, its use is strictly > > prohibited, please delete the e-mail and notify the sender. Zensar > > Technologies Ltd. does not accept any liability for virus infected > mails. > > > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Copying resource files - what for?
I think it is rather dangerous way: some people will test when resources are in src/ while others - when they are moved to bin by tar or something else So if we want to have a single binary image we have to create it first (by copying resources) Thanks, Mikhail 2006/4/20, Mark Hindess <[EMAIL PROTECTED]>: > I suspect inclusion of the resource files (with path renaming) could > be handled by a zip/tar task rather than by copying every time the > tests are run. So I don't think this is a good reason. > > Regards, > Mark. > > On 4/20/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > I can see one reason to copy resources - if we want to produce > > a single downloadable binary image of the test suite. > > > > Other than that it does not make much sense to me. > > > > The image might be usefull for kind of regular QA cycles later. > > > > Thanks, > > Mikhail > > > > 2006/4/20, Paulex Yang <[EMAIL PROTECTED]>: > > > Stepan > > > > > > +1. > > > > > > I just proposed similar modification to classpath of each modules in > > > another thread, which will make the IDE(Eclipse at least) user easier to > > > run test. > > > > > > Stepan Mishura wrote: > > > > Hi George, > > > > > > > > Some time ago we agreed to copy resource files to classpath (i.e. > > > > bin/test > > > > directory). I saw that you added corresponing targets to build files. > > > > But > > > > now I realized that I don't understand why we should copy them instead > > > > of > > > > simply adding resource directory (i.e. src/test/resources) to > > > > classpath. May > > > > be there are simple reasons to do this that I don't know but anyway ... > > > > so > > > > why we have to copy thousands of files (there is no doubt that in > > > > future we > > > > will have thousands of resource files) each time we run tests? > > > > Thanks, > > > > Stepan Mishura > > > > Intel Middleware Products Division > > > > --- > > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > -- > > > Paulex Yang > > > China Software Development Lab > > > IBM > > > > > > > > > > > > - > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Mark Hindess <[EMAIL PROTECTED]> > IBM Java Technology Centre, UK. > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Classpath setting for Eclipse(was Re: [jira] Resolved: (HARMONY-349) The currency field of DecimalFormatSymbols is not deserialized properly)
Paulex Yang wrote:
George Harley wrote:
Hi Paulex,
I pressed "send" a bit too soon there. This is the sort of classpath
set up I was referring to in the previous message. Please note the
bottom "classpathentry" element which I think specifies the default
output folder for a project.
path="src/test/resources"/>
path="src/main/resources"/>
I pressed too soon, too;)
It's exactly what my .classpath now looks like, it works well for me.
That's great ! I'll move to close out the JIRA issues related to this
now (that's 334, 338 and 339).
Best regards,
George
Please let us know how it goes.
Best regards,
George
George Harley wrote:
Paulex Yang wrote:
Well, George, you caught me;)
I tried your solution on TEXT module at first, but for some unknown
reasons, Eclipse refused to compile according to the modification
and outputs:
"Cannot nest output folder 'text/bin/main' inside output folder
'text/bin' "
Hi Paulex,
Just a hunch, but is "text/bin" the default output folder for your
Eclipse project ? If so then could you change that default value to
be "text/bin/main" and see if the Eclipse compile error is still
there ?
Thanks,
George
I have no idea what happened, so I took a shortcut to walk around.
My environment is Eclipse 3.2 M5 on WinXP
If this issue can be resolved, I'm fine to output them directly to
existing bin/test directory.
George Harley wrote:
Hi Paulex,
Adding new Eclipse source folders to a module to cater for the
resources sounds good to me, but I don't understand the need to
have their output go to new sub-folders under bin. Why not just
have test resources go under the existing bin/test and main
resources go under bin/main like this ...
path="src/test/resources"/>
path="src/main/resources"/>
Best regards,
George
Paulex Yang wrote:
Recently we have agreed to put the serialization data file to the
/test/resources/serialization directory, but which
requires Eclipse user additional setting to run serialization
tests. To handle this issue, I propose to add the following lines
to .classpath file of each module as below, so that the files in
resources directory can be built into default classpath. Comments?
path="src/test/resources"/>
path="src/main/resources"/>
George Harley (JIRA) wrote:
[ http://issues.apache.org/jira/browse/HARMONY-349?page=all ]
George Harley resolved HARMONY-349:
---
Resolution: Fixed
Hi Paulex,
Changes committed in revision 395251. I made a couple of
modifications to the supplied test case to enable it to load the
.ser file from the system classloader. In addition I put the
.ser into the
modules/text/src/test/resources/serialization/java/text location
and updated the build.xml with a new copy.test.resources target
so that this .ser file (and eventually others like it) make it
onto the runtime classpath.
Please could you confirm if this version of your patch has been
applied to your satisfaction.
Thanks for this enhancement, George
The currency field of DecimalFormatSymbols is not deserialized
properly
Key: HARMONY-349
URL: http://issues.apache.org/jira/browse/HARMONY-349
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Paulex Yang
Assignee: George Harley
Attachments: 02.JIRA349_text.zip
According to the serialized form of DecimalFormatSymbols, the
DecimalFormatSymbols itself should be responsible for
initializing the currency from the intlCurrencySymbol field.
But Harmony only leave it as null. The following test case
reproduces this bug:
public void test_serialization() {
DecimalFormatSymbols symbols = new
DecimalFormatSymbols(Locale.FRANCE);
Currency currency = symbols.getCurrency();
assertNotNull(currency);
try {
// serialize
ByteArrayOutputStream byteOStream = new
ByteArrayOutputStream();
ObjectOutputStream objectOStream = new
ObjectOutputStream(
byteOStream);
objectOStream.writeObject(symbols);
// and deserialize
ObjectInputStream objectIStream = new
ObjectInputStream(
new
ByteArrayInputStream(byteOStream.toByteArray()));
DecimalFormatSymbols symbolsD =
(DecimalFormatSymbols) objectIStream
.readObject();
// The associated currency will not persist
currency = symbolsD.getCurrency();
} catch (Exception e1) {
fail("Errors occur during serialization");
}
try {
assertNotNull(currency);
} catch (Exception e) {
fail("currency should not be null");
}
}
Pass on RI(Sun JDK1.5.0_06)
Rail on Harmony
-
Terms of
Re: Copying resource files - what for?
Stepan Mishura wrote: On 4/20/06, George Harley wrote: Hi Stepan, As I recall it ( I've not my morning coffee yet so it could get a bit unreliable here :-) ) the motivation for wanting resource files on the classpath was to enable serialization data files to be read in by test programs without depending on specific file locations. Copying such serialization data files to a bin location prior to running the tests obviously gets them on the classpath in a very simple way. Yes, but we get the same if we just add resource directory to classpath - that is simpler then copying. Hi Stepan, You are saying that the source folder containing the resources should be added as an extra classpath entry when running the tests. I prefer only having "output folders" (e.g. bin folders) on the classpath so I copy the resources across. Both approaches seem fine to me. At least one popular Java IDE gives developers the option to send compiler output to either the source directory or to a separate output folder. The documentation for the Ant copy task states that that "files are only copied if the source file is newer than the destination file". I interpret that as meaning that we should not expect to see the copying of thousands of files each time we run the tests. But the build removes 'bin' directory during clean up so all copied resource files are removed too. What bin directory do you mean here ? Thanks, Stepan. Best regards, George Stepan Mishura wrote: Hi George, Some time ago we agreed to copy resource files to classpath (i.e. bin/test directory). I saw that you added corresponing targets to build files. But now I realized that I don't understand why we should copy them instead of simply adding resource directory (i.e. src/test/resources) to classpath. May be there are simple reasons to do this that I don't know but anyway ... so why we have to copy thousands of files (there is no doubt that in future we will have thousands of resource files) each time we run tests? Thanks, Stepan Mishura Intel Middleware Products Division --- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Thanks, Stepan Mishura Intel Middleware Products Division -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Classpath setting for Eclipse(was Re: [jira] Resolved: (HARMONY-349) The currency field of DecimalFormatSymbols is not deserialized properly)
George Harley wrote:
Hi Paulex,
I pressed "send" a bit too soon there. This is the sort of classpath
set up I was referring to in the previous message. Please note the
bottom "classpathentry" element which I think specifies the default
output folder for a project.
path="src/test/resources"/>
path="src/main/resources"/>
I pressed too soon, too;)
It's exactly what my .classpath now looks like, it works well for me.
Please let us know how it goes.
Best regards,
George
George Harley wrote:
Paulex Yang wrote:
Well, George, you caught me;)
I tried your solution on TEXT module at first, but for some unknown
reasons, Eclipse refused to compile according to the modification
and outputs:
"Cannot nest output folder 'text/bin/main' inside output folder
'text/bin' "
Hi Paulex,
Just a hunch, but is "text/bin" the default output folder for your
Eclipse project ? If so then could you change that default value to
be "text/bin/main" and see if the Eclipse compile error is still there ?
Thanks,
George
I have no idea what happened, so I took a shortcut to walk around.
My environment is Eclipse 3.2 M5 on WinXP
If this issue can be resolved, I'm fine to output them directly to
existing bin/test directory.
George Harley wrote:
Hi Paulex,
Adding new Eclipse source folders to a module to cater for the
resources sounds good to me, but I don't understand the need to
have their output go to new sub-folders under bin. Why not just
have test resources go under the existing bin/test and main
resources go under bin/main like this ...
path="src/test/resources"/>
path="src/main/resources"/>
Best regards,
George
Paulex Yang wrote:
Recently we have agreed to put the serialization data file to the
/test/resources/serialization directory, but which
requires Eclipse user additional setting to run serialization
tests. To handle this issue, I propose to add the following lines
to .classpath file of each module as below, so that the files in
resources directory can be built into default classpath. Comments?
path="src/test/resources"/>
path="src/main/resources"/>
George Harley (JIRA) wrote:
[ http://issues.apache.org/jira/browse/HARMONY-349?page=all ]
George Harley resolved HARMONY-349:
---
Resolution: Fixed
Hi Paulex,
Changes committed in revision 395251. I made a couple of
modifications to the supplied test case to enable it to load the
.ser file from the system classloader. In addition I put the .ser
into the modules/text/src/test/resources/serialization/java/text
location and updated the build.xml with a new copy.test.resources
target so that this .ser file (and eventually others like it)
make it onto the runtime classpath.
Please could you confirm if this version of your patch has been
applied to your satisfaction.
Thanks for this enhancement, George
The currency field of DecimalFormatSymbols is not deserialized
properly
Key: HARMONY-349
URL: http://issues.apache.org/jira/browse/HARMONY-349
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Paulex Yang
Assignee: George Harley
Attachments: 02.JIRA349_text.zip
According to the serialized form of DecimalFormatSymbols, the
DecimalFormatSymbols itself should be responsible for
initializing the currency from the intlCurrencySymbol field. But
Harmony only leave it as null. The following test case
reproduces this bug:
public void test_serialization() {
DecimalFormatSymbols symbols = new
DecimalFormatSymbols(Locale.FRANCE);
Currency currency = symbols.getCurrency();
assertNotNull(currency);
try {
// serialize
ByteArrayOutputStream byteOStream = new
ByteArrayOutputStream();
ObjectOutputStream objectOStream = new
ObjectOutputStream(
byteOStream);
objectOStream.writeObject(symbols);
// and deserialize
ObjectInputStream objectIStream = new
ObjectInputStream(
new
ByteArrayInputStream(byteOStream.toByteArray()));
DecimalFormatSymbols symbolsD =
(DecimalFormatSymbols) objectIStream
.readObject();
// The associated currency will not persist
currency = symbolsD.getCurrency();
} catch (Exception e1) {
fail("Errors occur during serialization");
}
try {
assertNotNull(currency);
} catch (Exception e) {
fail("currency should not be null");
}
}
Pass on RI(Sun JDK1.5.0_06)
Rail on Harmony
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Classpath setting for Eclipse(was Re: [jira] Resolved: (HARMONY-349) The currency field of DecimalFormatSymbols is not deserialized properly)
Great, it works!
I modified the line below of the .classpath
to
And now it is OK.
George Harley wrote:
Paulex Yang wrote:
Well, George, you caught me;)
I tried your solution on TEXT module at first, but for some unknown
reasons, Eclipse refused to compile according to the modification and
outputs:
"Cannot nest output folder 'text/bin/main' inside output folder
'text/bin' "
Hi Paulex,
Just a hunch, but is "text/bin" the default output folder for your
Eclipse project ? If so then could you change that default value to be
"text/bin/main" and see if the Eclipse compile error is still there ?
Thanks,
George
I have no idea what happened, so I took a shortcut to walk around.
My environment is Eclipse 3.2 M5 on WinXP
If this issue can be resolved, I'm fine to output them directly to
existing bin/test directory.
George Harley wrote:
Hi Paulex,
Adding new Eclipse source folders to a module to cater for the
resources sounds good to me, but I don't understand the need to have
their output go to new sub-folders under bin. Why not just have test
resources go under the existing bin/test and main resources go under
bin/main like this ...
path="src/test/resources"/>
path="src/main/resources"/>
Best regards,
George
Paulex Yang wrote:
Recently we have agreed to put the serialization data file to the
/test/resources/serialization directory, but which requires
Eclipse user additional setting to run serialization tests. To
handle this issue, I propose to add the following lines to
.classpath file of each module as below, so that the files in
resources directory can be built into default classpath. Comments?
path="src/test/resources"/>
path="src/main/resources"/>
George Harley (JIRA) wrote:
[ http://issues.apache.org/jira/browse/HARMONY-349?page=all ]
George Harley resolved HARMONY-349:
---
Resolution: Fixed
Hi Paulex,
Changes committed in revision 395251. I made a couple of
modifications to the supplied test case to enable it to load the
.ser file from the system classloader. In addition I put the .ser
into the modules/text/src/test/resources/serialization/java/text
location and updated the build.xml with a new copy.test.resources
target so that this .ser file (and eventually others like it) make
it onto the runtime classpath.
Please could you confirm if this version of your patch has been
applied to your satisfaction.
Thanks for this enhancement, George
The currency field of DecimalFormatSymbols is not deserialized
properly
Key: HARMONY-349
URL: http://issues.apache.org/jira/browse/HARMONY-349
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Paulex Yang
Assignee: George Harley
Attachments: 02.JIRA349_text.zip
According to the serialized form of DecimalFormatSymbols, the
DecimalFormatSymbols itself should be responsible for
initializing the currency from the intlCurrencySymbol field. But
Harmony only leave it as null. The following test case
reproduces this bug:
public void test_serialization() {
DecimalFormatSymbols symbols = new
DecimalFormatSymbols(Locale.FRANCE);
Currency currency = symbols.getCurrency();
assertNotNull(currency);
try {
// serialize
ByteArrayOutputStream byteOStream = new
ByteArrayOutputStream();
ObjectOutputStream objectOStream = new
ObjectOutputStream(
byteOStream);
objectOStream.writeObject(symbols);
// and deserialize
ObjectInputStream objectIStream = new ObjectInputStream(
new
ByteArrayInputStream(byteOStream.toByteArray()));
DecimalFormatSymbols symbolsD =
(DecimalFormatSymbols) objectIStream
.readObject();
// The associated currency will not persist
currency = symbolsD.getCurrency();
} catch (Exception e1) {
fail("Errors occur during serialization");
}
try {
assertNotNull(currency);
} catch (Exception e) {
fail("currency should not be null");
}
}
Pass on RI(Sun JDK1.5.0_06)
Rail on Harmony
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Paulex Yang
China Software Development Lab
IBM
-
Terms of use : http://incubator.apache.org/harmon
Re: Classpath setting for Eclipse(was Re: [jira] Resolved: (HARMONY-349) The currency field of DecimalFormatSymbols is not deserialized properly)
Hi Paulex,
I pressed "send" a bit too soon there. This is the sort of classpath set
up I was referring to in the previous message. Please note the bottom
"classpathentry" element which I think specifies the default output
folder for a project.
Please let us know how it goes.
Best regards,
George
George Harley wrote:
Paulex Yang wrote:
Well, George, you caught me;)
I tried your solution on TEXT module at first, but for some unknown
reasons, Eclipse refused to compile according to the modification and
outputs:
"Cannot nest output folder 'text/bin/main' inside output folder
'text/bin' "
Hi Paulex,
Just a hunch, but is "text/bin" the default output folder for your
Eclipse project ? If so then could you change that default value to be
"text/bin/main" and see if the Eclipse compile error is still there ?
Thanks,
George
I have no idea what happened, so I took a shortcut to walk around.
My environment is Eclipse 3.2 M5 on WinXP
If this issue can be resolved, I'm fine to output them directly to
existing bin/test directory.
George Harley wrote:
Hi Paulex,
Adding new Eclipse source folders to a module to cater for the
resources sounds good to me, but I don't understand the need to have
their output go to new sub-folders under bin. Why not just have test
resources go under the existing bin/test and main resources go under
bin/main like this ...
path="src/test/resources"/>
path="src/main/resources"/>
Best regards,
George
Paulex Yang wrote:
Recently we have agreed to put the serialization data file to the
/test/resources/serialization directory, but which requires
Eclipse user additional setting to run serialization tests. To
handle this issue, I propose to add the following lines to
.classpath file of each module as below, so that the files in
resources directory can be built into default classpath. Comments?
path="src/test/resources"/>
path="src/main/resources"/>
George Harley (JIRA) wrote:
[ http://issues.apache.org/jira/browse/HARMONY-349?page=all ]
George Harley resolved HARMONY-349:
---
Resolution: Fixed
Hi Paulex,
Changes committed in revision 395251. I made a couple of
modifications to the supplied test case to enable it to load the
.ser file from the system classloader. In addition I put the .ser
into the modules/text/src/test/resources/serialization/java/text
location and updated the build.xml with a new copy.test.resources
target so that this .ser file (and eventually others like it) make
it onto the runtime classpath.
Please could you confirm if this version of your patch has been
applied to your satisfaction.
Thanks for this enhancement, George
The currency field of DecimalFormatSymbols is not deserialized
properly
Key: HARMONY-349
URL: http://issues.apache.org/jira/browse/HARMONY-349
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Paulex Yang
Assignee: George Harley
Attachments: 02.JIRA349_text.zip
According to the serialized form of DecimalFormatSymbols, the
DecimalFormatSymbols itself should be responsible for
initializing the currency from the intlCurrencySymbol field. But
Harmony only leave it as null. The following test case
reproduces this bug:
public void test_serialization() {
DecimalFormatSymbols symbols = new
DecimalFormatSymbols(Locale.FRANCE);
Currency currency = symbols.getCurrency();
assertNotNull(currency);
try {
// serialize
ByteArrayOutputStream byteOStream = new
ByteArrayOutputStream();
ObjectOutputStream objectOStream = new
ObjectOutputStream(
byteOStream);
objectOStream.writeObject(symbols);
// and deserialize
ObjectInputStream objectIStream = new ObjectInputStream(
new
ByteArrayInputStream(byteOStream.toByteArray()));
DecimalFormatSymbols symbolsD =
(DecimalFormatSymbols) objectIStream
.readObject();
// The associated currency will not persist
currency = symbolsD.getCurrency();
} catch (Exception e1) {
fail("Errors occur during serialization");
}
try {
assertNotNull(currency);
} catch (Exception e) {
fail("currency should not be null");
}
}
Pass on RI(Sun JDK1.5.0_06)
Rail on Harmony
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTE
Re: Copying resource files - what for?
On 4/20/06, Leo Simons <[EMAIL PROTECTED]> wrote: > Hi gang, > > On Thu, Apr 20, 2006 at 11:14:56AM +0700, Stepan Mishura wrote: > > Some time ago we agreed to copy resource files to classpath (i.e. bin/test > > directory). I saw that you added corresponing targets to build files. But > > now I realized that I don't understand why we should copy them instead of > > simply adding resource directory (i.e. src/test/resources) to classpath. May > > be there are simple reasons to do this that I don't know but anyway ... so > > why we have to copy thousands of files (there is no doubt that in future we > > will have thousands of resource files) each time we run tests? > > mostly unrelated, but another reason to do the is that you get the > benefit of Ant's filters and file munging when you need it (eg to replace > @@VERSION@@ in a property file with for example the current SVN revision). > > I suspect that's why copying resource files became common practice years ago, > and why ant's mechanism for doing copies is so blazingly efficient (really. > Sometimes it beats rsync). and sometimes it doesn't ... http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200604.mbox/[EMAIL PROTECTED] ;-) -Mark. -- Mark Hindess <[EMAIL PROTECTED]> IBM Java Technology Centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r395541 - /incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml
Stepan, In your original commit for HARMONY-315, you made this change: I'm not sure how this relates to this JIRA but it is this that breaks the test. Why not remove/fix this unrelated change rather than comment out the otherwise working test? IMHO, we should avoid making unrelated changes in a single commit. Regards, Mark. On 4/20/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Author: smishura > Date: Thu Apr 20 02:05:28 2006 > New Revision: 395541 > > URL: http://svn.apache.org/viewcvs?rev=395541&view=rev > Log: > tests/api/javax/crypto/CipherTest.java back to exclude test to make test > suite pass on Linux > > Modified: > > incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml > > Modified: > incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml > URL: > http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml?rev=395541&r1=395540&r2=395541&view=diff > == > --- > incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml > (original) > +++ > incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml > Thu Apr 20 02:05:28 2006 > @@ -118,6 +118,9 @@ > > > > + > + > + > > > > > > -- Mark Hindess <[EMAIL PROTECTED]> IBM Java Technology Centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Classpath setting for Eclipse(was Re: [jira] Resolved: (HARMONY-349) The currency field of DecimalFormatSymbols is not deserialized properly)
Paulex Yang wrote:
Well, George, you caught me;)
I tried your solution on TEXT module at first, but for some unknown
reasons, Eclipse refused to compile according to the modification and
outputs:
"Cannot nest output folder 'text/bin/main' inside output folder
'text/bin' "
Hi Paulex,
Just a hunch, but is "text/bin" the default output folder for your
Eclipse project ? If so then could you change that default value to be
"text/bin/main" and see if the Eclipse compile error is still there ?
Thanks,
George
I have no idea what happened, so I took a shortcut to walk around. My
environment is Eclipse 3.2 M5 on WinXP
If this issue can be resolved, I'm fine to output them directly to
existing bin/test directory.
George Harley wrote:
Hi Paulex,
Adding new Eclipse source folders to a module to cater for the
resources sounds good to me, but I don't understand the need to have
their output go to new sub-folders under bin. Why not just have test
resources go under the existing bin/test and main resources go under
bin/main like this ...
Best regards,
George
Paulex Yang wrote:
Recently we have agreed to put the serialization data file to the
/test/resources/serialization directory, but which requires
Eclipse user additional setting to run serialization tests. To
handle this issue, I propose to add the following lines to
.classpath file of each module as below, so that the files in
resources directory can be built into default classpath. Comments?
path="src/test/resources"/>
path="src/main/resources"/>
George Harley (JIRA) wrote:
[ http://issues.apache.org/jira/browse/HARMONY-349?page=all ]
George Harley resolved HARMONY-349:
---
Resolution: Fixed
Hi Paulex,
Changes committed in revision 395251. I made a couple of
modifications to the supplied test case to enable it to load the
.ser file from the system classloader. In addition I put the .ser
into the modules/text/src/test/resources/serialization/java/text
location and updated the build.xml with a new copy.test.resources
target so that this .ser file (and eventually others like it) make
it onto the runtime classpath.
Please could you confirm if this version of your patch has been
applied to your satisfaction.
Thanks for this enhancement, George
The currency field of DecimalFormatSymbols is not deserialized
properly
Key: HARMONY-349
URL: http://issues.apache.org/jira/browse/HARMONY-349
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Paulex Yang
Assignee: George Harley
Attachments: 02.JIRA349_text.zip
According to the serialized form of DecimalFormatSymbols, the
DecimalFormatSymbols itself should be responsible for initializing
the currency from the intlCurrencySymbol field. But Harmony only
leave it as null. The following test case reproduces this bug:
public void test_serialization() {
DecimalFormatSymbols symbols = new
DecimalFormatSymbols(Locale.FRANCE);
Currency currency = symbols.getCurrency();
assertNotNull(currency);
try {
// serialize
ByteArrayOutputStream byteOStream = new
ByteArrayOutputStream();
ObjectOutputStream objectOStream = new
ObjectOutputStream(
byteOStream);
objectOStream.writeObject(symbols);
// and deserialize
ObjectInputStream objectIStream = new ObjectInputStream(
new
ByteArrayInputStream(byteOStream.toByteArray()));
DecimalFormatSymbols symbolsD = (DecimalFormatSymbols)
objectIStream
.readObject();
// The associated currency will not persist
currency = symbolsD.getCurrency();
} catch (Exception e1) {
fail("Errors occur during serialization");
}
try {
assertNotNull(currency);
} catch (Exception e) {
fail("currency should not be null");
}
}
Pass on RI(Sun JDK1.5.0_06)
Rail on Harmony
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Copying resource files - what for?
On 4/20/06, George Harley wrote: > > Hi Stepan, > > As I recall it ( I've not my morning coffee yet so it could get a bit > unreliable here :-) ) the motivation for wanting resource files on the > classpath was to enable serialization data files to be read in by test > programs without depending on specific file locations. Copying such > serialization data files to a bin location prior to running the tests > obviously gets them on the classpath in a very simple way. Yes, but we get the same if we just add resource directory to classpath - that is simpler then copying. The documentation for the Ant copy task states that that "files are only > copied if the source file is newer than the destination file". I > interpret that as meaning that we should not expect to see the copying > of thousands of files each time we run the tests. But the build removes 'bin' directory during clean up so all copied resource files are removed too. Thanks, Stepan. Best regards, > George > > Stepan Mishura wrote: > > Hi George, > > > > Some time ago we agreed to copy resource files to classpath (i.e. > bin/test > > directory). I saw that you added corresponing targets to build files. > But > > now I realized that I don't understand why we should copy them instead > of > > simply adding resource directory (i.e. src/test/resources) to classpath. > May > > be there are simple reasons to do this that I don't know but anyway ... > so > > why we have to copy thousands of files (there is no doubt that in future > we > > will have thousands of resource files) each time we run tests? > > Thanks, > > Stepan Mishura > > Intel Middleware Products Division > > --- > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Thanks, Stepan Mishura Intel Middleware Products Division -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Copying resource files - what for?
On 4/20/06, George Harley <[EMAIL PROTECTED]> wrote: > Mark Hindess wrote: > > I suspect inclusion of the resource files (with path renaming) could > > be handled by a zip/tar task rather than by copying every time the > > tests are run. So I don't think this is a good reason. > > > > Regards, > > Mark. > > > > Hi Mark, > > The resource files don't get copied every time the tests are run. The > Ant copy task only does it if the destination file is stale with respect > to the source. > > You are really proposing that an Ant copy be replaced with a zip/tar > task ? How often will the resultant archive be refreshed ? If an entry > is stale with respect to the source ? Hang on, that sounds familiar No. This was a response to Mikhail's message about a single downloadable binary image. That would already have a tar/zip task which could include the resource files from src without needing an additional copy task. I was merely point out the requirement for a downloadable binary did really make any difference to the argument about copying (or not) the resource files. Regards, Mark. > > On 4/20/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > > >> I can see one reason to copy resources - if we want to produce > >> a single downloadable binary image of the test suite. > >> > >> Other than that it does not make much sense to me. > >> > >> The image might be usefull for kind of regular QA cycles later. > >> > >> Thanks, > >> Mikhail > >> > >> 2006/4/20, Paulex Yang <[EMAIL PROTECTED]>: > >> > >>> Stepan > >>> > >>> +1. > >>> > >>> I just proposed similar modification to classpath of each modules in > >>> another thread, which will make the IDE(Eclipse at least) user easier to > >>> run test. > >>> > >>> Stepan Mishura wrote: > >>> > Hi George, > > Some time ago we agreed to copy resource files to classpath (i.e. > bin/test > directory). I saw that you added corresponing targets to build files. But > now I realized that I don't understand why we should copy them instead of > simply adding resource directory (i.e. src/test/resources) to classpath. > May > be there are simple reasons to do this that I don't know but anyway ... > so > why we have to copy thousands of files (there is no doubt that in future > we > will have thousands of resource files) each time we run tests? > Thanks, > Stepan Mishura > Intel Middleware Products Division > --- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > >>> -- > >>> Paulex Yang > >>> China Software Development Lab > >>> IBM > >>> > >>> > >>> > >>> - > >>> Terms of use : http://incubator.apache.org/harmony/mailing.html > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >>> > >> - > >> Terms of use : http://incubator.apache.org/harmony/mailing.html > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > >> > > > > > > -- > > Mark Hindess <[EMAIL PROTECTED]> > > IBM Java Technology Centre, UK. > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Mark Hindess <[EMAIL PROTECTED]> IBM Java Technology Centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Copying resource files - what for?
Hi Mark, Sorry, I misunderstood your append. Please ignore my response. I really need to go for a coffee :-) Best regards, George George Harley wrote: Mark Hindess wrote: I suspect inclusion of the resource files (with path renaming) could be handled by a zip/tar task rather than by copying every time the tests are run. So I don't think this is a good reason. Regards, Mark. Hi Mark, The resource files don't get copied every time the tests are run. The Ant copy task only does it if the destination file is stale with respect to the source. You are really proposing that an Ant copy be replaced with a zip/tar task ? How often will the resultant archive be refreshed ? If an entry is stale with respect to the source ? Hang on, that sounds familiar Best regards, George On 4/20/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: I can see one reason to copy resources - if we want to produce a single downloadable binary image of the test suite. Other than that it does not make much sense to me. The image might be usefull for kind of regular QA cycles later. Thanks, Mikhail 2006/4/20, Paulex Yang <[EMAIL PROTECTED]>: Stepan +1. I just proposed similar modification to classpath of each modules in another thread, which will make the IDE(Eclipse at least) user easier to run test. Stepan Mishura wrote: Hi George, Some time ago we agreed to copy resource files to classpath (i.e. bin/test directory). I saw that you added corresponing targets to build files. But now I realized that I don't understand why we should copy them instead of simply adding resource directory (i.e. src/test/resources) to classpath. May be there are simple reasons to do this that I don't know but anyway ... so why we have to copy thousands of files (there is no doubt that in future we will have thousands of resource files) each time we run tests? Thanks, Stepan Mishura Intel Middleware Products Division --- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Hindess <[EMAIL PROTECTED]> IBM Java Technology Centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Copying resource files - what for?
Hi gang, On Thu, Apr 20, 2006 at 11:14:56AM +0700, Stepan Mishura wrote: > Some time ago we agreed to copy resource files to classpath (i.e. bin/test > directory). I saw that you added corresponing targets to build files. But > now I realized that I don't understand why we should copy them instead of > simply adding resource directory (i.e. src/test/resources) to classpath. May > be there are simple reasons to do this that I don't know but anyway ... so > why we have to copy thousands of files (there is no doubt that in future we > will have thousands of resource files) each time we run tests? mostly unrelated, but another reason to do the is that you get the benefit of Ant's filters and file munging when you need it (eg to replace @@VERSION@@ in a property file with for example the current SVN revision). I suspect that's why copying resource files became common practice years ago, and why ant's mechanism for doing copies is so blazingly efficient (really. Sometimes it beats rsync). cheers! Leo - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Copying resource files - what for?
George Harley wrote: Paulex Yang wrote: Stepan +1. I just proposed similar modification to classpath of each modules in another thread, which will make the IDE(Eclipse at least) user easier to run test. Hi Paulex, Your proposed modification to the Eclipse .classpath file doesn't add src/test/resources to the classpath. Ah, you are right, George, I misunderstood Stepan just now. Sorry for the confusion caused. Best regards, George Stepan Mishura wrote: Hi George, Some time ago we agreed to copy resource files to classpath (i.e. bin/test directory). I saw that you added corresponing targets to build files. But now I realized that I don't understand why we should copy them instead of simply adding resource directory (i.e. src/test/resources) to classpath. May be there are simple reasons to do this that I don't know but anyway ... so why we have to copy thousands of files (there is no doubt that in future we will have thousands of resource files) each time we run tests? Thanks, Stepan Mishura Intel Middleware Products Division --- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Classpath setting for Eclipse(was Re: [jira] Resolved: (HARMONY-349) The currency field of DecimalFormatSymbols is not deserialized properly)
Well, George, you caught me;)
I tried your solution on TEXT module at first, but for some unknown
reasons, Eclipse refused to compile according to the modification and
outputs:
"Cannot nest output folder 'text/bin/main' inside output folder 'text/bin' "
I have no idea what happened, so I took a shortcut to walk around. My
environment is Eclipse 3.2 M5 on WinXP
If this issue can be resolved, I'm fine to output them directly to
existing bin/test directory.
George Harley wrote:
Hi Paulex,
Adding new Eclipse source folders to a module to cater for the
resources sounds good to me, but I don't understand the need to have
their output go to new sub-folders under bin. Why not just have test
resources go under the existing bin/test and main resources go under
bin/main like this ...
Best regards,
George
Paulex Yang wrote:
Recently we have agreed to put the serialization data file to the
/test/resources/serialization directory, but which requires
Eclipse user additional setting to run serialization tests. To handle
this issue, I propose to add the following lines to .classpath file
of each module as below, so that the files in resources directory can
be built into default classpath. Comments?
path="src/test/resources"/>
path="src/main/resources"/>
George Harley (JIRA) wrote:
[ http://issues.apache.org/jira/browse/HARMONY-349?page=all ]
George Harley resolved HARMONY-349:
---
Resolution: Fixed
Hi Paulex,
Changes committed in revision 395251. I made a couple of
modifications to the supplied test case to enable it to load the
.ser file from the system classloader. In addition I put the .ser
into the modules/text/src/test/resources/serialization/java/text
location and updated the build.xml with a new copy.test.resources
target so that this .ser file (and eventually others like it) make
it onto the runtime classpath.
Please could you confirm if this version of your patch has been
applied to your satisfaction.
Thanks for this enhancement, George
The currency field of DecimalFormatSymbols is not deserialized
properly
Key: HARMONY-349
URL: http://issues.apache.org/jira/browse/HARMONY-349
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Paulex Yang
Assignee: George Harley
Attachments: 02.JIRA349_text.zip
According to the serialized form of DecimalFormatSymbols, the
DecimalFormatSymbols itself should be responsible for initializing
the currency from the intlCurrencySymbol field. But Harmony only
leave it as null. The following test case reproduces this bug:
public void test_serialization() {
DecimalFormatSymbols symbols = new
DecimalFormatSymbols(Locale.FRANCE);
Currency currency = symbols.getCurrency();
assertNotNull(currency);
try {
// serialize
ByteArrayOutputStream byteOStream = new
ByteArrayOutputStream();
ObjectOutputStream objectOStream = new ObjectOutputStream(
byteOStream);
objectOStream.writeObject(symbols);
// and deserialize
ObjectInputStream objectIStream = new ObjectInputStream(
new
ByteArrayInputStream(byteOStream.toByteArray()));
DecimalFormatSymbols symbolsD = (DecimalFormatSymbols)
objectIStream
.readObject();
// The associated currency will not persist
currency = symbolsD.getCurrency();
} catch (Exception e1) {
fail("Errors occur during serialization");
}
try {
assertNotNull(currency);
} catch (Exception e) {
fail("currency should not be null");
}
}
Pass on RI(Sun JDK1.5.0_06)
Rail on Harmony
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Paulex Yang
China Software Development Lab
IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Copying resource files - what for?
Mark Hindess wrote: I suspect inclusion of the resource files (with path renaming) could be handled by a zip/tar task rather than by copying every time the tests are run. So I don't think this is a good reason. Regards, Mark. Hi Mark, The resource files don't get copied every time the tests are run. The Ant copy task only does it if the destination file is stale with respect to the source. You are really proposing that an Ant copy be replaced with a zip/tar task ? How often will the resultant archive be refreshed ? If an entry is stale with respect to the source ? Hang on, that sounds familiar Best regards, George On 4/20/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: I can see one reason to copy resources - if we want to produce a single downloadable binary image of the test suite. Other than that it does not make much sense to me. The image might be usefull for kind of regular QA cycles later. Thanks, Mikhail 2006/4/20, Paulex Yang <[EMAIL PROTECTED]>: Stepan +1. I just proposed similar modification to classpath of each modules in another thread, which will make the IDE(Eclipse at least) user easier to run test. Stepan Mishura wrote: Hi George, Some time ago we agreed to copy resource files to classpath (i.e. bin/test directory). I saw that you added corresponing targets to build files. But now I realized that I don't understand why we should copy them instead of simply adding resource directory (i.e. src/test/resources) to classpath. May be there are simple reasons to do this that I don't know but anyway ... so why we have to copy thousands of files (there is no doubt that in future we will have thousands of resource files) each time we run tests? Thanks, Stepan Mishura Intel Middleware Products Division --- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Hindess <[EMAIL PROTECTED]> IBM Java Technology Centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Copying resource files - what for?
Paulex Yang wrote: Stepan +1. I just proposed similar modification to classpath of each modules in another thread, which will make the IDE(Eclipse at least) user easier to run test. Hi Paulex, Your proposed modification to the Eclipse .classpath file doesn't add src/test/resources to the classpath. Best regards, George Stepan Mishura wrote: Hi George, Some time ago we agreed to copy resource files to classpath (i.e. bin/test directory). I saw that you added corresponing targets to build files. But now I realized that I don't understand why we should copy them instead of simply adding resource directory (i.e. src/test/resources) to classpath. May be there are simple reasons to do this that I don't know but anyway ... so why we have to copy thousands of files (there is no doubt that in future we will have thousands of resource files) each time we run tests? Thanks, Stepan Mishura Intel Middleware Products Division --- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Copying resource files - what for?
Hi Stepan, As I recall it ( I've not my morning coffee yet so it could get a bit unreliable here :-) ) the motivation for wanting resource files on the classpath was to enable serialization data files to be read in by test programs without depending on specific file locations. Copying such serialization data files to a bin location prior to running the tests obviously gets them on the classpath in a very simple way. The documentation for the Ant copy task states that that "files are only copied if the source file is newer than the destination file". I interpret that as meaning that we should not expect to see the copying of thousands of files each time we run the tests. Best regards, George Stepan Mishura wrote: Hi George, Some time ago we agreed to copy resource files to classpath (i.e. bin/test directory). I saw that you added corresponing targets to build files. But now I realized that I don't understand why we should copy them instead of simply adding resource directory (i.e. src/test/resources) to classpath. May be there are simple reasons to do this that I don't know but anyway ... so why we have to copy thousands of files (there is no doubt that in future we will have thousands of resource files) each time we run tests? Thanks, Stepan Mishura Intel Middleware Products Division --- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r395524 - in /incubator/harmony/enhanced/classlib/trunk/modules/crypto: make/common/build.xml src/main/java/javax/crypto/Cipher.java
Interesting it passed on Windows but fails on Linux :-(
Thanks,
Stepan.
On 4/20/06, Mark Hindess <[EMAIL PROTECTED]> wrote:
>
> Looks like the (unrelated?) change to the classpath broken another test. I
> get:
>
> Failed to load resource: hyts_des-ede3-cbc.test1.cipherText
>
> junit.framework.AssertionFailedError: Failed to load resource:
> hyts_des-ede3-cbc.test1.cipherText at
> tests.api.javax.crypto.CipherTest.getStream(CipherTest.java:583) at
> tests.api.javax.crypto.CipherTest.loadBytes(CipherTest.java:563) at
> tests.api.javax.crypto.CipherTest.test_doFinal(CipherTest.java:553) at
> java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205)
> 0.011
>
> Geir, for some reason the test failure messages aren't reaching the
> list. They are coming from the same address but have a different
> subject line.
>
> -Mark.
>
> On 4/20/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Author: smishura
> > Date: Thu Apr 20 00:44:23 2006
> > New Revision: 395524
> >
> > URL: http://svn.apache.org/viewcvs?rev=395524&view=rev
> > Log:
> > Partial fix for HARMONY-315 (javax.crypto.Cipher.getInstance doesn't
> match RI exception behaviour.)
> >
> > Modified:
> >
> incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml
> >
> incubator/harmony/enhanced/classlib/trunk/modules/crypto/src/main/java/javax/crypto/Cipher.java
> >
> > Modified:
> incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml
> > URL:
> http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml?rev=395524&r1=395523&r2=395524&view=diff
> >
> ==
> > ---
> incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml
> (original)
> > +++
> incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml
> Thu Apr 20 00:44:23 2006
> > @@ -109,14 +109,15 @@
> >
> >
> >
> > +
> > +
> > +
> > +
> >
> >
> >
> >
> >
> > -
> > -
> > - name="tests/api/javax/crypto/CipherTest.java"/>
> >
> >
> >
> >
> > Modified:
> incubator/harmony/enhanced/classlib/trunk/modules/crypto/src/main/java/javax/crypto/Cipher.java
> > URL:
> http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/crypto/src/main/java/javax/crypto/Cipher.java?rev=395524&r1=395523&r2=395524&view=diff
> >
> ==
> > ---
> incubator/harmony/enhanced/classlib/trunk/modules/crypto/src/main/java/javax/crypto/Cipher.java
> (original)
> > +++
> incubator/harmony/enhanced/classlib/trunk/modules/crypto/src/main/java/javax/crypto/Cipher.java
> Thu Apr 20 00:44:23 2006
> > @@ -146,6 +146,11 @@
> > public static final Cipher getInstance(String transformation,
> > String provider) throws NoSuchAlgorithmException,
> > NoSuchProviderException, NoSuchPaddingException {
> > +
> > +if (provider == null) {
> > +throw new IllegalArgumentException("provider is null");
> > +}
> > +
> > Provider p = Security.getProvider(provider);
> > if (p == null) {
> > throw new NoSuchProviderException("Provider " + provider
> >
> >
> >
>
>
> --
> Mark Hindess <[EMAIL PROTECTED]>
> IBM Java Technology Centre, UK.
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
--
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r395524 - in /incubator/harmony/enhanced/classlib/trunk/modules/crypto: make/common/build.xml src/main/java/javax/crypto/Cipher.java
Looks like the (unrelated?) change to the classpath broken another test. I get:
Failed to load resource: hyts_des-ede3-cbc.test1.cipherText
junit.framework.AssertionFailedError: Failed to load resource:
hyts_des-ede3-cbc.test1.cipherText at
tests.api.javax.crypto.CipherTest.getStream(CipherTest.java:583) at
tests.api.javax.crypto.CipherTest.loadBytes(CipherTest.java:563) at
tests.api.javax.crypto.CipherTest.test_doFinal(CipherTest.java:553) at
java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) 0.011
Geir, for some reason the test failure messages aren't reaching the
list. They are coming from the same address but have a different
subject line.
-Mark.
On 4/20/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Author: smishura
> Date: Thu Apr 20 00:44:23 2006
> New Revision: 395524
>
> URL: http://svn.apache.org/viewcvs?rev=395524&view=rev
> Log:
> Partial fix for HARMONY-315 (javax.crypto.Cipher.getInstance doesn't match RI
> exception behaviour.)
>
> Modified:
>
> incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml
>
> incubator/harmony/enhanced/classlib/trunk/modules/crypto/src/main/java/javax/crypto/Cipher.java
>
> Modified:
> incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml
> URL:
> http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml?rev=395524&r1=395523&r2=395524&view=diff
> ==
> ---
> incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml
> (original)
> +++
> incubator/harmony/enhanced/classlib/trunk/modules/crypto/make/common/build.xml
> Thu Apr 20 00:44:23 2006
> @@ -109,14 +109,15 @@
>
> value="-Xbootclasspath/a:${hy.crypto.bin.test}${path.separator}../../../../${junit.jar}${path.separator}../../../../build/tests"/>
>
> +
> +
> +
> +
>
>
>
>
>
> -
> -
> -
>
>
>
>
> Modified:
> incubator/harmony/enhanced/classlib/trunk/modules/crypto/src/main/java/javax/crypto/Cipher.java
> URL:
> http://svn.apache.org/viewcvs/incubator/harmony/enhanced/classlib/trunk/modules/crypto/src/main/java/javax/crypto/Cipher.java?rev=395524&r1=395523&r2=395524&view=diff
> ==
> ---
> incubator/harmony/enhanced/classlib/trunk/modules/crypto/src/main/java/javax/crypto/Cipher.java
> (original)
> +++
> incubator/harmony/enhanced/classlib/trunk/modules/crypto/src/main/java/javax/crypto/Cipher.java
> Thu Apr 20 00:44:23 2006
> @@ -146,6 +146,11 @@
> public static final Cipher getInstance(String transformation,
> String provider) throws NoSuchAlgorithmException,
> NoSuchProviderException, NoSuchPaddingException {
> +
> +if (provider == null) {
> +throw new IllegalArgumentException("provider is null");
> +}
> +
> Provider p = Security.getProvider(provider);
> if (p == null) {
> throw new NoSuchProviderException("Provider " + provider
>
>
>
--
Mark Hindess <[EMAIL PROTECTED]>
IBM Java Technology Centre, UK.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Classpath setting for Eclipse(was Re: [jira] Resolved: (HARMONY-349) The currency field of DecimalFormatSymbols is not deserialized properly)
Hi Paulex,
Adding new Eclipse source folders to a module to cater for the resources
sounds good to me, but I don't understand the need to have their output
go to new sub-folders under bin. Why not just have test resources go
under the existing bin/test and main resources go under bin/main like
this ...
Best regards,
George
Paulex Yang wrote:
Recently we have agreed to put the serialization data file to the
/test/resources/serialization directory, but which requires
Eclipse user additional setting to run serialization tests. To handle
this issue, I propose to add the following lines to .classpath file of
each module as below, so that the files in resources directory can be
built into default classpath. Comments?
path="src/test/resources"/>
path="src/main/resources"/>
George Harley (JIRA) wrote:
[ http://issues.apache.org/jira/browse/HARMONY-349?page=all ]
George Harley resolved HARMONY-349:
---
Resolution: Fixed
Hi Paulex,
Changes committed in revision 395251. I made a couple of
modifications to the supplied test case to enable it to load the .ser
file from the system classloader. In addition I put the .ser into the
modules/text/src/test/resources/serialization/java/text location and
updated the build.xml with a new copy.test.resources target so that
this .ser file (and eventually others like it) make it onto the
runtime classpath.
Please could you confirm if this version of your patch has been
applied to your satisfaction.
Thanks for this enhancement, George
The currency field of DecimalFormatSymbols is not deserialized
properly
Key: HARMONY-349
URL: http://issues.apache.org/jira/browse/HARMONY-349
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Paulex Yang
Assignee: George Harley
Attachments: 02.JIRA349_text.zip
According to the serialized form of DecimalFormatSymbols, the
DecimalFormatSymbols itself should be responsible for initializing
the currency from the intlCurrencySymbol field. But Harmony only
leave it as null. The following test case reproduces this bug:
public void test_serialization() {
DecimalFormatSymbols symbols = new
DecimalFormatSymbols(Locale.FRANCE);
Currency currency = symbols.getCurrency();
assertNotNull(currency);
try {
// serialize
ByteArrayOutputStream byteOStream = new
ByteArrayOutputStream();
ObjectOutputStream objectOStream = new ObjectOutputStream(
byteOStream);
objectOStream.writeObject(symbols);
// and deserialize
ObjectInputStream objectIStream = new ObjectInputStream(
new
ByteArrayInputStream(byteOStream.toByteArray()));
DecimalFormatSymbols symbolsD = (DecimalFormatSymbols)
objectIStream
.readObject();
// The associated currency will not persist
currency = symbolsD.getCurrency();
} catch (Exception e1) {
fail("Errors occur during serialization");
}
try {
assertNotNull(currency);
} catch (Exception e) {
fail("currency should not be null");
}
}
Pass on RI(Sun JDK1.5.0_06)
Rail on Harmony
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Copying resource files - what for?
I suspect inclusion of the resource files (with path renaming) could be handled by a zip/tar task rather than by copying every time the tests are run. So I don't think this is a good reason. Regards, Mark. On 4/20/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > I can see one reason to copy resources - if we want to produce > a single downloadable binary image of the test suite. > > Other than that it does not make much sense to me. > > The image might be usefull for kind of regular QA cycles later. > > Thanks, > Mikhail > > 2006/4/20, Paulex Yang <[EMAIL PROTECTED]>: > > Stepan > > > > +1. > > > > I just proposed similar modification to classpath of each modules in > > another thread, which will make the IDE(Eclipse at least) user easier to > > run test. > > > > Stepan Mishura wrote: > > > Hi George, > > > > > > Some time ago we agreed to copy resource files to classpath (i.e. bin/test > > > directory). I saw that you added corresponing targets to build files. But > > > now I realized that I don't understand why we should copy them instead of > > > simply adding resource directory (i.e. src/test/resources) to classpath. > > > May > > > be there are simple reasons to do this that I don't know but anyway ... so > > > why we have to copy thousands of files (there is no doubt that in future > > > we > > > will have thousands of resource files) each time we run tests? > > > Thanks, > > > Stepan Mishura > > > Intel Middleware Products Division > > > --- > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > Paulex Yang > > China Software Development Lab > > IBM > > > > > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Mark Hindess <[EMAIL PROTECTED]> IBM Java Technology Centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
