Hello Christian;
Just to say that if you start to work on the new API, I would like to avoid
to commit anything in the old 3.2 codebase (felix-trunk/dependencymanager)
because it will be overriden very soon by the new 4.0.0 major version,
which is currently in my sandbox (everything has changed).
but, as explained previously, I still need to fix some stuff in the API, so
the API is still unstable but I plan to commit this WE.
I will email when the API will become stable.
kind regards;
/Pierre
On Thu, Nov 13, 2014 at 8:57 AM, Christian Schneider <
ch...@die-schneider.net> wrote:
> 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.
>
> Christian
>
>
>
>
> On 12.11.2014 23:15, Marcel Offermans wrote:
>
>> Hey all,
>>
>> On 11 Nov 2014, at 0:39 am, Pierre De Rop <pierre.de...@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
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>
