Hi Pierre,
I think we can and should do this without a major version bump.
We could simply add the new builders and keep the old ones in parallel
in deprecated status.
This would allow people some time to switch to the new syntax. For the
major version we can then later remove the deprecated syntax.
About auto adding. How about this:
Inside component() we add the component to a separate list of pending
components in dependency manager.
Then after init we call a method in the manager to finally add all
pending components into the active structure.
In that method we could then also convert from the class with the new
syntax to the existing class. So the changes for the new syntax would have
minimal impact to the rest of the code.
I created an issue for this:
https://issues.apache.org/jira/browse/FELIX-4689
As I would like to work on becoming a felix committer in the long term I
would ideally like to work this out and create a patch for the issue. If
you prefer to do it yourself I am also fine of course. In any case I
agree that we should first wait for feedback from Marcel.
Christian
On 11.11.2014 00:39, Pierre De Rop 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 <
[email protected]> 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
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
