felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: Make DependencyManager API more fluent?
Date Thu, 13 Nov 2014 07:57:27 GMT
Hi Marcel,

I very much like the idea of a separate builder class. It will make the 
transition very smooth. We can also package it in an extra bundle but I 
do not think there is a technical need for it. So I propose to simply 
add the new syntax in a separate package.

if we want to remove the old syntax at some point then we have to do 
this in a major version. So as 4.0 is quite near we might aim at this 
for 5.0.

We do not need to introduce the new API (if we keep the old one 
unchanged) in a major version. It is not a breaking change so I think it 
can be introduced in any minor version. Of course we can do it in 
version 4.0 but there is no technical need for it.

Btw. I am at apachecon next week. Would be great if we could take the 
chance to meet in person.


On 12.11.2014 23:15, Marcel Offermans wrote:
> Hey all,
>> On 11 Nov 2014, at 0:39 am, Pierre De Rop <pierre.derop@gmail.com> wrote:
>> 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.
> Agreed, we cannot introduce something like this any sooner than in version 4. However,
it is probably not too hard to implement this yourself on top of the current release either,
since 80% of what Christian is proposing is just renaming existing methods:
> If you create your own version of DependencyManagerBase and also wrap classes like Component
and ServiceDependency/ConfigurationDependency it is quite straightforward to delegate from
your new set of methods to the existing ones.
> This goes in the direction that Paul proposes as well with the builder class.
>> 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.
> I am fairly neutral on this.
> Yes, the proposed methods are better aligned with most fluent APIs. However, two downsides
I see is that it does break the existing API, making it harder for people to migrate to version
4 (and, for various reasons, they should do that). Also, you are not required to use the fluent
style, in some cases you end up invoking individual setter methods on DM components and in
those cases, the fluent style methods might look a bit strange.
> Because of this, maybe we should explore the separate builder class that Paul suggested!?
>> 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.
> Yes, and there are a few other scenarios as well where you don’t want to combine creating
and adding a component, so I think we should leave that part alone.
>> 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).
> I don’t think that makes the code better. You still have two calls (one to create,
one to add) and if you forget the addTo(…) it will probably still be hard to spot that that
was the “bug”.
>> 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 :-))
> Agreed, this is a good discussion, thanks for the input!
> Greetings, Marcel

Christian Schneider

Open Source Architect

View raw message