Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <49EE2A73.8070403@zeus.net.au>
Date: Wed, 22 Apr 2009 06:20:03 +1000
From: Peter Firmstone <jini@zeus.net.au>
User-Agent: Thunderbird 2.0.0.14 (X11/20080531)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: Build failed in Hudson: River-trunk #163
References: <6237744.1341240009299209.JavaMail.hudson@hudson.zones.apache.org>
	 <1240010004.5782.32.camel@localhost>
	 <510143ac0904172352k52234577r55a19aa5ba9af312@mail.gmail.com>
	 <1240092074.5782.105.camel@localhost>
	 <510143ac0904191516k11b6c608rd5c653ce5aa7d0d8@mail.gmail.com>
	 <49ED8938.3060709@zeus.net.au>
	 <759a1cdf0904210512u67e9b24ck903ac2c132917f91@mail.gmail.com>
	 <20090421151237.GA19950@east> <1240331238.4458.5.camel@localhost>
In-Reply-To: <1240331238.4458.5.camel@localhost>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Perhaps we could:

1. Make a note of the qa suite / integration tests depending on internal 
sun API's, they will
    fail on JDK 1.4.2 and 1.5 and require JDK 1.6 in the README.TXT

2. Make that qa release you were talking about available for download 
for those that don't want to compile the integration tests with JDK 1.6  
Can they be compiled on JDK 1.6, with a target of 1.4.2 and run on Java 
1.4.2?

3. If the compiled tests will run on Java 1.4.2, raise a low priority or 
trivial issue on jira regarding the integration tests relying on sun 
internal API's and requiring JDK 1.6 for these two tests with a link to 
the discussion history in the mail archives.

These are the integration tests, not the River platform, so I can't see 
any issues with requiring them to be compiled with JDK 1.6.

What are your thoughts?

Cheers,

Peter.


Ok, compiling on JDK 1.6 all good so far.

My environment has Sun's JDK versions 1.4.2 1.5 and 1.6, I can test with 
all three ;)

$ uname -aX
SunOS bluto 5.10 Generic_137111-06 sun4u sparc SUNW,Ultra-80System = SunOS
Node = bluto
Release = 5.10
KernelID = Generic_137111-06
Machine = sun4u
BusType = <unknown>
Serial = <unknown>
Users = <unknown>
OEM# = 0
Origin# = 1
NumCPU = 4

Off topic rant:
Would you believe this old bomb has SAS, USB, firewire, bluetooth etc... 
yeah I'm waiting for Sun/Oracle to release something new that can be 
used as a Workstation, other than x86 ;) , don't like the insecurity of 
x86.  Nevermind, makes a good dev box.

Jonathan Costers wrote:
> Of course .. How could I forget.
> Thanks for reminding me :-)
>
> Something a bit off-topic: the "jtreg tests" are mentioned in the
> discussion you linked to. How do these differ from the other harness/QA
> tests? I must say I haven't really looked at them deeply, but I did
> notice them and that they are separate from the QA suite ...
> For the moment the source just sits there .. Nothing is even compiled.
> Would you be able to give some pointers?
>
> Thanks again and best regards
> Jonathan
>
>   
>> FWIW, the build failure below looks like the issue that Brian Murphy
>> and I had discussed back in this and subsequent messages:
>>
>> http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200805.mbox/%3C20080523052848.GA15826@east%3E
>>
>> -- Peter
>>
>>
>> On Tue, Apr 21, 2009 at 02:12:14PM +0200, Jonathan Costers wrote:
>>     
>>> Hi Peter
>>>
>>> What is the environment you are using to build?
>>>
>>> Are you building with a Sun JDK / OpenJDK or something else? What version?
>>> What is your JAVA_HOME setting, if any?
>>> Does Ant pick up the correct JDK?
>>>
>>> Note that the QA test suite also depends on Sun internal APIs here and there
>>> (sun.net.spi.nameservice.NameService for instance). Since I am (and Hudson
>>> is) using openjdk to build, tools.jar is put on the classpath automatically
>>> by Ant. I've had no time to fix this yet. But it is one of the things on my
>>> list. Feel free to step in, though.
>>>
>>> Thanks and best regards
>>> Jonathan
>>>
>>> 2009/4/21 Peter Firmstone <jini@zeus.net.au>
>>>
>>>       
>>>> I'm getting the following 2 errors during the build on my machine:
>>>>
>>>>   [javac]
>>>> /opt/src/river/trunk/qa/src/com/sun/jini/test/impl/reggie/NameServiceImpl.java:29:
>>>> com.sun.jini.test.impl.reggie.NameServiceImpl is not abstract and does not
>>>> override abstract method lookupAllHostAddr(java.lang.String) in
>>>> sun.net.spi.nameservice.NameService
>>>>   [javac] public class NameServiceImpl implements NameService {
>>>>   [javac]        ^
>>>>   [javac]
>>>> /opt/src/river/trunk/qa/src/com/sun/jini/test/impl/reggie/NameServiceImpl.java:42:
>>>> lookupAllHostAddr(java.lang.String) in
>>>> com.sun.jini.test.impl.reggie.NameServiceImpl cannot implement
>>>> lookupAllHostAddr(java.lang.String) in sun.net.spi.nameservice.NameService;
>>>> attempting to use incompatible return type
>>>>   [javac] found   : java.net.InetAddress[]
>>>>   [javac] required: byte[][]
>>>>   [javac]     public InetAddress[] lookupAllHostAddr(String host)
>>>>   [javac]                          ^
>>>>   [javac] 2 errors
>>>>   [javac] 3 warnings
>>>>
>>>> BUILD FAILED
>>>> /opt/src/river/trunk/build.xml:2284: The following error occurred while
>>>> executing this line:
>>>> /opt/src/river/trunk/qa/build.xml:124: The following error occurred while
>>>> executing this line:
>>>> /opt/src/river/trunk/common.xml:99: Compile failed; see the compiler error
>>>> output for details.
>>>>
>>>>
>>>>
>>>>
>>>> Jukka Zitting wrote:
>>>>
>>>>         
>>>>> Hi,
>>>>>
>>>>> On Sun, Apr 19, 2009 at 12:01 AM, Jonathan Costers
>>>>> <jonathan.costers@googlemail.com> wrote:
>>>>>
>>>>>
>>>>>           
>>>>>> OK, here is what I think we should use for now:
>>>>>>
>>>>>> cd $WORKSPACE/jtsk/trunk
>>>>>> ant all.clean release qa.run
>>>>>>
>>>>>>
>>>>>>             
>>>>> OK, done.
>>>>>
>>>>> BR,
>>>>>
>>>>> Jukka Zitting
>>>>>
>>>>>
>>>>>
>>>>>           
>>>>         
>
>