Re: svn commit: r658927 - in /incubator/river: jtsk/trunk/ qatests/trunk/ qatests/trunk/source/vob/qa/src/ qatests/trunk/source/vob/qa/src/com/sun/jini/test/impl/reggie/ qatests/trunk/source/vob/qa/src/com/sun/jini/test/resources/ qatests/trunk/sourc

[Brian Murphy <bt...@gmail.com>]

On Fri, May 23, 2008 at 1:28 AM, Peter Jones <pe...@sun.com> wrote:

[I am curious: why update the old directory tree (trunk/qatests) as
> well as the new one (qatests/trunk)?


I'm not sure how much detail you want, but it has to do
with the fact that I had already made the changes in the
original directory layout (river/trunk/qatests & river/trunk/jtsk),
but before I could commit them, the directory structure was
changed; and the changes for the original structure don't
work with the new structure. Since I had more pressing
things to do, I set it all aside until recently. After making the
changes in the new directory structure, I realized I still had the
original modifications to the old structure in my workspace.

Now, I'm not an SVN expert, but it appeared to me that if
I was going to do a single commit for the new structure (to
associate a single changeset # with the modifications),
that I was going to have to perform the commit from the
directory above river/qatests and river/jtsk (that is, from
the river directory); which would also commit the changes
from the old structure, river/trunk. (I'm sure the SVN experts
will eventually chime in on all the different and better ways
I could have achieved what I wanted to do, but I just wanted
to get the stuff in as quickly as possible, while making it
easy to back it all out as a single changeset if problems
were discovered, as it appears they have.)

So I was faced with either committing the old changes, or
reverting them. I chose the former since the old structure is
still visible, and I thought that maybe someone might stumble
onto the old structure and try building the tests, and then
complain. Anyway, I new there'd be questions or complaints
either way. So it was kind of a coin toss.


>  I'm unclear why the old tree is even still visible.]


When the new structure was put in place, Mark B said that
at some point the old directory structure should eventually
be removed, but that hasn't happened yet.

Anyway, I presume that the change to this NameServiceImpl class:
>
>
> http://svn.apache.org/viewvc/incubator/river/qatests/trunk/source/vob/qa/src/com/sun/jini/test/impl/reggie/NameServiceImpl.java?r1=615035&r2=658927&diff_format=h
>
> was done so that it would compile against Sun's JDK 6. Unfortunately,
> that makes it no longer compile against earlier Sun JDKs, like 5.0 and
> 1.4.x.


Are you saying that prior to my commit, you were able to checkout
the distribution and compile the qatests under 5.0 and 1.4.x? Or
simply that they would compile under 1.4.x and 5.0, as long as the
appropriate ant, make, maven, shell, etc. script or command line
was provided?

I was assuming, perhaps mistakenly, that no one was using the
tests because the make files wouldn't compile the source and
build the jar files correctly, under any jdk version. So I figured
that being able to compile the tests under 1.6 was better than
nothing at all. But if my assumption was wrong about how the
tests are being used, then maybe we should back out the
changes I made. Do you have an opinion?

I experimented
> with a solution that uses a dynamic proxy implementing NameService
> with an invocation handler that obeys whichever version of the
> interface it determines to be in effect at runtime.



> I would be happy if we could assume JDK 6, but I gather that the
> discussion to raise the minimum even to 5.0 is still pending.


Yes it is. And based on how long it took folks to agree on the
project name, I'm guessing a discussion on the jdk version
could take quite some time. So, since we're talking about a
change to a test -- a single test -- not the actual River/Jini source,
I'm not sure I'd choose to wait for the results of that discussion
to provide a means for people to compile and run the tests;
especially given the fact that I was under the impression no one
was using those tests in the first place. If people are going to
be committing changes in the future, it seems like it would be
useful for them to take advantage of the hundreds and hundreds
of regression tests that already exist, rather than committing
on faith, or rolling their own test infrastructure.

That said, I'm wondering if there's a proposal implied in your
statement above. Are you maybe proposing that the changes
to the reggie/NameServiceImpl test be rolled back, and then
tell folks that they have to compile the tests under 1.4.x or 1.5?
If yes, then I'm certainly okay with that.

Admittedly, the changes I made were at best, a hack, and I made
them because I didn't think anyone else was going to. I focussed
on 1.6 because my company happens to rely on a number of 1.6
features, but I'm okay with requiring 1.4.x/1.5, if that's what you
were getting at. I just don't want to wait for the endless debates
on the jdk version to complete.

I'm expecting that, in time, someone will eventually create robust
ant scripts to replace the hacked up GNU make files, and maybe
you'll change that reggie test to use the solution to the 1.4.x/1.5/1.6
dilemma you outlined, so that the qatests area is more in line with
the jtsk area of the distribution.

Of course, that's a red herring, as this particular problem isn't even
> about that: the tests are depending on a sun.* API, which with a
> different hat on I have little sympathy for-- the API was within its
> rights to change incompatibly, and these tests are just getting what
> they deserve.  As the author of the two affected jtreg tests above,
> though, I plead guilty-- it seemed like an expedient way to get
> automated regression testing for this multihomed handling, not needing
> any special environment configured.


Given that originally the tests were expected to be developed,
maintained, and executed in house, it's completely understandable;
and commendable that there's only one issue of this nature.

Thanks for the feedback, Peter.

Regards,
Brian

Re: svn commit: r658927 - in /incubator/river: jtsk/trunk/ qatests/trunk/ qatests/trunk/source/vob/qa/src/ qatests/trunk/source/vob/qa/src/com/sun/jini/test/impl/reggie/ qatests/trunk/source/vob/qa/src/com/sun/jini/test/resources/ qatests/trunk/sourc

[Brian Murphy <bt...@gmail.com>]

On Sat, May 24, 2008 at 4:37 AM, Mark Brouwer <ma...@marbro.org>
wrote:

Somebody has to start that discussion anyway, so do you have a proposal
> or want to drive that discussion?


No, I'll leave it to those who hold stronger opinions
on the matter. All I wanted to do was give folks a way
to build and run the regression tests against any
changes they might make to the codebase.


> For the test infrastructure I have no real problem with 1.6 (I don't
> know however for those with Mac OS X)


The jdk version issue isn't really that significant for the
tests. We can decide to revert that one test in the repository,
the developers can instead decide to revert it locally only in
their workspace, they can decide to leave that test as is and
build the tests against 1.6, or they can temporarily remove that
one test from their workspace. In any event, all of this will be
moot when Peter puts in the NameService solution he discussed
in his message. In that case, the tests will then build under
1.4.x, 1.5, or 1.6.

To me, the real issue, the issue that involves the most work in
addressing, is that the tests can be built only on systems that
have the GNU make utility installed (which I believe Mac OS X
does). Until someone converts the make files to ant scripts,
Windows users as well as users of some flavors of unix may
be unable to build the tests.

Brian

Re: svn commit: r658927 - in /incubator/river: jtsk/trunk/ qatests/trunk/ qatests/trunk/source/vob/qa/src/ qatests/trunk/source/vob/qa/src/com/sun/jini/test/impl/reggie/ qatests/trunk/source/vob/qa/src/com/sun/jini/test/resources/ qatests/trunk/sourc

[Mark Brouwer <ma...@marbro.org>]

Hi Brian,

Brian Murphy wrote:

>>  I'm unclear why the old tree is even still visible.]
> 
> 
> When the new structure was put in place, Mark B said that
> at some point the old directory structure should eventually
> be removed, but that hasn't happened yet.

That is because no issue was created for that and so I forgot about it
as I never look at the complete River tree these days. I've filed an
issue for that to fix.

>> I would be happy if we could assume JDK 6, but I gather that the
>> discussion to raise the minimum even to 5.0 is still pending.
>
> Yes it is. And based on how long it took folks to agree on the
> project name, I'm guessing a discussion on the jdk version
> could take quite some time. So, since we're talking about a

I don't think it is completely fair to base the expected duration of
such a discussion on the one for the name, it is my experience that
without a compelling reasons to finish something quickly 90% people will
discuss forever ;-)

Somebody has to start that discussion anyway, so do you have a proposal
or want to drive that discussion?

My suggestion is to move to 1.5 for the release after AR2, whether we
want to take advantage of generics in the specs (in a compatible way)
I'm neutral about. Whether we want to start to generify the current
codebase that is rock-solid just for the sake of it, I'm not a big fan
of. I recall that generifying a lot of my libraries was an entertaining
exercise for the simple cases and frustrating for a lot of them.

1.6 is really a bridge to far, it is just a few weeks ago that I was
asked to make an estimate to port some applications written for 1.5 to
1.4 because well they want to deploy on WebSphere 6.0 (and this is a 
very huge bank).

> change to a test -- a single test -- not the actual River/Jini source,
> I'm not sure I'd choose to wait for the results of that discussion
> to provide a means for people to compile and run the tests;
> especially given the fact that I was under the impression no one
> was using those tests in the first place. If people are going to
> be committing changes in the future, it seems like it would be
> useful for them to take advantage of the hundreds and hundreds
> of regression tests that already exist, rather than committing
> on faith, or rolling their own test infrastructure.

I agree and it would be nice if e.g. such a test environment would be
arranged as part of a properly working nightly build. I thank you for
the instructions provided and hopefully I'll find some time so I can try
to get it running here, but it would be nice as well if somebody with a
lot more experience would sort things out a bit here at Apache.

> That said, I'm wondering if there's a proposal implied in your
> statement above. Are you maybe proposing that the changes
> to the reggie/NameServiceImpl test be rolled back, and then
> tell folks that they have to compile the tests under 1.4.x or 1.5?
> If yes, then I'm certainly okay with that.
> 
> Admittedly, the changes I made were at best, a hack, and I made
> them because I didn't think anyone else was going to. I focussed
> on 1.6 because my company happens to rely on a number of 1.6
> features, but I'm okay with requiring 1.4.x/1.5, if that's what you
> were getting at. I just don't want to wait for the endless debates
> on the jdk version to complete.

For the test infrastructure I have no real problem with 1.6 (I don't
know however for those with Mac OS X) although if it ain't much work to
modify I would prefer the same JVM level for all parts of River to
prevent from making mistakes.
-- 
Mark

Re: svn commit: r658927 - in /incubator/river: jtsk/trunk/ qatests/trunk/ qatests/trunk/source/vob/qa/src/ qatests/trunk/source/vob/qa/src/com/sun/jini/test/impl/reggie/ qatests/trunk/source/vob/qa/src/com/sun/jini/test/resources/ qatests/trunk/sourc

[Peter Jones <Pe...@Sun.COM>]

Hi Brian,

On May 23, 2008, at 10:11 AM, Brian Murphy wrote:
> On Fri, May 23, 2008 at 1:28 AM, Peter Jones <pe...@sun.com>  
> wrote:
>> [I am curious: why update the old directory tree (trunk/qatests) as
>> well as the new one (qatests/trunk)?
>
> I'm not sure how much detail you want,

Thanks for indulging me.  To the point of my curiosity: your  
explanation seems consistent with my previous understanding that I  
needn't worry about the old trees (so either choice of yours was fine).

>>  I'm unclear why the old tree is even still visible.]
>
> When the new structure was put in place, Mark B said that
> at some point the old directory structure should eventually
> be removed, but that hasn't happened yet.

I see that he has just filed an issue to do that-- should remove  
confusion from browsing the source trees.

>> Anyway, I presume that the change to this NameServiceImpl class:
>>
>> http://svn.apache.org/viewvc/incubator/river/qatests/trunk/source/ 
>> vob/qa/src/com/sun/jini/test/impl/reggie/NameServiceImpl.java? 
>> r1=615035&r2=658927&diff_format=h
>>
>> was done so that it would compile against Sun's JDK 6. Unfortunately,
>> that makes it no longer compile against earlier Sun JDKs, like 5.0  
>> and
>> 1.4.x.
>
> Are you saying that prior to my commit, you were able to checkout
> the distribution and compile the qatests under 5.0 and 1.4.x? Or
> simply that they would compile under 1.4.x and 5.0, as long as the
> appropriate ant, make, maven, shell, etc. script or command line
> was provided?

I wasn't making any claim about the overall compilability of the  
qatests area-- I haven't tried to build it all from the River tree  
myself.

For my recent River changes, I only tried to run the jtreg suite from  
the River tree.  My changes were all in the JERI area, which has good  
coverage from the jtreg tests, and (as you may recall) the jtreg  
tests are what I am most familiar with, so I focused on running  
them.  In doing so, and running with JDK 6, I encountered this issue  
with test classes implementing sun.net.spi.nameservice.NameService--  
so when I was skimming through your commits, I gathered that you  
encountered the exact same issue with the above reggie test class in  
the regular qatests area, hence my comments about the JDK version  
dependency above.

> I was assuming, perhaps mistakenly, that no one was using the
> tests because the make files wouldn't compile the source and
> build the jar files correctly, under any jdk version. So I figured
> that being able to compile the tests under 1.6 was better than
> nothing at all. But if my assumption was wrong about how the
> tests are being used, then maybe we should back out the
> changes I made. Do you have an opinion?

I suspect that your assumption was right, and I think that it's great  
that you have put this effort into improving the situation.

>> I experimented
>> with a solution that uses a dynamic proxy implementing NameService
>> with an invocation handler that obeys whichever version of the
>> interface it determines to be in effect at runtime.
>
>> I would be happy if we could assume JDK 6, but I gather that the
>> discussion to raise the minimum even to 5.0 is still pending.
>
> Yes it is. And based on how long it took folks to agree on the
> project name, I'm guessing a discussion on the jdk version
> could take quite some time. So, since we're talking about a
> change to a test -- a single test -- not the actual River/Jini source,
> I'm not sure I'd choose to wait for the results of that discussion
> to provide a means for people to compile and run the tests;
> especially given the fact that I was under the impression no one
> was using those tests in the first place. If people are going to
> be committing changes in the future, it seems like it would be
> useful for them to take advantage of the hundreds and hundreds
> of regression tests that already exist, rather than committing
> on faith, or rolling their own test infrastructure.

Agreed, of course.  I probably shouldn't have even mentioned the  
"platform Java version" question, because as I said later, it's  
really a red herring for this particular test issue.  Evolution of  
the Java platform API, in general, should never introduce such  
incompatibility dilemmas, so it should be possible (and is  
important!) to run the tests with a later JDK version.

> That said, I'm wondering if there's a proposal implied in your
> statement above. Are you maybe proposing that the changes
> to the reggie/NameServiceImpl test be rolled back, and then
> tell folks that they have to compile the tests under 1.4.x or 1.5?
> If yes, then I'm certainly okay with that.

I'm not proposing rolling back your changes or anything else in  
particular.  I mostly just wanted to share that I had encountered the  
same problem that you had evidently encountered, although in a  
different River test suite (jtreg vs. the regular qatests), and some  
further thoughts about it.

> Admittedly, the changes I made were at best, a hack, and I made
> them because I didn't think anyone else was going to. I focussed
> on 1.6 because my company happens to rely on a number of 1.6
> features, but I'm okay with requiring 1.4.x/1.5, if that's what you
> were getting at. I just don't want to wait for the endless debates
> on the jdk version to complete.

If we have to choose one or the other, then personally, I think that  
working with JDK 6 (as you chose) is more useful at this point.  But  
I will try to look further into the hack to make it work either way.   
(It's actually less of a problem for the jtreg tests, because they  
are compiled on a per-test basis, so this problem only causes the  
affected tests to fail, it doesn't block executing the rest of the  
suite.)

Cheers,
-- Peter