[jira] [Updated] (FELIX-2926) No log message on missing activate method
[ https://issues.apache.org/jira/browse/FELIX-2926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks updated FELIX-2926: Attachment: FELIX-2926.diff logs missing activate, deactivate, and modified methods > No log message on missing activate method > - > > Key: FELIX-2926 > URL: https://issues.apache.org/jira/browse/FELIX-2926 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.6.0 >Reporter: David Jencks > Attachments: FELIX-2926.diff > > > DS spec 112.5.8 says: > If the activate attribute is specified and no suitable method is located, SCR > must log an error message with the Log Service, if present,... > This is not implemented and the lack makes it really hard to figure out why > the DS isn't activated. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-2926) No log message on missing activate method
No log message on missing activate method - Key: FELIX-2926 URL: https://issues.apache.org/jira/browse/FELIX-2926 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.6.0 Reporter: David Jencks DS spec 112.5.8 says: If the activate attribute is specified and no suitable method is located, SCR must log an error message with the Log Service, if present,... This is not implemented and the lack makes it really hard to figure out why the DS isn't activated. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] framework 3.2.1 and related subproject releases
On 4/20/11 7:54 PM, David Jencks wrote: I have no clue about what you guys decide is a release artifact but org.apache.felix.main.distribution-3.2.1-bin.tar.gz appears to only have a couple legal files in it which appears odd to me. Yeah, maybe there is a better way to do this, but the subproject is just a maven assembly, so that file is really not worthwhile since there is no associated binary for the subproject. The real artifact is in the non-bin tar.gz. -> richard david jencks On Apr 18, 2011, at 2:51 PM, Karl Pauls wrote: I would like to call a vote on the following subproject releases: framework 3.2.1 main 3.2.1 main.distribution 3.2.1 Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-098/ 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 098 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments)
Re: [VOTE] framework 3.2.1 and related subproject releases
I have no clue about what you guys decide is a release artifact but org.apache.felix.main.distribution-3.2.1-bin.tar.gz appears to only have a couple legal files in it which appears odd to me. david jencks On Apr 18, 2011, at 2:51 PM, Karl Pauls wrote: > I would like to call a vote on the following subproject releases: > > framework 3.2.1 > main 3.2.1 > main.distribution 3.2.1 > > Staging repositories: > https://repository.apache.org/content/repositories/orgapachefelix-098/ > > 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 098 /tmp/felix-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Veto the release (please provide specific comments)
[jira] [Commented] (FELIX-2925) java.lang.NullPointerException: reference and pid must not be null
[
https://issues.apache.org/jira/browse/FELIX-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022401#comment-13022401
]
Andrei Pozolotin commented on FELIX-2925:
-
target managed component service:
String pid = "com.barchart.hello.impl.CompSingle";
nevertheless gets its configuration and gets activated fine despite the
exception;
> java.lang.NullPointerException: reference and pid must not be null
> --
>
> Key: FELIX-2925
> URL: https://issues.apache.org/jira/browse/FELIX-2925
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
>Affects Versions: scr-1.6.0
>Reporter: Andrei Pozolotin
>
> #
> getting this:
> *ERROR* Unexpected problem executing task
> java.lang.NullPointerException: reference and pid must not be null
> at
> org.osgi.service.cm.ConfigurationEvent.(ConfigurationEvent.java:120)
> at
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:1818)
> at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:104)
> at java.lang.Thread.run(Thread.java:662)
> #
> at this line:
> conf.update(props);
> #
> for this snippet:
> package com.barchart.mgr;
> import java.util.Date;
> import java.util.Dictionary;
> import java.util.Properties;
> import org.apache.felix.scr.annotations.Activate;
> import org.apache.felix.scr.annotations.Component;
> import org.apache.felix.scr.annotations.Deactivate;
> import org.apache.felix.scr.annotations.Reference;
> import org.osgi.service.cm.Configuration;
> import org.osgi.service.cm.ConfigurationAdmin;
> import org.osgi.service.component.ComponentContext;
> import org.slf4j.Logger;
> import org.slf4j.LoggerFactory;
> @Component
> public class HelloManager {
> private static Logger log = LoggerFactory.getLogger(HelloManager.class);
> @Reference
> private ConfigurationAdmin admin;
> @Activate
> protected synchronized void activate(ComponentContext context) {
> log.debug("ACTIVATE");
> log.debug("admin: {}", admin);
> try {
> Configuration[] confArray =
> admin.listConfigurations(null);
> if (confArray == null) {
> log.debug("confArray == null");
> } else {
> for (Configuration conf : confArray) {
> log.debug("conf: {}", conf);
> }
> }
> String pid = "com.barchart.hello.impl.CompSingle";
> Configuration conf = admin.getConfiguration(pid, null);
> conf.update();
> log.debug("conf: {}", conf);
> Dictionary props = conf.getProperties();
> if (props == null) {
> log.debug("props == null");
> props = new Properties();
> props.put("created", new Date().toString());
> }
> conf.update(props);
> } catch (Exception e) {
> log.error("", e);
> }
> }
> @Deactivate
> protected synchronized void deactivate(ComponentContext context) {
> log.debug("DEACTIVATE");
> }
> }
> #
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-2925) java.lang.NullPointerException: reference and pid must not be null
java.lang.NullPointerException: reference and pid must not be null
--
Key: FELIX-2925
URL: https://issues.apache.org/jira/browse/FELIX-2925
Project: Felix
Issue Type: Bug
Components: Declarative Services (SCR)
Affects Versions: scr-1.6.0
Reporter: Andrei Pozolotin
#
getting this:
*ERROR* Unexpected problem executing task
java.lang.NullPointerException: reference and pid must not be null
at
org.osgi.service.cm.ConfigurationEvent.(ConfigurationEvent.java:120)
at
org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:1818)
at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:104)
at java.lang.Thread.run(Thread.java:662)
#
at this line:
conf.update(props);
#
for this snippet:
package com.barchart.mgr;
import java.util.Date;
import java.util.Dictionary;
import java.util.Properties;
import org.apache.felix.scr.annotations.Activate;
import org.apache.felix.scr.annotations.Component;
import org.apache.felix.scr.annotations.Deactivate;
import org.apache.felix.scr.annotations.Reference;
import org.osgi.service.cm.Configuration;
import org.osgi.service.cm.ConfigurationAdmin;
import org.osgi.service.component.ComponentContext;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
@Component
public class HelloManager {
private static Logger log = LoggerFactory.getLogger(HelloManager.class);
@Reference
private ConfigurationAdmin admin;
@Activate
protected synchronized void activate(ComponentContext context) {
log.debug("ACTIVATE");
log.debug("admin: {}", admin);
try {
Configuration[] confArray =
admin.listConfigurations(null);
if (confArray == null) {
log.debug("confArray == null");
} else {
for (Configuration conf : confArray) {
log.debug("conf: {}", conf);
}
}
String pid = "com.barchart.hello.impl.CompSingle";
Configuration conf = admin.getConfiguration(pid, null);
conf.update();
log.debug("conf: {}", conf);
Dictionary props = conf.getProperties();
if (props == null) {
log.debug("props == null");
props = new Properties();
props.put("created", new Date().toString());
}
conf.update(props);
} catch (Exception e) {
log.error("", e);
}
}
@Deactivate
protected synchronized void deactivate(ComponentContext context) {
log.debug("DEACTIVATE");
}
}
#
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (FELIX-2924) bundle stop hangs for http-2.2.0 in felix-3.2.0
[ https://issues.apache.org/jira/browse/FELIX-2924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022290#comment-13022290 ] Richard S. Hall edited comment on FELIX-2924 at 4/20/11 6:52 PM: - I am pretty sure this is the same issue as FELIX-2913. was (Author: rickhall): I am pretty sure this is the same issue. > bundle stop hangs for http-2.2.0 in felix-3.2.0 > --- > > Key: FELIX-2924 > URL: https://issues.apache.org/jira/browse/FELIX-2924 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-3.2.0 > Environment: Mac OSX java version "1.6.0_24" >Reporter: Derek Baum > > stopping http jetty 2.2.0 hangs framework. > it is fine with http jetty 2.0.4 in framework 3.2.0 > or with http jetty 2.2.0 in framework 3.0.9 > $ cd felix-framework-3.2.0 > $ java -jar bin/felix.jar > > Welcome to Apache Felix Gogo > g! [INFO] Started jetty 6.1.x at port(s) HTTP:8080 > g! lb > START LEVEL 1 >ID|State |Level|Name > 0|Active |0|System Bundle (3.2.0) > 1|Active |1|Apache Felix Bundle Repository (1.6.2) > 2|Active |1|Apache Felix Gogo Command (0.8.0) > 3|Active |1|Apache Felix Gogo Runtime (0.8.0) > 4|Active |1|Apache Felix Gogo Shell (0.8.0) > 5|Active |1|Apache Felix Http Jetty (2.2.0) > g! stop 5 > [ HANGS HERE ] > THREAD DUMP: > ^\2011-04-20 19:07:35 > Full thread dump Java HotSpot(TM) 64-Bit Server VM (19.1-b02-334 mixed mode): > "Timer-0" daemon prio=5 tid=102a5f000 nid=0x10ac9c000 in Object.wait() > [10ac9b000] >java.lang.Thread.State: TIMED_WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > - waiting on <7f30aa0d0> (a java.util.TaskQueue) > at java.util.TimerThread.mainLoop(Timer.java:509) > - locked <7f30aa0d0> (a java.util.TaskQueue) > at java.util.TimerThread.run(Timer.java:462) > "Poller SunPKCS11-Darwin" daemon prio=1 tid=1019c0800 nid=0x10ab99000 waiting > on condition [10ab98000] >java.lang.Thread.State: TIMED_WAITING (sleeping) > at java.lang.Thread.sleep(Native Method) > at sun.security.pkcs11.SunPKCS11$TokenPoller.run(SunPKCS11.java:692) > at java.lang.Thread.run(Thread.java:680) > "918201446@qtp-896472140-0" prio=5 tid=1029cf800 nid=0x10a93c000 in > Object.wait() [10a93b000] >java.lang.Thread.State: TIMED_WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > - waiting on <7f42b2040> (a > org.mortbay.thread.QueuedThreadPool$PoolThread) > at > org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:626) > - locked <7f42b2040> (a > org.mortbay.thread.QueuedThreadPool$PoolThread) > "Jetty HTTP Service" daemon prio=5 tid=1029cd000 nid=0x10a839000 in > Object.wait() [10a837000] >java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > - waiting on <7f437f998> (a [Ljava.lang.Object;) > at java.lang.Object.wait(Object.java:485) > at org.apache.felix.framework.Felix.acquireBundleLock(Felix.java:4930) > - locked <7f437f998> (a [Ljava.lang.Object;) > at > org.apache.felix.framework.Felix.removeServiceListener(Felix.java:2844) > at > org.apache.felix.framework.BundleContextImpl.removeServiceListener(BundleContextImpl.java:256) > at org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:391) > - locked <7f4344008> (a > org.apache.felix.http.base.internal.listener.HttpSessionAttributeListenerManager) > at > org.apache.felix.http.base.internal.HttpServiceController.unregister(HttpServiceController.java:144) > at > org.apache.felix.http.base.internal.DispatcherServlet.destroy(DispatcherServlet.java:54) > at > org.mortbay.jetty.servlet.ServletHolder.destroyInstance(ServletHolder.java:318) > at > org.mortbay.jetty.servlet.ServletHolder.doStop(ServletHolder.java:289) > at > org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:76) > - locked <7f42f4cb0> (a java.lang.Object) > at > org.mortbay.jetty.servlet.ServletHandler.doStop(ServletHandler.java:174) > - locked <7f42f49c8> (a org.mortbay.jetty.servlet.ServletHandler) > at > org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:76) > - locked <7f42f4a38> (a java.lang.Object) > at > org.mortbay.jetty.handler.HandlerWrapper.doStop(HandlerWrapper.java:142) > at > org.mortbay.jetty.servlet.SessionHandler.doStop(SessionHandler.java:125) > at > org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:76) > - locked <7f42f51a8> (a java.l
[jira] [Created] (FELIX-2924) bundle stop hangs for http-2.2.0 in felix-3.2.0
bundle stop hangs for http-2.2.0 in felix-3.2.0 --- Key: FELIX-2924 URL: https://issues.apache.org/jira/browse/FELIX-2924 Project: Felix Issue Type: Bug Components: Framework Affects Versions: framework-3.2.0 Environment: Mac OSX java version "1.6.0_24" Reporter: Derek Baum stopping http jetty 2.2.0 hangs framework. it is fine with http jetty 2.0.4 in framework 3.2.0 or with http jetty 2.2.0 in framework 3.0.9 $ cd felix-framework-3.2.0 $ java -jar bin/felix.jar Welcome to Apache Felix Gogo g! [INFO] Started jetty 6.1.x at port(s) HTTP:8080 g! lb START LEVEL 1 ID|State |Level|Name 0|Active |0|System Bundle (3.2.0) 1|Active |1|Apache Felix Bundle Repository (1.6.2) 2|Active |1|Apache Felix Gogo Command (0.8.0) 3|Active |1|Apache Felix Gogo Runtime (0.8.0) 4|Active |1|Apache Felix Gogo Shell (0.8.0) 5|Active |1|Apache Felix Http Jetty (2.2.0) g! stop 5 [ HANGS HERE ] THREAD DUMP: ^\2011-04-20 19:07:35 Full thread dump Java HotSpot(TM) 64-Bit Server VM (19.1-b02-334 mixed mode): "Timer-0" daemon prio=5 tid=102a5f000 nid=0x10ac9c000 in Object.wait() [10ac9b000] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <7f30aa0d0> (a java.util.TaskQueue) at java.util.TimerThread.mainLoop(Timer.java:509) - locked <7f30aa0d0> (a java.util.TaskQueue) at java.util.TimerThread.run(Timer.java:462) "Poller SunPKCS11-Darwin" daemon prio=1 tid=1019c0800 nid=0x10ab99000 waiting on condition [10ab98000] java.lang.Thread.State: TIMED_WAITING (sleeping) at java.lang.Thread.sleep(Native Method) at sun.security.pkcs11.SunPKCS11$TokenPoller.run(SunPKCS11.java:692) at java.lang.Thread.run(Thread.java:680) "918201446@qtp-896472140-0" prio=5 tid=1029cf800 nid=0x10a93c000 in Object.wait() [10a93b000] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <7f42b2040> (a org.mortbay.thread.QueuedThreadPool$PoolThread) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:626) - locked <7f42b2040> (a org.mortbay.thread.QueuedThreadPool$PoolThread) "Jetty HTTP Service" daemon prio=5 tid=1029cd000 nid=0x10a839000 in Object.wait() [10a837000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <7f437f998> (a [Ljava.lang.Object;) at java.lang.Object.wait(Object.java:485) at org.apache.felix.framework.Felix.acquireBundleLock(Felix.java:4930) - locked <7f437f998> (a [Ljava.lang.Object;) at org.apache.felix.framework.Felix.removeServiceListener(Felix.java:2844) at org.apache.felix.framework.BundleContextImpl.removeServiceListener(BundleContextImpl.java:256) at org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:391) - locked <7f4344008> (a org.apache.felix.http.base.internal.listener.HttpSessionAttributeListenerManager) at org.apache.felix.http.base.internal.HttpServiceController.unregister(HttpServiceController.java:144) at org.apache.felix.http.base.internal.DispatcherServlet.destroy(DispatcherServlet.java:54) at org.mortbay.jetty.servlet.ServletHolder.destroyInstance(ServletHolder.java:318) at org.mortbay.jetty.servlet.ServletHolder.doStop(ServletHolder.java:289) at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:76) - locked <7f42f4cb0> (a java.lang.Object) at org.mortbay.jetty.servlet.ServletHandler.doStop(ServletHandler.java:174) - locked <7f42f49c8> (a org.mortbay.jetty.servlet.ServletHandler) at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:76) - locked <7f42f4a38> (a java.lang.Object) at org.mortbay.jetty.handler.HandlerWrapper.doStop(HandlerWrapper.java:142) at org.mortbay.jetty.servlet.SessionHandler.doStop(SessionHandler.java:125) at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:76) - locked <7f42f51a8> (a java.lang.Object) at org.mortbay.jetty.handler.HandlerWrapper.doStop(HandlerWrapper.java:142) at org.mortbay.jetty.handler.ContextHandler.doStop(ContextHandler.java:591) at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:76) - locked <7f42f4890> (a java.lang.Object) at org.mortbay.jetty.handler.HandlerWrapper.doStop(HandlerWrapper.java:142) at org.mortbay.jetty.Server.doStop(Server.java:283) at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:76) - locked <7f42f1d30> (a java.lang.Object) at org.a
Re: Project source code host things for "Bndtools based OSGi bundles maker project"
It will ... Otherwise Richard will surely kill me after having suffered heavy torture :-) Kind regards, Peter Kriens On 20 apr 2011, at 15:08, Tiger Gui wrote: > Ok, we will host it at github first. And hoping it can be merged into > Felxi oneday :-) > > 2011/4/20 Peter Kriens : >> I would rather strongly prefer to use git in this project so I suggest >> github. bnd and bndtools are scheduled to move to Felix later (actually when >> we find some way to keep using git and not have to revert to svn). Github >> will integrate rather nicely with bnd and bntools that are also hosted at >> github. At github you can just fork the bnd and bndtools repositories. I >> think this model will be a whole lot less complex this way. Once we move >> bnd(tools) to Felix we can integrate your code as well. >> >> bnd is at http://www.github.com/bnd >> bndtools is at http://www.github.com/njbartlett >> >> Kind regards, >> >>Peter Kriens >> >> >> >> On 20 apr 2011, at 14:57, Tiger Gui wrote: >> >>> Hi Peter, >>> >>> After these days's research job and coding experiment, i think it is >>> time for me to start some real coding job first. Now the only problem >>> is that where should we host our project ? If our project is accepted >>> by Apache, should we create a SVN workspace in Apache's SVN server or >>> something ? Or we should find some other place to host our project, >>> for example, host it in Google Code platform ? Thank you >>> >>> -- >>> Best Regards >>> >>> Tiger Gui [tigergui1...@gmail.com] >> >> > > > > -- > Best Regards > > Tiger Gui [tigergui1...@gmail.com]
Re: Project source code host things for "Bndtools based OSGi bundles maker project"
Ok, we will host it at github first. And hoping it can be merged into Felxi oneday :-) 2011/4/20 Peter Kriens : > I would rather strongly prefer to use git in this project so I suggest > github. bnd and bndtools are scheduled to move to Felix later (actually when > we find some way to keep using git and not have to revert to svn). Github > will integrate rather nicely with bnd and bntools that are also hosted at > github. At github you can just fork the bnd and bndtools repositories. I > think this model will be a whole lot less complex this way. Once we move > bnd(tools) to Felix we can integrate your code as well. > > bnd is at http://www.github.com/bnd > bndtools is at http://www.github.com/njbartlett > > Kind regards, > > Peter Kriens > > > > On 20 apr 2011, at 14:57, Tiger Gui wrote: > >> Hi Peter, >> >> After these days's research job and coding experiment, i think it is >> time for me to start some real coding job first. Now the only problem >> is that where should we host our project ? If our project is accepted >> by Apache, should we create a SVN workspace in Apache's SVN server or >> something ? Or we should find some other place to host our project, >> for example, host it in Google Code platform ? Thank you >> >> -- >> Best Regards >> >> Tiger Gui [tigergui1...@gmail.com] > > -- Best Regards Tiger Gui [tigergui1...@gmail.com]
Re: Project source code host things for "Bndtools based OSGi bundles maker project"
I would rather strongly prefer to use git in this project so I suggest github. bnd and bndtools are scheduled to move to Felix later (actually when we find some way to keep using git and not have to revert to svn). Github will integrate rather nicely with bnd and bntools that are also hosted at github. At github you can just fork the bnd and bndtools repositories. I think this model will be a whole lot less complex this way. Once we move bnd(tools) to Felix we can integrate your code as well. bnd is at http://www.github.com/bnd bndtools is at http://www.github.com/njbartlett Kind regards, Peter Kriens On 20 apr 2011, at 14:57, Tiger Gui wrote: > Hi Peter, > > After these days's research job and coding experiment, i think it is > time for me to start some real coding job first. Now the only problem > is that where should we host our project ? If our project is accepted > by Apache, should we create a SVN workspace in Apache's SVN server or > something ? Or we should find some other place to host our project, > for example, host it in Google Code platform ? Thank you > > -- > Best Regards > > Tiger Gui [tigergui1...@gmail.com]
Re: [VOTE] framework 3.2.1 and related subproject releases
On 4/20/11 4:41, Jean-Baptiste Onofré wrote: +1 (non binding) However, we have an issue in Karaf which seems related to Felix framework: https://issues.apache.org/jira/browse/KARAF-534 I don't think that the issue is specific to 3.2.1 (I suspect it's more global). I'm working to have a better understanding of the behavior and submit a Jira/patch. Let us know if you figure anything out here or come up with a simple test case... -> richard Regards JB On 04/18/2011 11:51 PM, Karl Pauls wrote: I would like to call a vote on the following subproject releases: framework 3.2.1 main 3.2.1 main.distribution 3.2.1 Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-098/ 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 098 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments)
Project source code host things for "Bndtools based OSGi bundles maker project"
Hi Peter, After these days's research job and coding experiment, i think it is time for me to start some real coding job first. Now the only problem is that where should we host our project ? If our project is accepted by Apache, should we create a SVN workspace in Apache's SVN server or something ? Or we should find some other place to host our project, for example, host it in Google Code platform ? Thank you -- Best Regards Tiger Gui [tigergui1...@gmail.com]
[jira] [Resolved] (FELIX-2916) Don't include Embed-Dependency in manifest
[ https://issues.apache.org/jira/browse/FELIX-2916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved FELIX-2916. - Resolution: Won't Fix Sweet, thanks Felix > Don't include Embed-Dependency in manifest > -- > > Key: FELIX-2916 > URL: https://issues.apache.org/jira/browse/FELIX-2916 > Project: Felix > Issue Type: Improvement > Components: Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-2.3.4 >Reporter: Carsten Ziegeler >Priority: Minor > > The Embed-Dependency directive is an instruction for the plugin (bnd) - it > should not be included in the final manifest -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2916) Don't include Embed-Dependency in manifest
[ https://issues.apache.org/jira/browse/FELIX-2916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022045#comment-13022045 ] Felix Meschberger commented on FELIX-2916: -- Actually we can close this issue as won't fix because there is a way to exclude the header: <_removeheaders>Embed-Dependency > Don't include Embed-Dependency in manifest > -- > > Key: FELIX-2916 > URL: https://issues.apache.org/jira/browse/FELIX-2916 > Project: Felix > Issue Type: Improvement > Components: Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-2.3.4 >Reporter: Carsten Ziegeler >Priority: Minor > > The Embed-Dependency directive is an instruction for the plugin (bnd) - it > should not be included in the final manifest -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] framework 3.2.1 and related subproject releases
Good catch. It looks like we didn't have a LICENSE and NOTICE in the main-sources for a while (for sure not during the last release either). Sucks. I cancel this vote. regards, Karl On Wed, Apr 20, 2011 at 11:17 AM, Clement Escoffier wrote: > Hi, > > +1 for the framework: > - only small issue : the DEPENDENCIES summary title is not 'III. Overall > License Summary' as defined on > http://felix.apache.org/site/dependencies-file-template.html > > Pending / -1 for main: > - the -sources artifacts does not contains the LICENSE, and NOTICE files. > - same issue about the DEPENDENCIES summary title > > As the distribution is containing main, it's, unfortunately, -1 too. > > Regards, > > Clement > > On 18.04.11 23:51, "Karl Pauls" wrote: > >>I would like to call a vote on the following subproject releases: >> >>framework 3.2.1 >>main 3.2.1 >>main.distribution 3.2.1 >> >>Staging repositories: >>https://repository.apache.org/content/repositories/orgapachefelix-098/ >> >>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 098 /tmp/felix-staging >> >>Please vote to approve this release: >> >>[ ] +1 Approve the release >>[ ] -1 Veto the release (please provide specific comments) > > > -- Karl Pauls karlpa...@gmail.com
Re: [VOTE] framework 3.2.1 and related subproject releases
Hi, +1 for the framework: - only small issue : the DEPENDENCIES summary title is not 'III. Overall License Summary' as defined on http://felix.apache.org/site/dependencies-file-template.html Pending / -1 for main: - the -sources artifacts does not contains the LICENSE, and NOTICE files. - same issue about the DEPENDENCIES summary title As the distribution is containing main, it's, unfortunately, -1 too. Regards, Clement On 18.04.11 23:51, "Karl Pauls" wrote: >I would like to call a vote on the following subproject releases: > >framework 3.2.1 >main 3.2.1 >main.distribution 3.2.1 > >Staging repositories: >https://repository.apache.org/content/repositories/orgapachefelix-098/ > >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 098 /tmp/felix-staging > >Please vote to approve this release: > >[ ] +1 Approve the release >[ ] -1 Veto the release (please provide specific comments)
Re: [VOTE] framework 3.2.1 and related subproject releases
+1 (non binding) However, we have an issue in Karaf which seems related to Felix framework: https://issues.apache.org/jira/browse/KARAF-534 I don't think that the issue is specific to 3.2.1 (I suspect it's more global). I'm working to have a better understanding of the behavior and submit a Jira/patch. Regards JB On 04/18/2011 11:51 PM, Karl Pauls wrote: I would like to call a vote on the following subproject releases: framework 3.2.1 main 3.2.1 main.distribution 3.2.1 Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-098/ 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 098 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments)
[jira] [Commented] (FELIX-2916) Don't include Embed-Dependency in manifest
[ https://issues.apache.org/jira/browse/FELIX-2916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022009#comment-13022009 ] Carsten Ziegeler commented on FELIX-2916: - Yes, it does not do any harm - but it looks ugly to me :) (ok, this is more personal taste than anything else) Making this configurable (if included or not) sounds too much for me as well. So, if there is noone else who things that this should not end up in the final bundle, let's close this issue. > Don't include Embed-Dependency in manifest > -- > > Key: FELIX-2916 > URL: https://issues.apache.org/jira/browse/FELIX-2916 > Project: Felix > Issue Type: Improvement > Components: Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-2.3.4 >Reporter: Carsten Ziegeler >Priority: Minor > > The Embed-Dependency directive is an instruction for the plugin (bnd) - it > should not be included in the final manifest -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
