felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Bakker <paul.bak...@luminis.eu>
Subject Re: Make DependencyManager API more fluent?
Date Tue, 11 Nov 2014 07:55:40 GMT
One thing to consider is that although DM 4 is a major version bump, it so
far seems to be very close to a drop-in replacement of DM 3. Changing the
API itself would break all existing code. This is technically ok for a
major version, but will make adoption of the new version a lot slower.

On the other hand, I do like the proposal :-) Maybe it's possible to add a
new API, while keeping the existing one. E.g. introduce a builder class
specifically for this reason, user can than gradually move towards the new
API. Potentially there could even be builders for multiple JVM languages,
leveraging the DSL functionality of language Groovy etc.

Cheers,

Paul

On Tue, Nov 11, 2014 at 12:39 AM, Pierre De Rop <pierre.derop@gmail.com>
wrote:

> Hello Christian;
>
> The improvements you are proposing would require a major version bump since
> it's an incompatible API change. But I personally like what you are
> suggesting, and I could quickly do it in the upcoming Dependency Manager
> 4.0.0, which is a new major version.
>
> But before, I need to know if Marcel is agree to go ahead with all this; so
> for the moment, may be you can just create a Jira issue, and let's wait for
> Marcel to see if he's OK.
>
> Just one remark: the setters can be easily removed, however I think we
> can't manage to make the "component()" method automatically add the
> Component to the DependencyManager, because technically; when you add a
> Component to a DependencyManager, the Component is actually *activated*,
> and at this point, all the necessary dependencies have to be already in
> place.
>
> So, the only possible improvement I'm thinking about for now could have the
> form of this:
>
>     public void init(BundleContext context, DependencyManager manager)
> throws Exception {
>         component()
>             .implementation(DataGenerator.class)
>             .add(serviceDependency(Store.class).required())
>             .add(serviceDependency(LogService.class))
>             .addTo(manager);
>     }
>
> (notice the addTo method at the end of the sample above, which could just
> add the fully built component to the DependencyManager "manager" object).
>
> but I propose you first create the Jira issue and see what Marcel thinks.
>
> I will possible add more suggestions in your Jira issue once you will have
> created it (like also using a builder pattern for the aspects/adapters:
> this would allow to reduce the number of method signatures for the
> createAdapter/createAspect methods).
>
> kind regards (and thanks for proposing to improve Dependency Manager :-))
>
> /Pierre
>
> On Mon, Nov 10, 2014 at 11:40 AM, Christian Schneider <
> chris@die-schneider.net> wrote:
>
> > I wonder if the DependencyManager API could be made a bit more fluent.
> > Technically it already uses the fluent builder pattern
> > but all the builder verbs still look a lot like traditional setters.
> >
> > I know what I propose is mostly syntactic sugar but I think the result
> > looks more readable and crisp. See below for some ideas.
> >
> > Christian
> >
> > ----
> >
> > This is from samples.dependonservice:
> >     public void init(BundleContext context, DependencyManager manager)
> > throws Exception {
> >         manager.add(createComponent()
> >             .setImplementation(DataGenerator.class)
> >             .add(createServiceDependency()
> >                 .setService(Store.class)
> >                 .setRequired(true)
> >             )
> >             .add(createServiceDependency()
> >                 .setService(LogService.class)
> >                 .setRequired(false)
> >             )
> >         );
> >     }
> >
> > Why not make it look like this:
> >     public void init(BundleContext context, DependencyManager manager)
> > throws Exception {
> >         component()
> >             .implementation(DataGenerator.class)
> >             .add(serviceDependency(Store.class).required())
> >             .add(serviceDependency(LogService.class))
> >             );
> >         );
> >     }
> >
> > component() could create and add the component.
> >
> > Or for configuration:
> >     public void init(BundleContext context, DependencyManager manager)
> > throws Exception {
> >         manager.add(createComponent()
> >             .setImplementation(Task.class)
> >             .add(createConfigurationDependency()
> >                 .setPid("config.pid")
> >                 // The following is optional and allows to display our
> > configuration from webconsole
> >                 .setHeading("Task Configuration")
> >                 .setDescription("Configuration for the Task Service")
> >                 .add(createPropertyMetaData()
> >                      .setCardinality(0)
> >                      .setType(String.class)
> >                      .setHeading("Task Interval")
> >                      .setDescription("Declare here the interval used to
> > trigger the Task")
> >                      .setDefaults(new String[] {"10"})
> >                      .setId("interval"))));
> >     }
> >
> > could be:
> >     public void init(BundleContext context, DependencyManager manager)
> > throws Exception {
> >         component().implementation(Task.class)
> >             .configuration("config.pid")
> >                 .add(meta("Task Configuration)
> >                     .description("Configuration for the Task Service")
> >                     .add(property("interval")
> >                             .cardinality(0)
> >                             .type(String.class)
> >                             .heading("Task Interval")
> >                             .description("Declare here the interval used
> > to trigger the Task")
> >                             .default("10"))
> >     }
> >
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> >
> > Open Source Architect
> > http://www.talend.com
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message