Re: [DISCUSS] Release maven-bundle-plugin
Well, given I used the latest master branch of bnd, I suppose this is included in the version embedded... It we keep it, that may definitely warrant of minor version change. It the change is seen as risky, I can revert it and keep with bndlib 2.x released on maven central and we could release a micro version of the maven plugin. 2015-07-15 22:36 GMT+02:00 David Bosschaert : > We could consider waiting for bnd 3.0 which fixes a number of issues. > This includes new OSGi annotations. For example this one: > https://github.com/bndtools/bnd/issues/956 > > I think bnd 3.0 is planned for July 31st or some time around that. > > Cheers, > > David > > On 15 July 2015 at 21:25, Jean-Baptiste Onofré wrote: > > +1 > > > > Regards > > JB > > > > > > On 07/15/2015 08:40 PM, Guillaume Nodet wrote: > >> > >> I'd like to release a new version of the maven-bundle-plugin. > >> I've fixed a few bugs recently. > >> One thing worth to mention is that the plugin currently embeds the > latest > >> bndlib jar (grabbed from the bnd CI build) to fix one bug. I haven't > seen > >> any problem with it so far, but I wonder if we should bump to a minor > >> version or not (or eventually revert it to release a micro version). > >> > >> Thoughts ? > >> > >> Guillaume Nodet > >> > > > > -- > > Jean-Baptiste Onofré > > jbono...@apache.org > > http://blog.nanthrax.net > > Talend - http://www.talend.com >
[jira] [Closed] (FELIX-4961) Make the relationship to dependencymanager.runtime more clear
[ https://issues.apache.org/jira/browse/FELIX-4961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Bakker closed FELIX-4961. -- Resolution: Fixed Closing the issue since a solution was already available. > Make the relationship to dependencymanager.runtime more clear > - > > Key: FELIX-4961 > URL: https://issues.apache.org/jira/browse/FELIX-4961 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager Annotations >Reporter: Paul Bakker >Priority: Minor > > For components that I wrote using DM annotations I often get questions why > the component doesn't work. It always turns out the dependencymanager.runtime > bundle is missing. > There is not really an obvious way to learn about this requirement for new > users besides the docs. The docs are ok for DM users, but not an obvious > place to look for users of a component that uses DM internally. > I do not have a solution for this issue, but would like to start discussing > how we can improve this situation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [DISCUSS] Release maven-bundle-plugin
We could consider waiting for bnd 3.0 which fixes a number of issues. This includes new OSGi annotations. For example this one: https://github.com/bndtools/bnd/issues/956 I think bnd 3.0 is planned for July 31st or some time around that. Cheers, David On 15 July 2015 at 21:25, Jean-Baptiste Onofré wrote: > +1 > > Regards > JB > > > On 07/15/2015 08:40 PM, Guillaume Nodet wrote: >> >> I'd like to release a new version of the maven-bundle-plugin. >> I've fixed a few bugs recently. >> One thing worth to mention is that the plugin currently embeds the latest >> bndlib jar (grabbed from the bnd CI build) to fix one bug. I haven't seen >> any problem with it so far, but I wonder if we should bump to a minor >> version or not (or eventually revert it to release a micro version). >> >> Thoughts ? >> >> Guillaume Nodet >> > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com
Re: [DISCUSS] Release maven-bundle-plugin
+1 Regards JB On 07/15/2015 08:40 PM, Guillaume Nodet wrote: I'd like to release a new version of the maven-bundle-plugin. I've fixed a few bugs recently. One thing worth to mention is that the plugin currently embeds the latest bndlib jar (grabbed from the bnd CI build) to fix one bug. I haven't seen any problem with it so far, but I wonder if we should bump to a minor version or not (or eventually revert it to release a micro version). Thoughts ? Guillaume Nodet -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
[DISCUSS] Release maven-bundle-plugin
I'd like to release a new version of the maven-bundle-plugin. I've fixed a few bugs recently. One thing worth to mention is that the plugin currently embeds the latest bndlib jar (grabbed from the bnd CI build) to fix one bug. I haven't seen any problem with it so far, but I wonder if we should bump to a minor version or not (or eventually revert it to release a micro version). Thoughts ? Guillaume Nodet
[jira] [Commented] (FELIX-4961) Make the relationship to dependencymanager.runtime more clear
[ https://issues.apache.org/jira/browse/FELIX-4961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14628088#comment-14628088 ] Paul Bakker commented on FELIX-4961: That's great! Just did a quick test and it seems to do exactly what I was hoping for. Yes, I agree Bootstrap should do that by default, I will add that. Enjoy your holiday! > Make the relationship to dependencymanager.runtime more clear > - > > Key: FELIX-4961 > URL: https://issues.apache.org/jira/browse/FELIX-4961 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager Annotations >Reporter: Paul Bakker >Priority: Minor > > For components that I wrote using DM annotations I often get questions why > the component doesn't work. It always turns out the dependencymanager.runtime > bundle is missing. > There is not really an obvious way to learn about this requirement for new > users besides the docs. The docs are ok for DM users, but not an obvious > place to look for users of a component that uses DM internally. > I do not have a solution for this issue, but would like to start discussing > how we can improve this situation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4961) Make the relationship to dependencymanager.runtime more clear
[
https://issues.apache.org/jira/browse/FELIX-4961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14628074#comment-14628074
]
Pierre De Rop commented on FELIX-4961:
--
Hi Paul;
Here is a quick response (I'm currently in vacations, will get back next 24
july):
Since the r1 release (see FELIX-4676), there is now the possibility to
configure the DM bnd annotation plugin in order to generate a
"Require-Capability" header in annotated bundles. Such header requires the
presence of the DM runtime bundle.
For instance, if you add the following option in the plugin:
{code}
-plugin:
org.apache.felix.dm.annotation.plugin.bnd.AnnotationPlugin;add-require-capability=true;\
{code}
then the bundle will include the following generated header:
{code}
Require-Capability:
osgi.extender;filter:="(&(osgi.extender=org.apache.felix.dependencymanager.runtime)(version>=4.0.0))"
{code}
Now, the DM runtime provides a corresponding "Require-Capability" header, and
if the DM runtime is missing, then the bundle won't be installed and the
following error will be logged:
{code}
! Failed to start bundle
org.apache.felix.dependencymanager.samples.dynamicdep.annot-1.0.0, exception
Unresolved constraint in bundle
org.apache.felix.dependencymanager.samples.dynamicdep.annot [25]: Unable to
resolve 25.0: missing requirement [25.0] osgi.extender;
(&(osgi.extender=org.apache.felix.dependencymanager.runtime)(version>=4.0.0))
{code}
I think this corresponds to what you are asking for ? If yes, then may be the
Amdatu bootstrap could generate by default the "add-require-capability=true" dm
annotation plugin option ?
Also, please notice that the deprecated "Import-Service" header is not
generated anymore so you don't have to use the
"build-import-export-service=false" option (I'm not sure but I think that
Amdatu bootstrap is currently using the "import-export-service=false" option).
Also, this new option is not currently documented (I will do it when back from
holidays, sorry about that).
One last note: if you have more than one annotated component in a given bundle,
then currently, multiple dm runtime extenders are concatenated in the
"Require-Capability" header, but this does not causes problems ... however I
will also fix this when back from vacations.
let me know if all this corresponds to what you are asking for.
> Make the relationship to dependencymanager.runtime more clear
> -
>
> Key: FELIX-4961
> URL: https://issues.apache.org/jira/browse/FELIX-4961
> Project: Felix
> Issue Type: Improvement
> Components: Dependency Manager Annotations
>Reporter: Paul Bakker
>Priority: Minor
>
> For components that I wrote using DM annotations I often get questions why
> the component doesn't work. It always turns out the dependencymanager.runtime
> bundle is missing.
> There is not really an obvious way to learn about this requirement for new
> users besides the docs. The docs are ok for DM users, but not an obvious
> place to look for users of a component that uses DM internally.
> I do not have a solution for this issue, but would like to start discussing
> how we can improve this situation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: svn commit: r1691137 - in /felix/trunk/framework/src: main/java/org/apache/felix/framework/BundleRevisionImpl.java test/java/org/apache/felix/framework/BundleRevisionImplTest.java
Fixed in http://svn.apache.org/viewvc?view=revision&revision=1691141 Cheers, David On 15 July 2015 at 08:53, David Bosschaert wrote: > Ah, sorry, I missed that :( > I will change to use a Java 5 one. > > Thanks for the heads up! > > David > > On 15 July 2015 at 08:48, Chetan Mehrotra wrote: >> Hi David, >> >> On Wed, Jul 15, 2015 at 1:14 PM, wrote: >>> +if (contentPath == null) >>> +return Collections.emptyEnumeration(); >> >> This method is JDK 1.7+ >> >> Chetan Mehrotra
[jira] [Created] (FELIX-4961) Make the relationship to dependencymanager.runtime more clear
Paul Bakker created FELIX-4961: -- Summary: Make the relationship to dependencymanager.runtime more clear Key: FELIX-4961 URL: https://issues.apache.org/jira/browse/FELIX-4961 Project: Felix Issue Type: Improvement Components: Dependency Manager Annotations Reporter: Paul Bakker Priority: Minor For components that I wrote using DM annotations I often get questions why the component doesn't work. It always turns out the dependencymanager.runtime bundle is missing. There is not really an obvious way to learn about this requirement for new users besides the docs. The docs are ok for DM users, but not an obvious place to look for users of a component that uses DM internally. I do not have a solution for this issue, but would like to start discussing how we can improve this situation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: svn commit: r1691137 - in /felix/trunk/framework/src: main/java/org/apache/felix/framework/BundleRevisionImpl.java test/java/org/apache/felix/framework/BundleRevisionImplTest.java
Ah, sorry, I missed that :( I will change to use a Java 5 one. Thanks for the heads up! David On 15 July 2015 at 08:48, Chetan Mehrotra wrote: > Hi David, > > On Wed, Jul 15, 2015 at 1:14 PM, wrote: >> +if (contentPath == null) >> +return Collections.emptyEnumeration(); > > This method is JDK 1.7+ > > Chetan Mehrotra
Re: svn commit: r1691137 - in /felix/trunk/framework/src: main/java/org/apache/felix/framework/BundleRevisionImpl.java test/java/org/apache/felix/framework/BundleRevisionImplTest.java
Hi David, On Wed, Jul 15, 2015 at 1:14 PM, wrote: > +if (contentPath == null) > +return Collections.emptyEnumeration(); This method is JDK 1.7+ Chetan Mehrotra
[jira] [Resolved] (FELIX-4960) NPE in BundleRevisionImpl.getResourcesLocal()
[
https://issues.apache.org/jira/browse/FELIX-4960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert resolved FELIX-4960.
-
Resolution: Fixed
Fixed in http://svn.apache.org/viewvc?view=revision&revision=1691137
> NPE in BundleRevisionImpl.getResourcesLocal()
> -
>
> Key: FELIX-4960
> URL: https://issues.apache.org/jira/browse/FELIX-4960
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.4.0, framework-5.0.1
>Reporter: David Bosschaert
>Assignee: David Bosschaert
> Fix For: framework-5.0.2
>
>
> In some situations a NPE can be observed in the
> BundleRevisionImpl.getResourcesLocal() method.
> {code}java.lang.NullPointerException: null
>at
> org.apache.felix.framework.BundleRevisionImpl.getResourcesLocal(BundleRevisionImpl.java:531)
>at
> org.apache.felix.framework.BundleWiringImpl.findResourcesByDelegation(BundleWiringImpl.java:1191)
>at
> org.apache.felix.framework.BundleWiringImpl.getResourcesByDelegation(BundleWiringImpl.java:1101)
>at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5.getResources(BundleWiringImpl.java:1888){code}
> The offending line of code is:
> {code} for (int i = 0; i < contentPath.size(); i++){code}
> So it seems that contentPath is null in some cases.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Resolver does not compile with Java versions pre 8
Hi all, Just noticed that the Felix Resolver does not compile if you try to do this with a pre-Java 8 compiler. I'm getting the following error: [INFO] - [ERROR] COMPILATION ERROR : [INFO] - [ERROR] /Users/David/checkouts/felix/resolver/src/main/java/org/apache/felix/resolver/util/ArrayMap.java:[100,46] is not abstract and does not override abstract method remove() in java.util.Iterator [ERROR] /Users/David/checkouts/felix/resolver/src/main/java/org/apache/felix/resolver/util/ArrayMap.java:[131,52] is not abstract and does not override abstract method remove() in java.util.Iterator If I compile with Java 8 it all works (which is a little strange, because I would have expected the Maven compiler settings to govern this). Guillaume, I guess this might be related to your recent changes in the resolver area. Could you please take a look? Cheers, David
[jira] [Commented] (FELIX-4960) NPE in BundleRevisionImpl.getResourcesLocal()
[
https://issues.apache.org/jira/browse/FELIX-4960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627661#comment-14627661
]
David Bosschaert commented on FELIX-4960:
-
Right - there is actually a more specific exception that is being logged from
this line of code in getContentPath():
{code}((BundleImpl) m_bundle).getFramework().getLogger().log(m_bundle,
Logger.LOG_ERROR, "Unable to get module class path.", ex);{code}
However execution continues after this leading to the NPE. I think the NPE
should not happen in either case...
> NPE in BundleRevisionImpl.getResourcesLocal()
> -
>
> Key: FELIX-4960
> URL: https://issues.apache.org/jira/browse/FELIX-4960
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.4.0, framework-5.0.1
>Reporter: David Bosschaert
>Assignee: David Bosschaert
> Fix For: framework-5.0.2
>
>
> In some situations a NPE can be observed in the
> BundleRevisionImpl.getResourcesLocal() method.
> {code}java.lang.NullPointerException: null
>at
> org.apache.felix.framework.BundleRevisionImpl.getResourcesLocal(BundleRevisionImpl.java:531)
>at
> org.apache.felix.framework.BundleWiringImpl.findResourcesByDelegation(BundleWiringImpl.java:1191)
>at
> org.apache.felix.framework.BundleWiringImpl.getResourcesByDelegation(BundleWiringImpl.java:1101)
>at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5.getResources(BundleWiringImpl.java:1888){code}
> The offending line of code is:
> {code} for (int i = 0; i < contentPath.size(); i++){code}
> So it seems that contentPath is null in some cases.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-4960) NPE in BundleRevisionImpl.getResourcesLocal()
[
https://issues.apache.org/jira/browse/FELIX-4960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627658#comment-14627658
]
Grzegorz Grzybek commented on FELIX-4960:
-
I had similar issue, when old BundleClassLoader was used to get resources. This
was the case described in ARIES-1161 and the
[fix|https://github.com/apache/aries/commit/760dac830ac7a84f628a27dc680a9ba6ee1ba711]
was to switch the key from bundle to bundle wiring.
The problem occurred after updating bundle. Old bundle wiring (and classloader)
was invalid, but was still used leading to NPE in Felix code.
> NPE in BundleRevisionImpl.getResourcesLocal()
> -
>
> Key: FELIX-4960
> URL: https://issues.apache.org/jira/browse/FELIX-4960
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.4.0, framework-5.0.1
>Reporter: David Bosschaert
>Assignee: David Bosschaert
> Fix For: framework-5.0.2
>
>
> In some situations a NPE can be observed in the
> BundleRevisionImpl.getResourcesLocal() method.
> {code}java.lang.NullPointerException: null
>at
> org.apache.felix.framework.BundleRevisionImpl.getResourcesLocal(BundleRevisionImpl.java:531)
>at
> org.apache.felix.framework.BundleWiringImpl.findResourcesByDelegation(BundleWiringImpl.java:1191)
>at
> org.apache.felix.framework.BundleWiringImpl.getResourcesByDelegation(BundleWiringImpl.java:1101)
>at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5.getResources(BundleWiringImpl.java:1888){code}
> The offending line of code is:
> {code} for (int i = 0; i < contentPath.size(); i++){code}
> So it seems that contentPath is null in some cases.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FELIX-4960) NPE in BundleRevisionImpl.getResourcesLocal()
David Bosschaert created FELIX-4960:
---
Summary: NPE in BundleRevisionImpl.getResourcesLocal()
Key: FELIX-4960
URL: https://issues.apache.org/jira/browse/FELIX-4960
Project: Felix
Issue Type: Bug
Components: Framework
Affects Versions: framework-4.4.0, framework-5.0.1
Reporter: David Bosschaert
Assignee: David Bosschaert
Fix For: framework-5.0.2
In some situations a NPE can be observed in the
BundleRevisionImpl.getResourcesLocal() method.
{code}java.lang.NullPointerException: null
at
org.apache.felix.framework.BundleRevisionImpl.getResourcesLocal(BundleRevisionImpl.java:531)
at
org.apache.felix.framework.BundleWiringImpl.findResourcesByDelegation(BundleWiringImpl.java:1191)
at
org.apache.felix.framework.BundleWiringImpl.getResourcesByDelegation(BundleWiringImpl.java:1101)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5.getResources(BundleWiringImpl.java:1888){code}
The offending line of code is:
{code} for (int i = 0; i < contentPath.size(); i++){code}
So it seems that contentPath is null in some cases.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
