river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@trasuk.com>
Subject Next steps after 2.2.1 release
Date Sun, 07 Apr 2013 02:18:47 GMT

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.

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.


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.

View raw message