I am on the side of "simplifying deployment" as the phrase of the hour, more than "enhance configuration" (too). If there was anything that I thing would make things better, it would be a deployment environment that takes care of "things" for you with tremendously satisfying defaults/results. I know that Dennis has focused on deployment and lifecycle in Rio, with management as a strong contender for the top spot. Those things, for me, are the big barriers. Configuration "issues" are just an artifact of deployment management. Keeping configuration in the realm of deployment is, for me, the right place. What annotations might bring to the table, is documenting the usage of configurable items in a way that is "exporting" that knowledge to the user of the software.
I've read over a lot of "Javadoc" configuration details, over the years. One of the things that I remember doing early on, was do copy and paste of "keywords" out of javadoc into my configuration files, because they needed to be spelled correctly, and I didn't want that to be a simple mistake, which can lead to unexpected or intractable behaviors. From my perspective, it seems that the most predominate step forward that we might take, would be to make all configuration used in services be visible to tooling on the outside which could then guide the deployment much more dependably and accelerate this small but currently oh so fragile set of steps toward getting River up and running in your environment. Gregg On Sep 25, 2012, at 7:35 AM, Dennis Reedy <[email protected]> wrote: > Hi Simon, > > Not sure I follow. My comment was simply stating that from my experience > developers are less interested in annotations that support configuration then > annotations that support lifecycle. Providing acceptable defaults for things > like exporters allow developers to get up & running easier (and I thought > that was the whole purpose behind your effort) allows that. > > Regards > > Dennis > > On Sep 25, 2012, at 821AM, Simon IJskes - QCG wrote: > >> On 25-09-12 12:46, Dennis Reedy wrote: >>> Certainly getting a service "working" is important, but wouldn't providing >>> acceptable defaults be easier? >> >> And if you want to deviate from the default, for a very small part of the >> services, how would you implement this? Provide a annotation reference to a >> Configuration component name, allow Configuration to introspect for specific >> deviations? >> >> -- >> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl >> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397 >
