Re: correct syntax for multi-valued properties in fileinstall cfg files?
Well, that's already in fileinstall since some time.
Though the extension has to be slightly different, iirc, it needs to
be .config
On Sun, Feb 6, 2011 at 16:48, Carl Hall c...@hallwaytech.com wrote:
Reposting to dev since this is a development question. I can get a
patch in for this pretty soon once the direction agreed upon.
-- Forwarded message --
From: Carl Hall c...@hallwaytech.com
Date: Thu, Jan 27, 2011 at 7:35 PM
Subject: Re: correct syntax for multi-valued properties in fileinstall
cfg files?
To: us...@felix.apache.org
What if the syntax that is used by the config admin is used for this?
The processing in ConfigurationHandler can be abstracted and
fileinstall already has a dependency on config admin. The code has
been used in Felix for a while, so we would get free testing with it.
:)
The syntax is this:
value = type ( [ values ] | ( values ) | simple ) .
values = value { , value } .
simple = { stringsimple } .
type = // 1-char type code .
stringsimple = // quoted string representation of the value .
Examples of this,
* [thing1,thing2] = String[2]
* i[10,250,365] = int[3]
I would like to add this feature, so any discussion on how best to
proceed is greatly welcomed.
On Thu, 18 Mar 2010 13:19:36 -0700 Justin Edelson said,
Ah, so the
header ::= header ( ':' | '=' ) value ( '\nl value ) *
part is saying that a single value can be split over multiple lines...
gotcha.
I think the scr javadoc annotation way is reasonable, although it's not
backwards-compatible.
Justin
On 3/18/10 4:03 PM, Chris Custine wrote:
OK, I see what you are after now :-) The fileinstall config handler
doesn't currently support multivalue properties, so whatever you set on
a property value gets parsed as a single string (the code simply uses
load(inputstream) from the Properties class). This functionality could
probably be added, but we would have to decide on a way to differentiate
between scalar values and arrays (this, is, one, string vs. String[]
property = {this,is,one,string} ). Another option would be to
support syntax similar to the scr javadoc annotations and munge the
properties into an array (value.1=this, value.2=is, etc
become String[] property = {this,is, etc} ). If you are interested
in that feature, please create a Jira and someone will take a look.
http://issues.apache.org/jira/browse/FELIX
Until then, you could either add your own config admin code to do
something like this, or you can add a method with a single string
argument to accept the property and then parse and process into your
component after it is set by scr from the config admin.
Thanks,
Chris
--
Chris Custine
FUSESource :: http://fusesource.com
My Blog :: http://blog.organicelement.com
Apache ServiceMix :: http://servicemix.apache.org
Apache Felix :: http://felix.apache.org
Apache Directory Server :: http://directory.apache.org
On Thu, Mar 18, 2010 at 10:11 AM, Justin Edelson
justinedel...@gmail.com mailto:justinedel...@gmail.com wrote:
Thanks Chris.
I was actually referring to the configuration files (with .cfg
extension) which is described here:
http://felix.apache.org/site/apache-felix-file-install.html#ApacheFelixFileInstall-Configurations
I would like to set a property to a String array. With scr qdox
annotations, this would look like this:
/**
* @scr.property values.1=/foo values.2=/bar
*/
I saw this line in the documentation:
header ::= header ( ':' | '=' ) value ( '\nl value ) *
which implied to me that the syntax I used below would work.
If no one knows, I'll look through the code. Maybe this isn't possible.
Justin
On 3/17/10 11:37 PM, Chris Custine wrote:
There really aren't any config properties for fileinstall that accept
multiple values as far as I know. If you need to monitor multiple
directories you can create multiple config files as shown in the
fileinstall docs
here:
http://felix.apache.org/site/apache-felix-file-install.html#ApacheFelixFileInstall-WatchingmultipledirectorieswithFileInstall
Chris
http://felix.apache.org/site/apache-felix-file-install.html#ApacheFelixFileInstall-WatchingmultipledirectorieswithFileInstall
--
Chris Custine
FUSESource :: http://fusesource.com
My Blog :: http://blog.organicelement.com
Apache ServiceMix :: http://servicemix.apache.org
Apache Felix :: http://felix.apache.org
Apache Directory Server :: http://directory.apache.org
On Wed, Mar 17, 2010 at 7:07 PM, Justin Edelson
justinedel...@gmail.com mailto:justinedel...@gmail.com
mailto:justinedel...@gmail.com mailto:justinedel...@gmail.com
wrote:
What is the correct syntax for multi-valued properties in a
fileinstall
cfg file? I tried a few variations on:
name=value1 \
[RESULT] [VOTE] Release maven-bundle-plugin 2.3.4
Closing this vote with the following: +1: Jean-Baptiste Onofré, Hiram Chirino, Toni Menzel, Felix Meschberger, Andreas Pieber, Stuart McCulloch, Guillaume Nodet No other votes. I'll publish the artifacts asap. On Sun, Feb 6, 2011 at 20:46, Guillaume Nodet gno...@gmail.com wrote: +1 On Wed, Feb 2, 2011 at 18:09, Guillaume Nodet gno...@gmail.com wrote: I would like to call another vote on the maven-bundle-plugin 2.3.4 release: Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-029/ Changelog: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100version=12316061 You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 029 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Release fileinstall-3.1.10
We're still missing a few binding votes ... On Sun, Feb 6, 2011 at 20:45, Guillaume Nodet gno...@gmail.com wrote: +1 On Wed, Feb 2, 2011 at 15:37, Guillaume Nodet gno...@gmail.com wrote: Vote on fileinstall .3.1.10 This release fixes three issues https://issues.apache.org/jira/secure/ReleaseNote.jspa?atl_token=8159ff149eb3d70fdca9490b559e5269f0ea79d8version=12316134styleName=TextprojectId=12310100Create=Create * [FELIX-2798] - ArtifactListener services are not ordered according to the OSGi ranking * [FELIX-2799] - FileInstall creates multiple configurations for factory configurations on windows * [FELIX-2818] - File Install does not support empty configuration when no configuration already exists The staging repo is available at: https://repository.apache.org/content/repositories/orgapachefelix-026/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 026 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Release fileinstall-3.1.10
+1, Regards, Clement On 02.02.11 15:37, Guillaume Nodet gno...@gmail.com wrote: Vote on fileinstall .3.1.10 This release fixes three issues https://issues.apache.org/jira/secure/ReleaseNote.jspa?atl_token=8159ff149 eb3d70fdca9490b559e5269f0ea79d8version=12316134styleName=TextprojectId= 12310100Create=Create * [FELIX-2798] - ArtifactListener services are not ordered according to the OSGi ranking * [FELIX-2799] - FileInstall creates multiple configurations for factory configurations on windows * [FELIX-2818] - File Install does not support empty configuration when no configuration already exists The staging repo is available at: https://repository.apache.org/content/repositories/orgapachefelix-026/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 026 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
[jira] Created: (FELIX-2828) DependencyManager ResourceDependency annotation can't be applied on a class field
DependencyManager ResourceDependency annotation can't be applied on a class
field
-
Key: FELIX-2828
URL: https://issues.apache.org/jira/browse/FELIX-2828
Project: Felix
Issue Type: Bug
Components: Dependency Manager
Reporter: Pierre De Rop
Assignee: Pierre De Rop
Priority: Minor
When using the Dependency Manager @ResourceDependency annotation, it is not
possible to inject the resource on a class fields.
For example, the following code does not work:
@Component
class VideoPlayer
{
@ResourceDependency(required=true, filter = (path=/path/video.mkv))
URL resource;
void play()
{
// this.resource is not injected with the required URL ...
}
}
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (FELIX-2828) DependencyManager ResourceDependency annotation can't be applied on a class field
[
https://issues.apache.org/jira/browse/FELIX-2828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop closed FELIX-2828.
DependencyManager ResourceDependency annotation can't be applied on a class
field
-
Key: FELIX-2828
URL: https://issues.apache.org/jira/browse/FELIX-2828
Project: Felix
Issue Type: Bug
Components: Dependency Manager
Reporter: Pierre De Rop
Assignee: Pierre De Rop
Priority: Minor
When using the Dependency Manager @ResourceDependency annotation, it is not
possible to inject the resource on a class fields.
For example, the following code does not work:
@Component
class VideoPlayer
{
@ResourceDependency(required=true, filter = (path=/path/video.mkv))
URL resource;
void play()
{
// this.resource is not injected with the required URL ...
}
}
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (FELIX-2828) DependencyManager ResourceDependency annotation can't be applied on a class field
[
https://issues.apache.org/jira/browse/FELIX-2828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop resolved FELIX-2828.
--
Resolution: Fixed
Committed a patch in revision 1067937.
DependencyManager ResourceDependency annotation can't be applied on a class
field
-
Key: FELIX-2828
URL: https://issues.apache.org/jira/browse/FELIX-2828
Project: Felix
Issue Type: Bug
Components: Dependency Manager
Reporter: Pierre De Rop
Assignee: Pierre De Rop
Priority: Minor
When using the Dependency Manager @ResourceDependency annotation, it is not
possible to inject the resource on a class fields.
For example, the following code does not work:
@Component
class VideoPlayer
{
@ResourceDependency(required=true, filter = (path=/path/video.mkv))
URL resource;
void play()
{
// this.resource is not injected with the required URL ...
}
}
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (FELIX-2826) LogService.log second overload does not work
[ https://issues.apache.org/jira/browse/FELIX-2826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriyko updated FELIX-2826: Attachment: logServiceError.png LogService.log second overload does not work Key: FELIX-2826 URL: https://issues.apache.org/jira/browse/FELIX-2826 Project: Felix Issue Type: Bug Components: Log Service Reporter: Andriyko Attachments: logServiceError.png I am using org.osgi.service.log.LogService. I have the weirdest bug, when writting my LogHelper class. The second overloaded log function does not work. Now I can call the: LogService.log(int level, String message) with no problems, but when I try to use the one with the Throwable overloaded argument: LogService.log(int level, String message, Throwable exception) Eclipse highlights the call as wrong, and gives me this wierd error message: The type org.osgi.framework.ServiceReference cannot be resolved. It is indirectly referenced from required .class files P.S.: I created a stackoverflow question for this issue, no-one seems to know what's up: http://stackoverflow.com/questions/4819269/osgi-logservice-log-method-does-not-work -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (FELIX-2826) LogService.log second overload does not work
[ https://issues.apache.org/jira/browse/FELIX-2826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12991371#comment-12991371 ] Andriyko commented on FELIX-2826: - Here is a screenshot, as you can see it does not even compile it. LogService.log second overload does not work Key: FELIX-2826 URL: https://issues.apache.org/jira/browse/FELIX-2826 Project: Felix Issue Type: Bug Components: Log Service Reporter: Andriyko Attachments: logServiceError.png I am using org.osgi.service.log.LogService. I have the weirdest bug, when writting my LogHelper class. The second overloaded log function does not work. Now I can call the: LogService.log(int level, String message) with no problems, but when I try to use the one with the Throwable overloaded argument: LogService.log(int level, String message, Throwable exception) Eclipse highlights the call as wrong, and gives me this wierd error message: The type org.osgi.framework.ServiceReference cannot be resolved. It is indirectly referenced from required .class files P.S.: I created a stackoverflow question for this issue, no-one seems to know what's up: http://stackoverflow.com/questions/4819269/osgi-logservice-log-method-does-not-work -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (FELIX-2826) LogService.log second overload does not work
[ https://issues.apache.org/jira/browse/FELIX-2826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12991385#comment-12991385 ] Justin Edelson commented on FELIX-2826: --- Is the ServiceReference class on your Eclipse classpath? LogService.log second overload does not work Key: FELIX-2826 URL: https://issues.apache.org/jira/browse/FELIX-2826 Project: Felix Issue Type: Bug Components: Log Service Reporter: Andriyko Attachments: logServiceError.png I am using org.osgi.service.log.LogService. I have the weirdest bug, when writting my LogHelper class. The second overloaded log function does not work. Now I can call the: LogService.log(int level, String message) with no problems, but when I try to use the one with the Throwable overloaded argument: LogService.log(int level, String message, Throwable exception) Eclipse highlights the call as wrong, and gives me this wierd error message: The type org.osgi.framework.ServiceReference cannot be resolved. It is indirectly referenced from required .class files P.S.: I created a stackoverflow question for this issue, no-one seems to know what's up: http://stackoverflow.com/questions/4819269/osgi-logservice-log-method-does-not-work -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (FELIX-2826) LogService.log second overload does not work
[ https://issues.apache.org/jira/browse/FELIX-2826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12991387#comment-12991387 ] Andriyko commented on FELIX-2826: - Wow, thank you. I put the org.osgi.core into my dependency managed pom, and now it works. How did you figure that out, heh? You should answer my SO question so I can mark your answer as correct :) http://stackoverflow.com/questions/4819269/osgi-logservice-log-method-does-not-work LogService.log second overload does not work Key: FELIX-2826 URL: https://issues.apache.org/jira/browse/FELIX-2826 Project: Felix Issue Type: Bug Components: Log Service Reporter: Andriyko Attachments: logServiceError.png I am using org.osgi.service.log.LogService. I have the weirdest bug, when writting my LogHelper class. The second overloaded log function does not work. Now I can call the: LogService.log(int level, String message) with no problems, but when I try to use the one with the Throwable overloaded argument: LogService.log(int level, String message, Throwable exception) Eclipse highlights the call as wrong, and gives me this wierd error message: The type org.osgi.framework.ServiceReference cannot be resolved. It is indirectly referenced from required .class files P.S.: I created a stackoverflow question for this issue, no-one seems to know what's up: http://stackoverflow.com/questions/4819269/osgi-logservice-log-method-does-not-work -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (FELIX-2826) LogService.log second overload does not work
[ https://issues.apache.org/jira/browse/FELIX-2826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12991390#comment-12991390 ] Toni Menzel commented on FELIX-2826: Though this is nothing about OSGi at all. Its just Eclipse trying to follow the entire call stack of a library you are using. So this is a generic thing to remember (and to know). Just out of curiosity, which maven eclipse integration do you use ? Would believe M2Eclipse takes care of this transitive dependency. LogService.log second overload does not work Key: FELIX-2826 URL: https://issues.apache.org/jira/browse/FELIX-2826 Project: Felix Issue Type: Bug Components: Log Service Reporter: Andriyko Attachments: logServiceError.png I am using org.osgi.service.log.LogService. I have the weirdest bug, when writting my LogHelper class. The second overloaded log function does not work. Now I can call the: LogService.log(int level, String message) with no problems, but when I try to use the one with the Throwable overloaded argument: LogService.log(int level, String message, Throwable exception) Eclipse highlights the call as wrong, and gives me this wierd error message: The type org.osgi.framework.ServiceReference cannot be resolved. It is indirectly referenced from required .class files P.S.: I created a stackoverflow question for this issue, no-one seems to know what's up: http://stackoverflow.com/questions/4819269/osgi-logservice-log-method-does-not-work -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (FELIX-2826) LogService.log second overload does not work
[ https://issues.apache.org/jira/browse/FELIX-2826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12991394#comment-12991394 ] Andriyko commented on FELIX-2826: - Interesting. I am using something that shows up as Maven Integration for Eclipse in my installed software tab, which I do believe is the same as m2eclipse. I installed it from marketplace. LogService.log second overload does not work Key: FELIX-2826 URL: https://issues.apache.org/jira/browse/FELIX-2826 Project: Felix Issue Type: Bug Components: Log Service Reporter: Andriyko Attachments: logServiceError.png I am using org.osgi.service.log.LogService. I have the weirdest bug, when writting my LogHelper class. The second overloaded log function does not work. Now I can call the: LogService.log(int level, String message) with no problems, but when I try to use the one with the Throwable overloaded argument: LogService.log(int level, String message, Throwable exception) Eclipse highlights the call as wrong, and gives me this wierd error message: The type org.osgi.framework.ServiceReference cannot be resolved. It is indirectly referenced from required .class files P.S.: I created a stackoverflow question for this issue, no-one seems to know what's up: http://stackoverflow.com/questions/4819269/osgi-logservice-log-method-does-not-work -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (FELIX-2829) The maven-ipojo-plugin archetype descriptor is not conform
The maven-ipojo-plugin archetype descriptor is not conform -- Key: FELIX-2829 URL: https://issues.apache.org/jira/browse/FELIX-2829 Project: Felix Issue Type: Bug Components: iPOJO Reporter: Clement Escoffier Assignee: Clement Escoffier The archetype descriptor provided inside the maven-ipojo-plugin does not follow the schema leading to some issue in m2eclipse. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (FELIX-2829) The maven-ipojo-plugin archetype descriptor is not conform
[ https://issues.apache.org/jira/browse/FELIX-2829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier updated FELIX-2829: - Fix Version/s: maven-ipojo-plugin-1.8.2 The maven-ipojo-plugin archetype descriptor is not conform -- Key: FELIX-2829 URL: https://issues.apache.org/jira/browse/FELIX-2829 Project: Felix Issue Type: Bug Components: iPOJO Reporter: Clement Escoffier Assignee: Clement Escoffier Fix For: maven-ipojo-plugin-1.8.2 The archetype descriptor provided inside the maven-ipojo-plugin does not follow the schema leading to some issue in m2eclipse. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (FELIX-2825) maven-ipojo-plugin WAR
[
https://issues.apache.org/jira/browse/FELIX-2825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clement Escoffier updated FELIX-2825:
-
Fix Version/s: ipojo-manipulator-1.8.2
maven-ipojo-plugin WAR
Key: FELIX-2825
URL: https://issues.apache.org/jira/browse/FELIX-2825
Project: Felix
Issue Type: Bug
Components: iPOJO
Affects Versions: iPOJO-1.8.0
Environment: Jetty, Windows
Reporter: Dyblast
Fix For: ipojo-manipulator-1.8.2
HI,
I have notice a problem with the maven-ipojo-plugin on war package.
The resulting classes are incorrect.
Indeed when i create a war i have this error when i deploy it:
createInstance - Cannot invoke the constructor (method not found) :
Now if i create a bundle instead, i take the classes from it and i put it in
the former war, the war works
my plugins part of maven:
-
plugins
plugin
artifactIdmaven-war-plugin/artifactId
configuration
archive
manifestFile${project.build.outputDirectory}/META-INF/MANIFEST.MF/manifestFile
/archive
/configuration
/plugin
plugin
groupIdorg.apache.felix/groupId
artifactIdmaven-bundle-plugin/artifactId
version1.4.3/version
extensionstrue/extensions
executions
execution
idbundle-manifest/id
phaseprocess-classes/phase
goals
goalmanifest/goal
/goals
configuration
instructions
Bundle-ClassPath
.,
WEB-INF/classes
/Bundle-ClassPath
Embed-DirectoryWEB-INF/lib/Embed-Directory
Embed-Dependency*;scope=compile|runtime/Embed-Dependency
Embed-Transitivetrue/Embed-Transitive
Web-ContextPathwebapp/Web-ContextPath
Webapp-Contextwebapp/Webapp-Context
/instructions
/configuration
/execution
/executions
configuration
supportedProjectTypes
supportedProjectTypejar/supportedProjectType
supportedProjectTypebundle/supportedProjectType
supportedProjectTypewar/supportedProjectType
/supportedProjectTypes
/configuration
/plugin
plugin
groupIdorg.apache.felix/groupId
artifactIdmaven-ipojo-plugin/artifactId
version1.8.0/version
executions
execution
goals
goalipojo-bundle/goal
/goals
/execution
/executions
/plugin
/plugins
-
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: correct syntax for multi-valued properties in fileinstall cfg files?
Thanks, Guillaume! I somehow misread that bit of the code and thought
.config was reserved for XML.
On Mon, Feb 7, 2011 at 4:32 AM, Guillaume Nodet gno...@gmail.com wrote:
Well, that's already in fileinstall since some time.
Though the extension has to be slightly different, iirc, it needs to
be .config
On Sun, Feb 6, 2011 at 16:48, Carl Hall c...@hallwaytech.com wrote:
Reposting to dev since this is a development question. I can get a
patch in for this pretty soon once the direction agreed upon.
-- Forwarded message --
From: Carl Hall c...@hallwaytech.com
Date: Thu, Jan 27, 2011 at 7:35 PM
Subject: Re: correct syntax for multi-valued properties in fileinstall
cfg files?
To: us...@felix.apache.org
What if the syntax that is used by the config admin is used for this?
The processing in ConfigurationHandler can be abstracted and
fileinstall already has a dependency on config admin. The code has
been used in Felix for a while, so we would get free testing with it.
:)
The syntax is this:
value = type ( [ values ] | ( values ) | simple ) .
values = value { , value } .
simple = { stringsimple } .
type = // 1-char type code .
stringsimple = // quoted string representation of the value .
Examples of this,
* [thing1,thing2] = String[2]
* i[10,250,365] = int[3]
I would like to add this feature, so any discussion on how best to
proceed is greatly welcomed.
On Thu, 18 Mar 2010 13:19:36 -0700 Justin Edelson said,
Ah, so the
header ::= header ( ':' | '=' ) value ( '\nl value ) *
part is saying that a single value can be split over multiple lines...
gotcha.
I think the scr javadoc annotation way is reasonable, although it's not
backwards-compatible.
Justin
On 3/18/10 4:03 PM, Chris Custine wrote:
OK, I see what you are after now :-) The fileinstall config handler
doesn't currently support multivalue properties, so whatever you set on
a property value gets parsed as a single string (the code simply uses
load(inputstream) from the Properties class). This functionality could
probably be added, but we would have to decide on a way to differentiate
between scalar values and arrays (this, is, one, string vs. String[]
property = {this,is,one,string} ). Another option would be to
support syntax similar to the scr javadoc annotations and munge the
properties into an array (value.1=this, value.2=is, etc
become String[] property = {this,is, etc} ). If you are interested
in that feature, please create a Jira and someone will take a look.
http://issues.apache.org/jira/browse/FELIX
Until then, you could either add your own config admin code to do
something like this, or you can add a method with a single string
argument to accept the property and then parse and process into your
component after it is set by scr from the config admin.
Thanks,
Chris
--
Chris Custine
FUSESource :: http://fusesource.com
My Blog :: http://blog.organicelement.com
Apache ServiceMix :: http://servicemix.apache.org
Apache Felix :: http://felix.apache.org
Apache Directory Server :: http://directory.apache.org
On Thu, Mar 18, 2010 at 10:11 AM, Justin Edelson
justinedel...@gmail.com mailto:justinedel...@gmail.com wrote:
Thanks Chris.
I was actually referring to the configuration files (with .cfg
extension) which is described here:
http://felix.apache.org/site/apache-felix-file-install.html#ApacheFelixFileInstall-Configurations
I would like to set a property to a String array. With scr qdox
annotations, this would look like this:
/**
* @scr.property values.1=/foo values.2=/bar
*/
I saw this line in the documentation:
header ::= header ( ':' | '=' ) value ( '\nl value ) *
which implied to me that the syntax I used below would work.
If no one knows, I'll look through the code. Maybe this isn't possible.
Justin
On 3/17/10 11:37 PM, Chris Custine wrote:
There really aren't any config properties for fileinstall that accept
multiple values as far as I know. If you need to monitor multiple
directories you can create multiple config files as shown in the
fileinstall docs
here:
http://felix.apache.org/site/apache-felix-file-install.html#ApacheFelixFileInstall-WatchingmultipledirectorieswithFileInstall
Chris
http://felix.apache.org/site/apache-felix-file-install.html#ApacheFelixFileInstall-WatchingmultipledirectorieswithFileInstall
--
Chris Custine
FUSESource :: http://fusesource.com
My Blog :: http://blog.organicelement.com
Apache ServiceMix :: http://servicemix.apache.org
Apache Felix :: http://felix.apache.org
Apache Directory Server :: http://directory.apache.org
On Wed, Mar 17, 2010 at 7:07 PM, Justin Edelson
justinedel...@gmail.com mailto:justinedel...@gmail.com
mailto:justinedel...@gmail.com mailto:justinedel...@gmail.com
wrote:
Re: [VOTE] Versioning after a failed release
A (non-binding). FWIW: Stuart brought me off the fence. If the first 1.0.x release is 1.0.5 then under semantic versioning guidelines this would mean 5 releases of the bundle at previous micro numbers have already passed which might cause users some confusion, or cause them to ask for an explanation. This confusion persists for ever more. The number of people seeing this admittedly lesser kind of confusion will likely be far greater than the people who use the RC artifacts from a staging repo, who should know better. On 5 February 2011 12:50, Stuart McCulloch mccu...@gmail.com wrote: On 5 February 2011 12:21, Guillaume Nodet gno...@gmail.com wrote: As long has the release has not been approved, the tag does not match an official release, so it can be freely deleted. yep, that's what I meant - another point to consider is users might see 1.0.5 and think it's stable (as it's not 1.0.0) whereas in fact there could have been 5 staged versions just to sort out license / dependency issues and no actual code changes Once the release is voted, I think everyone agree the tag becomes immutable. FWIW, Git is much better as a tag really correspond to a moment in the history, not a branch (which actually makes more sense if you think about it). agreed, git is better in this regard - but it can be hard to understand at times :) On Sat, Feb 5, 2011 at 11:04, Felix Meschberger fmesc...@adobe.com wrote: Hi, Am Samstag, den 05.02.2011, 09:52 + schrieb Sahoo: On Friday 04 February 2011 04:48 PM, Stuart McCulloch wrote: it is easy to retag releases in svn What exactly do you mean by retag releases in svn? Rename an existing tag or using the same tag name to tag a different snapshot of the source code base? Neither should be done in my IMHO. Agreed, both is far too easy ... Regards Felix -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Stuart
[jira] Commented: (FELIX-2826) LogService.log second overload does not work
[ https://issues.apache.org/jira/browse/FELIX-2826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12991409#comment-12991409 ] Richard S. Hall commented on FELIX-2826: Should this be closed now? LogService.log second overload does not work Key: FELIX-2826 URL: https://issues.apache.org/jira/browse/FELIX-2826 Project: Felix Issue Type: Bug Components: Log Service Reporter: Andriyko Attachments: logServiceError.png I am using org.osgi.service.log.LogService. I have the weirdest bug, when writting my LogHelper class. The second overloaded log function does not work. Now I can call the: LogService.log(int level, String message) with no problems, but when I try to use the one with the Throwable overloaded argument: LogService.log(int level, String message, Throwable exception) Eclipse highlights the call as wrong, and gives me this wierd error message: The type org.osgi.framework.ServiceReference cannot be resolved. It is indirectly referenced from required .class files P.S.: I created a stackoverflow question for this issue, no-one seems to know what's up: http://stackoverflow.com/questions/4819269/osgi-logservice-log-method-does-not-work -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (FELIX-2825) The maven-ipojo-plugin does not replace component classes in WAR files
[
https://issues.apache.org/jira/browse/FELIX-2825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12991422#comment-12991422
]
Clement Escoffier commented on FELIX-2825:
--
Fixed in trunk.
I've modified your patch a bit, please check with the manipulator and the
maven-ipojo-plugin from the trunk (1.9.0-SNAPSHOT).
Thanks
The maven-ipojo-plugin does not replace component classes in WAR files
--
Key: FELIX-2825
URL: https://issues.apache.org/jira/browse/FELIX-2825
Project: Felix
Issue Type: Bug
Components: iPOJO
Affects Versions: iPOJO-1.8.0
Environment: Jetty, Windows
Reporter: Dyblast
Assignee: Clement Escoffier
Fix For: ipojo-manipulator-1.8.2
HI,
I have notice a problem with the maven-ipojo-plugin on war package.
The resulting classes are incorrect.
Indeed when i create a war i have this error when i deploy it:
createInstance - Cannot invoke the constructor (method not found) :
Now if i create a bundle instead, i take the classes from it and i put it in
the former war, the war works
my plugins part of maven:
-
plugins
plugin
artifactIdmaven-war-plugin/artifactId
configuration
archive
manifestFile${project.build.outputDirectory}/META-INF/MANIFEST.MF/manifestFile
/archive
/configuration
/plugin
plugin
groupIdorg.apache.felix/groupId
artifactIdmaven-bundle-plugin/artifactId
version1.4.3/version
extensionstrue/extensions
executions
execution
idbundle-manifest/id
phaseprocess-classes/phase
goals
goalmanifest/goal
/goals
configuration
instructions
Bundle-ClassPath
.,
WEB-INF/classes
/Bundle-ClassPath
Embed-DirectoryWEB-INF/lib/Embed-Directory
Embed-Dependency*;scope=compile|runtime/Embed-Dependency
Embed-Transitivetrue/Embed-Transitive
Web-ContextPathwebapp/Web-ContextPath
Webapp-Contextwebapp/Webapp-Context
/instructions
/configuration
/execution
/executions
configuration
supportedProjectTypes
supportedProjectTypejar/supportedProjectType
supportedProjectTypebundle/supportedProjectType
supportedProjectTypewar/supportedProjectType
/supportedProjectTypes
/configuration
/plugin
plugin
groupIdorg.apache.felix/groupId
artifactIdmaven-ipojo-plugin/artifactId
version1.8.0/version
executions
execution
goals
goalipojo-bundle/goal
/goals
/execution
/executions
/plugin
/plugins
-
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (FELIX-2825) The maven-ipojo-plugin does not replace component classes in WAR files
[
https://issues.apache.org/jira/browse/FELIX-2825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clement Escoffier resolved FELIX-2825.
--
Resolution: Fixed
Assignee: Clement Escoffier
The maven-ipojo-plugin does not replace component classes in WAR files
--
Key: FELIX-2825
URL: https://issues.apache.org/jira/browse/FELIX-2825
Project: Felix
Issue Type: Bug
Components: iPOJO
Affects Versions: iPOJO-1.8.0
Environment: Jetty, Windows
Reporter: Dyblast
Assignee: Clement Escoffier
Fix For: ipojo-manipulator-1.8.2
HI,
I have notice a problem with the maven-ipojo-plugin on war package.
The resulting classes are incorrect.
Indeed when i create a war i have this error when i deploy it:
createInstance - Cannot invoke the constructor (method not found) :
Now if i create a bundle instead, i take the classes from it and i put it in
the former war, the war works
my plugins part of maven:
-
plugins
plugin
artifactIdmaven-war-plugin/artifactId
configuration
archive
manifestFile${project.build.outputDirectory}/META-INF/MANIFEST.MF/manifestFile
/archive
/configuration
/plugin
plugin
groupIdorg.apache.felix/groupId
artifactIdmaven-bundle-plugin/artifactId
version1.4.3/version
extensionstrue/extensions
executions
execution
idbundle-manifest/id
phaseprocess-classes/phase
goals
goalmanifest/goal
/goals
configuration
instructions
Bundle-ClassPath
.,
WEB-INF/classes
/Bundle-ClassPath
Embed-DirectoryWEB-INF/lib/Embed-Directory
Embed-Dependency*;scope=compile|runtime/Embed-Dependency
Embed-Transitivetrue/Embed-Transitive
Web-ContextPathwebapp/Web-ContextPath
Webapp-Contextwebapp/Webapp-Context
/instructions
/configuration
/execution
/executions
configuration
supportedProjectTypes
supportedProjectTypejar/supportedProjectType
supportedProjectTypebundle/supportedProjectType
supportedProjectTypewar/supportedProjectType
/supportedProjectTypes
/configuration
/plugin
plugin
groupIdorg.apache.felix/groupId
artifactIdmaven-ipojo-plugin/artifactId
version1.8.0/version
executions
execution
goals
goalipojo-bundle/goal
/goals
/execution
/executions
/plugin
/plugins
-
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (FELIX-2815) Difference between instance and provides
[
https://issues.apache.org/jira/browse/FELIX-2815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12991434#comment-12991434
]
Clement Escoffier commented on FELIX-2815:
--
Hi,
I've added a link to the 'factory/instance' page from the {{provides}} page.
I definitely agree about the navigation, it should be completely redone.
Unfortunately, I lack of time. Especially, the content is still on Confluence,
and reaching the current state was really not easy (and I still have some
issue: modifying the menu force me to edit *all* pages and re-save them, if not
the sync do not update them). I've learned that Apache projects are migrating
to a CMS, which might make the documentation support easier.
Difference between instance and provides
Key: FELIX-2815
URL: https://issues.apache.org/jira/browse/FELIX-2815
Project: Felix
Issue Type: Bug
Components: iPOJO
Reporter: Andriyko
Assignee: Clement Escoffier
Labels: documentation, felix,, ipojo
In the documentation on iPOJO Services:
http://felix.apache.org/site/providing-osgi-services.html#ProvidingOSGiservices-Instancereconfiguration
There is no clear explanation of what is the difference between provides
and instance.
It is not clear why instance is needed at all.
Under the Service Properties heading on the page, the two are used
interchangeably in the examples.
For example, first property is configured with provides:
component classname=...FooProviderType1
provides
property name=foo field=m_foo value=Foo/
property name=static type=java.lang.String
value=this is a static property/
/provides
/component
and then immediately, with no explanation what-so-ever and intsance is
used, with a tiny explanation that The value can be given in the instance
configuration:
instance component=...FooProviderType1
property name=foo value=My New Foo Value/
property name=static value=My Value For Static/
/instance
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (FELIX-2827) Spelling Mistake
[ https://issues.apache.org/jira/browse/FELIX-2827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12991440#comment-12991440 ] Clement Escoffier commented on FELIX-2827: -- Hi, I've updated the page. Will be sync shortly. Thanks ! Spelling Mistake Key: FELIX-2827 URL: https://issues.apache.org/jira/browse/FELIX-2827 Project: Felix Issue Type: Bug Components: Documentation Reporter: Andriyko Assignee: Clement Escoffier Labels: grammar, spelling In the Providing OSGI services: http://felix.apache.org/site/providing-osgi-services.html#ProvidingOSGiservices-Instancereconfiguration The mistakes are: 1. Under Service Serving Object Creation, first sentence in parenthesis, first word should be from not form. 2. Under Service Serving Object Creation, in the bullet points under Other strategies are available:, first point: strategy=instance allows creating one service object per asking iPOJO instance (despite they are in the same bundle) - I find the use of word asking weird here, and the wording inside the parenthesis is confusing - what is in the same bundle as what? 3. In the section titled Several Service Providing (XML only), Several Service Providing is not a proper sentence or a combination of words, I think. 4. Under Several Service Providing (XML only), 1st paragraph, 2nd sentence: All this provided service will be manage - should be managed. Also it is not clear what is meant by - by the same handler but separately, how can the same handler manage them separately, as opposed to together? 5. Under Service Property Propagation, 1st paragraph, 2nd sentence, ends in to all published service., should be services. 6. Section titled Publishing abstract and concrete class as services perhaps should be titled Publishing an Abstract or Concrete class as a Service?. Same change must be carried into the 1st sentence. 7. Under Publishing abstract and concrete class as services, last sentence of the section However, such practice are not recommended., should be is not.. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [RESULT] [VOTE] Release maven-bundle-plugin 2.3.4
Thank Guillaume! Regards, Hiram FuseSource Web: http://fusesource.com/ On Mon, Feb 7, 2011 at 4:36 AM, Guillaume Nodet gno...@gmail.com wrote: Closing this vote with the following: +1: Jean-Baptiste Onofré, Hiram Chirino, Toni Menzel, Felix Meschberger, Andreas Pieber, Stuart McCulloch, Guillaume Nodet No other votes. I'll publish the artifacts asap. On Sun, Feb 6, 2011 at 20:46, Guillaume Nodet gno...@gmail.com wrote: +1 On Wed, Feb 2, 2011 at 18:09, Guillaume Nodet gno...@gmail.com wrote: I would like to call another vote on the maven-bundle-plugin 2.3.4 release: Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-029/ Changelog: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100version=12316061 You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 029 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
[jira] Commented: (FELIX-2546) Only one service is provisioned even when specifying for mulitple services
[
https://issues.apache.org/jira/browse/FELIX-2546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12991478#comment-12991478
]
Guillaume Nodet commented on FELIX-2546:
I don't really understand the problem. I just like to keep backward
compatiblity. I don't have any problem commiting a patch that would provide a
switch to change that behavior. In a few months, we'll be working on a new
major version that will implement the OSGi RFC, so that would clearly be a good
time to change anything for default behaviors. Would you consider that as an
option ?
I don't ask any change in blueprint, I can cope with a major upgrade and make
sure my bundles still work, but an incompatible change in a minor upgrade is
definitely wrong.
And as to wether it should be considered a bug or an improvement, we could
argue ad nauseum, but that's not really the problem. It's an incompatible
behavioral change that wasn't really specified, so I'd like to not include it
in a minor release.
Only one service is provisioned even when specifying for mulitple services
--
Key: FELIX-2546
URL: https://issues.apache.org/jira/browse/FELIX-2546
Project: Felix
Issue Type: Bug
Components: Bundle Repository (OBR)
Affects Versions: bundlerepository-1.6.4
Environment: n/a
Reporter: Emily Jiang
Attachments: Felix OBR isMultiple support - timothyjward.txt
Felix OBR is unable to return multiple services when specifying 'multiple'
attribute with the value of 'true'. The test scenario is detailed below.
I am trying to get all bundles registering the service of
com.sample.HelloWorld and install them into the osgi framework . In my test
environment, there are two bundles with different symbolic name offering the
same service, com.sample.HelloWorld. However, only one bundle was pulled into
runtime. The snippet of my repository is shown below.
require extend=false
filter=(amp;(service=service)(objectClass=com.sample.HelloWorld)(mandatory:lt;*service))
multiple=true name=service optional=falseRequires service with
attributes {service=service, objectClass=com.sample.HelloWorld}/require
Regards
Emily
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (FELIX-2546) Only one service is provisioned even when specifying for mulitple services
[
https://issues.apache.org/jira/browse/FELIX-2546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12991535#comment-12991535
]
Guillaume Nodet commented on FELIX-2546:
Note that the work correctly would be a really bad name ;-)
Something like
{code}
int SOLVE_MULTIPLE_REQUIREMENTS = 0x20;
{code}
If you don't want to change your code, I'd be happy to include an OSGi
configuration that would provide a different default value through the
BundleContext.getProperty() so that we could both live with our code without
having to change it.
I actually think it could be a good idea and other default values such as
resolving optional requirements, etc... could be provided too.
The default wanted value could be discussed independently of the compatibility
issue. Solving all optional or multiple dependencies can lead to a big
solution which does not represent anything anymore.
Only one service is provisioned even when specifying for mulitple services
--
Key: FELIX-2546
URL: https://issues.apache.org/jira/browse/FELIX-2546
Project: Felix
Issue Type: Bug
Components: Bundle Repository (OBR)
Affects Versions: bundlerepository-1.6.4
Environment: n/a
Reporter: Emily Jiang
Attachments: Felix OBR isMultiple support - timothyjward.txt
Felix OBR is unable to return multiple services when specifying 'multiple'
attribute with the value of 'true'. The test scenario is detailed below.
I am trying to get all bundles registering the service of
com.sample.HelloWorld and install them into the osgi framework . In my test
environment, there are two bundles with different symbolic name offering the
same service, com.sample.HelloWorld. However, only one bundle was pulled into
runtime. The snippet of my repository is shown below.
require extend=false
filter=(amp;(service=service)(objectClass=com.sample.HelloWorld)(mandatory:lt;*service))
multiple=true name=service optional=falseRequires service with
attributes {service=service, objectClass=com.sample.HelloWorld}/require
Regards
Emily
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Versioning after a failed release
Hi, Just to shed some light from other projects: * In Jackrabbit a tag was created in anticipation of an imminent release 2.2.3. A bug was discovered. The tag was removed and the next release will be 2.2.4 (there will not be a 2.2.3). * In Tomcat they voted on a release and found issues (quality wise) so decided to declare 7.0.7 broken. The version number was not reused and the release currently under vote has the next version 7.0.8. Regards Felix Am Montag, den 07.02.2011, 10:56 + schrieb Jeremy Hughes: A (non-binding). FWIW: Stuart brought me off the fence. If the first 1.0.x release is 1.0.5 then under semantic versioning guidelines this would mean 5 releases of the bundle at previous micro numbers have already passed which might cause users some confusion, or cause them to ask for an explanation. This confusion persists for ever more. The number of people seeing this admittedly lesser kind of confusion will likely be far greater than the people who use the RC artifacts from a staging repo, who should know better. On 5 February 2011 12:50, Stuart McCulloch mccu...@gmail.com wrote: On 5 February 2011 12:21, Guillaume Nodet gno...@gmail.com wrote: As long has the release has not been approved, the tag does not match an official release, so it can be freely deleted. yep, that's what I meant - another point to consider is users might see 1.0.5 and think it's stable (as it's not 1.0.0) whereas in fact there could have been 5 staged versions just to sort out license / dependency issues and no actual code changes Once the release is voted, I think everyone agree the tag becomes immutable. FWIW, Git is much better as a tag really correspond to a moment in the history, not a branch (which actually makes more sense if you think about it). agreed, git is better in this regard - but it can be hard to understand at times :) On Sat, Feb 5, 2011 at 11:04, Felix Meschberger fmesc...@adobe.com wrote: Hi, Am Samstag, den 05.02.2011, 09:52 + schrieb Sahoo: On Friday 04 February 2011 04:48 PM, Stuart McCulloch wrote: it is easy to retag releases in svn What exactly do you mean by retag releases in svn? Rename an existing tag or using the same tag name to tag a different snapshot of the source code base? Neither should be done in my IMHO. Agreed, both is far too easy ... Regards Felix -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Stuart
Re: [VOTE] Versioning after a failed release
On 7 February 2011 19:50, Felix Meschberger fmesc...@adobe.com wrote: Hi, Just to shed some light from other projects: * In Jackrabbit a tag was created in anticipation of an imminent release 2.2.3. A bug was discovered. The tag was removed and the next release will be 2.2.4 (there will not be a 2.2.3). * In Tomcat they voted on a release and found issues (quality wise) so decided to declare 7.0.7 broken. The version number was not reused and the release currently under vote has the next version 7.0.8. which would actually be allowed under option A because it says can reuse, not must (unlike option B) personally I think it's a bad idea to try to create a single rule to cover all possibilities - just leave it to the discretion of the release manager Regards Felix Am Montag, den 07.02.2011, 10:56 + schrieb Jeremy Hughes: A (non-binding). FWIW: Stuart brought me off the fence. If the first 1.0.x release is 1.0.5 then under semantic versioning guidelines this would mean 5 releases of the bundle at previous micro numbers have already passed which might cause users some confusion, or cause them to ask for an explanation. This confusion persists for ever more. The number of people seeing this admittedly lesser kind of confusion will likely be far greater than the people who use the RC artifacts from a staging repo, who should know better. On 5 February 2011 12:50, Stuart McCulloch mccu...@gmail.com wrote: On 5 February 2011 12:21, Guillaume Nodet gno...@gmail.com wrote: As long has the release has not been approved, the tag does not match an official release, so it can be freely deleted. yep, that's what I meant - another point to consider is users might see 1.0.5 and think it's stable (as it's not 1.0.0) whereas in fact there could have been 5 staged versions just to sort out license / dependency issues and no actual code changes Once the release is voted, I think everyone agree the tag becomes immutable. FWIW, Git is much better as a tag really correspond to a moment in the history, not a branch (which actually makes more sense if you think about it). agreed, git is better in this regard - but it can be hard to understand at times :) On Sat, Feb 5, 2011 at 11:04, Felix Meschberger fmesc...@adobe.com wrote: Hi, Am Samstag, den 05.02.2011, 09:52 + schrieb Sahoo: On Friday 04 February 2011 04:48 PM, Stuart McCulloch wrote: it is easy to retag releases in svn What exactly do you mean by retag releases in svn? Rename an existing tag or using the same tag name to tag a different snapshot of the source code base? Neither should be done in my IMHO. Agreed, both is far too easy ... Regards Felix -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Stuart -- Cheers, Stuart
[jira] Commented: (FELIX-2826) LogService.log second overload does not work
[ https://issues.apache.org/jira/browse/FELIX-2826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12991732#comment-12991732 ] Justin Edelson commented on FELIX-2826: --- @Andriyko - this is a fairly common Eclipse issue IMHO. I don't use stackoverflow, but feel free to credit me there :) @Toni - I see this when using the provided scope, which is semantically correct for osgi-core and osgi-compendium. @Richard - yes LogService.log second overload does not work Key: FELIX-2826 URL: https://issues.apache.org/jira/browse/FELIX-2826 Project: Felix Issue Type: Bug Components: Log Service Reporter: Andriyko Attachments: logServiceError.png I am using org.osgi.service.log.LogService. I have the weirdest bug, when writting my LogHelper class. The second overloaded log function does not work. Now I can call the: LogService.log(int level, String message) with no problems, but when I try to use the one with the Throwable overloaded argument: LogService.log(int level, String message, Throwable exception) Eclipse highlights the call as wrong, and gives me this wierd error message: The type org.osgi.framework.ServiceReference cannot be resolved. It is indirectly referenced from required .class files P.S.: I created a stackoverflow question for this issue, no-one seems to know what's up: http://stackoverflow.com/questions/4819269/osgi-logservice-log-method-does-not-work -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (FELIX-2826) LogService.log second overload does not work
[ https://issues.apache.org/jira/browse/FELIX-2826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12991731#comment-12991731 ] Justin Edelson commented on FELIX-2826: --- @Andriyko - this is a fairly common Eclipse issue IMHO. I don't use stackoverflow, but feel free to credit me there :) @Toni - I see this when using the provided scope, which is semantically correct for osgi-core and osgi-compendium. @Richard - yes LogService.log second overload does not work Key: FELIX-2826 URL: https://issues.apache.org/jira/browse/FELIX-2826 Project: Felix Issue Type: Bug Components: Log Service Reporter: Andriyko Attachments: logServiceError.png I am using org.osgi.service.log.LogService. I have the weirdest bug, when writting my LogHelper class. The second overloaded log function does not work. Now I can call the: LogService.log(int level, String message) with no problems, but when I try to use the one with the Throwable overloaded argument: LogService.log(int level, String message, Throwable exception) Eclipse highlights the call as wrong, and gives me this wierd error message: The type org.osgi.framework.ServiceReference cannot be resolved. It is indirectly referenced from required .class files P.S.: I created a stackoverflow question for this issue, no-one seems to know what's up: http://stackoverflow.com/questions/4819269/osgi-logservice-log-method-does-not-work -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
