Hello Paul,
indeed, the DM4 code is very close to the old 3.2 API, and it would be
unfortunate if breaking the API too much would make slower the adoption of
the new version.
I gave immense effort to bring to life the new thread model introduced by
Marcel and Xander, and now we also have a nice actor thread model allowing
concurrent activation of Components while staying "single threaded"
internally ...
so I will check what has changed in the new 4.0 API and will manage to make
it closer to the old 3.2 API as much as possible (but some methods have
been removed, like the setInstanceBound method, for example).
Regarding your suggestion, adding specific builder classes could also be an
interesting way to go.
I would even consider to make some specific API bundles, like:
org.apache.felix.dependencymanager -> the current 4.0 API, and it should be
close to the old 3.2 API as much as possible (Marcel, what is your opinion
?)
org.apache.felix.dependencymanager.scala -> we could leverage DM API to
scala
org.apache.felix.dependencymanager.groovy -> same for groovy
etc ...
All this could be discussed with more details in the jira issue that
Christian created.
kind regards
/Pierre
On Tue, Nov 11, 2014 at 8:55 AM, Paul Bakker <paul.bak...@luminis.eu> wrote:
> 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.de...@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 <
> > ch...@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
> > >
> > >
> >
>
