Hello Christian, We could indeed deprecate all the setters methods, and introduce your proposed builder methods. And I do agree that we could also manage to let the new DependencyActivatorBase.component() method maintain the list of created components, and we could then auto-add all the created components in the DependencyManager object once the DependencyActivatorBase.init() method returns.
So, let's continue to discuss with Marcel about all of this in the jira issue you have created, and we also have to think about what Paul is proposing. For your information, the code from felix-trunk/dependencymanager is out dated, and I'm working since several months on a new DM 4.0.0 version, which is currently in [1]. We are using a new thread model which is described in [2] and in the presentation I recently added in [3] (see the "what's new in DM 4.0" section at the end of the presentation) For now the code is still unstable and I need some more time to finalize the API (one week I think). And then once finalized (I will email), then you could try to attach a patch in the jira issue (but on the sandbox codebase). This will help Marcel to decide. Cheers; /Pierre [1] http://svn.apache.org/viewvc/felix/sandbox/pderop/dependencymanager-prototype/ [2] http://svn.apache.org/viewvc/felix/sandbox/pderop/dependencymanager-prototype/org.apache.felix.dependencymanager/design.txt [3] http://svn.apache.org/viewvc/felix/sandbox/pderop/dependencymanager-prototype/doc/A_Glance_At_DependencyManager.odp On Tue, Nov 11, 2014 at 9:22 AM, Christian Schneider < ch...@die-schneider.net> wrote: > 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 < >> 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 >>> >>> >>> > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > >
