On Sun, 2013-04-07 at 06:34, Peter Firmstone wrote: > Oh, hang on, are you developing on Windows? If so, it's not supported > in 2.2.0. >
OSX 10.8 in this case, although I also plan to run the test suite on Windows XP32 and Win7-64. Possibly also Solaris 10. As I recall the "Windows not supported" was primarily about spaces in the file path. If that's the case, then IBM's Websphere is not supported on Windows either. I was planning to arrange for a space-free directory path. People have been running Jini on Windows since the dawn of time. Greg. > Peter Firmstone wrote: > > Greg, > > > > You need to spend some more time figuring out why those tests are > > failing, that isn't normal, when 280 tests fail, there's usually > > something wrong with configuration. The qa test suite just isn't that > > brittle ;) The tests that fail due to concurrency errors don't fail > > often, we're talking 3/10 you might get a failure (if you're lucky) > > and likely, you won't see any failures on single core hardware. The > > Jenkins tests tend to be more likely to fail because they run > > concurrent with other builds, in a busy network environment (sockets > > in use etc), with lots of superfluous discovery processes going in the > > background. > > > > If you need some help with the source tree, I'm quite familiar with > > it, don't be afraid to ask questions. > > > > This is a big distribution, there is a lot of code, it is initially > > difficult to find your way around, but patience will be rewarded. > > > > There are 3 test suites: > > > > 1. trunk/test > > 2. trunk/qa/src > > 3. trunk/qa/jtreg > > > > The first is the junit test suite, the second is the qa integration > > test suite and tck, which simulates a network environment with all the > > services, the last is the jtreg regression test suite. > > > > When you've done further investigation and better understand the code, > > then we'll be in a better position for discussion, right now the > > immediate focus should be on a 2.2.1 release. > > > > I'll switch to your branch and run the tests if you like. > > > > I'd also like to encourage you to look at the code in > > skunk/qa-refactoring, it's well documented and should be easy to read, > > I've followed Kent Beck's recommendations for code readability. > > > > I hope this helps. > > > > Regards, > > > > Peter. > > > > > > Greg Trasuk wrote: > >> OK, so in my last message I talked about how (speaking only for > >> myself) I'm a little nervous about the state of the trunk. > >> > >> So what now? > >> Problems we need to avoid in this discussion: > >> ------------------------------------------------------------- > >> > >> - Conflation of source tree structure issues with build tool selection. > >> - Conflation of Maven build, Maven as codebase provider (artifact > >> urls), and posting artifacts to Maven Central > >> - Wish lists of pet features > >> - Bruised egos and personal criticisms. > >> > >> Issues I see, in no particular order: > >> ---------------------------------------------- > >> - We've done changes both to the test framework and the code, and > >> lots of them. We should do one or the other, or small amounts of > >> coevolution, if absolutely necessary. > >> - Really, I'd like to see a completely separate integration test, and > >> have the TCK tests separated out again. > >> - The source tree is incomprehensible > >> - The tests appear to be awfully sensitive to their environment. > >> Insofar as when I run them locally on an untouched source tree, I get > >> 280 failures. > >> - There have been changes to class loading and security subsystems. > >> These subsystems are core to Jini, and the changes were made to the > >> existing source, so there's no way to "opt-out" of the changes. I'd > >> like to see radical changes be optional until proven in the field, > >> where possible. In the case of policy providers and class loaders, > >> that should be easy to do. > >> - Similarly, it seems there have been some changes to the JERI > >> framework. > >> - There are ".jar" files in our repository. I'll stipulate that the > >> licensing has been checked, but it smells bad. > >> > >> Discussion > >> ----------------- > >> I guess the biggest thing I'd like to see is stability in the test > >> framework. Perhaps it needs refactoring or reorganization, but if > >> so, we need to be very careful to separate it from changes to the > >> core functionality. > >> > >> Next, I'd like for it to be easier to comprehend the source tree. I > >> think a good way to do that is to separate out (carefully) the core > >> Jini package (basically the contents of jsk-platform.jar) and the > >> service implementations. There's no reason that we have to have one > >> huge everything-but-the-kitchen-sink distribution. That's just a > >> holdover from how Sun structured the JTSK - It was literally a > >> "starter kit". To me it would be fine to have separate deliverables > >> for the platform and the services. > >> > >> While we're separating out the services, it might also be a decent > >> time to implement Maven-based builds if we think that's a good idea. > >> I'd start with Reggie. It would also be a good time to get rid of > >> the "com.sun.jini" packages. > >> > >> Aside: I'm personally ambivalent on Maven (which is to say I'm > >> nowhere near as negative on it as I once was). I do agree with > >> Dennis, though, that the jars and appropriate poms need to be > >> published to Maven Central. There's no doubt that users will > >> appreciate that. > >> > >> Once we have a stable set of regression tests, then OK, we could > >> think about improving performance or using Maven repositories as the > >> codebase server. > >> > >> I realize this won't be popular, but my gut feel is that we need to > >> step back to the 2.2 branch and retrace our steps a little, and go > >> through the evolution again in a more measured fashion. > >> > >> Proposal > >> ------------ > >> > >> 1 - Release version 2.2.1 from the 2.2 branch. > >> 2 - Create a separate source tree for the test framework. This could > >> come from the "qa_refactor" branch, but the goal should be to > >> successfully test the 2.2.1 release. Plus it should be a no-brainer > >> to pull it down and run it on a local machine. > >> 3 - Release 2.2.2 from the pruned jtsk tree. Release 1.0.0 of the > >> test framework. > >> 4 - Pull out the infrastructure service implementations (Reggie, > >> Outrigger, Norm, etc) from the core into separate products. Release > >> 1.0.0 on each of them. Release 2.2.3 from the pruned jtsk tree. > >> 5 - Adopt a fixed release cycle. Not sure if it should be quarterly > >> or biennial, or whether it should be all products at once or > >> staggered releases. We'll need to discuss. > >> 6 - Then we can start making changes if necessary to the individual > >> products. And also try to deal with making it easier for new users > >> to use the technology. > >> > >> So there you go. Opinions? > >> > >> Greg Trasuk. > >> > >> > >> > >> > > > >
