Basically, externally, it should not have impact, the user guide will
stay valid.
The configuration files will stay the same, custom appenders or
collectors will still work (as they use EventAdmin topic).
Regards
JB
On 02/09/2016 01:37 PM, Jamie G. wrote:
+/- 0
I know that some down stream users are already building out Decanter
into their projects, long as things are well documented so that they
can adjust than things should be fine.
Cheers,
Jamie
On Tue, Feb 9, 2016 at 9:02 AM, Jean-Baptiste Onofré <[email protected]> wrote:
+1 (as discussed ;))
Agree to use DS in 1.1.x branch that I will create just after 1.0.2 release.
Regards
JB
On 02/09/2016 01:22 PM, Christian Schneider wrote:
I recently discussed with JB that the boilerplate code in decanter
increases. One typical example is that a decanter module needs to
reference EventAdmin, the Marshaller service and react on
configurations. In many cases we also need to be able to work with
ManagedServiceFactories.
So for this case DS seems like a good idea. It can do all of the above
with very simple annotations and can now also do type safe configs.
The only disadvantage is that we then need the scr feature. As it is
quite small I think this is a good tradeoff.
What do you think?
If there is no push back then I would like to switch decanter to DS once
the decanter release 1.0.2 is done. JB then wants to switch the master
to 1.1.x which allows us to do some more changes then in a bugfix line.
Christian
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
