Hi all: I see that we have added a new configuration mechanism to the JTSK trunk, and that this mechanism seems to require followon changes to ServiceStarter, and one would assume new constructors for the services (Reggie, Mahalo, Fiddler, Mercury, Outrigger) that ServiceStarter is intended to start.
I see that the new configuration mechanism requires a Velocity jar to be added to the build dependencies, and a jar file has been checked into the svn repository under 'trunk'. I see that the Hudson build has been broken and repaired once or twice. I don't quite understand how using a text-based tool to generate inputs to ConfigurationFile is significantly better than the override mechanism that's already built-in to ConfigurationFile, so I don't quite understand the need for these changes. I see that the discussion on the wisdom of adding Velocity dependencies consists of three messages that appear to have been sent between 7:02 AM and 7:18 AM in North American Eastern time. I think introducing a new configuration system that requires integration of an outside templating package is a fairly big change to River's core product, the Jini Technology Starter Kit. I also think that radical changes require discussions which in an email-focused environment like Apache, must by necessity take a little time, certainly more than 16 minutes while much of North America sleeps. I feel uncomfortable with major changes to the trunk in general, and with this one in particular for a few reasons. - I've always been told that putting jar files into a "Source Code Management System" is a bad idea. - We're contemplating a release of the trunk in the near future; I wonder if we should release a radical new feature without much QA or user feedback. - I'm not sure about the general approach of using a text tool to build a configuration file at runtime. The Configuration mechanism is designed to be extensible and in fact replaceable. If it's difficult to edit the current ConfigurationFile input in a GUI, for instance, then we're entirely free to create a different implementation of the Configuration interface that makes it easier. Dennis has provide the GroovyConfiguration. We could build an XMLConfiguration. There could be a PropertyBasedConfiguration. There's all kinds of options. If the goal is simply to be able to plug in a port and service name, the current override mechanism is perfectly fine. (By the way, we don't need a $configuration special entry; it's alredy there as 'this'). - I feel we should be a little conservative about changes to the core product. That isn't to say that River has to have only one product, however. - I think we should stick to the release plan that has been discussed, which included mainly bug fixes in the next release. In short, I'd be much happier if this kind of development took place outside of the jtsk trunk repository. I'd have no problem with it as an "extras" product. Then in the fullness of time, with benefit of both developer and user feedback, we could have a rational discussion about adding it to the trunk in a future release. Similar to the mechanism whereby "javax" packages have made their way into the core JDK distribution. Obviously I'm only one vote, but those are my thoughts. It's not my intention to impede progress, I just want to preserve some stability in the core product and preserve the developer list as a real discussion forum. Cheers, Greg Trasuk. -- Greg Trasuk, President StratusCom Manufacturing Systems Inc. - We use information technology to solve business problems on your plant floor. http://stratuscom.com
