Re: Declarative Services and service.pid
Am Donnerstag, den 06.09.2007, 11:53 +0800 schrieb Niclas Hedhman: > On Wednesday 05 September 2007 21:08, Felix Meschberger wrote: > > (2) For services registered through SCR, the service.pid property is set > > if configuration exists in the Configuration Admin for the service. In > > addition these services have the component.name property set. > > I find this statement strange. > > Services are expected to set their own PID, and the Config Admin does not > need > to have a Configuration created with that PID in advance. IIRC, the creation > of the Configuration instance is asynchronous with everything else. Agreed. > And why would there be any difference with Declarative Services? The service > itself sets the PID (but the spec should be very clear if this is done > declaratively or the SCR does it according to some algorithm, barely up for > interpretation) and the SCR have no doing in checking whether Config Admin > has already created a Config with that PID... It is different, because it is SCR which registers the service and therefore sets up the registration properties and not some activator or so. And yes, unfortunately the spec on Declarative Service only uses the PID when speaking of retrieving the configuration from Configuration Admin. There is no note as to whether the PID is set and who should set the PID. So, why is the PID added if configuration is available ? According to the Config Admin spec, the configuration properties must contain the service.pid (and others). According to the Declarative Services Spec, the Configuration properties are added to the component properties. As a consequence, the PID is added to the properties if configuration is available. Finally, agreed, that the SCR should not care for the PID, which is why I would not actually like such a solution. So, if the PID should be set - regardless of whether a configuration is available or not - the PID should be declared as a component property in the descriptor. There may be an ommission in the spec in this regards ? Maybe I should just ask on the OSGi dev list ... Regards Felix
Re: Declarative Services and service.pid
On Wednesday 05 September 2007 21:08, Felix Meschberger wrote: > (2) For services registered through SCR, the service.pid property is set > if configuration exists in the Configuration Admin for the service. In > addition these services have the component.name property set. I find this statement strange. Services are expected to set their own PID, and the Config Admin does not need to have a Configuration created with that PID in advance. IIRC, the creation of the Configuration instance is asynchronous with everything else. And why would there be any difference with Declarative Services? The service itself sets the PID (but the spec should be very clear if this is done declaratively or the SCR does it according to some algorithm, barely up for interpretation) and the SCR have no doing in checking whether Config Admin has already created a Config with that PID... What am I missing in this discussion? Cheers Niclas
[jira] Assigned: (FELIX-352) Caught ZipException with 'manifest' goal
[
https://issues.apache.org/jira/browse/FELIX-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stuart McCulloch reassigned FELIX-352:
--
Assignee: Stuart McCulloch
> Caught ZipException with 'manifest' goal
>
>
> Key: FELIX-352
> URL: https://issues.apache.org/jira/browse/FELIX-352
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: 1.0.0
> Environment: Linux t-quad 2.6.22-gentoo-r5 #1 SMP Thu Aug 23 09:53:07
> CEST 2007 i686 Intel(R) Core(TM)2 Quad CPU @ 2.40GHz GenuineIntel GNU/Linux
> Sun JDK 1.6.0.02 [sun-jdk-1.6]
> $ mvn -version
> Maven version: 2.0.7
> Java version: 1.6.0_02
> OS name: "linux" version: "2.6.22-gentoo-r5" arch: "i386"
>Reporter: Tobias Roeser
>Assignee: Stuart McCulloch
>
> I'm using the maven-bundle-plugin version 1.0 from the
> releases/bundleplugin-1.0.0 branch.
> The following command fails on a clean project:
> mvn org.apache.felix:maven-bundle-plugin:manifest
> The error message is:
> [DEBUG] Configuring mojo
> 'org.apache.felix:maven-bundle-plugin:1.0.0:manifest' -->
> [DEBUG] (f) baseDir = /home/t/work/test
> [DEBUG] (f) buildDirectory = /home/t/work/test/target
> [DEBUG] (f) instructions = {Bundle-Activator=de.example.main.Activator,
> Export-Package=de.example.main.*}
> [DEBUG] (f) manifestLocation = /home/t/work/test/target/classes/META-INF
> [DEBUG] (f) outputDirectory = /home/t/work/test/target/classes
> [DEBUG] (f) project = [EMAIL PROTECTED]
> [DEBUG] -- end configuration --
> [INFO] [bundle:manifest]
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error trying to generate Manifest
> Embedded error: error in opening zip file
> [INFO]
>
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error trying to
> generate Manifest
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
> 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.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error trying to
> generate Manifest
> at
> org.apache.felix.bundleplugin.ManifestPlugin.execute(ManifestPlugin.java:63)
> at
> org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:123)
> at
> org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:118)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> ... 16 more
> Caused by: java.util.zip.ZipException: error in opening zip file
> at java.util.zip.ZipFile.open(Native Method)
> at java.util.zip.ZipFile.(ZipFile.java:114)
> at java.util.zip.ZipFile.(ZipFile.java:131)
> at aQute.lib.osgi.ZipResource.build(ZipResource.java:39)
> at aQute.lib.osgi.ZipResource.build(ZipResource.java:32)
> at aQute.lib.osgi.Jar.(Jar.java:31)
> at aQute.lib.osgi.Jar.(Jar.java:50)
> at aQute.lib.osgi.Analyzer.setJar(Analyzer.java:619)
> at
> org.apache.felix.bundleplugin.ManifestPlugin.getAnalyzer(ManifestP
Re: Declarative Services and service.pid
Am Mittwoch, den 05.09.2007, 17:15 +0200 schrieb Carsten Ziegeler: > Hmm, but as we are also using the metatype service, I thought by > specifying the metatype:Designate with the metatype:Object element > inside the metatype.xml, a configuration is created for the service. > Therefore the configuration should not be new. Or am I misreading the > spec here? That is an interesting question. Currently the SCR does not register a ManagedService on behalf of a component to get the configuration but directly accesses the Configuration Admin for the configuration - which is also why a Configuration object is always created for each component. (This is different for factory components, where a ManagedServiceFactory is registered on behalf of the factory component) If SCR would do so, SCR could of course register a ManagedService which also is a MetaTypeProvider which could use the metatype service to access its object class definition for default configuration. But: This has probably no advantage regarding default configuration because the SCR plugin writes both the metatype file and the component descriptor with the same default values. So the component is already provided the default configuration. In addition, having a MetaTypeProvider would also not help in case there is no MetaType data (well, the SCR could of course construct this from the component descriptor ...) Finally, the Config Admin spec with regard to MetaTypeProvider is rather unclear as to how this would relate to the other spec, that a never updated Configuration must return when asked for the properties. Maybe the intent is to immediately update the newly created configuration with the MetaTypeProvider default configuration ? Regards Felix
[jira] Closed: (FELIX-353) Garbled scr.property name when serialVersionUID declaration is present
[
https://issues.apache.org/jira/browse/FELIX-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler closed FELIX-353.
--
> Garbled scr.property name when serialVersionUID declaration is present
> --
>
> Key: FELIX-353
> URL: https://issues.apache.org/jira/browse/FELIX-353
> Project: Felix
> Issue Type: Bug
> Components: Maven SCR Plugin
> Environment: macosx / JDK 1.5 / maven-scr-plugin V0.3.0-SNAPSHOT
>Reporter: Bertrand Delacretaz
>Priority: Minor
> Attachments: pom.xml
>
>
> Processing the following code with "mvn scr:scr" generates a garbled
> scr.property name in serviceComponents.xml:
> package org.apache.felix.bugreports;
> /** @scr.component */
> public class TestScrProperty {
> // the scr.property name is correctly generated
> // if the following declaration is commented out
> private static final long serialVersionUID = 5710195320616458465L;
>// this comment should not be part of the
>// scr.property name, but it is
> /** @scr.property value="something" */
> private final static String S = "whatever";
> }
> Leads to a bad scr:property name:
>
> http://www.osgi.org/xmlns/scr/v1.0.0";>
> name="org.apache.felix.bugreports.TestScrProperty">
>
> value="something"/>
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-353) Garbled scr.property name when serialVersionUID declaration is present
[
https://issues.apache.org/jira/browse/FELIX-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525133
]
Bertrand Delacretaz commented on FELIX-353:
---
Confirmed, revision #572968 processes my example correctly, thanks!
> Garbled scr.property name when serialVersionUID declaration is present
> --
>
> Key: FELIX-353
> URL: https://issues.apache.org/jira/browse/FELIX-353
> Project: Felix
> Issue Type: Bug
> Components: Maven SCR Plugin
> Environment: macosx / JDK 1.5 / maven-scr-plugin V0.3.0-SNAPSHOT
>Reporter: Bertrand Delacretaz
>Priority: Minor
> Attachments: pom.xml
>
>
> Processing the following code with "mvn scr:scr" generates a garbled
> scr.property name in serviceComponents.xml:
> package org.apache.felix.bugreports;
> /** @scr.component */
> public class TestScrProperty {
> // the scr.property name is correctly generated
> // if the following declaration is commented out
> private static final long serialVersionUID = 5710195320616458465L;
>// this comment should not be part of the
>// scr.property name, but it is
> /** @scr.property value="something" */
> private final static String S = "whatever";
> }
> Leads to a bad scr:property name:
>
> http://www.osgi.org/xmlns/scr/v1.0.0";>
> name="org.apache.felix.bugreports.TestScrProperty">
>
> value="something"/>
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-353) Garbled scr.property name when serialVersionUID declaration is present
[
https://issues.apache.org/jira/browse/FELIX-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler resolved FELIX-353.
Resolution: Fixed
The value of a field is used to determine the name of a property. I committed a
fix for this, please cross-check.
> Garbled scr.property name when serialVersionUID declaration is present
> --
>
> Key: FELIX-353
> URL: https://issues.apache.org/jira/browse/FELIX-353
> Project: Felix
> Issue Type: Bug
> Components: Maven SCR Plugin
> Environment: macosx / JDK 1.5 / maven-scr-plugin V0.3.0-SNAPSHOT
>Reporter: Bertrand Delacretaz
>Priority: Minor
> Attachments: pom.xml
>
>
> Processing the following code with "mvn scr:scr" generates a garbled
> scr.property name in serviceComponents.xml:
> package org.apache.felix.bugreports;
> /** @scr.component */
> public class TestScrProperty {
> // the scr.property name is correctly generated
> // if the following declaration is commented out
> private static final long serialVersionUID = 5710195320616458465L;
>// this comment should not be part of the
>// scr.property name, but it is
> /** @scr.property value="something" */
> private final static String S = "whatever";
> }
> Leads to a bad scr:property name:
>
> http://www.osgi.org/xmlns/scr/v1.0.0";>
> name="org.apache.felix.bugreports.TestScrProperty">
>
> value="something"/>
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Declarative Services and service.pid
Felix Meschberger wrote: > Am Mittwoch, den 05.09.2007, 16:31 +0200 schrieb Carsten Ziegeler: >> Which is fine, I think - because if the configuration admin would >> deliver the PID regardless if update() has been called, SCR would get >> the PID always and does not need any additional logic. > > This is not possible: The ConfigurationAdmin returns a Configuration > object, which has a method to access the PID (amongst others). The > properties returned from the Configuration object must either bei null > if the Configuration is new or must contain the PID (amongst others) if > not new. So in our problematic case the PID cannot be delivered from the > Configuration Admin. > Hmm, but as we are also using the metatype service, I thought by specifying the metatype:Designate with the metatype:Object element inside the metatype.xml, a configuration is created for the service. Therefore the configuration should not be new. Or am I misreading the spec here? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Declarative Services and service.pid
Am Mittwoch, den 05.09.2007, 16:31 +0200 schrieb Carsten Ziegeler: > Which is fine, I think - because if the configuration admin would > deliver the PID regardless if update() has been called, SCR would get > the PID always and does not need any additional logic. This is not possible: The ConfigurationAdmin returns a Configuration object, which has a method to access the PID (amongst others). The properties returned from the Configuration object must either bei null if the Configuration is new or must contain the PID (amongst others) if not new. So in our problematic case the PID cannot be delivered from the Configuration Admin. Regards Felix
Re: Declarative Services and service.pid
Felix Meschberger wrote: > Am Mittwoch, den 05.09.2007, 16:05 +0200 schrieb Carsten Ziegeler: >> I haven't looked briefly at the spec to be honest, but what I find >> strange is that the component has a pid when viewed in the configuration >> admin (and the metatype.xml contains an entry for this). It seems (as >> you write in the jira issue) that this pid is only available in scr if >> the configuration has been changed once (update() is called). So from a >> client perspective (someone using this component), it depends if it gets >> the PID based on the fact if someone has updated the configuration or >> not. This looks a little bit strange to me. > > I agree. But the Declarative Services spec only mentions the PID when > talking about retrieving configuration from the Configuration Admin. > Therefore the SCR does not set that property automatically - currently. > Which is fine, I think - because if the configuration admin would deliver the PID regardless if update() has been called, SCR would get the PID always and does not need any additional logic. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Declarative Services and service.pid
Am Mittwoch, den 05.09.2007, 16:05 +0200 schrieb Carsten Ziegeler: > I haven't looked briefly at the spec to be honest, but what I find > strange is that the component has a pid when viewed in the configuration > admin (and the metatype.xml contains an entry for this). It seems (as > you write in the jira issue) that this pid is only available in scr if > the configuration has been changed once (update() is called). So from a > client perspective (someone using this component), it depends if it gets > the PID based on the fact if someone has updated the configuration or > not. This looks a little bit strange to me. I agree. But the Declarative Services spec only mentions the PID when talking about retrieving configuration from the Configuration Admin. Therefore the SCR does not set that property automatically - currently. Regards Felix
Re: Declarative Services and service.pid
Felix Meschberger schrieb: > Hi all, > > Issue FELIX-354 ([1]) complains, that the ServiceReference properties of > services registered through the SCR do not always contain the > service.pid property. In the Felix implementation, this property is > currently only set if the Configuration Admin service can provide > configuration to the component with the component name used as the PID > because the Configuration Admin service has to set the service.pid in > the configuration (if configuration exists). > > So, this leaves us with a strange situation: > > (1) For services not registered through SCR, the service.pid is of > course only set if the registrar sets the property. > (2) For services registered through SCR, the service.pid property is set > if configuration exists in the Configuration Admin for the service. In > addition these services have the component.name property set. > > While the first case is completely outside of our control (which is > good), I am not sure about the second one: I would like to have the SCR > add the service.pid property to the service registration (if not set > through other means, e.g. the component properties). According to the > spec, the SCR only adds the component.id and component.name properties. > > I wonder, whether it is ok to modify the SCR like this ? > > Or should we rather extend the maven-scr-plugin to generate the > service.pid property automatically from the component name (if not > explicitly set by the user, which would probably not be a good idea) ? > > What do you think ? > I haven't looked briefly at the spec to be honest, but what I find strange is that the component has a pid when viewed in the configuration admin (and the metatype.xml contains an entry for this). It seems (as you write in the jira issue) that this pid is only available in scr if the configuration has been changed once (update() is called). So from a client perspective (someone using this component), it depends if it gets the PID based on the fact if someone has updated the configuration or not. This looks a little bit strange to me. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Commented: (FELIX-354) Service.PID not always available in properties
[ https://issues.apache.org/jira/browse/FELIX-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525100 ] Felix Meschberger commented on FELIX-354: - The service.pid property is not set by the SCR. It is either set by the declared component properties or by the configuration properties of there is configuration for the component. But there is some subtlety here: The ConfigurationAdmin.getConfiguration method always returns a Configuration object - either an existing or a newly created configuration. In the case of a newly created configuration object, the configuration apears to exist but as there has not been any properties set and thus the Configuration.update(Dictionary) method never called, the newly created object returns null instead of an empty Dictionary. In short, the component properties will not contain any ConfigurationAdmin configuration if the respective configuration object does not return a Dictionary. Therefore, the service.pid is not set. On the other hand, as soon as the Configuration.update(Dictionary) method has been called and the configuration data been stored, the component is cycled and provided with the new configuration data, this time with the service.pid property. To my understanding, this all works as specified. Still I agree, that it would probably be good to have the service.pid in the service properties and the component properties at all time. Two solutions come to mind: (1) Enhance SCR to inject the service.pid if not existing. I am not sure, whether this is ok with the spec (2) Enhance the maven-scr-plugin to create a service.pid property automatically Discussing these options in the dev list. > Service.PID not always available in properties > -- > > Key: FELIX-354 > URL: https://issues.apache.org/jira/browse/FELIX-354 > Project: Felix > Issue Type: Bug > Components: Declarative Services >Reporter: Carsten Ziegeler > > In some cases, the property Constants.SERVICE_PID is null for a service even > if it has a configuration. > Use case: > Two services are registered through SCR, service A has a static reference to > service B. > When the bind method in Service A is called with the ServiceReference to B, > the SERVICE_PID is null in the properties. > Service B has a configuration and can be configured through the configuration > admin (SERVICE_PID is available there). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Declarative Services and service.pid
Hi all, Issue FELIX-354 ([1]) complains, that the ServiceReference properties of services registered through the SCR do not always contain the service.pid property. In the Felix implementation, this property is currently only set if the Configuration Admin service can provide configuration to the component with the component name used as the PID because the Configuration Admin service has to set the service.pid in the configuration (if configuration exists). So, this leaves us with a strange situation: (1) For services not registered through SCR, the service.pid is of course only set if the registrar sets the property. (2) For services registered through SCR, the service.pid property is set if configuration exists in the Configuration Admin for the service. In addition these services have the component.name property set. While the first case is completely outside of our control (which is good), I am not sure about the second one: I would like to have the SCR add the service.pid property to the service registration (if not set through other means, e.g. the component properties). According to the spec, the SCR only adds the component.id and component.name properties. I wonder, whether it is ok to modify the SCR like this ? Or should we rather extend the maven-scr-plugin to generate the service.pid property automatically from the component name (if not explicitly set by the user, which would probably not be a good idea) ? What do you think ? Regards and Thanks Felix [1] https://issues.apache.org/jira/browse/FELIX-354
[jira] Created: (FELIX-354) Service.PID not always available in properties
Service.PID not always available in properties -- Key: FELIX-354 URL: https://issues.apache.org/jira/browse/FELIX-354 Project: Felix Issue Type: Bug Components: Declarative Services Reporter: Carsten Ziegeler In some cases, the property Constants.SERVICE_PID is null for a service even if it has a configuration. Use case: Two services are registered through SCR, service A has a static reference to service B. When the bind method in Service A is called with the ServiceReference to B, the SERVICE_PID is null in the properties. Service B has a configuration and can be configured through the configuration admin (SERVICE_PID is available there). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-352) Caught ZipException with 'manifest' goal
[
https://issues.apache.org/jira/browse/FELIX-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525043
]
Tobias Roeser commented on FELIX-352:
-
After more investigation on this issue, I figured out, that the method throwing
the Exception is ManifestPlugin.getAnalyzer(). this method doen't ensures, that
the output directory retrieved with getOutputDirectory() exists. After a 'mvn
clean' the default output directory 'target/classes' doesn't exists. A call to
PackageVersionAnalyzer.setJar() with an non existing directory as argument will
throw the Exception mentioned above.
The manifest goal should ensure, that the directory exists before using it, at
least if the output directory is the default one.
> Caught ZipException with 'manifest' goal
>
>
> Key: FELIX-352
> URL: https://issues.apache.org/jira/browse/FELIX-352
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: 1.0.0
> Environment: Linux t-quad 2.6.22-gentoo-r5 #1 SMP Thu Aug 23 09:53:07
> CEST 2007 i686 Intel(R) Core(TM)2 Quad CPU @ 2.40GHz GenuineIntel GNU/Linux
> Sun JDK 1.6.0.02 [sun-jdk-1.6]
> $ mvn -version
> Maven version: 2.0.7
> Java version: 1.6.0_02
> OS name: "linux" version: "2.6.22-gentoo-r5" arch: "i386"
>Reporter: Tobias Roeser
>
> I'm using the maven-bundle-plugin version 1.0 from the
> releases/bundleplugin-1.0.0 branch.
> The following command fails on a clean project:
> mvn org.apache.felix:maven-bundle-plugin:manifest
> The error message is:
> [DEBUG] Configuring mojo
> 'org.apache.felix:maven-bundle-plugin:1.0.0:manifest' -->
> [DEBUG] (f) baseDir = /home/t/work/test
> [DEBUG] (f) buildDirectory = /home/t/work/test/target
> [DEBUG] (f) instructions = {Bundle-Activator=de.example.main.Activator,
> Export-Package=de.example.main.*}
> [DEBUG] (f) manifestLocation = /home/t/work/test/target/classes/META-INF
> [DEBUG] (f) outputDirectory = /home/t/work/test/target/classes
> [DEBUG] (f) project = [EMAIL PROTECTED]
> [DEBUG] -- end configuration --
> [INFO] [bundle:manifest]
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error trying to generate Manifest
> Embedded error: error in opening zip file
> [INFO]
>
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error trying to
> generate Manifest
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
> 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.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error trying to
> generate Manifest
> at
> org.apache.felix.bundleplugin.ManifestPlugin.execute(ManifestPlugin.java:63)
> at
> org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:123)
> at
> org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:118)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> ... 16 more
> Caused by: java.util.zip.ZipException: error in opening zip file
> at jav
[jira] Updated: (FELIX-353) Garbled scr.property name when serialVersionUID declaration is present
[
https://issues.apache.org/jira/browse/FELIX-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bertrand Delacretaz updated FELIX-353:
--
Attachment: pom.xml
the pom.xml that I'm using
> Garbled scr.property name when serialVersionUID declaration is present
> --
>
> Key: FELIX-353
> URL: https://issues.apache.org/jira/browse/FELIX-353
> Project: Felix
> Issue Type: Bug
> Components: Maven SCR Plugin
> Environment: macosx / JDK 1.5 / maven-scr-plugin V0.3.0-SNAPSHOT
>Reporter: Bertrand Delacretaz
>Priority: Minor
> Attachments: pom.xml
>
>
> Processing the following code with "mvn scr:scr" generates a garbled
> scr.property name in serviceComponents.xml:
> package org.apache.felix.bugreports;
> /** @scr.component */
> public class TestScrProperty {
> // the scr.property name is correctly generated
> // if the following declaration is commented out
> private static final long serialVersionUID = 5710195320616458465L;
>// this comment should not be part of the
>// scr.property name, but it is
> /** @scr.property value="something" */
> private final static String S = "whatever";
> }
> Leads to a bad scr:property name:
>
> http://www.osgi.org/xmlns/scr/v1.0.0";>
> name="org.apache.felix.bugreports.TestScrProperty">
>
> value="something"/>
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-353) Garbled scr.property name when serialVersionUID declaration is present
Garbled scr.property name when serialVersionUID declaration is present
--
Key: FELIX-353
URL: https://issues.apache.org/jira/browse/FELIX-353
Project: Felix
Issue Type: Bug
Components: Maven SCR Plugin
Environment: macosx / JDK 1.5 / maven-scr-plugin V0.3.0-SNAPSHOT
Reporter: Bertrand Delacretaz
Priority: Minor
Processing the following code with "mvn scr:scr" generates a garbled
scr.property name in serviceComponents.xml:
package org.apache.felix.bugreports;
/** @scr.component */
public class TestScrProperty {
// the scr.property name is correctly generated
// if the following declaration is commented out
private static final long serialVersionUID = 5710195320616458465L;
// this comment should not be part of the
// scr.property name, but it is
/** @scr.property value="something" */
private final static String S = "whatever";
}
Leads to a bad scr:property name:
http://www.osgi.org/xmlns/scr/v1.0.0";>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-352) Caught ZipException with 'manifest' goal
Caught ZipException with 'manifest' goal
Key: FELIX-352
URL: https://issues.apache.org/jira/browse/FELIX-352
Project: Felix
Issue Type: Bug
Components: Maven Bundle Plugin
Affects Versions: 1.0.0
Environment: Linux t-quad 2.6.22-gentoo-r5 #1 SMP Thu Aug 23 09:53:07
CEST 2007 i686 Intel(R) Core(TM)2 Quad CPU @ 2.40GHz GenuineIntel GNU/Linux
Sun JDK 1.6.0.02 [sun-jdk-1.6]
$ mvn -version
Maven version: 2.0.7
Java version: 1.6.0_02
OS name: "linux" version: "2.6.22-gentoo-r5" arch: "i386"
Reporter: Tobias Roeser
I'm using the maven-bundle-plugin version 1.0 from the
releases/bundleplugin-1.0.0 branch.
The following command fails on a clean project:
mvn org.apache.felix:maven-bundle-plugin:manifest
The error message is:
[DEBUG] Configuring mojo 'org.apache.felix:maven-bundle-plugin:1.0.0:manifest'
-->
[DEBUG] (f) baseDir = /home/t/work/test
[DEBUG] (f) buildDirectory = /home/t/work/test/target
[DEBUG] (f) instructions = {Bundle-Activator=de.example.main.Activator,
Export-Package=de.example.main.*}
[DEBUG] (f) manifestLocation = /home/t/work/test/target/classes/META-INF
[DEBUG] (f) outputDirectory = /home/t/work/test/target/classes
[DEBUG] (f) project = [EMAIL PROTECTED]
[DEBUG] -- end configuration --
[INFO] [bundle:manifest]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error trying to generate Manifest
Embedded error: error in opening zip file
[INFO]
[DEBUG] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error trying to
generate Manifest
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
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.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error trying to
generate Manifest
at
org.apache.felix.bundleplugin.ManifestPlugin.execute(ManifestPlugin.java:63)
at
org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:123)
at
org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:118)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
... 16 more
Caused by: java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.(ZipFile.java:114)
at java.util.zip.ZipFile.(ZipFile.java:131)
at aQute.lib.osgi.ZipResource.build(ZipResource.java:39)
at aQute.lib.osgi.ZipResource.build(ZipResource.java:32)
at aQute.lib.osgi.Jar.(Jar.java:31)
at aQute.lib.osgi.Jar.(Jar.java:50)
at aQute.lib.osgi.Analyzer.setJar(Analyzer.java:619)
at
org.apache.felix.bundleplugin.ManifestPlugin.getAnalyzer(ManifestPlugin.java:116)
at
org.apache.felix.bundleplugin.ManifestPlugin.getManifest(ManifestPlugin.java:87)
at
org.apache.felix.bundleplugin.ManifestPlugin.execute(ManifestPlugin.java:59)
... 20 more
After running 'mvn package' the same call of the goal will succeed.
Quick workarround: log a better error message reporting which zip/jar file was
tried to read, when the exception occured.
This problem occurs in a more advanced setup, t
