Re: bundleplugin release
It's working now. I updated the plugin and deployed it to snapshots. Thanks :-) regards, Karl On 7/12/07, Carlos Sanchez [EMAIL PROTECTED] wrote: some problems with the repo, fixed now On 7/11/07, Karl Pauls [EMAIL PROTECTED] wrote: hm, I can't seem to get it: dependency groupIdorg.apache.maven.shared/groupId artifactIdmaven-osgi/artifactId - version0.1.0-SNAPSHOT/version + version0.1.0/version /dependency gives me errors. Do I have to add a different repo? regards, Karl On 7/10/07, Carlos Sanchez [EMAIL PROTECTED] wrote: maven-osgi 0.1.0 was released and it will be available in few hours in the repo so you can update the dependency in preparation for the release of the bundle plugin On 7/9/07, Carlos Sanchez [EMAIL PROTECTED] wrote: the files were corrupt, just delete them from the local repo and try again On 7/9/07, Richard S. Hall [EMAIL PROTECTED] wrote: I think this will be good. The one change I was stilling hoping to make was updating the plugin to use version 160 of BND...this is not in the Maven repo, but when I download it I get checksum errors. Not sure what is going on. - richard Karl Pauls wrote: Hi all, as discussed previously, Rick and I have been working on getting the bundleplugin into shape for the 1.0.0 release. I just resolved the last remaining issue and deployed the new version to the snapshot repo. Furthermore, I create a release candidate under releases and added the current documentation form the wiki to the doc dir. Additionally, I created a changelog too. We intent to call a vote on it soonish so please let us know whether there are any showstoppers. regards, Karl -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride -- Karl Pauls [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride -- Karl Pauls [EMAIL PROTECTED]
Configuration Admin Extension
Hi all, Currently the Felix Config Admin implements the spec and as such provides the configuration objects as required. What we are missing here in one our projects is some kind of default configuration. As far as I understand the specs, the Configuration Admin provides configuration to ManagedService[Factory] objects. In addition the Declarative Services specification defines, that the declared components must be provided with Configuration Admin configuration (if the service and such configuration is available) overwriting any declared properties in the component declarations. Our issue now is, that in some cases the default configuration inside the ManagedService[Factory] objects or the declared components are not sufficient for the application but the Configuration Admin does not have any configuration yet to overwrite the defaults. We came up with the idea of supporting such initial configuration to the Configuration Admin inside of deployed bundles. Some service would pick up this configuration and add it to the Configuration Admin. So here is, what I propose: The ConfigurationManager of the Felix Config Admin listens for bundle changes. Whenever a bundle is installed, a special bundle manifest header - e.g. Felix-Configuration - would be read, which contains a comma-separated list of bundle entries. Each entry contains one or more configurations to be added to the Configuration Admin. The configurations from the bundles would be added to the Configuration Admin using the permissions of the bundle providing the configuration. Configuration is only added. That is, for normal configurations (non-factory), the configuration is only added if no configuration with the given service.pid already exists. For Factory configuration, the given configuraiton would only be added if no factory configuration for the given service.pid already exists. (In the future support for configuration update/enhancement might be added, but this is a wide open field, which I would not want to touch yet). What do you think ? Would such an extension make sense to other people ? Is the conceptual approach correct ? I will provide a prototype implementation shortly in a JIRA issue for further consideration. Thanks for any feedback on this. Regards Felix
problem with bundle instantiation
Hi everybody, I am developping an application where I have to associate a bundle to an other bundle providing a service A. However I want to have several bundles which provide the same service A. When I execute a getServiceReference on this service, I want it returns a list which contains the references of the registrations of service A. Until now, I cannot manage to get the different registrations of service, the getServiceReference method returns the reference of the first bundle which registrates the service. Is it possible to do this with Felix or not ? Does someone got the solution ? Thanks. Chris.
Re: problem with bundle instantiation
not sure if this is the problem, but if you expect different service implementations in a context, you always can get them using bundleContext.getServiceReferences(..) returning an array of ServiceReferences. If you deal with Services the ServiceTracker (org.osgi.tracker.ServiceTracker) is always worth looking at. Does this match your problem? otherwise try to reformulate your question.. regards, Toni Original-Nachricht Datum: Thu, 12 Jul 2007 11:58:04 +0200 Von: christine louberry [EMAIL PROTECTED] An: [EMAIL PROTECTED] Betreff: problem with bundle instantiation Hi everybody, I am developping an application where I have to associate a bundle to an other bundle providing a service A. However I want to have several bundles which provide the same service A. When I execute a getServiceReference on this service, I want it returns a list which contains the references of the registrations of service A. Until now, I cannot manage to get the different registrations of service, the getServiceReference method returns the reference of the first bundle which registrates the service. Is it possible to do this with Felix or not ? Does someone got the solution ? Thanks. Chris.
Re: Configuration Admin Extension
Have you looked at section 115 Auto Configuration in the OSGi R4 Mobile spec? I think it does what you want. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 Felix Meschberger [EMAIL PROTECTED] Sent by: Felix Meschberger [EMAIL PROTECTED] 2007-07-12 03:36 Please respond to dev@felix.apache.org To Felix Dev dev@felix.apache.org cc Subject Configuration Admin Extension Hi all, Currently the Felix Config Admin implements the spec and as such provides the configuration objects as required. What we are missing here in one our projects is some kind of default configuration. As far as I understand the specs, the Configuration Admin provides configuration to ManagedService[Factory] objects. In addition the Declarative Services specification defines, that the declared components must be provided with Configuration Admin configuration (if the service and such configuration is available) overwriting any declared properties in the component declarations. Our issue now is, that in some cases the default configuration inside the ManagedService[Factory] objects or the declared components are not sufficient for the application but the Configuration Admin does not have any configuration yet to overwrite the defaults. We came up with the idea of supporting such initial configuration to the Configuration Admin inside of deployed bundles. Some service would pick up this configuration and add it to the Configuration Admin. So here is, what I propose: The ConfigurationManager of the Felix Config Admin listens for bundle changes. Whenever a bundle is installed, a special bundle manifest header - e.g. Felix-Configuration - would be read, which contains a comma-separated list of bundle entries. Each entry contains one or more configurations to be added to the Configuration Admin. The configurations from the bundles would be added to the Configuration Admin using the permissions of the bundle providing the configuration. Configuration is only added. That is, for normal configurations (non-factory), the configuration is only added if no configuration with the given service.pid already exists. For Factory configuration, the given configuraiton would only be added if no factory configuration for the given service.pid already exists. (In the future support for configuration update/enhancement might be added, but this is a wide open field, which I would not want to touch yet). What do you think ? Would such an extension make sense to other people ? Is the conceptual approach correct ? I will provide a prototype implementation shortly in a JIRA issue for further consideration. Thanks for any feedback on this. Regards Felix
Re: Configuration Admin Extension
Wow ! I have to admit that I did not have a look at the 4.1 spec yet, so I did not realize there was a whole bunch of new service specs. I will of course now go back and start reading. Thanks for the hint. Until then I think, this idea is just to be dropped :-) Regards Felix Am Donnerstag, den 12.07.2007, 08:25 -0400 schrieb BJ Hargrave: Have you looked at section 115 Auto Configuration in the OSGi R4 Mobile spec? I think it does what you want.
Re: PreferencesService Implementation
Carsten Ziegeler wrote: I just wanted to let you know that I'm currently working on an implementation of the preferences service. I hope to get it finished in the next days. There is currently one (minor) point unclear to me. Is it allowed to call removeNode() on the parent node of the preferences? I don't see why not. The parent is just a node that can be removed like any other... - richard
1.0.0 subprojects release candidates
Hi all, Rick and I have been working some more on the 1.0.0 release. I just created release candidates for the first batch of subprojects we need to release before we can release the framework namely, pom-1.0.0-RC bundleplugin-1.0.0-RC2 org.osgi.core-1.0.0.-RC shell-1.0.0-RC shell.tui-1.0.0-RC bundlerepository-1.0.0-RC We intent to call a vote on them soonish so please let us know whether there are any showstoppers. regards, Karl -- Karl Pauls [EMAIL PROTECTED]
Re: 1.0.0 subprojects release candidates
For those that don't know, these release candidates are just tags in our SVN repo; they can be found here: http://svn.apache.org/repos/asf/felix/releases - richard On Jul 12, 2007, at 5:25 PM, Karl Pauls wrote: Hi all, Rick and I have been working some more on the 1.0.0 release. I just created release candidates for the first batch of subprojects we need to release before we can release the framework namely, pom-1.0.0-RC bundleplugin-1.0.0-RC2 org.osgi.core-1.0.0.-RC shell-1.0.0-RC shell.tui-1.0.0-RC bundlerepository-1.0.0-RC We intent to call a vote on them soonish so please let us know whether there are any showstoppers. regards, Karl -- Karl Pauls [EMAIL PROTECTED]
[jira] Updated: (FELIX-326) NPE in manifest goal
[ https://issues.apache.org/jira/browse/FELIX-326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez updated FELIX-326: - Attachment: patch.txt Patch for last exception NPE in manifest goal Key: FELIX-326 URL: https://issues.apache.org/jira/browse/FELIX-326 Project: Felix Issue Type: Bug Components: Maven Bundle Plugin Reporter: Carlos Sanchez Attachments: patch.txt, patch.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
