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/rmannibuca
>> u> | LinkedIn <https://www.linkedin.com/in/rmannibucau>
>>
>
