surprised by auto-generated Import-Package
Using the POM at: http://svn.apache.org/viewvc/maven/sandbox/branches/doxia-ide-eclipse-with-tycho/org.apache.maven.doxia.eclipse.dependencies/pom.xml?revision=1162392view=markup I am perplexed to get a very long Import-Package, including many things that are embedded, plus things like com.apple.mrj. Should I just put in an explicit Import-Package of '*' in the POM, or is there something more complex I've messed up here? - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Declarative Services, determining reference satisfaction with target services
Hi David, Indeed I have also reproduce the problem you are describing. I think I have a working patch; so I will create a JIRA issue and will attach the patch to it. kind regards; /Pierre On Fri, Aug 26, 2011 at 11:58 PM, david.humen...@l-3com.com wrote: It looks like part of the problem is that the ComponentFactoryImpl doesn't look at the target service properties for some reason so it accepts services even if the target doesn't match. When the component instance is created, the ComponentFactoryNewInstance does check the target properties so the instantiation fails. I think this is a bug. David Humeniuk -Original Message- From: david.humen...@l-3com.com [mailto:david.humen...@l-3com.com] Sent: Friday, August 26, 2011 3:33 PM To: users@felix.apache.org Subject: Declarative Services, determining reference satisfaction with target services I have a factory component (call it ComponentA) with a service reference (call it X). The service reference X has an interface of Y and a target of (name=Z) If a service is registered with an interface of Y, but a name service property of something other than Z, I would expect the service reference X to not be satisfied. However, using Felix SCR, I'm seeing that the reference is satisfied. When I go to create an instance with the factory, I then get a ComponentException saying the dependency is not satisfied. David Humeniuk Software Engineer L-3 Nova Engineering 4393 Digital Way Mason, Ohio 45040 513-204-7628 (Direct) 513-204-7600 (Main) 513-204-8999 (Main Fax) www.L-3com.com/Nova - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Declarative Services, determining reference satisfaction with target services
David, I created the FELIX-3090 issue, and attached a patch to it. can you test it ? thanks. /pierre On Sat, Aug 27, 2011 at 11:50 PM, Pierre De Rop pierre.de...@gmail.comwrote: Hi David, Indeed I have also reproduce the problem you are describing. I think I have a working patch; so I will create a JIRA issue and will attach the patch to it. kind regards; /Pierre On Fri, Aug 26, 2011 at 11:58 PM, david.humen...@l-3com.com wrote: It looks like part of the problem is that the ComponentFactoryImpl doesn't look at the target service properties for some reason so it accepts services even if the target doesn't match. When the component instance is created, the ComponentFactoryNewInstance does check the target properties so the instantiation fails. I think this is a bug. David Humeniuk -Original Message- From: david.humen...@l-3com.com [mailto:david.humen...@l-3com.com] Sent: Friday, August 26, 2011 3:33 PM To: users@felix.apache.org Subject: Declarative Services, determining reference satisfaction with target services I have a factory component (call it ComponentA) with a service reference (call it X). The service reference X has an interface of Y and a target of (name=Z) If a service is registered with an interface of Y, but a name service property of something other than Z, I would expect the service reference X to not be satisfied. However, using Felix SCR, I'm seeing that the reference is satisfied. When I go to create an instance with the factory, I then get a ComponentException saying the dependency is not satisfied. David Humeniuk Software Engineer L-3 Nova Engineering 4393 Digital Way Mason, Ohio 45040 513-204-7628 (Direct) 513-204-7600 (Main) 513-204-8999 (Main Fax) www.L-3com.com/Nova - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
generated manifest loses things on the way into the jar
In my project, (using 2.3.5 and the bundle packaging) a perfectly reasonable manifest appears in target/classes/META-INF/MANIFEST.MF. However, the manifest that is actually delivered to the jar is DIFFERENT, and lacks a critical Export-Package. I don't know how to attack this. - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: generated manifest loses things on the way into the jar
On 28 August 2011 01:29, Benson Margulies bimargul...@gmail.com wrote: In my project, (using 2.3.5 and the bundle packaging) a perfectly reasonable manifest appears in target/classes/META-INF/MANIFEST.MF. However, the manifest that is actually delivered to the jar is DIFFERENT, and lacks a critical Export-Package. I don't know how to attack this. I tried your example in FELIX-3091 and the export is there, but the last t of the package is wrapped onto the next line. For some reason the manifest extracted from the jar file has a different line-length wrapping than the one written out to target/classes. But they do show the same packages when you unwrap the content. Note, you can use bnd to pretty-print the manifest which can help when searching: java -jar bnd.jar print target/org.apache.maven.doxia.eclipse.dependencies_1.0.0-SNAPSHOT.jar See http://www.aqute.biz/Bnd/CommandLine http://www.aqute.biz/Bnd/Download -- Cheers, Stuart
Re: surprised by auto-generated Import-Package
On 27 August 2011 17:52, Benson Margulies bimargul...@gmail.com wrote: Using the POM at: http://svn.apache.org/viewvc/maven/sandbox/branches/doxia-ide-eclipse-with-tycho/org.apache.maven.doxia.eclipse.dependencies/pom.xml?revision=1162392view=markup I am perplexed to get a very long Import-Package, including many things that are embedded, plus things like com.apple.mrj. Should I just put in an explicit Import-Package of '*' in the POM, or is there something more complex I've messed up here? that example uses bundleplugin 2.1.0 which automatically imported every import for reasons of substitutability: http://felix.apache.org/site/apache-felix-osgi-faq.html#ApacheFelixOSGiFAQ-Shouldabundleimportitsownexportedpackages%253F in recent versions (2.3.5) the bundleplugin (actually bnd, which does the hard work) takes a heuristic approach: http://www.aqute.biz/Bnd/Versioning - see Substitution section near the end of the page which means you shouldn't see as many imports using the defaults - see also: http://www.aqute.biz/Bnd/Format#import-package http://www.aqute.biz/Bnd/Format#export-package for ways to exclude imports, mark them as optional, or stop selected exports from being imported -- Cheers, Stuart
