Yes, I think this is the best way. I would wait with it until 5th or 6th of January, when people are back from holidays. I will later then make a proposal for the vote and if we agree on that, we should do the vote...
2014-12-27 15:20 GMT+01:00 John D. Ament <[email protected]>: > As best as I can tell from reading this thread, there is no clear winner. > I would recommend you guys hold a vote first before making any changes > requested within here. > > On Wed Dec 24 2014 at 10:30:36 AM Werner Keil <[email protected]> > wrote: > > > Huge thread, so I'll stick to the format question for now, see inline. > > > > On Wed, Dec 24, 2014 at 9:56 AM, Oliver B. Fischer < > > [email protected] > > > wrote: > > > > > See inline... > > > Am 24.12.14 um 02:07 schrieb Anatole Tresch: > > > > > >> 3.) Should we define any configuration formats, and if so which one? > > >> *-> I would like to see a minimal set of formats in core, so we can > > >> provide a minimal dependency version that fits most needs. > > >> .properties, > > >> .xml(properties) and .ini I think is a good set, but definitively not > > >> more.* > > >> *-> We can then leverage apache commons config with bridges in the > > >> extension modules for suporting additional formats ;). * > > >> > > > > > > At my company we use mostly > https://github.com/typesafehub/config/blob/ > > > master/HOCON.md and YAML. For me only property files and the other > > > mentioned formats feel a little bit outdated. Not only because they > exist > > > already for a long time but for their usability. > > > > > > Writing large configurations is mostly about structuring the > information > > > you provide. In this area are property files weak and no one wants XML > > > again. If I would tell this someone around me the answer would be: > "Come > > > back if you have something more usefull." > > > > > > > > In one of the largest clouds outside the infrastructure of the likes of > > Google, Amazon, Microsoft, etc. (on top of Kokki/Multiconf) we used JSON > > and some components also used YAML. However, these are just the DevOps > > duties like build management and processing with some management, > > provisioning and monitoring of the actual servers, too. > > > > When it comes to configuration of various Enterprise Containers and Java > EE > > applications to be deployed there in all the various stages, XML rules. > And > > those who really think for the actual Java part everything can be done > > purely with annotations probably also insist, Santa is coming through > their > > chimney tonight ;-D > > > > Purely annotation based solutions are nice to do quick demos, but if you > > need true staging all the way from your local development box to a giant > > cluster in production, at least the server and containers requires loads > of > > XML to provision it correctly for each container, and without touching > and > > changing the code for every step, there is practically no production > ready > > app servers today supporting that, even if the app may truly be written > > just with annotations supporting everything from local dev boxes to > > production, then the slightest change in each of these phases would still > > break everything. And those large cloud solutions by big vendors normally > > get deployed by others that are not supposed to build and compile your > app > > again;-) OSGi sounded promising also for EE containers, but Glassfish > > (which had some good support for it) is merely the Java EE RI now and > JBoss > > WildFly also removed it. So dynamic loading and injection of components > at > > runtime becomes harder. > > > > I also looked into HOCON which is a nice approach, though a bit limited. > > Fortunately, what it admits to be missing, Java is getting as a standard > > these days, a unit subsystem (JSR 363). On the monitoring front, Parfait > > https://code.google.com/p/parfait/ shows how the earlier JSR (275) is > used > > for support of MB, GB, etc. but also other vital signs of the system if > > needed like temperature (seamless and typesafe whether it's °C or F;-) US > > Smart Grid vendor Opower wrote a JSON binding solution around Unit-API > > (0.6, the "missing link" betweeen 275 and 363) so supporting formats like > > JSON for data exchange also works. There's an upcoming JSR for JSON-B, so > > maybe under Java EE 8 or with this on its own, you may use Java EE > > standards there, too, until then alternatives like Jackson or GSON, do, > > too. > > > > Merry Christmas, > > > > Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead | > > Eclipse UOMo Lead, Babel Language Champion | Apache Committer | Advisory > > Board Member, DWX '15 > > > > Twitter @wernerkeil | @UnitAPI | @JSR354 | @AgoravaProj | @DeviceMap | > > #EclipseUOMo > > | #DevOps > > Skype werner.keil | Google+ gplus.to/wernerkeil > > > -- *Anatole Tresch* Java Engineer & Architect, JSR Spec Lead Glärnischweg 10 CH - 8620 Wetzikon *Switzerland, Europe Zurich, GMT+1* *Twitter: @atsticks* *Blogs: **http://javaremarkables.blogspot.ch/ <http://javaremarkables.blogspot.ch/>* *Google: atsticksMobile +41-76 344 62 79*
