Hi Dennis: I’ll bite twice:
- Your offer to contribute Rio may have been before my time as a committer, because I don’t recall the discussion (mind you I’m also at a loss to recall what I had for dinner last night ;-). How was River unwelcoming, and do you feel the same situation exists now? - Could you give a little detail on why you think container projects should be outside River? Is it just development stickiness, or something else? I’ll expand on why I think River needs a container desperately: Basically there is no way for a developer to use Jini or River as it stands. For reasons that we’ve talked about endlessly, the Service Starter approach is unworkable (even without a potential race condition). That isn’t new - I remember when I started using Jini many years ago, I spent at least two days just bringing up Reggie. Then another two days getting a service running The “new-user” experience has been an issue since before we came to Apache. That’s why I wrote Harvester, that’s why Dennis created Rio, that’s why there were half a dozen containers created. In fact I suspect that every developer who’s ever used Jini did their own container implementation, in one form or another. As a result, we are not attracting users (we can’t even point to a “first steps” example that works), and hence not attracting developers. In the board minutes, one of the Apache Directors commented (quite correctly), that it’s a long time (2011) since we’ve added a committer or PMC member. Now, we’ve had discussions about changing the build system, modularizing it, etc, in hopes of attracting developers. I think those discussions miss the point. In my opinion, we don’t need a group of new developers messing around in the River source code (yet). What we need is new developers to use River in their daily work, to create SOA applications. Then we’ll find where the pain points are in River, and interested developers can fix them (probably becoming PMC members in the process). But right now, developers have a very difficult time adopting River, or even running a sample application. This problem is more important than bugs or race conditions. Bugs and race conditions don’t even exist for users if users can’t use the code to begin with. I’m fine with developing the container on Github if the community decides that’s the right decision, but in the meantime I’m going to argue hard for a better user experience. Cheers, Greg. On Feb 18, 2014, at 10:30 AM, Dennis Reedy <dennis.re...@gmail.com> wrote: > > On Feb 18, 2014, at 1011AM, Greg Trasuk <tras...@stratuscom.com> wrote: > >> >> By the way, inevitably this container will be compared to Rio and other >> containers, and someone will ask “Why didn’t you just use Rio (or >> ‘startnow', or Seven, etc)?” What can I say? I had a different itch to >> scratch. Rio includes quality-of-service handling that I didn’t need, and I >> wanted a container that had a similar deployment model to Tomcat, so I wrote >> it inside the Apache River project. People are also encouraged to look at >> Rio, and if the Rio group wants to contribute code to River, we should >> welcome them. > > I've offered before, River just has not (in the past) been welcoming. Right > now, I dont think that either your project or Rio should be part of River. > I'd prefer that we have a Related Projects page that includes pointers to > River related projects. That might be easiest. > > Dennis >
