river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Hobbs <tvho...@googlemail.com>
Subject Re: Release 2.2 comments
Date Thu, 30 Jun 2011 08:12:49 GMT
If its not used then delete it now.  Why wait?  But I get what you're saying
about the problem being more than just this file.  Is this building in 6 and
testing in 5/6 documented on the web?  I can't remember off hand and not in
a position to check.

In any case...

+1 release current artifacts (river.a.o/~thobbs/river)



Grammar and spelling have been sacrificed on the altar of messaging via
mobile device.

On 30 Jun 2011 08:06, "Peter" <jini@zeus.net.au> wrote:
> The qa suite needs to be considered separately from the main build. It
currently requires jdk1.6, there are other tests using sun internal
implementations that depend on jdk 1.6.
>
> With source=1.4 or jsr14 it didn't matter, it still had to be compiled
with 1.6, we bundled it into the main build in recent times, it used to have
it's own separate make build.
>
> If we use source=5, target=5 we need to check it compiles and runs on java
6, even if it doesn't compile on 5.
>
> My preference:
>
> Compile on jdk 1.6, test on java 5 and 6, some tests will fail on 5.
>
> Java is bytecode backward compatible, but not necessarily source backward
compatible.
>
> Forget deleting tests, this is just a distraction and side effect of using
a very large build while trying to support a number of platforms.
>
> +1 release current artifacts.
>
> This is the best release so far with a number of fixes, lets get it out
there.
>
> We can deal with this issue given proper time to consider alternatives to
sun internal implementations, eg DI, mocking?
>
> File a jira, lets release, fix the qa platform compile issue later.
>
> Peter.
>
> ----- Original message -----
>> I'm signing off for the night. Sill one failure.
>>
>> Patricia
>>
>>
>> On 6/29/2011 8:56 PM, Patricia Shanahan wrote:
>> > I got a QA test failure,
>> > com/sun/jini/test/impl/reggie/MultihomedClientTest.td. The failure is
>> > due to the missing
>> > com.sun.jini.test.impl.reggie.NameServiceDescriptorImpl class.
>> >
>> > That leaves us with the following options:
>> >
>> > 1. Insist on Java 5 compilation, and change the code to match the Java
5
>> > version of the interface.
>> >
>> > 2. Delete the files, and drop one or more tests which are presumably
>> > testing configurations that nothing else tests.
>> >
>> > I'm inclined towards the first answer, but not strongly.
>> >
>> > Patricia
>> >
>> >
>> > On 6/29/2011 2:17 PM, Tom Hobbs wrote:
>> > > Well that's something. A good something! Fingers cross on the QA
>> > > tests. I'm just about to sign off now, but please check the deletions
>> > > into the trunk if/when you're happy with them and I'll create some
new
>> > > RCs.
>> > >
>> > > If only all fixes were as simple.
>> > >
>> > >
>> > > On Wed, Jun 29, 2011 at 9:56 PM, Patricia Shanahan<pats@acm.org>
wrote:
>> > > > I've done a clean build with the classes in question deleted. It
got a
>> > > > "BUILD SUCCESSFUL". I'll start the QA tests that way, but I suggest
>> > > > making
>> > > > that change. (I'm not checking in anything to the trunk right now,
to
>> > > > avoid
>> > > > risk of tripping up your efforts).
>> > > >
>> > > > Patricia
>> > > >
>> > > > On 6/29/2011 1:07 PM, Tom Hobbs wrote:
>> > > > >
>> > > > > I've just done a quick search for uses of NameServiceImpl and
the
only
>> > > > > thing I could find was in NameServiceDescriptorImpl. And I
couldn't
>> > > > > find any references for that.
>> > > > >
>> > > > > Given that the package is "com.sun.jini.test.impl.reggie" for
both of
>> > > > > these classes, can I assume that they're for some test only?
Does
>> > > > > anyone know what they're for? Can we just remove them? (I love
>> > > > > deleting code!)
>> > > > >
>> > > > > I'm sure you guys are aware of the problem, but for anyone new
to
the
>> > > > > party; NameServiceImpl implements NameService which is an
*internal*
>> > > > > Sun class, which by rights we shouldn't really be using anyway.
The
>> > > > > return type of a the lookupAllHostAddr method differs from Java
5
to
>> > > > > 6, so we're unable to build a release that satisfies both Java
>> > > > > versions.
>> > > > >
>> > > > > If we can't get around this, it looks like we might be stuck
at
Java 5
>> > > > > and only 5 until we come up with something clever.
>> > > > >
>> > > > > This is disappointing because I was hoping to build some new
release
>> > > > > candidates tonight...
>> > > > >
>> > > > > Thoughts?
>> > > > >
>> > > > > Tom
>> > > > >
>> > > > > On Wed, Jun 29, 2011 at 3:41 AM, Peter<jini@zeus.net.au>
wrote:
>> > > > > >
>> > > > > > We have a number of uses of internal sun impl classes, I'd
agree they
>> > > > > > should all be replaced so we can expand beyond the sun
>> > > > > > implementation. Is
>> > > > > > there a related jira?
>> > > > > >
>> > > > > > If you can see a simple fix eliminating the sun dependency,
go
for it,
>> > > > > > otherwise I think just fix it enough to get our release
out.
>> > > > > >
>> > > > > > I hadn't given it further consideration last time I looked.
>> > > > > >
>> > > > > > Cheers,
>> > > > > >
>> > > > > > Peter.
>> > > > > >
>> > > > > > ----- Original message -----
>> > > > > > >
>> > > > > > > I think the problem may go deeper.
>> > > > > > > sun.net.spi.nameservice.NameService
>> > > > > > > is a sun.net interface that can change from version
to
version. Is it
>> > > > > > > essential that we have our own implementation?
>> > > > > > >
>> > > > > > > Patricia
>> > > > > > >
>> > > > > > >
>> > > > > > > On 6/28/2011 12:18 AM, Peter wrote:
>> > > > > > > >
>> > > > > > > > Oops, I fixed that but didn't commit, sorry Not
near my dev
box,
>> > > > > > > > but the fix
>> > > > > > > > is relatively simple, get byte array from each
InetAddress,
and
>> > > > > > > > return
>> > > > > > > > byte[][] instead, can someone fix it?
>> > > > > > > >
>> > > > > > > > ----- Original message -----
>> > > > > > > > >
>> > > > > > > > > I downloaded the source, and tried a naive
build on
Windows XP,
>> > > > > > > > > Cygwin.
>> > > > > > > > > I put a JDK 1.5 bin directory at the start
of my path,
and ran
>> > > > > > > > > "ant all.build". It failed with the following
errors:
>> > > > > > > > >
>> > > > > > > > > compile:
>> > > > > > > > > [javac] Compiling 1993 source files to
>> > > > > > > > > C:\Documents and
>> > > > > > > > > Settings\Administrator\My
>> > > > > > > > >
>> > > > > > > > >
Documents\River_2.2\apache-river-2.2.0-src\apache-river-2.2.0\qa\build\classes
>> > > > > > > > >
>> > > > > > > > > [javac] C:/Documents and
>> > > > > > > > > Settings/Administrator/My
>> > > > > > > > >
>> > > > > > > > >
Documents/River_2.2/apache-river-2.2.0-src/apache-river-2.2.0/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] C:/Documents and
>> > > > > > > > > Settings/Administrator/My
>> > > > > > > > >
>> > > > > > > > >
Documents/River_2.2/apache-river-2.2.0-src/apache-river-2.2.0/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] Note: Some input files use or override
a
>> > > > > > > > > deprecated API.
>> > > > > > > > > [javac] Note: Recompile with -Xlint:deprecation
>> > > > > > > > > for details.
>> > > > > > > > > [javac] Note: Some input files use unchecked
or
>> > > > > > > > > unsafe operations.
>> > > > > > > > > [javac] Note: Recompile with -Xlint:unchecked
>> > > > > > > > > for details.
>> > > > > > > > > [javac] 2 errors
>> > > > > > > > >
>> > > > > > > > > (I'm not worried about the deprecated APIs,
just the
compile
>> > > > > > > > > failures.)
>> > > > > > > > >
>> > > > > > > > > I next tried to find instructions. I looked
at
>> > > > > > > > > src-doc/static/build.html. It says "The bin
directory of
the
>> > > > > > > > > Java(TM)
>> > > > > > > > > 2
>> > > > > > > > > SDK, Standard Edition, v 1.4 (or later) must
be in your
>> > > > > > > > > executable search path."
>> > > > > > > > >
>> > > > > > > > > I believe we now need 1.5 or later.
>> > > > > > > > >
>> > > > > > > > > Patricia
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > > >
>> > >
>> >
>> >
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message