Mark Hindess wrote:
Dan,
Thanks for the helpful comments.
On 3/30/06, bootjvm [EMAIL PROTECTED] wrote:
Concerning the ideas for platform names, I think lower case names
like 'linux' and 'windows' and 'solaris' and 'aix' is by far the simplest
method. It avoids UPPER case errors with the
Stepan,
I've taken out this dependency on the Eclipse compiler so that the build
continue to run on a regular jdk. We can discuss what the hard
dependencies for the build should be.
Regards,
Tim
[EMAIL PROTECTED] wrote:
Author: tellison
Date: Thu Mar 30 02:40:36 2006
New Revision: 390069
Tim,
I'm OK with removing the dependency. I did by analogy with x-net module
build files so this dependency exists there too.
Also I did the same when created patch for extracting crypto module.
Thanks,
Stepan.
On 3/30/06, Tim Ellison wrote:
Stepan,
I've taken out this dependency on the
Understood -- maybe it should be removed from there too and we should
set up the compiler adapter in a 'global' build-java properties file
(where we can also deal with the different targets required by eclipse
and sun compilers).
Regards,
Tim
Stepan Mishura wrote:
Tim,
I'm OK with removing
I think this is the case when me might choose follow the spec
Most likely we will not break existing applications if we weaken
requirements for method arguments. But advanced users would be able
to use our benefits.
Thanks,
Mikhail
2006/3/30, Paulex Yang [EMAIL PROTECTED]:
Hi,
About the
[SNIP]
IMHO, this relates to stress tests and load tests only. This means that we
shouldn't put such kind of tests in a 'regular test suite'. The 'regular
test suite' is used to verify regressions only. Returning back to a test's
size, I think it is up to developer - we can only recommend
On 3/30/06, Tim Ellison wrote:
Understood -- maybe it should be removed from there too and we should
set up the compiler adapter in a 'global' build-java properties file
(where we can also deal with the different targets required by eclipse
and sun compilers).
Agreed with all above.
On 3/30/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
I think this is the case when me might choose follow the spec
Most likely we will not break existing applications if we weaken
requirements for method arguments. But advanced users would be able
to use our benefits.
+1
--
Anton Avtamonov,
Stepan Mishura wrote:
On 3/30/06, Richard Liang wrote:
Dears,
I notice that we put all the test code into one big test method (for
example,
org.apache.harmony.tests.java.util.jar.test_putLjava_lang_ObjectLjava_lang_Object
).
This way we will lose some benefits of junit and even unit test:
Mikhail Loenko wrote:
I think this is the case when me might choose follow the spec
+1. I think it's a bug of RI.
Most likely we will not break existing applications if we weaken
requirements for method arguments. But advanced users would be able
to use our benefits.
Thanks,
Mikhail
Isn't there some standard naming strategy, used by other Apache
projects? I know that autoconf has a platform naming strategy.
I recommend to study other platform naming strategies before making a
decision. This will help reduce the number of mistakes.
Etienne
bootjvm wrote:
Bottom line:
[Original Message]
From: Mark Hindess [EMAIL PROTECTED]
To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED]
Date: 3/29/06 11:55:13 PM
Subject: Re: [classlib] ant platform property definitions
Dan,
Thanks for the helpful comments.
On 3/30/06, bootjvm [EMAIL PROTECTED] wrote:
...
[Original Message]
From: Etienne Gagnon [EMAIL PROTECTED]
To: harmony-dev@incubator.apache.org
Date: 3/30/06 6:39:47 AM
Subject: Re: [classlib] ant platform property definitions
Isn't there some standard naming strategy, used by other Apache
projects? I know that autoconf has a
+1
Mikhail Loenko wrote:
I think this is the case when me might choose follow the spec
Most likely we will not break existing applications if we weaken
requirements for method arguments. But advanced users would be able
to use our benefits.
Thanks,
Mikhail
2006/3/30, Paulex Yang
All the (enabled) tests are passing for me. What do you see failing?
Regards,
Tim
Stepan Mishura (JIRA) wrote:
[ http://issues.apache.org/jira/browse/HARMONY-279?page=all ]
Stepan Mishura updated HARMONY-279:
---
Attachment:
Is www.dlldump.com our chosen supplier? I've never heard of them.
I browsed around and didn't see it anywhere on the microsoft.com
website. I know we are checking the MD5 to ensure we get the right
thing; any idea about reliability etc.
Regards,
Tim
Mark Hindess (JIRA) wrote:
download
I failed to find it on microsoft.com too. Though I'd be happy to be corrected.
It was the first hit on the google search I did - or the first that
didn't use javascript and popups to serve the download. It's trivial
to change if you find a better source.
I was careful to make sure the file it
Ok, if somebody prefers a different source send a note.
Regards,
Tim
Mark Hindess wrote:
I failed to find it on microsoft.com too. Though I'd be happy to be
corrected.
It was the first hit on the google search I did - or the first that
didn't use javascript and popups to serve the
Yes, I saw that too, and I agree that it makes it virtually impossible
to see exactly what was changed. I used a windows machine to apply your
patch and commit the code, so I can only assume that's why the file was
converted to DOS EOL.
I'll poke around to see if I can make it preserve the
The property works. I has been in use in the SableVM repository for a
long time now.
Actually, you need to set 2 properties:
svn:mime-type : text/plain
svn:eol-style : native
Note that svn will give you trouble if you try to set these properties
on a file which contains mixed EOL types.
I'm not too familiar with the Harmony code yet, but since I've had a
bunch of experience on large projects I thought I'd toss my $.02 in here.
1) When dealing with a project as large and with as much surface area
as a VM, your unit tests for the entire project will probably take
several
Actually, you need to set 2 properties:
svn:mime-type : text/plain
svn:eol-style : native
It depends a lot from the svn client, though. I tried this, but in my
case files are returning from repository in the format they are stored
in repository.
Thanks a lot for the comment, I'll try to use
Can we set up the server to recognize .java / .xml / etc files as
text/plain native types?
Regards,
Tim
Etienne Gagnon wrote:
The property works. I has been in use in the SableVM repository for a
long time now.
Actually, you need to set 2 properties:
svn:mime-type : text/plain
Wow. This patch touched lots of files to fix spelling mistakes, and the
commit fell foul of the EOL diff problem being discussed elsewhere.
Hand-on-heart, I looked at every incoming change and swear that they are
simple typo fixes in comments and a few error strings.
I know that nobody can
Tim Ellison wrote:
Wow. This patch touched lots of files to fix spelling mistakes, and the
commit fell foul of the EOL diff problem being discussed elsewhere.
Hand-on-heart, I looked at every incoming change and swear that they are
simple typo fixes in comments and a few error strings.
I know
Tim Ellison wrote:
Can we set up the server to recognize .java / .xml / etc files as
text/plain native types?
Sounds good to me
$ find . -name \*.java -o -name \*.xml \
| xargs svn propset svn:eol-style native \
svn ci -m Set native EOL style
Etienne Gagnon wrote:
Actually, you
+1
Tim Ellison wrote:
Understood -- maybe it should be removed from there too and we should
set up the compiler adapter in a 'global' build-java properties file
(where we can also deal with the different targets required by eclipse
and sun compilers).
Regards,
Tim
Stepan Mishura wrote:
Tim,
+1
Mikhail Loenko wrote:
I think this is the case when me might choose follow the spec
Most likely we will not break existing applications if we weaken
requirements for method arguments. But advanced users would be able
to use our benefits.
Thanks,
Mikhail
2006/3/30, Paulex Yang [EMAIL
I was going to say...
I figure this will go away when we get eol: fixed...
geir
Tim Ellison wrote:
Wow. This patch touched lots of files to fix spelling mistakes, and the
commit fell foul of the EOL diff problem being discussed elsewhere.
Hand-on-heart, I looked at every incoming change and
yes - eol-style is the solution here, and I thought SVN did the right
thing for obvious text files...
geir
Archie Cobbs wrote:
Tim Ellison wrote:
Can we set up the server to recognize .java / .xml / etc files as
text/plain native types?
Sounds good to me
$ find . -name \*.java -o
This gives me the heebie-jeebies. What is the license for that dll?
Are people allowed to re-distribute independent of an app that uses it?
Where else can people get it?
Tim Ellison wrote:
Ok, if somebody prefers a different source send a note.
Regards,
Tim
Mark Hindess wrote:
I failed to
Geir Magnusson Jr (JIRA) wrote:
[ http://issues.apache.org/jira/browse/HARMONY-221?page=all ]
Geir Magnusson Jr reassigned HARMONY-221:
-
Assign To: Geir Magnusson Jr
regex need moving from modules/regex-beans-math to modules/regex
As far as I undersood the dll file in not distributed alone. Dot
NET redistributable package on microsoft.com [1] contains it but the package
size is 23Mb.
Thanks,
Stepan.
[1]
http://www.microsoft.com/downloads/details.aspx?FamilyID=262d25e3-f589-4842-8157-034d1e7cf3a3DisplayLang=en
On 3/30/06,
Tim Ellison (JIRA) wrote:
[ http://issues.apache.org/jira/browse/HARMONY-280?page=all ]
Tim Ellison resolved HARMONY-280:
-
Resolution: Duplicate
Duplicate of HARMONY-121
Customized SecurityManager cannot cooperate with AccessController
I'm not a lawyer, but as to my knowledge, many commercial as well as
open source software distribution includes msvcr71.dll, say, wincvs,
ImageMagick, VMWare, OpenOffice, etc(just a few cases).
And the vctoolkit2003's EULA says:
2.2 Redistributable Code-General. Microsoft grants you a
On 3/30/06, Richard Liang wrote:
Stepan Mishura wrote:
On 3/30/06, Richard Liang wrote:
[SNIP]
IMHO, this relates to stress tests and load tests only. This means
that we
shouldn't put such kind of tests in a 'regular test suite'. The 'regular
test suite' is used to verify regressions
will pugh wrote:
I'm not too familiar with the Harmony code yet, but since I've had a
bunch of experience on large projects I thought I'd toss my $.02 in here.
1) When dealing with a project as large and with as much surface area
as a VM, your unit tests for the entire project will probably
This file exists on my windows + free soft only machine
For example it presents in Microsoft .NET Framework
Thanks,
Mikhail
Yes, it is included in .Net framework, but I'm not sure if it is
included in pure 32 bits Windows distribution.
I guess it is not perfect to make our potential user into another JRE
like situation, which is, if you want to run Harmony, you must download
.Net Framework manually and separately.
Oh, yes. Crypto test suite is not included in 'common test suite run' so all
the (enabled) test are passing for you. I meant passing all crypto tests. I
run tests for crypto module by typing:
cd modules\crypto\make; ant test
I think it should be included to 'common test suite run' to avoid
It would also be helpful to raise a bug against whatever tool Tim is
using. It is almost certainly making incorrect assumptions about line
endings of files being patched based on eol characters of the
metadata. Or possibly assuming the line endings of all files being
patched are the same which
41 matches
Mail list logo
