@JB: thought about another option which can be almost hurtless for beam: 1. we ensure all "config" classes are public (would avoid nasty hacks) 2. while migrating to java 8 you activate the javac -parameters flag
does it sound better? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> 2018-01-14 19:25 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>: > Works for me but forbids the usage of the abstract class cause of final > fields. That said if beam can get a Factory.createIO(clazz, > configAsPrimitivesMap) Im happy whatever solution is used. > > > Le 14 janv. 2018 17:19, "Jean-Baptiste Onofré" <j...@nanthrax.net> a écrit : > >> Hi Romain, >> >> I think the missing thing for automation projects is probably more around >> "documentation" for the setters/getters. >> >> So, why not: >> 1. we don't change the usage and AutoValue itself >> 2. we can imagine to add a new set of annotations in IO Common with a >> specific annotation processor that create another POJO class, not actually >> used in the IO code, but "describing" the configuration for automation >> projects. This POJO will be public, no final. >> >> WDYT ? >> >> Regards >> JB >> >> On 12/01/2018 19:26, Romain Manni-Bucau wrote: >> >>> Hi guys >>> >>> I'd like to discuss the IO configuration. >>> >>> My goal is to be able to instrospect (or equivalent) the IO to >>> instantiate them programmatically in a generic manner from a generic config >>> - this is not yet linked to the system property topic but can benefit beam >>> on this other topic too. >>> >>> Auto value loosing the final fields ordering is impossible to use until >>> you parse sources. >>> >>> In other words: auto value is nice for programmatic usage but is >>> blocking for any automotion on top of it - even using unsafe is not an >>> option ATM :(. >>> >>> Can we try to get something to solve that need please? >>> >>> Here are the solutions I see (pick just one ;)): >>> >>> 1. migrate IO to IOOptions (based on pipeline options kind of design). >>> This is a breaking change - but I'm sure we can mitigate it in term of user >>> compatibility - but it unifies the beam config and enables to not have IO >>> specific configurations which can vary between the IO if not developped by >>> the same guy. >>> 2. Add an extension to @AutoValue to also generate the field names order >>> in the create() (@Fields({"address","username","password"}). Cheap but >>> the way to instantiate an IO from a config is still a pain (think >>> Factory.createIO(clazz, properties)) >>> 3. Also generate a plain pojo from the abstract @AutoValue class - this >>> requires to modify the source class to make it working but is feasible with >>> a processor >>> 4. drop autovalue and use plain pojo - writing it cause it is a >>> technical option but it leads to break as much as 1 without getting all the >>> benefit to have an agnostic config and the tooling we can build on top of it >>> 5. probably others >>> >>> >>> Wdyt? >>> >>> Personally I really like 1 cause it starts to create a clean programming >>> model we can then build other features on. >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau <https://twitter.com/rmannibucau> | Blog < >>> https://rmannibucau.metawerx.net/> | Old Blog < >>> http://rmannibucau.wordpress.com> | Github < >>> https://github.com/rmannibucau> | LinkedIn < >>> https://www.linkedin.com/in/rmannibucau> >>> >>
