Gregg Wonderly wrote:
I think that there are a couple of issues around doing this. There are a handful of things which the deployer of the service will want to configure. The Configuration interface still seems viable to me and groovy config is a great thing to get into circulation it seems to me.
What I'd like to suggest is that we create a large amount of security as a
default detail. Configuration should provide the ability to turn it down/off.
That way safe computing is the default.
+1 Peter. Good thinking Gregg.
There are people who have expressed frustrated with the configuration
system, rather than opening up constructors everywhere, introducing
coupling, perhaps we could do something with Guice as well?
So an application can configure itself without coupling?
I have some things in mind but have not got them fleshed out yet for real
discussion.
Gregg Wonderly
Sent from my iPad
On May 22, 2010, at 11:42 AM, Dennis Reedy <[email protected]> wrote:
I'd like to solicit some ideas into what would be the source and configuration
content so a River archetype [1] can be created. This will allow developers to
create a working River maven project in seconds. I know Chris Sterling
developed one a few years back, but I think we can do this one a little
differently. Some questions:
Generate a simple service that just provides an empty interface, service impl
and configuration?
For configuration, use the Jini configuration approach or can we move forward
with adopting the Groovy configuration provider?
Generate a JavaSpace project?
Should the Rio classdepandjar mojo be used to build the artifacts? In this way
we can produce the service, dl and api artifacts right out of the gate.
What to provide for testing the application? Does the River test framework make
sense to include?
Feedback would be great.
Dennis
[1] Info on Maven archetypes:
http://maven.apache.org/guides/introduction/introduction-to-archetypes.html
http://maven.apache.org/archetype/maven-archetype-plugin/
