On Fri, May 23, 2008 at 1:28 AM, Peter Jones <[EMAIL PROTECTED]> 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
