Hi Pierre,
Don't worry, I don't think it's a problem at all if some things changed.
It's a huge new release after all! I was only suggesting that we shouldn't
get rid of the component registration API completely in favour of a better
API. For the methods that don't longer exist etc. I don't see much problem,
this are more special cases anyway.
I know about the new threading mechanism btw, very good stuff :-)
Cheers,
Paul
On Wed, Nov 12, 2014 at 9:13 AM, Pierre De Rop <pierre.de...@gmail.com>
wrote:
> 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
> > > >
> > > >
> > >
> >
>
