Re: [drlvm] fyi -- what to try if build.bat update.... is not working
On 5/15/06, Weldon Washburn [EMAIL PROTECTED] wrote: FYI -- If you get connection timed out errors when trying to run build.bat update..., it could be because http.proxyhost and http.proxyPort are not set correctly. Proxy settings can be set as follows: build.bat -Dhttp.proxyHost=your_proxy_host -Dhttp.proxyPort=your_proxy_port# update Proxy port host most likely will be available in a current web browser settings. Or, one can ask a system administrator to learn them. The alternative way to set proxy is to put the lines: http.proxyHost=your_proxy_host http.proxyPort=your_proxy_port# at build\make\*.properties files. Andrey Chernyshev Intel Middleware Products Division -- Weldon Washburn 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: jchevm status?
You mean it's hand-me-down-ware these days, you just get a copy from someone who got it from someone else who paid 50 bucks a few years ago and wishes he didn't? Amazing how many widely-used benchmarks fall into that category ... On Monday 15 May 2006 22:51, Geir Magnusson Jr wrote: Neither, probably :) Chris Gray wrote: BTW is spec98jvm open-source these days, or is it still send 50 bucks to this address and we will send you a floppy disk which only installs on windoze? - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - 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] Layout of tests in crypto module
Hi George, see below 2006/5/16, George Harley [EMAIL PROTECTED]: Hi Mikhail, I have a couple of minor comments about your proposal for a test layouts. I should have responded sooner, I know, but I have suffered from a number of hardware problems in the past few weeks that slowed things down somewhat for me. Anyway, it's all great but it would be nice to get answers to the following ... 1) The section on Location of the tests in the directory tree proposes modulename/src/tests/impl for Harmony specific tests and modulename/src/tests/api for implementation-independent tests. Where would tests go for Harmony API's that are not part of the J2SE spec but are still accessible ? Strictly speaking they are API as well as being specific to Harmony. The main idea is to separate tests that must pass on any conformant implementation from the tests passing on Harmony only. When these are separated we can e.g. easily validate implementation- independent tests by running them against RI. Actually I would not like to start an endless philosophical discussion here about what are unit vs. api vs. whatever tests. api is just a name (suggested by Tim) and might be changed to any unconfusing one. So, back to your question, those must go to 'impl' as far as they fail on RI: modulename/src/tests/impl - Harmony specific tests What about the location of tests designed to run on the classpath and tests designed to run on the bootclasspath ? That does not seem to be addressed in this section. When the tests are run how are Directory defines the root of the test suite, then the package goes, see Package names for different types of the tests section: If the test is designed to be run from bootclasspath then its package is the same as the package of the class under test the bootclasspath and classpath tests distinguished ? Purely on package name ? Did you ever see the append I wrote to the list a couple of weeks ago on this topic ? [1] Yes, I've seen it. As you could notice we had more test categories. They are described in the same thread. We might have independent tests running from bootclasspath and specific ones running from classpath. 2) Still in the Location of the tests in the directory tree section, shouldn't the suggested source folder names include java in there ? e.g. modulename/src/tests/java/api ? What is wrong with the src/test/java (below here is Java code), src/test/resources (below here is non-code test artefacts) convention ? I notice that at present the page does not include any mention of where test resources would go. Yes, you are right. It's missing. It was supposed to be under test type, like: module/src/test/api/java module/src/test/api/resources 3) What does the sentence Tests are not separated by functionality under test, e.g. tests against clone() methods are not separated from tests against equals() methods actually mean ? That was to address Tim's concern: 1. Tests are separated on directory level by 'intention' I agree where the intention is broad (i.e. functional tests vs. performance tests vs. stress tests) but I'm not convinced that we need to separate to a precise 'intent', at least I've never been in a position where I've wished that my my serialization tests are separate from my cloning tests or whatever. Feel free to reword if something is not clear in the proposal Thanks, Mikhail Best regards, George [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200604.mbox/[EMAIL PROTECTED] Mikhail Loenko wrote: Hello I would like to make some changes in the crypto module: - Separate implemetation-independent tests from implementation specific ones. - Fix layout according to the proposed scheme [1] Please let me know if you do any changes in that module then I'll delay restruct. Thanks, Mikhail [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/testing.html - 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: Supporting working on a single module?
Tim Ellison wrote: That layout works for me too. Patches welcome ;-) hehe, had a feeling that might be coming ;) Im actually working on a couple of preliminary patches at the moment for this refactoring. One is a minor tidy up, raised in HARMONY-451. I hope to raise another JIRA soon which will alter the build scripts to create and populate an hdk directory structure under deploy - which basically means moving the deploy/jre and deploy/include directories down a level to deploy/jdk/jre and deploy/jdk/include. Once this is done we will be in a good position to start moving the native code into modules (which Im also happy to work on and provide patches for). Regards, Tim -- Oliver Deakin IBM United Kingdom Limited - 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] Layout of tests in crypto module
Mikhail Loenko wrote: Hi George, see below 2006/5/16, George Harley [EMAIL PROTECTED]: Hi Mikhail, I have a couple of minor comments about your proposal for a test layouts. I should have responded sooner, I know, but I have suffered from a number of hardware problems in the past few weeks that slowed things down somewhat for me. Anyway, it's all great but it would be nice to get answers to the following ... 1) The section on Location of the tests in the directory tree proposes modulename/src/tests/impl for Harmony specific tests and modulename/src/tests/api for implementation-independent tests. Where would tests go for Harmony API's that are not part of the J2SE spec but are still accessible ? Strictly speaking they are API as well as being specific to Harmony. The main idea is to separate tests that must pass on any conformant implementation from the tests passing on Harmony only. When these are separated we can e.g. easily validate implementation- independent tests by running them against RI. Actually I would not like to start an endless philosophical discussion here about what are unit vs. api vs. whatever tests. Me ? Start a philosophical discussion ? :-) api is just a name (suggested by Tim) and might be changed to any unconfusing one. So, back to your question, those must go to 'impl' as far as they fail on RI: modulename/src/tests/impl - Harmony specific tests What about the location of tests designed to run on the classpath and tests designed to run on the bootclasspath ? That does not seem to be addressed in this section. When the tests are run how are Directory defines the root of the test suite, then the package goes, see Package names for different types of the tests section: If the test is designed to be run from bootclasspath then its package is the same as the package of the class under test Is it the case that all of the classes under a particular source folder (say src/tests/api/java) get compiled to one output folder ? the bootclasspath and classpath tests distinguished ? Purely on package name ? Did you ever see the append I wrote to the list a couple of weeks ago on this topic ? [1] Yes, I've seen it. As you could notice we had more test categories. They are described in the same thread. We might have independent tests running from bootclasspath and specific ones running from classpath. 2) Still in the Location of the tests in the directory tree section, shouldn't the suggested source folder names include java in there ? e.g. modulename/src/tests/java/api ? What is wrong with the src/test/java (below here is Java code), src/test/resources (below here is non-code test artefacts) convention ? I notice that at present the page does not include any mention of where test resources would go. Yes, you are right. It's missing. It was supposed to be under test type, like: module/src/test/api/java module/src/test/api/resources 3) What does the sentence Tests are not separated by functionality under test, e.g. tests against clone() methods are not separated from tests against equals() methods actually mean ? That was to address Tim's concern: 1. Tests are separated on directory level by 'intention' I agree where the intention is broad (i.e. functional tests vs. performance tests vs. stress tests) but I'm not convinced that we need to separate to a precise 'intent', at least I've never been in a position where I've wished that my my serialization tests are separate from my cloning tests or whatever. Feel free to reword if something is not clear in the proposal Thanks, Mikhail Best regards, George [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200604.mbox/[EMAIL PROTECTED] Mikhail Loenko wrote: Hello I would like to make some changes in the crypto module: - Separate implemetation-independent tests from implementation specific ones. - Fix layout according to the proposed scheme [1] Please let me know if you do any changes in that module then I'll delay restruct. Thanks, Mikhail [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/testing.html - 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe,
Re: [classlib] Layout of tests in crypto module
2006/5/16, George Harley [EMAIL PROTECTED]: Mikhail Loenko wrote: Hi George, see below 2006/5/16, George Harley [EMAIL PROTECTED]: Hi Mikhail, I have a couple of minor comments about your proposal for a test layouts. I should have responded sooner, I know, but I have suffered from a number of hardware problems in the past few weeks that slowed things down somewhat for me. Anyway, it's all great but it would be nice to get answers to the following ... 1) The section on Location of the tests in the directory tree proposes modulename/src/tests/impl for Harmony specific tests and modulename/src/tests/api for implementation-independent tests. Where would tests go for Harmony API's that are not part of the J2SE spec but are still accessible ? Strictly speaking they are API as well as being specific to Harmony. The main idea is to separate tests that must pass on any conformant implementation from the tests passing on Harmony only. When these are separated we can e.g. easily validate implementation- independent tests by running them against RI. Actually I would not like to start an endless philosophical discussion here about what are unit vs. api vs. whatever tests. Me ? Start a philosophical discussion ? :-) api is just a name (suggested by Tim) and might be changed to any unconfusing one. So, back to your question, those must go to 'impl' as far as they fail on RI: modulename/src/tests/impl - Harmony specific tests What about the location of tests designed to run on the classpath and tests designed to run on the bootclasspath ? That does not seem to be addressed in this section. When the tests are run how are Directory defines the root of the test suite, then the package goes, see Package names for different types of the tests section: If the test is designed to be run from bootclasspath then its package is the same as the package of the class under test Is it the case that all of the classes under a particular source folder (say src/tests/api/java) get compiled to one output folder ? We have not discuss it yet. So, suggestions are welcome! :) Thanks, Mikhail the bootclasspath and classpath tests distinguished ? Purely on package name ? Did you ever see the append I wrote to the list a couple of weeks ago on this topic ? [1] Yes, I've seen it. As you could notice we had more test categories. They are described in the same thread. We might have independent tests running from bootclasspath and specific ones running from classpath. 2) Still in the Location of the tests in the directory tree section, shouldn't the suggested source folder names include java in there ? e.g. modulename/src/tests/java/api ? What is wrong with the src/test/java (below here is Java code), src/test/resources (below here is non-code test artefacts) convention ? I notice that at present the page does not include any mention of where test resources would go. Yes, you are right. It's missing. It was supposed to be under test type, like: module/src/test/api/java module/src/test/api/resources 3) What does the sentence Tests are not separated by functionality under test, e.g. tests against clone() methods are not separated from tests against equals() methods actually mean ? That was to address Tim's concern: 1. Tests are separated on directory level by 'intention' I agree where the intention is broad (i.e. functional tests vs. performance tests vs. stress tests) but I'm not convinced that we need to separate to a precise 'intent', at least I've never been in a position where I've wished that my my serialization tests are separate from my cloning tests or whatever. Feel free to reword if something is not clear in the proposal Thanks, Mikhail Best regards, George [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200604.mbox/[EMAIL PROTECTED] Mikhail Loenko wrote: Hello I would like to make some changes in the crypto module: - Separate implemetation-independent tests from implementation specific ones. - Fix layout according to the proposed scheme [1] Please let me know if you do any changes in that module then I'll delay restruct. Thanks, Mikhail [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/testing.html - 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
[DRLVM] build process improvement
My personal opinion is we need to improve the existent build system for DRLVM contribution. I'd like to share my thoughts how it can be accomplished. It's known there are two stages of build process: - Downloading the sources for the third party tools (./build.sh update); - Compilation process (./build.sh). First stage is enough prolonged process and should be performed by each who is interested in this. It's clear the versions of third party tools will not be permanently changed (I mean very often). Therefore there are no needs to compile them each of participants. It'd be fine to have these sources pre-compiled (another snapshot?) and to download the binaries at the VM compilation stage. In my opinion it will speed up the DRLVM build process and all will be only happy. Maybe it's prematurely to think about this right now. I don't know. I just want to understand what people think about this. Does it make big sense to make it? Thanks, Vladimir.
RE: [Stress tests] generator review I
Alexei, Thanks you for your comments. They were very useful. Fixes according to most comments are included into the new version. Please, find the new version (0.2) and all previous versions here: http://issues.apache.org/jira/secure/ManageAttachments.jspa?id=12340105 Some disputes: The problem is that deadlocked tests are counted as passed I had resolved this problem in some other way that you suggested. Please, find it in source. (Briefly, I've introduced new parameter - timeToAbort). BTW, using this approach we can use IGenerator interface for generators instead of a parent class. I like interfaces more even if they are slower. :-) They are more flexible. I'm ready to agree with this point, but I want to ask the community first. Does it make sense to abolish current heritage model? Thanks, Alexander Shipilov. 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: [continuum] BUILD FAILURE: Classlib/win.ia32 Build/Test
This has broken because the subant target picks up any directory matching modules/* which has a make/build.xml in it. The modules/rmi2/ make/build.xml isn't integrated so it breaks the build. Quick fix would be to rename: modules/rmi2/make/build.xml to: modules/rmi2/make/build.orig.xml Tim, I guess you'll be buying the beers at JavaOne then? ;-) Regards, Mark. On 16 May 2006 at 15:05, Apache Harmony Build [EMAIL PROTECTED] wrote: Online report : http://ibmonly.hursley.ibm.com/continuum/win.ia32/servlet/con tinuum/target/ProjectBuild.vm/view/ProjectBuild/id/6/buildId/954 Build statistics: State: Failed Previous State: Ok Started at: Tue, 16 May 2006 15:04:04 +0100 Finished at: Tue, 16 May 2006 15:05:14 +0100 Total time: 1m 9s Build Trigger: Schedule Exit code: 1 Building machine hostname: hy1 Operating system : Windows XP Java version : 1.5.0(IBM Corporation) [SNIP - first attempt was over the -dev list 10 byte limit] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] build process improvement
Vladimir Gorr wrote: My personal opinion is we need to improve the existent build system for DRLVM contribution. ... Therefore there are no needs to compile them each of participants. It'd be fine to have these sources pre-compiled (another snapshot?) The idea of having something precompiled looks close to idea of HDK (Harmony Development Kit): to have a binary bundle which makes development of Harmony as convenient as possible. I think having third party libraries precompiled qualifies as making DRLVM developer life easier, so it is well worth of implementing in HDK. As far as I remember, the consensus about HDK was that it would be a good thing, but nobody yet volunteered to do it. -- Salikh - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [continuum] BUILD FAILURE: Classlib/win.ia32 Build/Test
Mark Hindess wrote: This has broken because the subant target picks up any directory matching modules/* which has a make/build.xml in it. The modules/rmi2/ make/build.xml isn't integrated so it breaks the build. Quick fix would be to rename: modules/rmi2/make/build.xml to: modules/rmi2/make/build.orig.xml Hi Mark, Done. Best regards, George Tim, I guess you'll be buying the beers at JavaOne then? ;-) Regards, Mark. On 16 May 2006 at 15:05, Apache Harmony Build [EMAIL PROTECTED] wrote: Online report : http://ibmonly.hursley.ibm.com/continuum/win.ia32/servlet/con tinuum/target/ProjectBuild.vm/view/ProjectBuild/id/6/buildId/954 Build statistics: State: Failed Previous State: Ok Started at: Tue, 16 May 2006 15:04:04 +0100 Finished at: Tue, 16 May 2006 15:05:14 +0100 Total time: 1m 9s Build Trigger: Schedule Exit code: 1 Building machine hostname: hy1 Operating system : Windows XP Java version : 1.5.0(IBM Corporation) [SNIP - first attempt was over the -dev list 10 byte limit] - 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]
So today Sun announced...
I was at the J1 keynote this morning hoping to hear news about Sun open-sourcing Java. First, they announced some kind of distribution-like agreement with Ubuntu, so that any Debian-based distro can easily install Java. It wasn't clear if they really are going to distribute Ubuntu w/ Java or just make it easy to install via apt. I guess it's a new license for their binaries. This is good news - one of the motivations of Harmony was to help make Java a first-class citizen on Linux, and this is a solid step in that direction. Second I'm not sure how to describe this. When Jonathan Schwartz (the CEO of Sun) asked Rich Green (the new EVP of software) if he was going to open-source Java, the answer was the question isn't if, but how... (or something like that) I suppose that means they have made some sort of decision to do it, but have no idea how or when. So, while many of us knew that Sun will OSS Java eventually, it's still good news, and it's nice to see that the Java ecosystem is moving slowly but surely to openness :) 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: So today Sun announced...
On Tue, May 16, 2006 at 10:46:55AM -0700, Geir Magnusson Jr wrote: I was at the J1 keynote this morning hoping to hear news about Sun open-sourcing Java. First, they announced some kind of distribution-like agreement with Ubuntu, so that any Debian-based distro can easily install Java. It wasn't clear if they really are going to distribute Ubuntu w/ Java or just make it easy to install via apt. I guess it's a new license for Since I am not at JavaOne, and thus out of reach of catapulted T-shirts, here is the gist of it: SPOILER ALERT This post contains sarcasm and pokes mild fun at Sun. You can still hit 'd', if you can't stand someone making fun of Sun's antics. SPOILER ALERT Basicially, Sun decided to fix the more wacky parts of the binary license that made it impossible for distributions to ship the JDK without having to ram down Sun's proprietary software down the throats of their users, and leave them no choice of a free software alternative. After ~5 years of Debian pointing out the obvious issues[1] of that one, Sun eventually figured out that it may not be such a great idea, after all. That blazingly fast display of the ability to listen follows Schwartz's so accurately titled blog entry Java, and Survival of the Most Adaptable. E pur si muove! :) their binaries. This is good news - one of the motivations of Harmony was to help make Java a first-class citizen on Linux, and this is a solid step in that direction. Sorta. Kinda. It's basically the first step Sun made to get off their appreciation for applying Microsoft's Windows OEM licensing concepts to the redistributors of the JDK/JRE binaries. They could have done a lot better than with the license they ended up with. They could have also done worse, I guess, given Sun's legal divisions' masterworks like the Read Only license. It's a huge step for Sun, no wonder it took 5 years to remove a handful of clauses from the BCL. :) Second I'm not sure how to describe this. When Jonathan Schwartz (the CEO of Sun) asked Rich Green (the new EVP of software) if he was going to open-source Java, the answer was the question isn't if, but how... (or something like that) I suppose that means they have made some sort of decision to do it, but have no idea how or when. Well, if you've seen Jonathan Schwartz pompously 'open source Java3D' a few years ago, and then seen that after the hype cleared up, it meant that Sun was keeping Java3D proprietary, and just releasing a bunch of coding examples under a anti-nuclear BSD license, you know what to expect: more of the same. My guess from Sun's past performance pseudo-open-sourcing Java3D, JAI, etc. is that Schwartz will 'open source Java' in 2010, with huge fanfares, and when one looks at the small print, that will actually mean that you'll be able to get the examples from the Swing trail, and nothing else, under the anti-nuclear BSD license. :) So, while many of us knew that Sun will OSS Java eventually, it's still good news, and it's nice to see that the Java ecosystem is moving slowly but surely to openness :) For a suitable definition of 'openness', which Sun has not figured out yet ... so no new license announcement just yet. :) Nevertheless, I propose the name Java 'Openness' License for the upcoming wonderlicense at JAvaOne 2010. :) cheers, dalibor topic [1] http://groups.google.de/group/linux.debian.legal/browse_thread/thread/41c95fc0e542c5c5/cfcff8fd3e4b4d63?lnk=stq=jdk+debian-legalrnum=35hl=de#cfcff8fd3e4b4d63 geir - 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: So today Sun announced...
I give Sun credit for two things... 1. preventing polluting of the platform a la J++. In a June 20, 1996, memo entitled windows internet issues Microsoft's then-VP Paul Maritz explainedhttp://www.courttv.com/archive/trials/microsoft/legaldocs/doj_suit.htmlthat it was necessary for the firm to fundamentally blunt Java/AWT momentum in order to protect our core asset Windows – the thing we get paid $s for. 2. Continuing pouring $$$ into its development, despite the screams from the financial gurus telling McNealy and co that it was not generating money for the company. Had it been an IBM project, it would be as alive today as OpenDoc, IBM Voicetype, OS/2, Lotus Smartsuite, VisualAge for Java, VisualAge for Basic, Person to Person (video converence package), VisualAge for C++, Hotmedia (java based streaming), IBM Netcomber, Web Traffic Express (proxy-cache) the list of abandoned IBM software by clueless IBM managers goes on forever So every time I read about some clueless IBM manager rolling and screaming like a stabbed pig because Sun still controls OpenOffice or Sun should opensource java I grin and think no line of code deserves to be sent to IBM's clueless managers' way... ...I guess kicking Sun is becoming some sort of national sport -- not that they don't have anything to be criticized about http://geekgaucho.blogspot.com/2006/05/uglification-of-sun-workstation-cases.html ...but their software strategy and their contributions to the open source camp over the years is something worth praising, not ridiculing... Graham Hamilton, Sun VP said in his blog: The licensing rules for J2SE 5.0were carefully designed to allow independent, compatible open-source implementations of the J2SE specification. FC On 5/16/06, Dalibor Topic [EMAIL PROTECTED] wrote: On Tue, May 16, 2006 at 10:46:55AM -0700, Geir Magnusson Jr wrote: I was at the J1 keynote this morning hoping to hear news about Sun open-sourcing Java.
Re: [continuum] BUILD FAILURE: Classlib/win.ia32 Build/Test
Arghh. Thanks for bailing me out George -- I'd forgotten about that subant business. I'll seek out purveyors of sack cloth and ashes in the area :-( Regards, Tim George Harley wrote: Mark Hindess wrote: This has broken because the subant target picks up any directory matching modules/* which has a make/build.xml in it. The modules/rmi2/ make/build.xml isn't integrated so it breaks the build. Quick fix would be to rename: modules/rmi2/make/build.xml to: modules/rmi2/make/build.orig.xml Hi Mark, Done. Best regards, George Tim, I guess you'll be buying the beers at JavaOne then? ;-) Regards, Mark. On 16 May 2006 at 15:05, Apache Harmony Build [EMAIL PROTECTED] wrote: Online report : http://ibmonly.hursley.ibm.com/continuum/win.ia32/servlet/con tinuum/target/ProjectBuild.vm/view/ProjectBuild/id/6/buildId/954 Build statistics: State: Failed Previous State: Ok Started at: Tue, 16 May 2006 15:04:04 +0100 Finished at: Tue, 16 May 2006 15:05:14 +0100 Total time: 1m 9s Build Trigger: Schedule Exit code: 1 Building machine hostname: hy1 Operating system : Windows XP Java version : 1.5.0(IBM Corporation) [SNIP - first attempt was over the -dev list 10 byte limit] - 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] -- 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: So today Sun announced...
Dalibor Topic wrote: On Tue, May 16, 2006 at 10:46:55AM -0700, Geir Magnusson Jr wrote: I was at the J1 keynote this morning hoping to hear news about Sun open-sourcing Java. First, they announced some kind of distribution-like agreement with Ubuntu, so that any Debian-based distro can easily install Java. It wasn't clear if they really are going to distribute Ubuntu w/ Java or just make it easy to install via apt. I guess it's a new license for Since I am not at JavaOne, and thus out of reach of catapulted T-shirts, here is the gist of it: SPOILER ALERT This post contains sarcasm and pokes mild fun at Sun. You can still hit 'd', if you can't stand someone making fun of Sun's antics. SPOILER ALERT Basicially, Sun decided to fix the more wacky parts of the binary license that made it impossible for distributions to ship the JDK without having to ram down Sun's proprietary software down the throats of their users, and leave them no choice of a free software alternative. After ~5 years of Debian pointing out the obvious issues[1] of that one, Sun eventually figured out that it may not be such a great idea, after all. That blazingly fast display of the ability to listen follows Schwartz's so accurately titled blog entry Java, and Survival of the Most Adaptable. E pur si muove! :) their binaries. This is good news - one of the motivations of Harmony was to help make Java a first-class citizen on Linux, and this is a solid step in that direction. Sorta. Kinda. It's basically the first step Sun made to get off their appreciation for applying Microsoft's Windows OEM licensing concepts to the redistributors of the JDK/JRE binaries. They could have done a lot better than with the license they ended up with. They could have also done worse, I guess, given Sun's legal divisions' masterworks like the Read Only license. It's a huge step for Sun, no wonder it took 5 years to remove a handful of clauses from the BCL. :) Second I'm not sure how to describe this. When Jonathan Schwartz (the CEO of Sun) asked Rich Green (the new EVP of software) if he was going to open-source Java, the answer was the question isn't if, but how... (or something like that) I suppose that means they have made some sort of decision to do it, but have no idea how or when. Well, if you've seen Jonathan Schwartz pompously 'open source Java3D' a few years ago, and then seen that after the hype cleared up, it meant that Sun was keeping Java3D proprietary, and just releasing a bunch of coding examples under a anti-nuclear BSD license, you know what to expect: more of the same. My guess from Sun's past performance pseudo-open-sourcing Java3D, JAI, etc. is that Schwartz will 'open source Java' in 2010, with huge fanfares, and when one looks at the small print, that will actually mean that you'll be able to get the examples from the Swing trail, and nothing else, under the anti-nuclear BSD license. :) So, while many of us knew that Sun will OSS Java eventually, it's still good news, and it's nice to see that the Java ecosystem is moving slowly but surely to openness :) For a suitable definition of 'openness', which Sun has not figured out yet ... so no new license announcement just yet. :) Nevertheless, I propose the name Java 'Openness' License for the upcoming wonderlicense at JAvaOne 2010. :) Here are the facts: http://packages.debian.org/changelogs/pool/non-free/s/sun-java5/sun-java5_1.5.0-06-1/copyright This is a great step in the widespread use of java in the linux world (apt-get install geronimo, anyone?) but it is no step in the direction of open sourcing java. the article at http://blogs.zdnet.com/BTL/?p=3048 (Simon, you still around here?) claims that this license is equivalent to https://java3d.dev.java.net/jdl-java3d.pdf and that the debian package is called sun-java-jre but claims are bogus. The package is called sun-java5 and it is available in the 'unstable' debian flavor. But I agree with Dalibor, eppur si muove ;-) -- Stefano. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DRLVM bootclasspath
As a PhD student looking for open-source infrastructure, it's exciting to see how much progress is being made in the Harmony project! That said, I've run into some strange behavior trying to run the DRLVM on my machine (x86 running Fedora Core 1). The VM itself seems to build fine, but I get the following error when I try to run it (from exctract_dir/build/lnx_ia32_gcc_release/deploy/jre/bin) ./ij.sh Hello java/lang/NoClassDefFoundError : java/lang/VMClassRegistry After tinkering around a bit, I have managed to run Hello.class by explicitly setting the bootclasspath: ./ij.sh -Xbootclasspath:extract_dir/build/lnx_ia32_gcc_release/ deploy/jre/lib/boot/kernel.jar:extract_dir/build/ lnx_ia32_gcc_release/deploy/jre/lib/boot/luni.jar:extract_dir/build/ lnx_ia32_gcc_release/deploy/jre/lib/boot/luni-kernel- stubs.jar:extract_dir/build/lnx_ia32_gcc_release/deploy/jre/lib/ boot/nio.jar:extract_dir/build/lnx_ia32_gcc_release/deploy/jre/lib/ boot/security.jar:extract_dir/build/lnx_ia32_gcc_release/deploy/jre/ lib/boot/nio_char.jar:extract_dir/build/lnx_ia32_gcc_release/deploy/ jre/lib/boot/icu4jni-3.4.jar Hello Any ideas what is wrong? FYI, I am using the latest (as of yesterday) prebuilt Harmony class libraries. Thanks, Naveen - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
HarmonyOne
If you are coming, we're upstairs. Call my cell +1 203 665 6437 to find us - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DRLVM bootclasspath
Hi Naveen, On 5/17/06, Naveen Neelakantam [EMAIL PROTECTED] wrote: As a PhD student looking for open-source infrastructure, it's exciting to see how much progress is being made in the Harmony project! That said, I've run into some strange behavior trying to run the DRLVM on my machine (x86 running Fedora Core 1). The VM itself seems to build fine, but I get the following error when I try to run it (from exctract_dir/build/lnx_ia32_gcc_release/deploy/jre/bin) ./ij.sh Hello java/lang/NoClassDefFoundError : java/lang/VMClassRegistry I'm not sure but could you please unset the CLASSPATH env variable and try again? After tinkering around a bit, I have managed to run Hello.class by explicitly setting the bootclasspath: I believe there are no needs to make this. ./ij.sh -Xbootclasspath:extract_dir/build/lnx_ia32_gcc_release/ deploy/jre/lib/boot/kernel.jar:extract_dir/build/ lnx_ia32_gcc_release/deploy/jre/lib/boot/luni.jar:extract_dir/build/ lnx_ia32_gcc_release/deploy/jre/lib/boot/luni-kernel- stubs.jar:extract_dir/build/lnx_ia32_gcc_release/deploy/jre/lib/ boot/nio.jar:extract_dir/build/lnx_ia32_gcc_release/deploy/jre/lib/ boot/security.jar:extract_dir/build/lnx_ia32_gcc_release/deploy/jre/ lib/boot/nio_char.jar:extract_dir/build/lnx_ia32_gcc_release/deploy/ jre/lib/boot/icu4jni-3.4.jar Hello Any ideas what is wrong? FYI, I am using the latest (as of yesterday) prebuilt Harmony class libraries. Thanks, Vladimir. Thanks, Naveen - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] build process improvement
On 5/16/06, Salikh Zakirov [EMAIL PROTECTED] wrote: Vladimir Gorr wrote: My personal opinion is we need to improve the existent build system for DRLVM contribution. ... Therefore there are no needs to compile them each of participants. It'd be fine to have these sources pre-compiled (another snapshot?) The idea of having something precompiled looks close to idea of HDK (Harmony Development Kit): to have a binary bundle which makes development of Harmony as convenient as possible. Yes, my suggestion is not new idea. I my opinion the HDK is a long-term task. All I suggested can be made at short time. We only need to slightly modify the build system and to get the image of third party tools. I suppose it will significantly make easy the life each of us and save money eventually :-). Thanks, Vladimir. I think having third party libraries precompiled qualifies as making DRLVM developer life easier, so it is well worth of implementing in HDK. As far as I remember, the consensus about HDK was that it would be a good thing, but nobody yet volunteered to do it. -- Salikh - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DRLVM bootclasspath
Hi Vladimir, On May 16, 2006, at 10:19 PM, Vladimir Gorr wrote: Hi Naveen, On 5/17/06, Naveen Neelakantam [EMAIL PROTECTED] wrote: As a PhD student looking for open-source infrastructure, it's exciting to see how much progress is being made in the Harmony project! That said, I've run into some strange behavior trying to run the DRLVM on my machine (x86 running Fedora Core 1). The VM itself seems to build fine, but I get the following error when I try to run it (from exctract_dir/build/lnx_ia32_gcc_release/deploy/jre/bin) ./ij.sh Hello java/lang/NoClassDefFoundError : java/lang/VMClassRegistry I'm not sure but could you please unset the CLASSPATH env variable and try again? It is unset. Is there a way to check what the current setting for the bootclasspath is? Naveen - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
