I'm with you, Dan, that we need to be looking at the big picture (as well as the administrivia).
It was mentioned by Sean in another post that River will appeal to two kinds of developers--the hard core dev wanting full access to the tool and the more typical dev who wants the complex bits hidden away. I agree, and would suggest that River should attempt to be an exceptional platform for building other tools. Optionally (preferably, in my mind) it could provide its own toolkit on top of that framework to prove the API. As an example, I'd like to see the Configuration mechanism refactored to be entirely Java-based. Then the current code could be modified to adapt from the current configuration format to the Java configuration. The hard-core dev could still have the full power of the runtime configuration but tool providers would have an easier time providing alternative implementations (Groovy, XML, etc.). Backwards compatibility is maintained but new options are opened up. Configuration is a very visible point of difficulty for new users. Jeff On 2/6/07, Dan Creswell <[EMAIL PROTECTED]> wrote:
Okay, so do we think that developers will be attracted by fixes to PreferredClassLoader or coding styles or debate about rules for checkins or a collection of JIRA issues they can look at or....... Will they be attracted because Jini is deemed cool, it's accessible, there are compelling reasons to use it, there's a strong direction which everyone can see benefit from, there are some serious challenges outlined that people can contribute to etc? Or maybe something else entirely?
