Enable reference: protocol in Karaf

[matteor]

Hello! 

I tried to enable the reference protocol in Karaf adding these bundles to
the startup.properties:



And in fact now I can see the installed bundles in my runtime:



But when in my test I try to use the protocol like this:



I get quite a strange error:



Could you please advice on how to address this error? Am I missing any
configuration entries?

Thank you very much,
Matteo



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Enable reference: protocol in Karaf

[Francois Papon]

Hi Matteo,

We can't see your additionnals info, can you re-paste ?

regards,

François


Le 09/07/2018 à 13:59, matteor a écrit :
> Hello! 
>
> I tried to enable the reference protocol in Karaf adding these bundles to
> the startup.properties:
>
>
>
> And in fact now I can see the installed bundles in my runtime:
>
>
>
> But when in my test I try to use the protocol like this:
>
>
>
> I get quite a strange error:
>
>
>
> Could you please advice on how to address this error? Am I missing any
> configuration entries?
>
> Thank you very much,
> Matteo
>
>
>
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Enable reference: protocol in Karaf

[matteor]

Sorry. It seems that message formatting in nabble does not work very well...
Here is the message with all the details:

I tried to enable the reference protocol in Karaf adding these bundles to
the startup.properties:

mvn\:org.ops4j.base/ops4j-base-lang/1.5.0 = 11
mvn\:org.ops4j.base/ops4j-base-util-property/1.5.0 = 11
mvn\:org.ops4j.pax.swissbox/pax-swissbox-property/1.8.3 = 11
mvn\:org.ops4j.pax.url/pax-url-commons/2.5.3 = 11
mvn\:org.ops4j.pax.url/pax-url-reference/2.5.3 = 12

And in fact now I can see the installed bundles in my runtime:

list -t 0 -s | grep pax
 4 │ Active   │   5 │ 2.5.2  │ org.ops4j.pax.url.mvn
 5 │ Active   │   8 │ 1.10.1 │
org.ops4j.pax.logging.pax-logging-api
 6 │ Active   │   8 │ 1.10.1 │
org.ops4j.pax.logging.pax-logging-log4j2
15 │ Active   │  11 │ 1.8.3  │ org.ops4j.pax.swissbox.property
16 │ Active   │  11 │ 2.5.3  │ org.ops4j.pax.url.commons
17 │ Active   │  12 │ 2.5.3  │ org.ops4j.pax.url.reference
60 │ Active   │   5 │ 2.5.2  │ org.ops4j.pax.url.wrap

But when in my test I try to use the protocol like this:

Option[] options = new Option[] {
systemProperty("pax.exam.osgi.unresolved.fail").value("true"),
features(testUtils.getStandardRepo(), "aries-blueprint"),
features(testUtils.getStandardRepo(), "http"),
features(testUtils.getStandardRepo(), "http-whiteboard"),
bundle("reference:file:target/classes/")
};

I get quite a strange error:

org.apache.karaf.features.internal.util.MultiException: Error:

/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/exam/424a9312-bd8e-4ef9-8e62-e768b5b11cdf/data/tmp
(Is a directory)
at
org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader.(MavenDownloadManager.java:84)
~[?:?]
at
org.apache.karaf.features.internal.download.impl.MavenDownloadManager.createDownloader(MavenDownloadManager.java:72)
~[?:?]
at
org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:375)
~[?:?]
at
org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:372)
~[?:?]
at
org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:187)
~[?:?]
at
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:291)
~[?:?]
at
org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1233)
~[?:?]
at
org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$0(FeaturesServiceImpl.java:1132)
~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[?:?]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
Suppressed: java.io.FileNotFoundException:
/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/exam/424a9312-bd8e-4ef9-8e62-e768b5b11cdf/data/tmp
(Is a directory)
at java.io.FileInputStream.open0(Native Method) ~[?:?]
at java.io.FileInputStream.open(FileInputStream.java:195) [?:?]
at java.io.FileInputStream.(FileInputStream.java:138) 
[?:?]
at
org.apache.karaf.features.internal.download.impl.AbstractDownloadTask.open(AbstractDownloadTask.java:54)
[18:org.apache.karaf.features.core:4.1.2]
at
org.apache.karaf.features.internal.region.Subsystem.getMetadata(Subsystem.java:535)
[18:org.apache.karaf.features.core:4.1.2]
at
org.apache.karaf.features.internal.region.Subsystem$1.downloaded(Subsystem.java:402)
[18:org.apache.karaf.features.core:4.1.2]
at
org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader$1.operationComplete(MavenDownloadManager.java:133)
[18:org.apache.karaf.features.core:4.1.2]
at
org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader$1.operationComplete(MavenDownloadManager.java:127)
[18:org.apache.karaf.features.core:4.1.2]
at
org.apache.karaf.features.internal.download.impl.DefaultFuture.notifyListener(DefaultFuture.java:350)
[18:org.apache.karaf.features.core:4.1.2]
at
org.apache.karaf.features.internal.download.impl.DefaultFuture.notifyListeners(DefaultFuture.java:335)
[18:org.apache.karaf.features.core:4.1.2]
at
org.apache.karaf.features.internal.download.impl.DefaultFuture.setValue(DefaultFuture.java:259)
[18:org.apache.karaf.features.core:4.1.2]
at
org.apache.karaf.features.internal.download.impl.AbstractDownloadTask.setFile(AbstractDownloadTask.java:61)
[18:org.apache.karaf.features.core:4.1.2]
   

Re: Enable reference: protocol in Karaf

[Francois Papon]

Which version of Karaf are you using ?

regards

François


Le 09/07/2018 à 14:05, matteor a écrit :
> Sorry. It seems that message formatting in nabble does not work very well...
> Here is the message with all the details:
>
> I tried to enable the reference protocol in Karaf adding these bundles to
> the startup.properties:
>
> mvn\:org.ops4j.base/ops4j-base-lang/1.5.0 = 11
> mvn\:org.ops4j.base/ops4j-base-util-property/1.5.0 = 11
> mvn\:org.ops4j.pax.swissbox/pax-swissbox-property/1.8.3 = 11
> mvn\:org.ops4j.pax.url/pax-url-commons/2.5.3 = 11
> mvn\:org.ops4j.pax.url/pax-url-reference/2.5.3 = 12
>
> And in fact now I can see the installed bundles in my runtime:
>
> list -t 0 -s | grep pax
>  4 │ Active   │   5 │ 2.5.2  │ org.ops4j.pax.url.mvn
>  5 │ Active   │   8 │ 1.10.1 │
> org.ops4j.pax.logging.pax-logging-api
>  6 │ Active   │   8 │ 1.10.1 │
> org.ops4j.pax.logging.pax-logging-log4j2
> 15 │ Active   │  11 │ 1.8.3  │ org.ops4j.pax.swissbox.property
> 16 │ Active   │  11 │ 2.5.3  │ org.ops4j.pax.url.commons
> 17 │ Active   │  12 │ 2.5.3  │ org.ops4j.pax.url.reference
> 60 │ Active   │   5 │ 2.5.2  │ org.ops4j.pax.url.wrap
>
> But when in my test I try to use the protocol like this:
>
> Option[] options = new Option[] {
>   systemProperty("pax.exam.osgi.unresolved.fail").value("true"),
>   features(testUtils.getStandardRepo(), "aries-blueprint"),
>   features(testUtils.getStandardRepo(), "http"),
>   features(testUtils.getStandardRepo(), "http-whiteboard"),
>   bundle("reference:file:target/classes/")
> };
>
> I get quite a strange error:
>
> org.apache.karaf.features.internal.util.MultiException: Error:
>
> /Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/exam/424a9312-bd8e-4ef9-8e62-e768b5b11cdf/data/tmp
> (Is a directory)
>   at
> org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader.(MavenDownloadManager.java:84)
> ~[?:?]
>   at
> org.apache.karaf.features.internal.download.impl.MavenDownloadManager.createDownloader(MavenDownloadManager.java:72)
> ~[?:?]
>   at
> org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:375)
> ~[?:?]
>   at
> org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:372)
> ~[?:?]
>   at
> org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:187)
> ~[?:?]
>   at
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:291)
> ~[?:?]
>   at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1233)
> ~[?:?]
>   at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$0(FeaturesServiceImpl.java:1132)
> ~[?:?]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
>   at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [?:?]
>   at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [?:?]
>   at java.lang.Thread.run(Thread.java:748) [?:?]
>   Suppressed: java.io.FileNotFoundException:
> /Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/exam/424a9312-bd8e-4ef9-8e62-e768b5b11cdf/data/tmp
> (Is a directory)
>   at java.io.FileInputStream.open0(Native Method) ~[?:?]
>   at java.io.FileInputStream.open(FileInputStream.java:195) [?:?]
>   at java.io.FileInputStream.(FileInputStream.java:138) 
> [?:?]
>   at
> org.apache.karaf.features.internal.download.impl.AbstractDownloadTask.open(AbstractDownloadTask.java:54)
> [18:org.apache.karaf.features.core:4.1.2]
>   at
> org.apache.karaf.features.internal.region.Subsystem.getMetadata(Subsystem.java:535)
> [18:org.apache.karaf.features.core:4.1.2]
>   at
> org.apache.karaf.features.internal.region.Subsystem$1.downloaded(Subsystem.java:402)
> [18:org.apache.karaf.features.core:4.1.2]
>   at
> org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader$1.operationComplete(MavenDownloadManager.java:133)
> [18:org.apache.karaf.features.core:4.1.2]
>   at
> org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader$1.operationComplete(MavenDownloadManager.java:127)
> [18:org.apache.karaf.features.core:4.1.2]
>   at
> org.apache.karaf.features.internal.download.impl.DefaultFuture.notifyListener(DefaultFuture.java:350)
> [18:org.apache.karaf.features.core:4.1.2]
>   at
> org.apache.karaf.features.internal.download.impl.DefaultFuture.notifyListeners(DefaultFuture.java:335)
> [18:org.apache.karaf.features.core:4.1.2]
>   at
> org.apache.karaf.features.internal.download.impl.DefaultFuture.setValue(Defaul

Re: Enable reference: protocol in Karaf

[Matteo Rulli]

I’m using the Karaf version 4.1.2 and the test is running on MAC-OS.

> On 9 Jul 2018, at 12:07, Francois Papon  wrote:
> 
> Which version of Karaf are you using ?
> 
> regards
> 
> François
> 
> 
> Le 09/07/2018 à 14:05, matteor a écrit :
>> Sorry. It seems that message formatting in nabble does not work very well...
>> Here is the message with all the details:
>> 
>> I tried to enable the reference protocol in Karaf adding these bundles to
>> the startup.properties:
>> 
>> mvn\:org.ops4j.base/ops4j-base-lang/1.5.0 = 11
>> mvn\:org.ops4j.base/ops4j-base-util-property/1.5.0 = 11
>> mvn\:org.ops4j.pax.swissbox/pax-swissbox-property/1.8.3 = 11
>> mvn\:org.ops4j.pax.url/pax-url-commons/2.5.3 = 11
>> mvn\:org.ops4j.pax.url/pax-url-reference/2.5.3 = 12
>> 
>> And in fact now I can see the installed bundles in my runtime:
>> 
>> list -t 0 -s | grep pax
>> 4 │ Active   │   5 │ 2.5.2  │ org.ops4j.pax.url.mvn
>> 5 │ Active   │   8 │ 1.10.1 │
>> org.ops4j.pax.logging.pax-logging-api
>> 6 │ Active   │   8 │ 1.10.1 │
>> org.ops4j.pax.logging.pax-logging-log4j2
>> 15 │ Active   │  11 │ 1.8.3  │ org.ops4j.pax.swissbox.property
>> 16 │ Active   │  11 │ 2.5.3  │ org.ops4j.pax.url.commons
>> 17 │ Active   │  12 │ 2.5.3  │ org.ops4j.pax.url.reference
>> 60 │ Active   │   5 │ 2.5.2  │ org.ops4j.pax.url.wrap
>> 
>> But when in my test I try to use the protocol like this:
>> 
>> Option[] options = new Option[] {
>>  systemProperty("pax.exam.osgi.unresolved.fail").value("true"),
>>  features(testUtils.getStandardRepo(), "aries-blueprint"),
>>  features(testUtils.getStandardRepo(), "http"),
>>  features(testUtils.getStandardRepo(), "http-whiteboard"),
>>  bundle("reference:file:target/classes/")
>> };
>> 
>> I get quite a strange error:
>> 
>> org.apache.karaf.features.internal.util.MultiException: Error:
>> 
>> /Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/exam/424a9312-bd8e-4ef9-8e62-e768b5b11cdf/data/tmp
>> (Is a directory)
>>  at
>> org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader.(MavenDownloadManager.java:84)
>> ~[?:?]
>>  at
>> org.apache.karaf.features.internal.download.impl.MavenDownloadManager.createDownloader(MavenDownloadManager.java:72)
>> ~[?:?]
>>  at
>> org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:375)
>> ~[?:?]
>>  at
>> org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:372)
>> ~[?:?]
>>  at
>> org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:187)
>> ~[?:?]
>>  at
>> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:291)
>> ~[?:?]
>>  at
>> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1233)
>> ~[?:?]
>>  at
>> org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$0(FeaturesServiceImpl.java:1132)
>> ~[?:?]
>>  at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
>>  at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>> [?:?]
>>  at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>> [?:?]
>>  at java.lang.Thread.run(Thread.java:748) [?:?]
>>  Suppressed: java.io.FileNotFoundException:
>> /Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/exam/424a9312-bd8e-4ef9-8e62-e768b5b11cdf/data/tmp
>> (Is a directory)
>>  at java.io.FileInputStream.open0(Native Method) ~[?:?]
>>  at java.io.FileInputStream.open(FileInputStream.java:195) [?:?]
>>  at java.io.FileInputStream.(FileInputStream.java:138) 
>> [?:?]
>>  at
>> org.apache.karaf.features.internal.download.impl.AbstractDownloadTask.open(AbstractDownloadTask.java:54)
>> [18:org.apache.karaf.features.core:4.1.2]
>>  at
>> org.apache.karaf.features.internal.region.Subsystem.getMetadata(Subsystem.java:535)
>> [18:org.apache.karaf.features.core:4.1.2]
>>  at
>> org.apache.karaf.features.internal.region.Subsystem$1.downloaded(Subsystem.java:402)
>> [18:org.apache.karaf.features.core:4.1.2]
>>  at
>> org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader$1.operationComplete(MavenDownloadManager.java:133)
>> [18:org.apache.karaf.features.core:4.1.2]
>>  at
>> org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader$1.operationComplete(MavenDownloadManager.java:127)
>> [18:org.apache.karaf.features.core:4.1.2]
>>  at
>> org.apache.karaf.features.internal.download.impl.DefaultFuture.notifyListener(DefaultFuture.java:350)
>> [18:org.apache.karaf.features.core:4.1.2]
>>  at
>> org.apache.karaf.features.int

Re: Enable reference: protocol in Karaf

[Francois Papon]

Does it work's without bundle("...") ?


Le 09/07/2018 à 14:09, Matteo Rulli a écrit :
> I’m using the Karaf version 4.1.2 and the test is running on MAC-OS.
>
>> On 9 Jul 2018, at 12:07, Francois Papon > > wrote:
>>
>> Which version of Karaf are you using ?
>>
>> regards
>>
>> François
>>
>>
>> Le 09/07/2018 à 14:05, matteor a écrit :
>>> Sorry. It seems that message formatting in nabble does not work very
>>> well...
>>> Here is the message with all the details:
>>>
>>> I tried to enable the reference protocol in Karaf adding these
>>> bundles to
>>> the startup.properties:
>>>
>>> mvn\:org.ops4j.base/ops4j-base-lang/1.5.0 = 11
>>> mvn\:org.ops4j.base/ops4j-base-util-property/1.5.0 = 11
>>> mvn\:org.ops4j.pax.swissbox/pax-swissbox-property/1.8.3 = 11
>>> mvn\:org.ops4j.pax.url/pax-url-commons/2.5.3 = 11
>>> mvn\:org.ops4j.pax.url/pax-url-reference/2.5.3 = 12
>>>
>>> And in fact now I can see the installed bundles in my runtime:
>>>
>>> list -t 0 -s | grep pax
>>> 4 │ Active   │   5 │ 2.5.2  │ org.ops4j.pax.url.mvn
>>> 5 │ Active   │   8 │ 1.10.1 │
>>> org.ops4j.pax.logging.pax-logging-api
>>> 6 │ Active   │   8 │ 1.10.1 │
>>> org.ops4j.pax.logging.pax-logging-log4j2
>>> 15 │ Active   │  11 │ 1.8.3  │
>>> org.ops4j.pax.swissbox.property
>>> 16 │ Active   │  11 │ 2.5.3  │ org.ops4j.pax.url.commons
>>> 17 │ Active   │  12 │ 2.5.3  │ org.ops4j.pax.url.reference
>>> 60 │ Active   │   5 │ 2.5.2  │ org.ops4j.pax.url.wrap
>>>
>>> But when in my test I try to use the protocol like this:
>>>
>>> Option[] options = new Option[] {
>>> systemProperty("pax.exam.osgi.unresolved.fail").value("true"),
>>> features(testUtils.getStandardRepo(), "aries-blueprint"),
>>> features(testUtils.getStandardRepo(), "http"),
>>> features(testUtils.getStandardRepo(), "http-whiteboard"),
>>> bundle("reference:file:target/classes/")
>>> };
>>>
>>> I get quite a strange error:
>>>
>>> org.apache.karaf.features.internal.util.MultiException: Error:
>>>
>>> /Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/exam/424a9312-bd8e-4ef9-8e62-e768b5b11cdf/data/tmp
>>> (Is a directory)
>>> at
>>> org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader.(MavenDownloadManager.java:84)
>>> ~[?:?]
>>> at
>>> org.apache.karaf.features.internal.download.impl.MavenDownloadManager.createDownloader(MavenDownloadManager.java:72)
>>> ~[?:?]
>>> at
>>> org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:375)
>>> ~[?:?]
>>> at
>>> org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:372)
>>> ~[?:?]
>>> at
>>> org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:187)
>>> ~[?:?]
>>> at
>>> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:291)
>>> ~[?:?]
>>> at
>>> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1233)
>>> ~[?:?]
>>> at
>>> org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$0(FeaturesServiceImpl.java:1132)
>>> ~[?:?]
>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
>>> at
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>> [?:?]
>>> at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>> [?:?]
>>> at java.lang.Thread.run(Thread.java:748) [?:?]
>>> Suppressed: java.io.FileNotFoundException:
>>> /Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/exam/424a9312-bd8e-4ef9-8e62-e768b5b11cdf/data/tmp
>>> (Is a directory)
>>> at java.io.FileInputStream.open0(Native Method) ~[?:?]
>>> at java.io.FileInputStream.open(FileInputStream.java:195) [?:?]
>>> at java.io.FileInputStream.(FileInputStream.java:138) [?:?]
>>> at
>>> org.apache.karaf.features.internal.download.impl.AbstractDownloadTask.open(AbstractDownloadTask.java:54)
>>> [18:org.apache.karaf.features.core:4.1.2]
>>> at
>>> org.apache.karaf.features.internal.region.Subsystem.getMetadata(Subsystem.java:535)
>>> [18:org.apache.karaf.features.core:4.1.2]
>>> at
>>> org.apache.karaf.features.internal.region.Subsystem$1.downloaded(Subsystem.java:402)
>>> [18:org.apache.karaf.features.core:4.1.2]
>>> at
>>> org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader$1.operationComplete(MavenDownloadManager.java:133)
>>> [18:org.apache.karaf.features.core:4.1.2]
>>> at
>>> org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader$1.operationComplete(MavenDownloadManager.java:127)
>>> [18:org.apache.karaf.features.core:4.1.2]
>>> at
>>> org.apache.karaf.features.internal.download.impl.DefaultFuture.notifyListener(DefaultFuture.java:350)
>>> [18:org.apache.karaf.features.core:4.1.2]
>>> at
>>> org.apache.karaf.features.internal.download.impl.Default

Re: Enable reference: protocol in Karaf

[Matteo Rulli]

Yes. If I remove the bundle(“reference:….”) line in the test ops and I manually 
do

install 
reference:file:/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/classes/
Bundle ID: 131
flairbit@root()> start 131

Everything works just fine.

Matteo


> On 9 Jul 2018, at 12:24, Francois Papon  wrote:
> 
> Does it work's without bundle("...") ?
> 
> 
> Le 09/07/2018 à 14:09, Matteo Rulli a écrit :
>> I’m using the Karaf version 4.1.2 and the test is running on MAC-OS.
>> 
>>> On 9 Jul 2018, at 12:07, Francois Papon >> > wrote:
>>> 
>>> Which version of Karaf are you using ?
>>> 
>>> regards
>>> 
>>> François
>>> 
>>> 
>>> Le 09/07/2018 à 14:05, matteor a écrit :
 Sorry. It seems that message formatting in nabble does not work very 
 well...
 Here is the message with all the details:
 
 I tried to enable the reference protocol in Karaf adding these bundles to
 the startup.properties:
 
 mvn\:org.ops4j.base/ops4j-base-lang/1.5.0 = 11
 mvn\:org.ops4j.base/ops4j-base-util-property/1.5.0 = 11
 mvn\:org.ops4j.pax.swissbox/pax-swissbox-property/1.8.3 = 11
 mvn\:org.ops4j.pax.url/pax-url-commons/2.5.3 = 11
 mvn\:org.ops4j.pax.url/pax-url-reference/2.5.3 = 12
 
 And in fact now I can see the installed bundles in my runtime:
 
 list -t 0 -s | grep pax
 4 │ Active   │   5 │ 2.5.2  │ org.ops4j.pax.url.mvn
 5 │ Active   │   8 │ 1.10.1 │
 org.ops4j.pax.logging.pax-logging-api
 6 │ Active   │   8 │ 1.10.1 │
 org.ops4j.pax.logging.pax-logging-log4j2
 15 │ Active   │  11 │ 1.8.3  │ org.ops4j.pax.swissbox.property
 16 │ Active   │  11 │ 2.5.3  │ org.ops4j.pax.url.commons
 17 │ Active   │  12 │ 2.5.3  │ org.ops4j.pax.url.reference
 60 │ Active   │   5 │ 2.5.2  │ org.ops4j.pax.url.wrap
 
 But when in my test I try to use the protocol like this:
 
 Option[] options = new Option[] {
systemProperty("pax.exam.osgi.unresolved.fail").value("true"),
features(testUtils.getStandardRepo(), "aries-blueprint"),
features(testUtils.getStandardRepo(), "http"),
features(testUtils.getStandardRepo(), "http-whiteboard"),
bundle("reference:file:target/classes/ 
 ")
 };
 
 I get quite a strange error:
 
 org.apache.karaf.features.internal.util.MultiException: Error:
 
 /Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/exam/424a9312-bd8e-4ef9-8e62-e768b5b11cdf/data/tmp
 (Is a directory)
at
 org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader.(MavenDownloadManager.java:84)
 ~[?:?]
at
 org.apache.karaf.features.internal.download.impl.MavenDownloadManager.createDownloader(MavenDownloadManager.java:72)
 ~[?:?]
at
 org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:375)
 ~[?:?]
at
 org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:372)
 ~[?:?]
at
 org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:187)
 ~[?:?]
at
 org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:291)
 ~[?:?]
at
 org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1233)
 ~[?:?]
at
 org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$0(FeaturesServiceImpl.java:1132)
 ~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
 [?:?]
at
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
 [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
Suppressed: java.io.FileNotFoundException:
 /Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/exam/424a9312-bd8e-4ef9-8e62-e768b5b11cdf/data/tmp
 (Is a directory)
at java.io.FileInputStream.open0(Native Method) ~[?:?]
at java.io.FileInputStream.open(FileInputStream.java:195) [?:?]
at java.io.FileInputStream.(FileInputStream.java:138) 
 [?:?]
at
 org.apache.karaf.features.internal.download.impl.AbstractDownloadTask.open(AbstractDownloadTask.java:54)
 [18:org.apache.karaf.features.core:4.1.2]
at
 org.apache.karaf.features.internal.region.Subsystem.getMetadata(Subsystem.java:535)
 [18:org.apache.karaf.features.core:4.1.2]
at
 org.apache.karaf.features.internal.region.Subsystem$1.downloaded(Subsystem.java:402)
 [18:org.apache.karaf.features.c

Re: Enable reference: protocol in Karaf

[Francois Papon]

Ok, but I see in your code :

bundle("reference:file:target/classes/")

Could you try with the full path of the repository ?


Le 09/07/2018 à 14:50, Matteo Rulli a écrit :
> Yes. If I remove the bundle(“reference:….”) line in the test ops and I
> manually do
>
> installreference:file:/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/classes/
> Bundle ID: 131
> *flairbit*@root()> start131
>
> Everything works just fine.
>
> Matteo
>
>
>> On 9 Jul 2018, at 12:24, Francois Papon > > wrote:
>>
>> Does it work's without bundle("...") ?
>>
>>
>> Le 09/07/2018 à 14:09, Matteo Rulli a écrit :
>>> I’m using the Karaf version 4.1.2 and the test is running on MAC-OS.
>>>
 On 9 Jul 2018, at 12:07, Francois Papon
 >>> > wrote:

 Which version of Karaf are you using ?

 regards

 François


 Le 09/07/2018 à 14:05, matteor a écrit :
> Sorry. It seems that message formatting in nabble does not work
> very well...
> Here is the message with all the details:
>
> I tried to enable the reference protocol in Karaf adding these
> bundles to
> the startup.properties:
>
> mvn\:org.ops4j.base/ops4j-base-lang/1.5.0 = 11
> mvn\:org.ops4j.base/ops4j-base-util-property/1.5.0 = 11
> mvn\:org.ops4j.pax.swissbox/pax-swissbox-property/1.8.3 = 11
> mvn\:org.ops4j.pax.url/pax-url-commons/2.5.3 = 11
> mvn\:org.ops4j.pax.url/pax-url-reference/2.5.3 = 12
>
> And in fact now I can see the installed bundles in my runtime:
>
> list -t 0 -s | grep pax
> 4 │ Active   │   5 │ 2.5.2  │ org.ops4j.pax.url.mvn
> 5 │ Active   │   8 │ 1.10.1 │
> org.ops4j.pax.logging.pax-logging-api
> 6 │ Active   │   8 │ 1.10.1 │
> org.ops4j.pax.logging.pax-logging-log4j2
> 15 │ Active   │  11 │ 1.8.3  │
> org.ops4j.pax.swissbox.property
> 16 │ Active   │  11 │ 2.5.3  │ org.ops4j.pax.url.commons
> 17 │ Active   │  12 │ 2.5.3  │ org.ops4j.pax.url.reference
> 60 │ Active   │   5 │ 2.5.2  │ org.ops4j.pax.url.wrap
>
> But when in my test I try to use the protocol like this:
>
> Option[] options = new Option[] {
> systemProperty("pax.exam.osgi.unresolved.fail").value("true"),
> features(testUtils.getStandardRepo(), "aries-blueprint"),
> features(testUtils.getStandardRepo(), "http"),
> features(testUtils.getStandardRepo(), "http-whiteboard"),
> bundle("reference:file:target/classes/")
> };
>
> I get quite a strange error:
>
> org.apache.karaf.features.internal.util.MultiException: Error:
>
> /Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/exam/424a9312-bd8e-4ef9-8e62-e768b5b11cdf/data/tmp
> (Is a directory)
> at
> org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader.(MavenDownloadManager.java:84)
> ~[?:?]
> at
> org.apache.karaf.features.internal.download.impl.MavenDownloadManager.createDownloader(MavenDownloadManager.java:72)
> ~[?:?]
> at
> org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:375)
> ~[?:?]
> at
> org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:372)
> ~[?:?]
> at
> org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:187)
> ~[?:?]
> at
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:291)
> ~[?:?]
> at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1233)
> ~[?:?]
> at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$0(FeaturesServiceImpl.java:1132)
> ~[?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [?:?]
> at java.lang.Thread.run(Thread.java:748) [?:?]
> Suppressed: java.io.FileNotFoundException:
> /Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/exam/424a9312-bd8e-4ef9-8e62-e768b5b11cdf/data/tmp
> (Is a directory)
> at java.io.FileInputStream.open0(Native Method) ~[?:?]
> at java.io.FileInputStream.open(FileInputStream.java:195) [?:?]
> at java.io.FileInputStream.(FileInputStream.java:138) [?:?]
> at
> org.apache.karaf.features.internal.download.impl.AbstractDownloadTask.open(AbstractDownloadTask.java:54)
> [18:org.apache.karaf.features.core:4.1.2]
> at
> org.apache.karaf.features.internal.region.Subsystem.getMetadata(Subsystem.java:535)
> [18:org.apache.k

Re: Enable reference: protocol in Karaf

[Matteo Rulli]

If I set

bundle("reference:file:/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/classes/“),

In the test opts (i.e. the absolute path of target folder) I get the same 
exception reported in the previous email (the data/tmp (Is a directory) one).

Matteo

> On 9 Jul 2018, at 12:52, Francois Papon  wrote:
> 
> Ok, but I see in your code :
> 
> bundle("reference:file:target/classes/ <>")
> 
> Could you try with the full path of the repository ?
> 
> Le 09/07/2018 à 14:50, Matteo Rulli a écrit :
>> Yes. If I remove the bundle(“reference:….”) line in the test ops and I 
>> manually do
>> 
>> install 
>> reference:file:/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/classes/
>>  
>> 
>> Bundle ID: 131
>> flairbit@root()> start 131
>> 
>> Everything works just fine.
>> 
>> Matteo
>> 
>> 
>>> On 9 Jul 2018, at 12:24, Francois Papon >> > wrote:
>>> 
>>> Does it work's without bundle("...") ?
>>> 
>>> 
>>> Le 09/07/2018 à 14:09, Matteo Rulli a écrit :
 I’m using the Karaf version 4.1.2 and the test is running on MAC-OS.
 
> On 9 Jul 2018, at 12:07, Francois Papon  > wrote:
> 
> Which version of Karaf are you using ?
> 
> regards
> 
> François
> 
> 
> Le 09/07/2018 à 14:05, matteor a écrit :
>> Sorry. It seems that message formatting in nabble does not work very 
>> well...
>> Here is the message with all the details:
>> 
>> I tried to enable the reference protocol in Karaf adding these bundles to
>> the startup.properties:
>> 
>> mvn\:org.ops4j.base/ops4j-base-lang/1.5.0 = 11
>> mvn\:org.ops4j.base/ops4j-base-util-property/1.5.0 = 11
>> mvn\:org.ops4j.pax.swissbox/pax-swissbox-property/1.8.3 = 11
>> mvn\:org.ops4j.pax.url/pax-url-commons/2.5.3 = 11
>> mvn\:org.ops4j.pax.url/pax-url-reference/2.5.3 = 12
>> 
>> And in fact now I can see the installed bundles in my runtime:
>> 
>> list -t 0 -s | grep pax
>> 4 │ Active   │   5 │ 2.5.2  │ org.ops4j.pax.url.mvn
>> 5 │ Active   │   8 │ 1.10.1 │
>> org.ops4j.pax.logging.pax-logging-api
>> 6 │ Active   │   8 │ 1.10.1 │
>> org.ops4j.pax.logging.pax-logging-log4j2
>> 15 │ Active   │  11 │ 1.8.3  │ 
>> org.ops4j.pax.swissbox.property
>> 16 │ Active   │  11 │ 2.5.3  │ org.ops4j.pax.url.commons
>> 17 │ Active   │  12 │ 2.5.3  │ org.ops4j.pax.url.reference
>> 60 │ Active   │   5 │ 2.5.2  │ org.ops4j.pax.url.wrap
>> 
>> But when in my test I try to use the protocol like this:
>> 
>> Option[] options = new Option[] {
>>  systemProperty("pax.exam.osgi.unresolved.fail").value("true"),
>>  features(testUtils.getStandardRepo(), "aries-blueprint"),
>>  features(testUtils.getStandardRepo(), "http"),
>>  features(testUtils.getStandardRepo(), "http-whiteboard"),
>>  bundle("reference:file:target/classes/ 
>> ")
>> };
>> 
>> I get quite a strange error:
>> 
>> org.apache.karaf.features.internal.util.MultiException: Error:
>> 
>> /Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/exam/424a9312-bd8e-4ef9-8e62-e768b5b11cdf/data/tmp
>> (Is a directory)
>>  at
>> org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader.(MavenDownloadManager.java:84)
>> ~[?:?]
>>  at
>> org.apache.karaf.features.internal.download.impl.MavenDownloadManager.createDownloader(MavenDownloadManager.java:72)
>> ~[?:?]
>>  at
>> org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:375)
>> ~[?:?]
>>  at
>> org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:372)
>> ~[?:?]
>>  at
>> org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:187)
>> ~[?:?]
>>  at
>> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:291)
>> ~[?:?]
>>  at
>> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1233)
>> ~[?:?]
>>  at
>> org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$0(FeaturesServiceImpl.java:1132)
>> ~[?:?]
>>  at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
>>  at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>> [?:?]
>>  at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>> [?:?]
>>  at java.lang.Thread.run(Thread.java:748) [?:?]
>>  Suppressed: java.io.FileNotFoundException:
>> /Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/targ

Re: Enable reference: protocol in Karaf

[Jean-Baptiste Onofré]

Hi Matteo,

it seems you are using in Pax Exam. Do you use your custom dispo in Pax
Exam ? I suspect that you use the standard Karaf distribution coming
with Pax Exam, so you will need to install pax-url-reference in
@Configuration of your test.

Regards
JB

On 09/07/2018 13:00, Matteo Rulli wrote:
> If I set
> 
> bundle("reference:file:/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/classes/“),
> 
> In the test opts (i.e. the absolute path of target folder) I get the
> same exception reported in the previous email (the data/tmp (Is a
> directory) one).
> 
> Matteo
> 
>> On 9 Jul 2018, at 12:52, Francois Papon > > wrote:
>>
>> Ok, but I see in your code :
>>
>> bundle("reference:file:target/classes/")
>>
>> Could you try with the full path of the repository ?
>>
>>
>> Le 09/07/2018 à 14:50, Matteo Rulli a écrit :
>>> Yes. If I remove the bundle(“reference:….”) line in the test ops and
>>> I manually do
>>>
>>> installreference:file:/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/classes/
>>> Bundle ID: 131
>>> *flairbit*@root()> start131
>>>
>>> Everything works just fine.
>>>
>>> Matteo
>>>
>>>
 On 9 Jul 2018, at 12:24, Francois Papon
 mailto:francois.pa...@openobject.fr>>
 wrote:

 Does it work's without bundle("...") ?


 Le 09/07/2018 à 14:09, Matteo Rulli a écrit :
> I’m using the Karaf version 4.1.2 and the test is running on MAC-OS.
>
>> On 9 Jul 2018, at 12:07, Francois Papon
>> > > wrote:
>>
>> Which version of Karaf are you using ?
>>
>> regards
>>
>> François
>>
>>
>> Le 09/07/2018 à 14:05, matteor a écrit :
>>> Sorry. It seems that message formatting in nabble does not work
>>> very well...
>>> Here is the message with all the details:
>>>
>>> I tried to enable the reference protocol in Karaf adding these
>>> bundles to
>>> the startup.properties:
>>>
>>> mvn\:org.ops4j.base/ops4j-base-lang/1.5.0 = 11
>>> mvn\:org.ops4j.base/ops4j-base-util-property/1.5.0 = 11
>>> mvn\:org.ops4j.pax.swissbox/pax-swissbox-property/1.8.3 = 11
>>> mvn\:org.ops4j.pax.url/pax-url-commons/2.5.3 = 11
>>> mvn\:org.ops4j.pax.url/pax-url-reference/2.5.3 = 12
>>>
>>> And in fact now I can see the installed bundles in my runtime:
>>>
>>> list -t 0 -s | grep pax
>>> 4 │ Active   │   5 │ 2.5.2  │ org.ops4j.pax.url.mvn
>>> 5 │ Active   │   8 │ 1.10.1 │
>>> org.ops4j.pax.logging.pax-logging-api
>>> 6 │ Active   │   8 │ 1.10.1 │
>>> org.ops4j.pax.logging.pax-logging-log4j2
>>> 15 │ Active   │  11 │ 1.8.3  │
>>> org.ops4j.pax.swissbox.property
>>> 16 │ Active   │  11 │ 2.5.3  │ org.ops4j.pax.url.commons
>>> 17 │ Active   │  12 │ 2.5.3  │
>>> org.ops4j.pax.url.reference
>>> 60 │ Active   │   5 │ 2.5.2  │ org.ops4j.pax.url.wrap
>>>
>>> But when in my test I try to use the protocol like this:
>>>
>>> Option[] options = new Option[] {
>>> systemProperty("pax.exam.osgi.unresolved.fail").value("true"),
>>> features(testUtils.getStandardRepo(), "aries-blueprint"),
>>> features(testUtils.getStandardRepo(), "http"),
>>> features(testUtils.getStandardRepo(), "http-whiteboard"),
>>> bundle("reference:file:target/classes/")
>>> };
>>>
>>> I get quite a strange error:
>>>
>>> org.apache.karaf.features.internal.util.MultiException: Error:
>>>
>>> /Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/exam/424a9312-bd8e-4ef9-8e62-e768b5b11cdf/data/tmp
>>> (Is a directory)
>>> at
>>> org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader.(MavenDownloadManager.java:84)
>>> ~[?:?]
>>> at
>>> org.apache.karaf.features.internal.download.impl.MavenDownloadManager.createDownloader(MavenDownloadManager.java:72)
>>> ~[?:?]
>>> at
>>> org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:375)
>>> ~[?:?]
>>> at
>>> org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:372)
>>> ~[?:?]
>>> at
>>> org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:187)
>>> ~[?:?]
>>> at
>>> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:291)
>>> ~[?:?]
>>> at
>>> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1233)
>>> ~[?:?]
>>> at
>>> org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$0(FeaturesServiceImpl.java:1132)
>>> ~[?:?]
>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
>>> at
>>> java.

Re: Enable reference: protocol in Karaf

[Matteo Rulli]

Hi,
I’m using a custom Karaf distro where I modify the framework feature in order 
to include the pax-url-reference bundles in the startup.properties through the 
karaf-maven-plugin. 

Apparently, the pax-url-reference bundles are installed correctly and they work 
because if I start the test, I do ssh into the running karaf and execute the 

flairbit@root()> install 
reference:file:/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/classes/
Bundle ID: 131

the command works fine. Despite this, when I try to install the exploded bundle 
with the 

bundle("reference:file:target/classes/“)

option, I get the reported error, both using the absolute and relative path for 
target folder.

Thank you,
Matteo


> On 9 Jul 2018, at 13:39, Jean-Baptiste Onofré  wrote:
> 
> Hi Matteo,
> 
> it seems you are using in Pax Exam. Do you use your custom dispo in Pax
> Exam ? I suspect that you use the standard Karaf distribution coming
> with Pax Exam, so you will need to install pax-url-reference in
> @Configuration of your test.
> 
> Regards
> JB
> 
> On 09/07/2018 13:00, Matteo Rulli wrote:
>> If I set
>> 
>> bundle("reference:file:/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/classes/“),
>> 
>> In the test opts (i.e. the absolute path of target folder) I get the
>> same exception reported in the previous email (the data/tmp (Is a
>> directory) one).
>> 
>> Matteo
>> 
>>> On 9 Jul 2018, at 12:52, Francois Papon >> 
>>> >> >> wrote:
>>> 
>>> Ok, but I see in your code :
>>> 
>>> bundle("reference:file:target/classes/")
>>> 
>>> Could you try with the full path of the repository ?
>>> 
>>> 
>>> Le 09/07/2018 à 14:50, Matteo Rulli a écrit :
 Yes. If I remove the bundle(“reference:….”) line in the test ops and
 I manually do
 
 installreference:file:/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/classes/
 Bundle ID: 131
 *flairbit*@root()> start131
 
 Everything works just fine.
 
 Matteo
 
 
> On 9 Jul 2018, at 12:24, Francois Papon
> mailto:francois.pa...@openobject.fr> 
>  >>
> wrote:
> 
> Does it work's without bundle("...") ?
> 
> 
> Le 09/07/2018 à 14:09, Matteo Rulli a écrit :
>> I’m using the Karaf version 4.1.2 and the test is running on MAC-OS.
>> 
>>> On 9 Jul 2018, at 12:07, Francois Papon
>>> mailto:francois.pa...@openobject.fr>
>>> >> >> wrote:
>>> 
>>> Which version of Karaf are you using ?
>>> 
>>> regards
>>> 
>>> François
>>> 
>>> 
>>> Le 09/07/2018 à 14:05, matteor a écrit :
 Sorry. It seems that message formatting in nabble does not work
 very well...
 Here is the message with all the details:
 
 I tried to enable the reference protocol in Karaf adding these
 bundles to
 the startup.properties:
 
 mvn\:org.ops4j.base/ops4j-base-lang/1.5.0 = 11
 mvn\:org.ops4j.base/ops4j-base-util-property/1.5.0 = 11
 mvn\:org.ops4j.pax.swissbox/pax-swissbox-property/1.8.3 = 11
 mvn\:org.ops4j.pax.url/pax-url-commons/2.5.3 = 11
 mvn\:org.ops4j.pax.url/pax-url-reference/2.5.3 = 12
 
 And in fact now I can see the installed bundles in my runtime:
 
 list -t 0 -s | grep pax
 4 │ Active   │   5 │ 2.5.2  │ org.ops4j.pax.url.mvn
 5 │ Active   │   8 │ 1.10.1 │
 org.ops4j.pax.logging.pax-logging-api
 6 │ Active   │   8 │ 1.10.1 │
 org.ops4j.pax.logging.pax-logging-log4j2
 15 │ Active   │  11 │ 1.8.3  │
 org.ops4j.pax.swissbox.property
 16 │ Active   │  11 │ 2.5.3  │ org.ops4j.pax.url.commons
 17 │ Active   │  12 │ 2.5.3  │
 org.ops4j.pax.url.reference
 60 │ Active   │   5 │ 2.5.2  │ org.ops4j.pax.url.wrap
 
 But when in my test I try to use the protocol like this:
 
 Option[] options = new Option[] {
 systemProperty("pax.exam.osgi.unresolved.fail").value("true"),
 features(testUtils.getStandardRepo(), "aries-blueprint"),
 features(testUtils.getStandardRepo(), "http"),
 features(testUtils.getStandardRepo(), "http-whiteboard"),
 bundle("reference:file:target/classes/")
 };
 
 I get quite a strange error:
 
 org.apache.karaf.features.internal.util.MultiException: Error:
 
 /Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/exam/424a9312-bd8e-4ef9-8e62-e768b5b11cdf/data/

Re: Enable reference: protocol in Karaf

[Matteo Rulli]

And the reference protocol works also if I install the exploded bundle from the 
test method with:

@Test
public void testCase() throws Exception {
assertNotNull(bcontext);

bcontext.installBundle("reference:file:/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/classes/").start();
Thread.sleep(Long.MAX_VALUE);
}

So the only way it gives problem is with the bundle() option. Isn’t this 
strange? Could it be a timing/race problem? Or a missing pax-exam configuration?

Matteo

> On 9 Jul 2018, at 14:20, Matteo Rulli  wrote:
> 
> Hi,
> I’m using a custom Karaf distro where I modify the framework feature in order 
> to include the pax-url-reference bundles in the startup.properties through 
> the karaf-maven-plugin. 
> 
> Apparently, the pax-url-reference bundles are installed correctly and they 
> work because if I start the test, I do ssh into the running karaf and execute 
> the 
> 
> flairbit@root()> install 
> reference:file:/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/classes/
> Bundle ID: 131
> 
> the command works fine. Despite this, when I try to install the exploded 
> bundle with the 
> 
> bundle("reference:file:target/classes/“)
> 
> option, I get the reported error, both using the absolute and relative path 
> for target folder.
> 
> Thank you,
> Matteo
> 
> 
>> On 9 Jul 2018, at 13:39, Jean-Baptiste Onofré > > wrote:
>> 
>> Hi Matteo,
>> 
>> it seems you are using in Pax Exam. Do you use your custom dispo in Pax
>> Exam ? I suspect that you use the standard Karaf distribution coming
>> with Pax Exam, so you will need to install pax-url-reference in
>> @Configuration of your test.
>> 
>> Regards
>> JB
>> 
>> On 09/07/2018 13:00, Matteo Rulli wrote:
>>> If I set
>>> 
>>> bundle("reference:file:/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/classes/“),
>>> 
>>> In the test opts (i.e. the absolute path of target folder) I get the
>>> same exception reported in the previous email (the data/tmp (Is a
>>> directory) one).
>>> 
>>> Matteo
>>> 
 On 9 Jul 2018, at 12:52, Francois Papon >>> 
 >> wrote:
 
 Ok, but I see in your code :
 
 bundle("reference:file:target/classes/")
 
 Could you try with the full path of the repository ?
 
 
 Le 09/07/2018 à 14:50, Matteo Rulli a écrit :
> Yes. If I remove the bundle(“reference:….”) line in the test ops and
> I manually do
> 
> installreference:file:/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/classes/
> Bundle ID: 131
> *flairbit*@root()> start131
> 
> Everything works just fine.
> 
> Matteo
> 
> 
>> On 9 Jul 2018, at 12:24, Francois Papon
>> mailto:francois.pa...@openobject.fr> 
>> > >>
>> wrote:
>> 
>> Does it work's without bundle("...") ?
>> 
>> 
>> Le 09/07/2018 à 14:09, Matteo Rulli a écrit :
>>> I’m using the Karaf version 4.1.2 and the test is running on MAC-OS.
>>> 
 On 9 Jul 2018, at 12:07, Francois Papon
 mailto:francois.pa...@openobject.fr>
 >> wrote:
 
 Which version of Karaf are you using ?
 
 regards
 
 François
 
 
 Le 09/07/2018 à 14:05, matteor a écrit :
> Sorry. It seems that message formatting in nabble does not work
> very well...
> Here is the message with all the details:
> 
> I tried to enable the reference protocol in Karaf adding these
> bundles to
> the startup.properties:
> 
> mvn\:org.ops4j.base/ops4j-base-lang/1.5.0 = 11
> mvn\:org.ops4j.base/ops4j-base-util-property/1.5.0 = 11
> mvn\:org.ops4j.pax.swissbox/pax-swissbox-property/1.8.3 = 11
> mvn\:org.ops4j.pax.url/pax-url-commons/2.5.3 = 11
> mvn\:org.ops4j.pax.url/pax-url-reference/2.5.3 = 12
> 
> And in fact now I can see the installed bundles in my runtime:
> 
> list -t 0 -s | grep pax
> 4 │ Active   │   5 │ 2.5.2  │ org.ops4j.pax.url.mvn
> 5 │ Active   │   8 │ 1.10.1 │
> org.ops4j.pax.logging.pax-logging-api
> 6 │ Active   │   8 │ 1.10.1 │
> org.ops4j.pax.logging.pax-logging-log4j2
> 15 │ Active   │  11 │ 1.8.3  │
> org.ops4j.pax.swissbox.property
> 16 │ Active   │  11 │ 2.5.3  │ org.ops4j.pax.url.commons
> 17 │ Active   │  12 │ 2.5.3  │
> org.ops4j.pax.url.reference
> 60 │ Active   │   5 │ 2.5.2  

Re: Enable reference: protocol in Karaf

[Jean-Baptiste Onofré]

bundle() method comes from the PaxExam probe. A possible issue is that
PaxExam probe doesn't have the DynamicImport-Package and so it doesn't
use the URL.

Can you please create a Jira at OPS4J PaxExam ? I will take a look.

In the mean time, using the bundle context as workaround is fine.

Regards
JB

On 09/07/2018 14:32, Matteo Rulli wrote:
> And the reference protocol works also if I install the exploded bundle
> from the test method with:
> 
> @Test
> *public* *void* testCase() *throws* Exception {
> /assertNotNull/(/bcontext/);
> /bcontext/.installBundle("reference:file:/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/classes/").start();
> Thread./sleep/(Long.*/MAX_VALUE/*);
> }
> 
> So the only way it gives problem is with the bundle() option. Isn’t this
> strange? Could it be a timing/race problem? Or a missing pax-exam
> configuration?
> 
> Matteo
> 
>> On 9 Jul 2018, at 14:20, Matteo Rulli > > wrote:
>>
>> Hi,
>> I’m using a custom Karaf distro where I modify the framework feature
>> in order to include the pax-url-reference bundles in the
>> startup.properties through the karaf-maven-plugin. 
>>
>> Apparently, the pax-url-reference bundles are installed correctly and
>> they work because if I start the test, I do ssh into the running karaf
>> and execute the 
>>
>> flairbit@root()>
>> install 
>> reference:file:/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/classes/
>> Bundle ID: 131
>>
>> the command works fine. Despite this, when I try to install the
>> exploded bundle with the 
>>
>> bundle("reference:file:target/classes/“)
>>
>> option, I get the reported error, both using the absolute and relative
>> path for target folder.
>>
>> Thank you,
>> Matteo
>>
>>
>>> On 9 Jul 2018, at 13:39, Jean-Baptiste Onofré >> > wrote:
>>>
>>> Hi Matteo,
>>>
>>> it seems you are using in Pax Exam. Do you use your custom dispo in Pax
>>> Exam ? I suspect that you use the standard Karaf distribution coming
>>> with Pax Exam, so you will need to install pax-url-reference in
>>> @Configuration of your test.
>>>
>>> Regards
>>> JB
>>>
>>> On 09/07/2018 13:00, Matteo Rulli wrote:
 If I set

 bundle("reference:file:/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/classes/“),

 In the test opts (i.e. the absolute path of target folder) I get the
 same exception reported in the previous email (the data/tmp (Is a
 directory) one).

 Matteo

> On 9 Jul 2018, at 12:52, Francois Papon
> mailto:francois.pa...@openobject.fr>
> > wrote:
>
> Ok, but I see in your code :
>
> bundle("reference:file:target/classes/")
>
> Could you try with the full path of the repository ?
>
>
> Le 09/07/2018 à 14:50, Matteo Rulli a écrit :
>> Yes. If I remove the bundle(“reference:….”) line in the test ops and
>> I manually do
>>
>> installreference:file:/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/classes/
>> Bundle ID: 131
>> *flairbit*@root()> start131
>>
>> Everything works just fine.
>>
>> Matteo
>>
>>
>>> On 9 Jul 2018, at 12:24, Francois Papon
>>> >>  
>>> >
>>> wrote:
>>>
>>> Does it work's without bundle("...") ?
>>>
>>>
>>> Le 09/07/2018 à 14:09, Matteo Rulli a écrit :
 I’m using the Karaf version 4.1.2 and the test is running on MAC-OS.

> On 9 Jul 2018, at 12:07, Francois Papon
> mailto:francois.pa...@openobject.fr>
> > wrote:
>
> Which version of Karaf are you using ?
>
> regards
>
> François
>
>
> Le 09/07/2018 à 14:05, matteor a écrit :
>> Sorry. It seems that message formatting in nabble does not work
>> very well...
>> Here is the message with all the details:
>>
>> I tried to enable the reference protocol in Karaf adding these
>> bundles to
>> the startup.properties:
>>
>> mvn\:org.ops4j.base/ops4j-base-lang/1.5.0 = 11
>> mvn\:org.ops4j.base/ops4j-base-util-property/1.5.0 = 11
>> mvn\:org.ops4j.pax.swissbox/pax-swissbox-property/1.8.3 = 11
>> mvn\:org.ops4j.pax.url/pax-url-commons/2.5.3 = 11
>> mvn\:org.ops4j.pax.url/pax-url-reference/2.5.3 = 12
>>
>> And in fact now I can see the installed bundles in my runtime:
>>
>> list -t 0 -s | grep pax
>> 4 │ Active   │   5 │ 2.5.2  │ org.ops4j.pax.url.mvn
>> 5 │ Active   │   8 │ 1.10.1 │
>> org.ops4j.pax.logging.pax-logging-api
>> 6 │ Active   │   8 │ 1.10.1 │
>>>

Re: Enable reference: protocol in Karaf

[Matteo Rulli]

Hello,
Thank you for your help. Apparently I cannot login or create an issue at the 
https://ops4j1.jira.com/  website. What is the right 
procedure to file a bug there?

By the way, I also tried adding the dynamic import to the probe with:

@ProbeBuilder 
public TestProbeBuilder probeConfiguration(TestProbeBuilder probe) {
probe.setHeader(Constants.DYNAMICIMPORT_PACKAGE, "*"); 
return probe;
}

but it didn’t help.

Thank you again,
Matteo

> On 9 Jul 2018, at 14:44, Jean-Baptiste Onofré  wrote:
> 
> bundle() method comes from the PaxExam probe. A possible issue is that
> PaxExam probe doesn't have the DynamicImport-Package and so it doesn't
> use the URL.
> 
> Can you please create a Jira at OPS4J PaxExam ? I will take a look.
> 
> In the mean time, using the bundle context as workaround is fine.
> 
> Regards
> JB
> 
> On 09/07/2018 14:32, Matteo Rulli wrote:
>> And the reference protocol works also if I install the exploded bundle
>> from the test method with:
>> 
>> @Test
>> *public* *void* testCase() *throws* Exception {
>> /assertNotNull/(/bcontext/);
>> /bcontext/.installBundle("reference:file:/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/classes/").start();
>> Thread./sleep/(Long.*/MAX_VALUE/*);
>> }
>> 
>> So the only way it gives problem is with the bundle() option. Isn’t this
>> strange? Could it be a timing/race problem? Or a missing pax-exam
>> configuration?
>> 
>> Matteo
>> 
>>> On 9 Jul 2018, at 14:20, Matteo Rulli >> 
>>> >> wrote:
>>> 
>>> Hi,
>>> I’m using a custom Karaf distro where I modify the framework feature
>>> in order to include the pax-url-reference bundles in the
>>> startup.properties through the karaf-maven-plugin. 
>>> 
>>> Apparently, the pax-url-reference bundles are installed correctly and
>>> they work because if I start the test, I do ssh into the running karaf
>>> and execute the 
>>> 
>>> flairbit@root()>
>>> install 
>>> reference:file:/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/classes/
>>> Bundle ID: 131
>>> 
>>> the command works fine. Despite this, when I try to install the
>>> exploded bundle with the 
>>> 
>>> bundle("reference:file:target/classes/“)
>>> 
>>> option, I get the reported error, both using the absolute and relative
>>> path for target folder.
>>> 
>>> Thank you,
>>> Matteo
>>> 
>>> 
 On 9 Jul 2018, at 13:39, Jean-Baptiste Onofré >>> 
 >> wrote:
 
 Hi Matteo,
 
 it seems you are using in Pax Exam. Do you use your custom dispo in Pax
 Exam ? I suspect that you use the standard Karaf distribution coming
 with Pax Exam, so you will need to install pax-url-reference in
 @Configuration of your test.
 
 Regards
 JB
 
 On 09/07/2018 13:00, Matteo Rulli wrote:
> If I set
> 
> bundle("reference:file:/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/classes/“),
> 
> In the test opts (i.e. the absolute path of target folder) I get the
> same exception reported in the previous email (the data/tmp (Is a
> directory) one).
> 
> Matteo
> 
>> On 9 Jul 2018, at 12:52, Francois Papon
>> mailto:francois.pa...@openobject.fr> 
>> > >
>> > >> wrote:
>> 
>> Ok, but I see in your code :
>> 
>> bundle("reference:file:target/classes/")
>> 
>> Could you try with the full path of the repository ?
>> 
>> 
>> Le 09/07/2018 à 14:50, Matteo Rulli a écrit :
>>> Yes. If I remove the bundle(“reference:….”) line in the test ops and
>>> I manually do
>>> 
>>> installreference:file:/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/classes/
>>> Bundle ID: 131
>>> *flairbit*@root()> start131
>>> 
>>> Everything works just fine.
>>> 
>>> Matteo
>>> 
>>> 
 On 9 Jul 2018, at 12:24, Francois Papon
 mailto:francois.pa...@openobject.fr>
 > 
 >>
 wrote:
 
 Does it work's without bundle("...") ?
 
 
 Le 09/07/2018 à 14:09, Matteo Rulli a écrit :
> I’m using the Karaf version 4.1.2 and the test is running on MAC-OS.
> 
>> On 9 Jul 2018, at 12:07, Francois Papon
>> mailto:francois.pa...@openobject.fr> 
>> > >
>> 

Re: Enable reference: protocol in Karaf

[Jean-Baptiste Onofré]

No problem, I will create the Jira based on your description.

Thanks
Regards
JB

On 09/07/2018 15:05, Matteo Rulli wrote:
> Hello,
> Thank you for your help. Apparently I cannot login or create an issue at
> the https://ops4j1.jira.com/ website. What is the right procedure to
> file a bug there?
> 
> By the way, I also tried adding the dynamic import to the probe with:
> 
> @ProbeBuilder 
> *public* TestProbeBuilder probeConfiguration(TestProbeBuilder probe) {
>     probe.setHeader(Constants.*/DYNAMICIMPORT_PACKAGE/*, "*"); 
>     *return* probe;
> }
> 
> but it didn’t help.
> 
> Thank you again,
> Matteo
> 
>> On 9 Jul 2018, at 14:44, Jean-Baptiste Onofré > > wrote:
>>
>> bundle() method comes from the PaxExam probe. A possible issue is that
>> PaxExam probe doesn't have the DynamicImport-Package and so it doesn't
>> use the URL.
>>
>> Can you please create a Jira at OPS4J PaxExam ? I will take a look.
>>
>> In the mean time, using the bundle context as workaround is fine.
>>
>> Regards
>> JB
>>
>> On 09/07/2018 14:32, Matteo Rulli wrote:
>>> And the reference protocol works also if I install the exploded bundle
>>> from the test method with:
>>>
>>> @Test
>>> *public* *void* testCase() *throws* Exception {
>>> /assertNotNull/(/bcontext/);
>>> /bcontext/.installBundle("reference:file:/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/classes/").start();
>>> Thread./sleep/(Long.*/MAX_VALUE/*);
>>> }
>>>
>>> So the only way it gives problem is with the bundle() option. Isn’t this
>>> strange? Could it be a timing/race problem? Or a missing pax-exam
>>> configuration?
>>>
>>> Matteo
>>>
 On 9 Jul 2018, at 14:20, Matteo Rulli >>> 
 > wrote:

 Hi,
 I’m using a custom Karaf distro where I modify the framework feature
 in order to include the pax-url-reference bundles in the
 startup.properties through the karaf-maven-plugin. 

 Apparently, the pax-url-reference bundles are installed correctly and
 they work because if I start the test, I do ssh into the running karaf
 and execute the 

 flairbit@root()>
 install 
 reference:file:/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/classes/
 Bundle ID: 131

 the command works fine. Despite this, when I try to install the
 exploded bundle with the 

 bundle("reference:file:target/classes/“)

 option, I get the reported error, both using the absolute and relative
 path for target folder.

 Thank you,
 Matteo


> On 9 Jul 2018, at 13:39, Jean-Baptiste Onofré  
> > wrote:
>
> Hi Matteo,
>
> it seems you are using in Pax Exam. Do you use your custom dispo in Pax
> Exam ? I suspect that you use the standard Karaf distribution coming
> with Pax Exam, so you will need to install pax-url-reference in
> @Configuration of your test.
>
> Regards
> JB
>
> On 09/07/2018 13:00, Matteo Rulli wrote:
>> If I set
>>
>> bundle("reference:file:/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/classes/“),
>>
>> In the test opts (i.e. the absolute path of target folder) I get the
>> same exception reported in the previous email (the data/tmp (Is a
>> directory) one).
>>
>> Matteo
>>
>>> On 9 Jul 2018, at 12:52, Francois Papon
>>> >>  
>>> 
>>> > wrote:
>>>
>>> Ok, but I see in your code :
>>>
>>> bundle("reference:file:target/classes/")
>>>
>>> Could you try with the full path of the repository ?
>>>
>>>
>>> Le 09/07/2018 à 14:50, Matteo Rulli a écrit :
 Yes. If I remove the bundle(“reference:….”) line in the test ops and
 I manually do

 installreference:file:/Users/username/git/contoso/iot/project-develop/support/project.sc.servlet/target/classes/
 Bundle ID: 131
 *flairbit*@root()> start131

 Everything works just fine.

 Matteo


> On 9 Jul 2018, at 12:24, Francois Papon
> mailto:francois.pa...@openobject.fr>
>  
> >
> wrote:
>
> Does it work's without bundle("...") ?
>
>
> Le 09/07/2018 à 14:09, Matteo Rulli a écrit :
>> I’m using the Karaf version 4.1.2 and the test is running on
>> MAC-OS.
>>
>>> On 9 Jul 2018, at 12:07, Francois Papon
>>> >>  
>>> 
>>> > w

Bundle resolve with range does not work on bundles in system repository

[Althaus, Volker]

Hello
I am facing a problem when resolving bundles with the mvn protocol and a range. 

Example feature.xml


  mvn:my.group/some.api/[5.2,6)


If the bundle resides in the local Karaf repository under "system", the bundle 
could not be resolved. "LATEST" also does not work, I will always have to 
specify a concrete version.
However, if it lies in the local .m2 Maven repository, it works! It think 
because the Maven repo is indexed properly with metadata and the system 
directory is not.

Unfortunately I need the range specification because the bundle is built and 
placed under "system" at customers site, with a minor version we don't exactly 
know before.

Any ideas how to solve this? Version is Karaf 4.0.4.


TIA & Regards
  Volker


CENIT AG, Industriestrasse 52-54, 70565 Stuttgart, Tel.: +49 711 7825-30, Fax: 
+49 711 7825-4000, Internet: www.cenit.com
Geschaeftsstellen (Branch Offices): Berlin, Frankfurt, Hamburg, Hannover, 
Muenchen, Oelsnitz, Ratingen, Saarbruecken
Vorstandsmitglieder (Members of the Board): Kurt Bengel  (CEO), Matthias 
Schmidt  (CFO)
Aufsichtsratsmitglieder (Supervisory Board Members): Prof. Dr. Oliver Riedel 
(Vorsitzender des Aufsichtsrats / Chairman of the Supervisory Board), Stephan 
Gier, Ricardo Malta
Bankverbindungen (Bank Accounts):
Deutsche Bank (BLZ 600 700 70) Kto. 1661 040 IBAN : DE85 6007 0070 0166 1040 00 
SWIFT-CODE : DEUTDESS,
Commerzbank (BLZ 600 400 71) Kto. 532 015 500 IBAN : DE83 6004 0071 0532 0155 
00 SWIFT-Code : COBADEFF600,
Registergericht (Registry court): Amtsgericht Stuttgart
Handelsregister (Commercial Register): HRB Nr. 19117
Umsatzsteuer (VAT) ID: DE 147 862 777

Re: Bundle resolve with range does not work on bundles in system repository

[Jean-Baptiste Onofré]

Hi,

what's the exception you have when bundle is in system ?

Maybe you can try to change etc/org.ops4j.pax.url.mvn.cfg file to use
local repositories as remotes.

org.ops4j.pax.url.mvn.defaultLocalRepoAsRemote = true

Both localRepository and defaultRepositories (where system repository is
defined) are considered as local.

Regards
JB

On 09/07/2018 16:16, Althaus, Volker wrote:
> Hello
> I am facing a problem when resolving bundles with the mvn protocol and a 
> range. 
> 
> Example feature.xml
> 
> 
>   mvn:my.group/some.api/[5.2,6)
> 
> 
> If the bundle resides in the local Karaf repository under "system", the 
> bundle could not be resolved. "LATEST" also does not work, I will always have 
> to specify a concrete version.
> However, if it lies in the local .m2 Maven repository, it works! It think 
> because the Maven repo is indexed properly with metadata and the system 
> directory is not.
> 
> Unfortunately I need the range specification because the bundle is built and 
> placed under "system" at customers site, with a minor version we don't 
> exactly know before.
> 
> Any ideas how to solve this? Version is Karaf 4.0.4.
> 
> 
> TIA & Regards
>   Volker
> 
> 
> CENIT AG, Industriestrasse 52-54, 70565 Stuttgart, Tel.: +49 711 7825-30, 
> Fax: +49 711 7825-4000, Internet: www.cenit.com
> Geschaeftsstellen (Branch Offices): Berlin, Frankfurt, Hamburg, Hannover, 
> Muenchen, Oelsnitz, Ratingen, Saarbruecken
> Vorstandsmitglieder (Members of the Board): Kurt Bengel  (CEO), Matthias 
> Schmidt  (CFO)
> Aufsichtsratsmitglieder (Supervisory Board Members): Prof. Dr. Oliver Riedel 
> (Vorsitzender des Aufsichtsrats / Chairman of the Supervisory Board), Stephan 
> Gier, Ricardo Malta
> Bankverbindungen (Bank Accounts):
> Deutsche Bank (BLZ 600 700 70) Kto. 1661 040 IBAN : DE85 6007 0070 0166 1040 
> 00 SWIFT-CODE : DEUTDESS,
> Commerzbank (BLZ 600 400 71) Kto. 532 015 500 IBAN : DE83 6004 0071 0532 0155 
> 00 SWIFT-Code : COBADEFF600,
> Registergericht (Registry court): Amtsgericht Stuttgart
> Handelsregister (Commercial Register): HRB Nr. 19117
> Umsatzsteuer (VAT) ID: DE 147 862 777
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Register now for ApacheCon and save $250

[Rich Bowen]

Greetings, Apache software enthusiasts!

(You’re getting this because you’re on one or more dev@ or users@ lists 
for some Apache Software Foundation project.)


ApacheCon North America, in Montreal, is now just 80 days away, and 
early bird prices end in just two weeks - on July 21. Prices will be 
going up from $550 to $800 so register NOW to save $250, at 
http://apachecon.com/acna18


And don’t forget to reserve your hotel room. We have negotiated a 
special rate and the room block closes August 24. 
http://www.apachecon.com/acna18/venue.html


Our schedule includes over 100 talks and we’ll be featuring talks from 
dozens of ASF projects.,  We have inspiring keynotes from some of the 
brilliant members of our community and the wider tech space, including:


 * Myrle Krantz, PMC chair for Apache Fineract, and leader in the open 
source financing space
 * Cliff Schmidt, founder of Literacy Bridge (now Amplio) and creator 
of the Talking Book project

 * Bridget Kromhout, principal cloud developer advocate at Microsoft
 * Euan McLeod, Comcast engineer, and pioneer in streaming video

We’ll also be featuring tracks for Geospatial science, Tomcat, 
Cloudstack, and Big Data, as well as numerous other fields where Apache 
software is leading the way. See the full schedule at 
http://apachecon.com/acna18/schedule.html


As usual we’ll be running our Apache BarCamp, the traditional ApacheCon 
Hackathon, and the Wednesday evening Lighting Talks, too, so you’ll want 
to be there.


Register today at http://apachecon.com/acna18 and we’ll see you in Montreal!

--
Rich Bowen
VP, Conferences, The Apache Software Foundation
h...@apachecon.com
@ApacheCon

Karaf Jenkins Job Configuration

[imranrazakhan]

Can we see jenkins job or pipeline configuration for karaf to get idea how
karaf running itest and other stuff. i check build its in view mode only.



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Karaf Jenkins Job Configuration

[Jean-Baptiste Onofré]

Hi,

Only some PMCs can edit and so view the Jenkins configuration.

I can extract some configuration for you.

What exactly are you looking for ?

Regards
JB

On 09/07/2018 19:05, imranrazakhan wrote:
> Can we see jenkins job or pipeline configuration for karaf to get idea how
> karaf running itest and other stuff. i check build its in view mode only.
> 
> 
> 
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Install feature as boot features with command line

[Nicolas Brasey]

Hi Francois,

No worries, thanks for the link, I'll have a look!

Nicolas

On Fri, Jul 6, 2018 at 3:43 PM Francois Papon 
wrote:

> Ok, sorry for the noise ;)
>
> May be you can write your own Deployer as a workaround, there is an
> example here :
> https://github.com/jbonofre/karaf/tree/DEV_GUIDE/examples/karaf-deployer-example
>
> François
>
>  Le 06/07/2018 à 17:33, Nicolas Brasey a écrit :
>
> Hi Francois,
>
> This is not possible, the servers are running in security zones without
> internet access, no proxying or tunneling is possible. But this is not
> really the problem as we use the kars which contain all we need.
>
> Nicolas
>
> On Fri, Jul 6, 2018 at 3:26 PM Francois Papon <
> francois.pa...@openobject.fr> wrote:
>
>> Hi Nicolas,
>>
>> When target machines are on a private network, it's usefull to have an
>> instance of Nexus used like a proxy for the externals dependencies and the
>> dev team can also publish their bundles on this Nexus.
>>
>> regards,
>>
>> François paponfpa...@apache.org
>> Yupiik - https://www.yupiik.com
>>
>> Le 06/07/2018 à 16:55, Nicolas Brasey a écrit :
>>
>> Yes we tried but had problems with the KarService implementation of
>> karaf v.4.1.2 which had some issues with starting our features, there was
>> some kind of loop which ended-up installing/uninstalling many time the same
>> features, it was not working for us, so we have now our own implementation
>> of a KarService which only unpacks the kar into a repository directory
>> outside of the karaf distribution. The installation of the feature is made
>> manually in a second stage. So at the moment we use the Kar as only a zip
>> container as maven repository.
>>
>> I saw the implementation of the KarService changed in the latest version
>> of Karaf, so I've not tried again since.
>>
>> Is it possible to tell the karaf feature resolver to persist the state of
>> the features outside of the karaf distribution ? This would be helpful for
>> us.
>>
>> Thanks,
>> Nicolas
>>
>>
>>
>>
>>
>>
>> On Fri, Jul 6, 2018 at 2:34 PM Guillaume Nodet  wrote:
>>
>>> Have you tried simply dropping the kars in the deploy folder ?
>>> This should install / start them automatically without the need to
>>> create a custom distribution.
>>>
>>> Guillaume
>>>
>>> Le jeu. 5 juil. 2018 à 13:53, Nicolas Brasey 
>>> a écrit :
>>>
 Hi all,

 I'm trying to find out if there is way to install a feature and make it
 as a boot feature without manually altering the feature cfg file
 (org.apache.karaf.features.cfg). Checking in karaf's code seems to indicate
 there is no way to do this programmatically.

 Ideally, it would be a flag in the feature:install command to indicate
 to add this feature as a boot feature.

 The reason we need this is that our solution is an integrated solution
 which is delivered by different departments:

 1) Product 1 (kar 1) => dev team A
 2) Product 2 (kar 2) => dev team B
 3) Integration layer (camel routes essentially) (kar 3) => integration
 team

 All these different teams delivering a self contained kar file with a
 feature which should be installed and started when karaf starts in order to
 have the global solution running.

 We are using karaf v.4.1.2 which does not seems to persist which
 features have been installed (only the boot features). I'm not sure about
 the v.4.2.x...

 I know Karaf since not so long, but I believe Karaf has been designed
 so that the delivery team is supposed to create a Karaf distribution and
 assembling the required boot features at build time. If this is true, then
 it is not ideal according to how our internal process is made.

 Any thoughts?
 Thanks!

 Best regards,
 Nicolas






>>>
>>>
>>> --
>>> 
>>> Guillaume Nodet
>>>
>>>
>>
>

Re: Install feature as boot features with command line

[Nicolas Brasey]

Our ideas is to provide maven repositories for each "application". These
repos should contains features.xml which refers to jars which are also in
the same repos or jars that are already available. I wanted to leverage the
fact that each kar repo is automatically available as remote repo by the
resolver.

I think Cave is definitely an option but I wanted to avoid the need to
maintain yet another server in prod and potential point of failures. I
wanted to keep it simple for now...





On Fri, Jul 6, 2018 at 3:48 PM Guillaume Nodet  wrote:

>
>
> Le ven. 6 juil. 2018 à 14:56, Nicolas Brasey  a
> écrit :
>
>> Yes we tried but had problems with the KarService implementation of
>> karaf v.4.1.2 which had some issues with starting our features, there was
>> some kind of loop which ended-up installing/uninstalling many time the same
>> features, it was not working for us, so we have now our own implementation
>> of a KarService which only unpacks the kar into a repository directory
>> outside of the karaf distribution. The installation of the feature is made
>> manually in a second stage. So at the moment we use the Kar as only a zip
>> container as maven repository.
>>
>
> So what are you distributing exactly ? Because if you use the kar
> deployer, it means you *have* to use a manual step after that because the
> features won't be available at boot stage.  If you repackage the
> application after having installed the kars manually, you're basically
> creating a custom distro, else, persisting something which has not taken
> place yet won't help...
>
>
>>
>> I saw the implementation of the KarService changed in the latest version
>> of Karaf, so I've not tried again since.
>>
>> Is it possible to tell the karaf feature resolver to persist the state of
>> the features outside of the karaf distribution ? This would be helpful for
>> us.
>>
>> Thanks,
>> Nicolas
>>
>>
>>
>>
>>
>>
>> On Fri, Jul 6, 2018 at 2:34 PM Guillaume Nodet  wrote:
>>
>>> Have you tried simply dropping the kars in the deploy folder ?
>>> This should install / start them automatically without the need to
>>> create a custom distribution.
>>>
>>> Guillaume
>>>
>>> Le jeu. 5 juil. 2018 à 13:53, Nicolas Brasey 
>>> a écrit :
>>>
 Hi all,

 I'm trying to find out if there is way to install a feature and make it
 as a boot feature without manually altering the feature cfg file
 (org.apache.karaf.features.cfg). Checking in karaf's code seems to indicate
 there is no way to do this programmatically.

 Ideally, it would be a flag in the feature:install command to indicate
 to add this feature as a boot feature.

 The reason we need this is that our solution is an integrated solution
 which is delivered by different departments:

 1) Product 1 (kar 1) => dev team A
 2) Product 2 (kar 2) => dev team B
 3) Integration layer (camel routes essentially) (kar 3) => integration
 team

 All these different teams delivering a self contained kar file with a
 feature which should be installed and started when karaf starts in order to
 have the global solution running.

 We are using karaf v.4.1.2 which does not seems to persist which
 features have been installed (only the boot features). I'm not sure about
 the v.4.2.x...

 I know Karaf since not so long, but I believe Karaf has been designed
 so that the delivery team is supposed to create a Karaf distribution and
 assembling the required boot features at build time. If this is true, then
 it is not ideal according to how our internal process is made.

 Any thoughts?
 Thanks!

 Best regards,
 Nicolas






>>>
>>>
>>> --
>>> 
>>> Guillaume Nodet
>>>
>>>
>
> --
> 
> Guillaume Nodet
>
>

Re: Install feature as boot features with command line

[Nicolas Brasey]

Thanks for that.

I'll experiment a little bit this week and come back to you in case I need
more guidance.

Thanks again.

Nicolas

On Fri, Jul 6, 2018 at 3:56 PM Jean-Baptiste Onofré  wrote:

> Hi Nicolas,
>
> I would recommend:
>
> 1. To take a look if you can't populate the system folder or even use
> Cave on Karaf instance, acting as Maven repository that you can populated
>
> Anyway, Kar is also an option but it needs a clean packaging and
> dependency on kar file:
>
> 1. Your can package all as a kar but you are loosing "flexibility"
> 2. In your case, I would recommend to use kar (with deploy
> folder/deployer or kar:* commands for deployment). A first kar could be
> a common kar providing packages/services that other kar will use. Other
> kar are atomic and isolated from the others.
> So you first deploy the first common kar and then the other kars (the
> order should not matter).
>
> Kar works fine but a kar is supposed to be atomic: that's why I asked if
> you have dependencies between kars.
>
> Regards
> JB
>
> On 06/07/2018 13:55, Nicolas Brasey wrote:
> > Hi Jean-Baptiste,
> >
> > Yes, our different kars have dependencies, so they must installed in a
> > certain order.
> >
> > The features.xml only is not possible in our case because our target
> > machines are running on private networks without internet access, so the
> > kars must contain all the runtime transitive dependencies.
> >
> > But to explain exactly what I'm trying to achieve today, I need to
> > explain the history of our solution. It started 3 years ago as a single
> > application, at that time, the dev team A was delivering the app as a
> > turnkey solution with a custom karaf distribution. The installation was
> > very easy for the delivery team => Move the distribution to the server,
> > unzip and start, the application jars were located in the system
> > repository and the app features marked as boot features.
> >
> > Over the last months, we extended the core application by providing
> > plugin mechanisms by using SPI's, implementing the white-board pattern
> > (we like this a lot by the way :)). So now dev team B is implementing
> > different plugins for specific needs. Those plugins have a different
> > life cycle that the core app, and they are released as kars.
> >
> > Lately we found a bug in the main app which needed to be fixed and
> > patched in a prod environment. We provided the patch with a new custom
> > karaf distribution which the delivery installed. Of course, this new
> > karaf distribution used another data directory and did not reinstall the
> > features of the kars of the different plugins. So manually reinstalling
> > the plugin features is absolutely needed in this scenario or the
> > behavior of the application can differ from before the patching, which
> > is obviously dangerous.
> >
> > Like I said, our main application is still released as part of our
> > custom karaf distribution, this should be changed and we will probably
> > release it a kar as well.
> >
> > So I try to achieve 3 things:
> >
> > 1) Find the optimal packaging for our app and plugins so that it can be
> > install / upgraded easily
> > 2) Hide Karaf (OSGi) complexity from the delivery team, and they don't
> > want to know about it :-)
> > 3) Find the optimal way to set the bundle versions in our feature files
> > using ranges
> >
> > What would be a good practice in a scenario like ours?
> >
> > Thanks again.
> > Regards
> > Nicolas
> >
> >
> >
> > On Thu, Jul 5, 2018 at 2:31 PM Jean-Baptiste Onofré  > > wrote:
> >
> > Hi Nicolas
> >
> > The purpose of boot features is to start in early stage, so it uses
> the
> > cfg file as definition.
> >
> > In your case, you should use inner and prerequisite feature.
> >
> > Do you have some dependencies between kar ?
> >
> > Why don't you use directly feature instead of packaging as a kar ?
> >
> > Can you explain exactly what you are trying to do ?
> >
> > Karaf always store the feature state (in the resolver), so, if you
> first
> > install kar1, then kar2, when you restart, the resolver will
> > reinstall/start those features.
> >
> > So, you don't have to use a boot feature: if you don't remove the
> data
> > folder, the installed features and repositories are stored.
> >
> > Regards
> > JB
> >
> > On 05/07/2018 13:52, Nicolas Brasey wrote:
> > > Hi all,
> > >
> > > I'm trying to find out if there is way to install a feature and
> > make it
> > > as a boot feature without manually altering the feature cfg file
> > > (org.apache.karaf.features.cfg). Checking in karaf's code seems to
> > > indicate there is no way to do this programmatically.
> > >
> > > Ideally, it would be a flag in the feature:install command to
> indicate
> > > to add this feature as a boot feature.
> > >
> > > The reason we need this is that our solution is an integrated
> solution
> > 

Re: Install feature as boot features with command line

[Jean-Baptiste Onofré]

Cool !

Don't hesitate to ping me (even on Hangout or whatever).

I'm always happy to help !

Regards
JB

On 09/07/2018 19:30, Nicolas Brasey wrote:
> Thanks for that.
> 
> I'll experiment a little bit this week and come back to you in case I
> need more guidance.
> 
> Thanks again.
> 
> Nicolas
> 
> On Fri, Jul 6, 2018 at 3:56 PM Jean-Baptiste Onofré  > wrote:
> 
> Hi Nicolas,
> 
> I would recommend:
> 
> 1. To take a look if you can't populate the system folder or even use
> Cave on Karaf instance, acting as Maven repository that you can
> populated
> 
> Anyway, Kar is also an option but it needs a clean packaging and
> dependency on kar file:
> 
> 1. Your can package all as a kar but you are loosing "flexibility"
> 2. In your case, I would recommend to use kar (with deploy
> folder/deployer or kar:* commands for deployment). A first kar could be
> a common kar providing packages/services that other kar will use. Other
> kar are atomic and isolated from the others.
> So you first deploy the first common kar and then the other kars (the
> order should not matter).
> 
> Kar works fine but a kar is supposed to be atomic: that's why I asked if
> you have dependencies between kars.
> 
> Regards
> JB
> 
> On 06/07/2018 13:55, Nicolas Brasey wrote:
> > Hi Jean-Baptiste, 
> >
> > Yes, our different kars have dependencies, so they must installed in a
> > certain order.
> >
> > The features.xml only is not possible in our case because our target
> > machines are running on private networks without internet access,
> so the
> > kars must contain all the runtime transitive dependencies.
> >
> > But to explain exactly what I'm trying to achieve today, I need to
> > explain the history of our solution. It started 3 years ago as a
> single
> > application, at that time, the dev team A was delivering the app as a
> > turnkey solution with a custom karaf distribution. The
> installation was
> > very easy for the delivery team => Move the distribution to the
> server,
> > unzip and start, the application jars were located in the system
> > repository and the app features marked as boot features.
> >
> > Over the last months, we extended the core application by providing
> > plugin mechanisms by using SPI's, implementing the white-board pattern
> > (we like this a lot by the way :)). So now dev team B is implementing
> > different plugins for specific needs. Those plugins have a different
> > life cycle that the core app, and they are released as kars.
> >
> > Lately we found a bug in the main app which needed to be fixed and
> > patched in a prod environment. We provided the patch with a new custom
> > karaf distribution which the delivery installed. Of course, this new
> > karaf distribution used another data directory and did not
> reinstall the
> > features of the kars of the different plugins. So manually
> reinstalling
> > the plugin features is absolutely needed in this scenario or the
> > behavior of the application can differ from before the patching, which
> > is obviously dangerous. 
> >
> > Like I said, our main application is still released as part of our
> > custom karaf distribution, this should be changed and we will probably
> > release it a kar as well.
> >
> > So I try to achieve 3 things:
> >
> > 1) Find the optimal packaging for our app and plugins so that it
> can be
> > install / upgraded easily
> > 2) Hide Karaf (OSGi) complexity from the delivery team, and they don't
> > want to know about it :-)
> > 3) Find the optimal way to set the bundle versions in our feature
> files
> > using ranges
> >
> > What would be a good practice in a scenario like ours?
> >
> > Thanks again.
> > Regards
> > Nicolas
> >
> >
> >
> > On Thu, Jul 5, 2018 at 2:31 PM Jean-Baptiste Onofré
> mailto:j...@nanthrax.net>
> > >> wrote:
> >
> >     Hi Nicolas
> >
> >     The purpose of boot features is to start in early stage, so it
> uses the
> >     cfg file as definition.
> >
> >     In your case, you should use inner and prerequisite feature.
> >
> >     Do you have some dependencies between kar ?
> >
> >     Why don't you use directly feature instead of packaging as a kar ?
> >
> >     Can you explain exactly what you are trying to do ?
> >
> >     Karaf always store the feature state (in the resolver), so, if
> you first
> >     install kar1, then kar2, when you restart, the resolver will
> >     reinstall/start those features.
> >
> >     So, you don't have to use a boot feature: if you don't remove
> the data
> >     folder, the i

Re: Install feature as boot features with command line

[Francois Papon]

Yes, Cave is a good option, especially with the last Cave Deployer
feature included by JB that is really interesting :)


Le 09/07/2018 à 21:29, Nicolas Brasey a écrit :
> Our ideas is to provide maven repositories for each "application".
> These repos should contains features.xml which refers to jars which
> are also in the same repos or jars that are already available. I
> wanted to leverage the fact that each kar repo is automatically
> available as remote repo by the resolver. 
>
> I think Cave is definitely an option but I wanted to avoid the need to
> maintain yet another server in prod and potential point of failures. I
> wanted to keep it simple for now...
>
>
>
>
>
> On Fri, Jul 6, 2018 at 3:48 PM Guillaume Nodet  > wrote:
>
>
>
> Le ven. 6 juil. 2018 à 14:56, Nicolas Brasey
> mailto:nicolas.bra...@gmail.com>> a écrit :
>
> Yes we tried but had problems with the
> KarService implementation of karaf v.4.1.2 which had some
> issues with starting our features, there was some kind of loop
> which ended-up installing/uninstalling many time the same
> features, it was not working for us, so we have now our own
> implementation of a KarService which only unpacks the kar into
> a repository directory outside of the karaf distribution. The
> installation of the feature is made manually in a second
> stage. So at the moment we use the Kar as only a zip container
> as maven repository.
>
>
> So what are you distributing exactly ? Because if you use the kar
> deployer, it means you *have* to use a manual step after that
> because the features won't be available at boot stage.  If you
> repackage the application after having installed the kars
> manually, you're basically creating a custom distro, else,
> persisting something which has not taken place yet won't help...
>  
>
>
> I saw the implementation of the KarService changed in the
> latest version of Karaf, so I've not tried again since.
>
> Is it possible to tell the karaf feature resolver to persist
> the state of the features outside of the karaf distribution ?
> This would be helpful for us.
>
> Thanks,
> Nicolas
>
>
>
>
>  
>
> On Fri, Jul 6, 2018 at 2:34 PM Guillaume Nodet
> mailto:gno...@apache.org>> wrote:
>
> Have you tried simply dropping the kars in the deploy
> folder ?
> This should install / start them automatically without the
> need to create a custom distribution.
>
> Guillaume
>
> Le jeu. 5 juil. 2018 à 13:53, Nicolas Brasey
>  > a écrit :
>
> Hi all,
>
> I'm trying to find out if there is way to install a
> feature and make it as a boot feature without manually
> altering the feature cfg file
> (org.apache.karaf.features.cfg). Checking in karaf's
> code seems to indicate there is no way to do this
> programmatically.
>
> Ideally, it would be a flag in the feature:install
> command to indicate to add this feature as a boot feature.
>
> The reason we need this is that our solution is an
> integrated solution which is delivered by different
> departments:
>
> 1) Product 1 (kar 1) => dev team A
> 2) Product 2 (kar 2) => dev team B
> 3) Integration layer (camel routes essentially)
> (kar 3) => integration team
>
> All these different teams delivering a self
> contained kar file with a feature which should be
> installed and started when karaf starts in order to
> have the global solution running.
>
> We are using karaf v.4.1.2 which does not seems to
> persist which features have been installed (only the
> boot features). I'm not sure about the v.4.2.x...
>
> I know Karaf since not so long, but I believe Karaf
> has been designed so that the delivery team is
> supposed to create a Karaf distribution and assembling
> the required boot features at build time. If this is
> true, then it is not ideal according to how our
> internal process is made.
>
> Any thoughts?
> Thanks!
>
> Best regards,
> Nicolas 
>
>
>
>
>  
>
>
>
> -- 
> 
> Guillaume Nodet
>
>
>
> -- 
> 
> Guillaume Nodet
>

AW: Bundle resolve with range does not work on bundles in system repository

[Althaus, Volker]

Hi,
nope, defaultLocalRepoAsRemote=true unfortunately changes nothing.

When loading my feature, the error is:
2018-07-10 07:51:20,328 | DEBUG | AbstractRetryableDownloadTask | 10 - 
org.apache.karaf.features.core - 4.0.4 |  | Error downloading 
mvn:my.group/some.api/[5.2,6): Error resolving artifact 
my.group/some.api:[5.2,6). Retrying in approx 14171 ms.

When installing via console:
karaf@root()> bundle:install mvn:my.group/some.api/[5.2,6)
Bundle IDs:
Error executing command: Error installing bundles:
Unable to install bundle mvn:my.group/some.api/[5.2,6)


Now I am thinking about to place the generated bundle in the deploy folder 
instead of system as a workaround.


BTW: I tried the same with Karaf 4.2.0 (Win 7, Java 8), there the console shuts 
down/crashes immediately without any Exception after executing the command. I 
will raise a Jira on this.

2018-07-10T08:13:03,708 | DEBUG | RMI TCP Connection(1)-127.0.0.1 | tcp 
 |  -  -  | RMI TCP Connection(1)-127.0.0.1: close 
connection
$ bundle:install mvn:my.group/some.api/[5.2,6)
2018-07-10T08:13:14,235 | DEBUG | Karaf local console user karaf | jline
| 40 - org.jline.terminal - 3.6.2 | Removing shutdown-hook: 
Thread[JLine Shutdown Hook,5,main]
2018-07-10T08:13:14,237 | DEBUG | FelixShutdown| CommandExtender
  | 33 - org.apache.karaf.shell.core - 4.2.0 | org.apache.felix.framework 
(0): Starting destruction process
2018-07-10T08:13:14,239 | DEBUG | FelixShutdown| CommandExtender
  | 33 - org.apache.karaf.shell.core - 4.2.0 | org.apache.felix.framework 
(0): Not an extended bundle or destruction of extension already finished
...


Regards,
  Volker


-Ursprüngliche Nachricht-
Von: Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Gesendet: Montag, 9. Juli 2018 16:21
An: user@karaf.apache.org
Betreff: Re: Bundle resolve with range does not work on bundles in system 
repository

Hi,

what's the exception you have when bundle is in system ?

Maybe you can try to change etc/org.ops4j.pax.url.mvn.cfg file to use local 
repositories as remotes.

org.ops4j.pax.url.mvn.defaultLocalRepoAsRemote = true

Both localRepository and defaultRepositories (where system repository is
defined) are considered as local.

Regards
JB

On 09/07/2018 16:16, Althaus, Volker wrote:
> Hello
> I am facing a problem when resolving bundles with the mvn protocol and a 
> range. 
> 
> Example feature.xml
> 
> 
>   mvn:my.group/some.api/[5.2,6)
> 
> 
> If the bundle resides in the local Karaf repository under "system", the 
> bundle could not be resolved. "LATEST" also does not work, I will always have 
> to specify a concrete version.
> However, if it lies in the local .m2 Maven repository, it works! It think 
> because the Maven repo is indexed properly with metadata and the system 
> directory is not.
> 
> Unfortunately I need the range specification because the bundle is built and 
> placed under "system" at customers site, with a minor version we don't 
> exactly know before.
> 
> Any ideas how to solve this? Version is Karaf 4.0.4.
> 
> 
> TIA & Regards
>   Volker

CENIT AG, Industriestrasse 52-54, 70565 Stuttgart, Tel.: +49 711 7825-30, Fax: 
+49 711 7825-4000, Internet: www.cenit.com
Geschaeftsstellen (Branch Offices): Berlin, Frankfurt, Hamburg, Hannover, 
Muenchen, Oelsnitz, Ratingen, Saarbruecken
Vorstandsmitglieder (Members of the Board): Kurt Bengel  (CEO), Matthias 
Schmidt  (CFO)
Aufsichtsratsmitglieder (Supervisory Board Members): Prof. Dr. Oliver Riedel 
(Vorsitzender des Aufsichtsrats / Chairman of the Supervisory Board), Stephan 
Gier, Ricardo Malta
Bankverbindungen (Bank Accounts):
Deutsche Bank (BLZ 600 700 70) Kto. 1661 040 IBAN : DE85 6007 0070 0166 1040 00 
SWIFT-CODE : DEUTDESS,
Commerzbank (BLZ 600 400 71) Kto. 532 015 500 IBAN : DE83 6004 0071 0532 0155 
00 SWIFT-Code : COBADEFF600,
Registergericht (Registry court): Amtsgericht Stuttgart
Handelsregister (Commercial Register): HRB Nr. 19117
Umsatzsteuer (VAT) ID: DE 147 862 777