How to organize OSGi bundles according to source code dependencies analyse report
Hi Peter, I am working about source code dependencies analyse algorithm design and implement job, i will finish the whole analyse algorithm in the coming month. This algorithm include two sections: package and class. 1. Package section a. It can analyse package cycles in project source code b. Analyse all the necessary packages for each package c. Tell us who use it about each package 2. Class section a. This algorithm will tell us all the class cycles in project source code (for example A - B - C - A) b. Analyse all the necessary classes for each class (for example, it can tell us class A use class B, C and D) c. Tell us who use it about each class (for example, it can tell us class A was used by class B and C) After we get the source code analyse report, we should split the project into several OSGi bundles, so the problems is how should we split the project according to the report. In my initial option: A. classes in a cycle should be in the same bundle B. classes (or interfaces ) which were used much by other classes, but does not require any other class, can be in the same bundle. (Usually, these are basic interface or abstract class). These classes usually be API define classes. I am very clear about these two situations, but there should be many other situations. So, you advises ? -- Best Regards Tiger Gui [tigergui1...@gmail.com]
Re: How to organize OSGi bundles according to source code dependencies analyse report
I think the primary focus is grouping packages with the following rules: 1) Group packages that are strongly connected 2) Start with the largest group and try to merge groups into it that do not cause additional dependencies 3) repeat for all groups I think you need a cost/entropy function to calculate the optimum division. If you group package A and B then the cost is zero if A and B have identical imports. Even if A and B are not cohesive they could be placed in the same bundle because they do not drag in additional dependencies. So the interesting question is what the cost is if B would add one additional import. Is it worth it? Or not? Part of that analysis is then to analyze if you could do more grouping if classes were moved from packages to other (new?) packages. I.e. sometimes you have a package where there is only one class that makes the package not groupable. I think there should be the concept of a dependency cost. If you import X by 15 packages and 254 classes it is likely that you get your moneys worth for that dependency. However, if you find that a single class drags in dependencies that nobody else uses it is likely that that class is expensive. It is interesting how much automation we can do there but I expect you need people to look at the details. One of the biggest modularity problems are usually when you get bridge classes. I.e. someone has a library doing X but wants to make it available with for example Spring. There is usually then a few classes bridging the library to the Spring world, which can be extremely expensive. For example, bnd is coupled to ant but I made sure that was a separate package. This all seems closely related to the concept of entropy and it might be interesting to take a look at Shannon et al. You have to find a decomposition that has minimum entropy where entropy is somehow defined in terms of imports versus contents. You want to group as much as possible while minimizing the connections between the groups. Again, this normally means you need a cost function and optimize that cost function. However, start with the mechanic grouping and apply that idea to open source projects to see how this would look like. If you could calculate the entropy of existing bundles that would also be very interesting. Kind regards, Peter Kriens On 8 jun 2011, at 10:35, Tiger Gui wrote: Hi Peter, I am working about source code dependencies analyse algorithm design and implement job, i will finish the whole analyse algorithm in the coming month. This algorithm include two sections: package and class. 1. Package section a. It can analyse package cycles in project source code b. Analyse all the necessary packages for each package c. Tell us who use it about each package 2. Class section a. This algorithm will tell us all the class cycles in project source code (for example A - B - C - A) b. Analyse all the necessary classes for each class (for example, it can tell us class A use class B, C and D) c. Tell us who use it about each class (for example, it can tell us class A was used by class B and C) After we get the source code analyse report, we should split the project into several OSGi bundles, so the problems is how should we split the project according to the report. In my initial option: A. classes in a cycle should be in the same bundle B. classes (or interfaces ) which were used much by other classes, but does not require any other class, can be in the same bundle. (Usually, these are basic interface or abstract class). These classes usually be API define classes. I am very clear about these two situations, but there should be many other situations. So, you advises ? -- Best Regards Tiger Gui [tigergui1...@gmail.com]
Re: iPOJO vs SCR vs Blueprint
The summary for me is that DS is limited to simplifying being a service and depending on other services while iPOJO and Blueprint add a programming language (XML/Annotations) that support services among many, many other features. In my experience DS is the simplest and least intrusive, especially with the SCR or bnd annotations. Blueprint is not my favorite because I consider XML among the worst programming languages one can imagine. I do not have a lot of experience with iPOJO; it is clearly the most powerful but it somehow lacks a compelling reason to switch as none of its additional functions seem worth the effort to switch. Anyway, who cares. They all interact very nicely and switching from one to the other is not so hard as long as you could in POJOs. Kind regards, Peter Kriens On 30 mei 2011, at 13:25, Felix Meschberger wrote: Hi, Just stating an incompletely informed opinion here .. If you want something simple, light-weight and easy to use, go for Declarative Services. If you want elaborate functionality or need something Declarative Services does not provide, consider iPojo (I understand it is an evolution of Declarative Services, right ?) If you have a Spring background go for blueprint. Regards Felix, whose loves and sticks with Declarative Services ;-) Am Donnerstag, den 26.05.2011, 02:23 +0100 schrieb jie yan: On Thu, May 26, 2011 at 6:02 AM, Alasdair Nottingham n...@apache.org wrote: Alasdair Nottingham On 25 May 2011, at 22:16, Richard S. Hall he...@ungoverned.org wrote: On 5/25/11 16:26, Alasdair Nottingham wrote: Hi, This is good I might link to it, or pinch it for the aries webpage too if that is ok. When doing that thought I would put some changes into the blueprint column. The Aries blueprint implementation provides some value add that would change some of the No's into Yes's. Sure. One thing though in component lifecycle control you have a Partial down for blueprint I was wondering what you meant by this. I'd have to review the chapter, I don't really claim to be any Blueprint expert...other than knowing it sucks... ;-) Of course if you were an expert you would know how much better it is than anything else ;) let the religious flame war begin, or not. In fact, casual users wish for an almighty expert who knows all solutions in-depth and exposes them to all. If there's no such expert, the second best method is, experts of different solutions advertise themself and compare with each other. Maybe that can be called religious flame war, but it's valuable. What we really need in open community is simple and perfect product in technology, but not many repeat manufacturing wheels like some outside companies. Regards, drhades - richard Thanks Alasdair On 25 May 2011 15:29, Richard S. Hallhe...@ungoverned.org wrote: On 5/25/11 9:19, Richard S. Hall wrote: We actually have a table in our book (OSGi in Action) that tries to compare the features...perhaps I could re-create that table on a web page... Ok, I added the table to the iPOJO FAQ on wiki: https://cwiki.apache.org/confluence/display/FELIX/iPOJO+FAQ#iPOJOFAQ-HowdoesiPOJOcomparetoDeclarativeServicesorBlueprint%3F It's not perfect, but it is better than nothing. It should eventually propagate to our static pages. Clement, please double check the iPOJO features, since you've added features since the book has been published. - richard On 5/25/11 5:26, jie yan wrote: +1 Regards, drhades On Wed, May 25, 2011 at 5:11 PM, Alex Karasuluakaras...@apache.org wrote: On Wed, May 25, 2011 at 6:28 AM, Richard S. Hall he...@ungoverned.org wrote: On 05/24/2011 09:46 PM, jie yan wrote: I wonder what is the difference between these three component runtime. They all manage service dependencies. Blueprint and iPOJO provide more sophisticated features than DS. Each has a different focus or goal. I guess everyone like myself is seeing this question occur regularly on this mailing list. It's a valid question that perhaps we can dedicate a wiki/web page to with the pros and cons. I myself have many questions and can't really tell which is best for our needs at directory but I do know that I have to sit down and do the research. However our situation is much more unique since we back configuration information needed to wire the server inside a LDIF/LDAP based backing store. Lots to think about for us. Excuse the digression on our specific issues but regarding having a page dedicated to the pros and cons of each option at felix could benefit many of our users. Best, Alex
Re: iPOJO vs SCR vs Blueprint
On 6/8/11 9:13, Peter Kriens wrote: The summary for me is that DS is limited to simplifying being a service and depending on other services while iPOJO and Blueprint add a programming language (XML/Annotations) that support services among many, many other features. In my experience DS is the simplest and least intrusive, especially with the SCR or bnd annotations. Blueprint is not my favorite because I consider XML among the worst programming languages one can imagine. I do not have a lot of experience with iPOJO; it is clearly the most powerful but it somehow lacks a compelling reason to switch as none of its additional functions seem worth the effort to switch. Yeah, who needs things like automatic concurrency handling for services or byte-code generated smart service references that eliminate the need to turn everything into a component in order to pass around services throughout your component? It's better to do all that stuff by hand with DS... ;-) - richard p.s. Sorry, I couldn't resist... :-P Anyway, who cares. They all interact very nicely and switching from one to the other is not so hard as long as you could in POJOs. Kind regards, Peter Kriens On 30 mei 2011, at 13:25, Felix Meschberger wrote: Hi, Just stating an incompletely informed opinion here .. If you want something simple, light-weight and easy to use, go for Declarative Services. If you want elaborate functionality or need something Declarative Services does not provide, consider iPojo (I understand it is an evolution of Declarative Services, right ?) If you have a Spring background go for blueprint. Regards Felix, whose loves and sticks with Declarative Services ;-) Am Donnerstag, den 26.05.2011, 02:23 +0100 schrieb jie yan: On Thu, May 26, 2011 at 6:02 AM, Alasdair Nottinghamn...@apache.org wrote: Alasdair Nottingham On 25 May 2011, at 22:16, Richard S. Hallhe...@ungoverned.org wrote: On 5/25/11 16:26, Alasdair Nottingham wrote: Hi, This is good I might link to it, or pinch it for the aries webpage too if that is ok. When doing that thought I would put some changes into the blueprint column. The Aries blueprint implementation provides some value add that would change some of the No's into Yes's. Sure. One thing though in component lifecycle control you have a Partial down for blueprint I was wondering what you meant by this. I'd have to review the chapter, I don't really claim to be any Blueprint expert...other than knowing it sucks... ;-) Of course if you were an expert you would know how much better it is than anything else ;) let the religious flame war begin, or not. In fact, casual users wish for an almighty expert who knows all solutions in-depth and exposes them to all. If there's no such expert, the second best method is, experts of different solutions advertise themself and compare with each other. Maybe that can be called religious flame war, but it's valuable. What we really need in open community is simple and perfect product in technology, but not many repeat manufacturing wheels like some outside companies. Regards, drhades - richard Thanks Alasdair On 25 May 2011 15:29, Richard S. Hallhe...@ungoverned.org wrote: On 5/25/11 9:19, Richard S. Hall wrote: We actually have a table in our book (OSGi in Action) that tries to compare the features...perhaps I could re-create that table on a web page... Ok, I added the table to the iPOJO FAQ on wiki: https://cwiki.apache.org/confluence/display/FELIX/iPOJO+FAQ#iPOJOFAQ-HowdoesiPOJOcomparetoDeclarativeServicesorBlueprint%3F It's not perfect, but it is better than nothing. It should eventually propagate to our static pages. Clement, please double check the iPOJO features, since you've added features since the book has been published. - richard On 5/25/11 5:26, jie yan wrote: +1 Regards, drhades On Wed, May 25, 2011 at 5:11 PM, Alex Karasuluakaras...@apache.org wrote: On Wed, May 25, 2011 at 6:28 AM, Richard S. Hall he...@ungoverned.org wrote: On 05/24/2011 09:46 PM, jie yan wrote: I wonder what is the difference between these three component runtime. They all manage service dependencies. Blueprint and iPOJO provide more sophisticated features than DS. Each has a different focus or goal. I guess everyone like myself is seeing this question occur regularly on this mailing list. It's a valid question that perhaps we can dedicate a wiki/web page to with the pros and cons. I myself have many questions and can't really tell which is best for our needs at directory but I do know that I have to sit down and do the research. However our situation is much more unique since we back configuration information needed to wire the server inside a LDIF/LDAP based backing store. Lots to think about for us. Excuse the digression on our specific issues but regarding having a page dedicated to the pros and cons of each option at felix could benefit many of our users. Best, Alex
[jira] [Commented] (FELIX-2980) org.apache.felix:maven-scr-plugin:1.7.1-SNAPSHOT:scr failed. NullPointerException
[
https://issues.apache.org/jira/browse/FELIX-2980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13045978#comment-13045978
]
Andrei Pozolotin commented on FELIX-2980:
-
now I am getting NPE again :-)
it seems the repo is back to previous snapshot 2011-05-17:
https://repository.apache.org/content/groups/snapshots/org/apache/felix/maven-scr-plugin/1.7.1-SNAPSHOT/maven-scr-plugin-1.7.1-20110517.073734-2.pom
can you please publish a fresh build? (the dates on pom jar do not look right)
org.apache.felix:maven-scr-plugin:1.7.1-SNAPSHOT:scr failed.
NullPointerException
-
Key: FELIX-2980
URL: https://issues.apache.org/jira/browse/FELIX-2980
Project: Felix
Issue Type: Bug
Components: Maven SCR Plugin
Reporter: Andrei Pozolotin
Assignee: Carsten Ziegeler
Fix For: maven-scr-plugin-1.7.2, scr generator 1.1.2
public Class?[] value() {
return Util.getClassArrayValue(annotation, value,
Service.class, desc.getClassLoader()); // line #80
}
[ERROR] Failed to execute goal
org.apache.felix:maven-scr-plugin:1.7.1-SNAPSHOT:scr (scr) on project
barchart-plugin-core: Execution scr of goal
org.apache.felix:maven-scr-plugin:1.7.1-SNAPSHOT:scr failed.
NullPointerException - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.felix:maven-scr-plugin:1.7.1-SNAPSHOT:scr (scr) on project
barchart-plugin-core: Execution scr of goal
org.apache.felix:maven-scr-plugin:1.7.1-SNAPSHOT:scr failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:534)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution scr of
goal org.apache.felix:maven-scr-plugin:1.7.1-SNAPSHOT:scr failed.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:116)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: java.lang.NullPointerException
at
org.apache.felix.scrplugin.tags.annotation.defaulttag.ServiceTag$1.value(ServiceTag.java:80)
at
org.apache.felix.scrplugin.tags.annotation.defaulttag.ServiceTag.createServiceTags(ServiceTag.java:87)
at
org.apache.felix.scrplugin.tags.annotation.defaulttag.DefaultAnnotationTagProvider.getTags(DefaultAnnotationTagProvider.java:50)
at
org.apache.felix.scrplugin.tags.annotation.AnnotationTagProviderManager.getTags(AnnotationTagProviderManager.java:159)
at
org.apache.felix.scrplugin.tags.annotation.AnnotationTagProviderManager.getTags(AnnotationTagProviderManager.java:141)
at
org.apache.felix.scrplugin.tags.annotation.AnnotationTagProviderManager.hasScrPluginAnnotation(AnnotationTagProviderManager.java:176)
at
org.apache.felix.scrplugin.JavaClassDescriptorManager.getJavaClassDescription(JavaClassDescriptorManager.java:396)
at
org.apache.felix.scrplugin.JavaClassDescriptorManager.getSourceDescriptions(JavaClassDescriptorManager.java:365)
at
[jira] [Commented] (FELIX-2963) scr annotations @Activate @Deactivate @Modified are not detected with class inheritance
[
https://issues.apache.org/jira/browse/FELIX-2963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13045988#comment-13045988
]
Andrei Pozolotin commented on FELIX-2963:
-
still does not work for me; probably I have wrong snapshot:
maven-scr-plugin-1.7.1-20110517.073734-2.jar (latest from the repo) ?
scr annotations @Activate @Deactivate @Modified are not detected with class
inheritance
---
Key: FELIX-2963
URL: https://issues.apache.org/jira/browse/FELIX-2963
Project: Felix
Issue Type: Bug
Components: Maven SCR Plugin
Affects Versions: maven-scr-plugin-1.7.0, scr generator 1.1.0
Reporter: Andrei Pozolotin
Assignee: Carsten Ziegeler
Fix For: maven-scr-plugin-1.7.2, scr generator 1.1.2
// 1) when I use a base component with scr lifecycle annotations:
@Component(componentAbstract = true)
public abstract class BasePluginEDT {
@Activate
protected final void activateEDT(final MapString, String config) {
@Deactivate
protected final void deactivateEDT(final MapString, String config) {
@Modified
protected final void modifiedEDT(final MapString, String config) {
// 2) which is inherited by a derived component:
@Service
@Component(name = PluginSpaceService.PID, policy =
ConfigurationPolicy.REQUIRE, immediate = true)
public class BucketPlugin extends BasePluginEDT implements PluginSpaceService
{
// 3) then xml for the derived component does not show annotated methods from
the parent
scr:component enabled=true immediate=true
name=barchart.service.space configuration-policy=require
implementation class=com.ddfplus.core.space.BucketPlugin/
service servicefactory=false
provide interface=com.ddfplus.api.plugin.PluginSpaceService/
/service
property name=service.pid type=String
value=barchart.service.space/
reference name=beanService
interface=com.ddfplus.api.host.HostBeanService cardinality=1..1
policy=static bind=bind unbind=unbind/
reference name=dispService
interface=com.ddfplus.api.host.HostDisplayService cardinality=1..1
policy=static bind=bind unbind=unbind/
/scr:component
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: iPOJO vs SCR vs Blueprint
Obviously everybody needs all these goodies you mention. However the choice is to do this in iPOJO with a new language and new semantics attached to it or do it in Java. I am very familiar with the semantics of Java and the pain of the redundancy in Java over iPOJO in this area has not been high enough to make this switch seem desirable. Kind regards, Peter Kriens On 8 jun 2011, at 15:24, Richard S. Hall wrote: On 6/8/11 9:13, Peter Kriens wrote: The summary for me is that DS is limited to simplifying being a service and depending on other services while iPOJO and Blueprint add a programming language (XML/Annotations) that support services among many, many other features. In my experience DS is the simplest and least intrusive, especially with the SCR or bnd annotations. Blueprint is not my favorite because I consider XML among the worst programming languages one can imagine. I do not have a lot of experience with iPOJO; it is clearly the most powerful but it somehow lacks a compelling reason to switch as none of its additional functions seem worth the effort to switch. Yeah, who needs things like automatic concurrency handling for services or byte-code generated smart service references that eliminate the need to turn everything into a component in order to pass around services throughout your component? It's better to do all that stuff by hand with DS... ;-) - richard p.s. Sorry, I couldn't resist... :-P Anyway, who cares. They all interact very nicely and switching from one to the other is not so hard as long as you could in POJOs. Kind regards, Peter Kriens On 30 mei 2011, at 13:25, Felix Meschberger wrote: Hi, Just stating an incompletely informed opinion here .. If you want something simple, light-weight and easy to use, go for Declarative Services. If you want elaborate functionality or need something Declarative Services does not provide, consider iPojo (I understand it is an evolution of Declarative Services, right ?) If you have a Spring background go for blueprint. Regards Felix, whose loves and sticks with Declarative Services ;-) Am Donnerstag, den 26.05.2011, 02:23 +0100 schrieb jie yan: On Thu, May 26, 2011 at 6:02 AM, Alasdair Nottinghamn...@apache.org wrote: Alasdair Nottingham On 25 May 2011, at 22:16, Richard S. Hallhe...@ungoverned.org wrote: On 5/25/11 16:26, Alasdair Nottingham wrote: Hi, This is good I might link to it, or pinch it for the aries webpage too if that is ok. When doing that thought I would put some changes into the blueprint column. The Aries blueprint implementation provides some value add that would change some of the No's into Yes's. Sure. One thing though in component lifecycle control you have a Partial down for blueprint I was wondering what you meant by this. I'd have to review the chapter, I don't really claim to be any Blueprint expert...other than knowing it sucks... ;-) Of course if you were an expert you would know how much better it is than anything else ;) let the religious flame war begin, or not. In fact, casual users wish for an almighty expert who knows all solutions in-depth and exposes them to all. If there's no such expert, the second best method is, experts of different solutions advertise themself and compare with each other. Maybe that can be called religious flame war, but it's valuable. What we really need in open community is simple and perfect product in technology, but not many repeat manufacturing wheels like some outside companies. Regards, drhades - richard Thanks Alasdair On 25 May 2011 15:29, Richard S. Hallhe...@ungoverned.org wrote: On 5/25/11 9:19, Richard S. Hall wrote: We actually have a table in our book (OSGi in Action) that tries to compare the features...perhaps I could re-create that table on a web page... Ok, I added the table to the iPOJO FAQ on wiki: https://cwiki.apache.org/confluence/display/FELIX/iPOJO+FAQ#iPOJOFAQ-HowdoesiPOJOcomparetoDeclarativeServicesorBlueprint%3F It's not perfect, but it is better than nothing. It should eventually propagate to our static pages. Clement, please double check the iPOJO features, since you've added features since the book has been published. - richard On 5/25/11 5:26, jie yan wrote: +1 Regards, drhades On Wed, May 25, 2011 at 5:11 PM, Alex Karasuluakaras...@apache.org wrote: On Wed, May 25, 2011 at 6:28 AM, Richard S. Hall he...@ungoverned.org wrote: On 05/24/2011 09:46 PM, jie yan wrote: I wonder what is the difference between these three component runtime. They all manage service dependencies. Blueprint and iPOJO provide more sophisticated features than DS. Each has a different focus or goal. I guess everyone like myself is seeing this question occur regularly on this mailing list. It's a valid question that perhaps we can dedicate a wiki/web page to with the
Re: iPOJO vs SCR vs Blueprint
On 6/8/11 11:16, Peter Kriens wrote: Obviously everybody needs all these goodies you mention. However the choice is to do this in iPOJO with a new language and new semantics Actually, there is no new language...the annotations are basically the same as the ones you like for DS...but, yes, there are some new semantics, otherwise there'd be no new functionality. :-) - richard attached to it or do it in Java. I am very familiar with the semantics of Java and the pain of the redundancy in Java over iPOJO in this area has not been high enough to make this switch seem desirable. Kind regards, Peter Kriens On 8 jun 2011, at 15:24, Richard S. Hall wrote: On 6/8/11 9:13, Peter Kriens wrote: The summary for me is that DS is limited to simplifying being a service and depending on other services while iPOJO and Blueprint add a programming language (XML/Annotations) that support services among many, many other features. In my experience DS is the simplest and least intrusive, especially with the SCR or bnd annotations. Blueprint is not my favorite because I consider XML among the worst programming languages one can imagine. I do not have a lot of experience with iPOJO; it is clearly the most powerful but it somehow lacks a compelling reason to switch as none of its additional functions seem worth the effort to switch. Yeah, who needs things like automatic concurrency handling for services or byte-code generated smart service references that eliminate the need to turn everything into a component in order to pass around services throughout your component? It's better to do all that stuff by hand with DS... ;-) - richard p.s. Sorry, I couldn't resist... :-P Anyway, who cares. They all interact very nicely and switching from one to the other is not so hard as long as you could in POJOs. Kind regards, Peter Kriens On 30 mei 2011, at 13:25, Felix Meschberger wrote: Hi, Just stating an incompletely informed opinion here .. If you want something simple, light-weight and easy to use, go for Declarative Services. If you want elaborate functionality or need something Declarative Services does not provide, consider iPojo (I understand it is an evolution of Declarative Services, right ?) If you have a Spring background go for blueprint. Regards Felix, whose loves and sticks with Declarative Services ;-) Am Donnerstag, den 26.05.2011, 02:23 +0100 schrieb jie yan: On Thu, May 26, 2011 at 6:02 AM, Alasdair Nottinghamn...@apache.org wrote: Alasdair Nottingham On 25 May 2011, at 22:16, Richard S. Hallhe...@ungoverned.org wrote: On 5/25/11 16:26, Alasdair Nottingham wrote: Hi, This is good I might link to it, or pinch it for the aries webpage too if that is ok. When doing that thought I would put some changes into the blueprint column. The Aries blueprint implementation provides some value add that would change some of the No's into Yes's. Sure. One thing though in component lifecycle control you have a Partial down for blueprint I was wondering what you meant by this. I'd have to review the chapter, I don't really claim to be any Blueprint expert...other than knowing it sucks... ;-) Of course if you were an expert you would know how much better it is than anything else ;) let the religious flame war begin, or not. In fact, casual users wish for an almighty expert who knows all solutions in-depth and exposes them to all. If there's no such expert, the second best method is, experts of different solutions advertise themself and compare with each other. Maybe that can be called religious flame war, but it's valuable. What we really need in open community is simple and perfect product in technology, but not many repeat manufacturing wheels like some outside companies. Regards, drhades - richard Thanks Alasdair On 25 May 2011 15:29, Richard S. Hallhe...@ungoverned.orgwrote: On 5/25/11 9:19, Richard S. Hall wrote: We actually have a table in our book (OSGi in Action) that tries to compare the features...perhaps I could re-create that table on a web page... Ok, I added the table to the iPOJO FAQ on wiki: https://cwiki.apache.org/confluence/display/FELIX/iPOJO+FAQ#iPOJOFAQ-HowdoesiPOJOcomparetoDeclarativeServicesorBlueprint%3F It's not perfect, but it is better than nothing. It should eventually propagate to our static pages. Clement, please double check the iPOJO features, since you've added features since the book has been published. -richard On 5/25/11 5:26, jie yan wrote: +1 Regards, drhades On Wed, May 25, 2011 at 5:11 PM, Alex Karasuluakaras...@apache.org wrote: On Wed, May 25, 2011 at 6:28 AM, Richard S. Hall he...@ungoverned.org wrote: On 05/24/2011 09:46 PM, jie yan wrote: I wonder what is the difference between these three component runtime. They all manage service dependencies. Blueprint and iPOJO provide more sophisticated features than DS. Each has a different focus or goal. I guess everyone
[jira] [Commented] (FELIX-2961) @Component annotation should support defining the name with a compile time constant (instead of just a constant value)
[
https://issues.apache.org/jira/browse/FELIX-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13046319#comment-13046319
]
Andrei Pozolotin commented on FELIX-2961:
-
re: new feature of the @Component annotation.
yes, thank you.
re: this property will always be overwritten.
well, the alternative interpretation would be:
if there is no name attribute provided for the @Component(...) ,
and a property with the name component.name is provided instead,
then use the component.name property value for the xml tag attribute;
@Component annotation should support defining the name with a compile time
constant (instead of just a constant value)
--
Key: FELIX-2961
URL: https://issues.apache.org/jira/browse/FELIX-2961
Project: Felix
Issue Type: New Feature
Components: Declarative Services (SCR)
Affects Versions: scr annotations 1.5.0
Reporter: Andrei Pozolotin
hello!
when I use config admin to control instaniation of scr component services, I
use this pattern:
// 1) in config source bundle:
Configuration config =
configAdmin.getConfiguration(ZZZ, null);
DictionaryString, String props =
config.getProperties();
config.update(props);
// 2) in config target bundle:
@Service
@Component(name = AAA, policy = ConfigurationPolicy.REQUIRE, immediate =
true)
public class BucketPlugin implements PluginSpaceService {
@Property(name = service.pid)
protected static final String PID = ZZZ;
// 3) despite the fact service.pid looks good in xml for the tagret
compenent:
scr:component enabled=true immediate=true name=AAA
configuration-policy=require
implementation class=com.ddfplus.core.space.BucketPlugin/
service servicefactory=false
provide interface=com.ddfplus.api.plugin.PluginSpaceService/
/service
property name=service.pid type=String value=ZZZ/
// 4) the scr fails to initialize the component; intitialzation works only
when
(scr.component.name == config.service.pid) and NOT when (config.service.pid
== scr.component.property.pid)
// 5) if I look on the the config target in console (when I do manage to
inititialize it),
it shows that again, actual service.pid comes from scr.component.name and not
from scr.component.property.service.pid
thank you.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-2987) DependencyManager ConfigurationDependency update isn't propagated to super classes
DependencyManager ConfigurationDependency update isn't propagated to super classes -- Key: FELIX-2987 URL: https://issues.apache.org/jira/browse/FELIX-2987 Project: Felix Issue Type: Bug Components: Dependency Manager Affects Versions: dependencymanager-3.0.0 Environment: Felix 3.2.2, ConfigAdmin 1.2.8 Reporter: Alexander Broekhuis When using the latest release of the dependency manager (3.0.0), configuration dependencies aren't propagated towards parent classes. For previous releases this used to work (2.0.1). To reproduce: - Have an abstract class which implements the ManagedService interface and has the updated() method - Create a class which extends the previous abstract class - Create a new DependencyManager component with the created class as component - Add a configuration dependency to the component -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
