[jira] [Created] (FELIX-2972) Treatment of version ranges seems incorrect.
Treatment of version ranges seems incorrect. Key: FELIX-2972 URL: https://issues.apache.org/jira/browse/FELIX-2972 Project: Felix Issue Type: Bug Components: Maven Bundle Plugin Affects Versions: maven-bundle-plugin-2.3.4 Reporter: Andy Jefferson I have a sample project which specifies a dependency on dependency groupIdjavax.jdo/groupId artifactIdjdo-api/artifactId version[3.0, )/version scopeprovided/scope /dependency and there is a version 3.0, 3.1-SNAPSHOT-20110319, 3.1-SNAPSHOT-20110223 in the specified respositories. I generate the MANIFEST.MF and it gives an ImportPackage of Import-Package: javax.jdo;version=[3.1,4), ... It seemingly just grabs the latest current version available in the repositories in that range and takes that as the OSGi start version. This is incorrect, since a user could have v3.0 on their system and deploy that into OSGi and it doesn't allow deployment of this project. Or is it doing something deeper? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-2972) Treatment of version ranges seems incorrect.
[ https://issues.apache.org/jira/browse/FELIX-2972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Jefferson updated FELIX-2972: -- Attachment: bundle_test.zip Sample maven project that has the issue. Just run mvn clean install Treatment of version ranges seems incorrect. Key: FELIX-2972 URL: https://issues.apache.org/jira/browse/FELIX-2972 Project: Felix Issue Type: Bug Components: Maven Bundle Plugin Affects Versions: maven-bundle-plugin-2.3.4 Reporter: Andy Jefferson Attachments: bundle_test.zip I have a sample project which specifies a dependency on dependency groupIdjavax.jdo/groupId artifactIdjdo-api/artifactId version[3.0, )/version scopeprovided/scope /dependency and there is a version 3.0, 3.1-SNAPSHOT-20110319, 3.1-SNAPSHOT-20110223 in the specified respositories. I generate the MANIFEST.MF and it gives an ImportPackage of Import-Package: javax.jdo;version=[3.1,4), ... It seemingly just grabs the latest current version available in the repositories in that range and takes that as the OSGi start version. This is incorrect, since a user could have v3.0 on their system and deploy that into OSGi and it doesn't allow deployment of this project. Or is it doing something deeper? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2972) Treatment of version ranges seems incorrect.
[ https://issues.apache.org/jira/browse/FELIX-2972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13038978#comment-13038978 ] Guillaume Nodet commented on FELIX-2972: The maven bundle plugin does not really use version ranges expressed in maven. Actually, I'm not even sure we can access those as one of the first thing maven will do will be to resolve those ranges to exact versions. If you want to generate [3.0,4), you can simply depend on the 3.0 version in maven and it will work. I guess the problem is that maven tends to resolve to the highest possible version instead of the lowest. Treatment of version ranges seems incorrect. Key: FELIX-2972 URL: https://issues.apache.org/jira/browse/FELIX-2972 Project: Felix Issue Type: Bug Components: Maven Bundle Plugin Affects Versions: maven-bundle-plugin-2.3.4 Reporter: Andy Jefferson Attachments: bundle_test.zip I have a sample project which specifies a dependency on dependency groupIdjavax.jdo/groupId artifactIdjdo-api/artifactId version[3.0, )/version scopeprovided/scope /dependency and there is a version 3.0, 3.1-SNAPSHOT-20110319, 3.1-SNAPSHOT-20110223 in the specified respositories. I generate the MANIFEST.MF and it gives an ImportPackage of Import-Package: javax.jdo;version=[3.1,4), ... It seemingly just grabs the latest current version available in the repositories in that range and takes that as the OSGi start version. This is incorrect, since a user could have v3.0 on their system and deploy that into OSGi and it doesn't allow deployment of this project. Or is it doing something deeper? -- 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
On Wed, May 25, 2011 at 6:28 AM, Richard S. Hall he...@ungoverned.orgwrote: 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
+1 Regards, drhades On Wed, May 25, 2011 at 5:11 PM, Alex Karasulu akaras...@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 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. Hallhe...@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] [Closed] (FELIX-2959) [Framework] Implement OSGi R4.3 class loader byte-code weaving hook
[ https://issues.apache.org/jira/browse/FELIX-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall closed FELIX-2959. -- Resolution: Fixed I have implemented this in trunk. It passes snapshot R4.3 CT. [Framework] Implement OSGi R4.3 class loader byte-code weaving hook --- Key: FELIX-2959 URL: https://issues.apache.org/jira/browse/FELIX-2959 Project: Felix Issue Type: New Feature Components: Framework, Specification compliance Affects Versions: framework-3.2.2 Reporter: Richard S. Hall Assignee: Richard S. Hall Fix For: framework-4.0.0 Implement the OSGi R4.3 specification's new class loading hook to enable byte code weaving. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-2973) [Framework] Implement OSGi R4.3 generic capabilities and requirements
[Framework] Implement OSGi R4.3 generic capabilities and requirements - Key: FELIX-2973 URL: https://issues.apache.org/jira/browse/FELIX-2973 Project: Felix Issue Type: New Feature Components: Framework, Specification compliance Affects Versions: framework-3.2.2 Reporter: Richard S. Hall Assignee: Richard S. Hall Fix For: framework-4.0.0 The OSGi R4.3 spec introduces a generic mechanism for a bundle to provide some capability (Provide-Capability) and other bundles to require such capabilities (Require-Capability). We need to implement this feature. Since it is based on the existing model used by the Felix framework, this should be reasonably straightforward. The biggest changes are the support of specifying types in the manifest header for capabilities and that generic capabilities can express uses constraints on packages. -- 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
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. One thing though in component lifecycle control you have a Partial down for blueprint I was wondering what you meant by this. Thanks Alasdair On 25 May 2011 15:29, Richard S. Hall he...@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. Hallhe...@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 -- Alasdair Nottingham n...@apache.org
Re: iPOJO vs SCR vs Blueprint
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... ;-) - 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. Hallhe...@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
Wouldn't it make more sense to add this to the Felix FAQ instead. In any case I'd be happy to add Dependency Manager to the list if nobody objects. On May 25, 2011, at 23:16 , Richard S. Hall 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... ;-) - 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. Hallhe...@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
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. - 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. Hallhe...@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 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 05/25/2011 06:00 PM, Marcel Offermans wrote: Wouldn't it make more sense to add this to the Felix FAQ instead. In any case I'd be happy to add Dependency Manager to the list if nobody objects. Well, we can point to it from any number of places, so I'm not sure if it matters where it leaves. But feel free to add DM and move it where you want (just update the iPOJO FAQ to point to it instead). - richard On May 25, 2011, at 23:16 , Richard S. Hall 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... ;-) - 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. Hallhe...@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 05/25/2011 09:23 PM, jie yan wrote: 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. When implementing any software there are design trade-offs as well as different focuses and goals. So, even though the wheel may look like a reinvention, it is not generally the exact same wheel, only similar. While it would be great if we could always agree on a single design and set of trade-offs, the likelihood of that is slim. - richard 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 Thu, May 26, 2011 at 10:38 AM, Richard S. Hall he...@ungoverned.orgwrote: On 05/25/2011 09:23 PM, jie yan wrote: 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. When implementing any software there are design trade-offs as well as different focuses and goals. So, even though the wheel may look like a reinvention, it is not generally the exact same wheel, only similar. While it would be great if we could always agree on a single design and set of trade-offs, the likelihood of that is slim. I agree with that. The current problem maybe that, we cannot easily see enough information about the trade-offs of each design and comparisons of them. We can also dive into the application and implementation of each solution, to find out the better one, to love and support one of them, or even to reinvent a better one based on existing design. While that's quite high cost, if there are no enough comparative information about design trade-offs that can be easily accessed. Regards, drhades - richard 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
snapshot of bundlerepository
Hi, Can someone please publish latest snapshot of the bundlerepository module? The one currently published is pretty old. Thanks, Jarek
