river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject ConfigurationBuilder and Velocity - Discussion
Date Thu, 13 Jan 2011 20:01:00 GMT

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,
- 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

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


Greg Trasuk.
Greg Trasuk, President
StratusCom Manufacturing Systems Inc. - We use information technology to
solve business problems on your plant floor.

View raw message