date:20170201

I think it's an issue we identified with Christian yesterday. And we can 
workaround. Let me check.

Regards
JB⁣

On Feb 1, 2017, 22:34, at 22:34, Krzysztof Sobkowiak 
 wrote:
>And the problem with ActiveMQ conole: should it be fixed in ActiveMQ or
>is it a missing bundle or feature which should be additionally
>installed in K11x to fix this problem? Should I open and issue in
>ActiveMQ or Karaf?
>
>Kindly regards
>Krzysztof
>
>On 01.02.2017 22:27, Jean-Baptiste Onofré wrote:
>> Hi
>>
>> Thanks for your tests. Yes for the shell console and rendering issues
>around completion: it's known, not release blocker but annoying.
>Clearly it has to be fix for 4.1.1.
>>
>> Regards
>> JB⁣
>>
>> On Feb 1, 2017, 22:12, at 22:12, Krzysztof Sobkowiak
> wrote:
>>> +1 (non-binding)
>>>
>>> I have tested some ActiveMQ and Camel features. The problem with
>>> commands after restart has been fixed in the new release candidate.
>>> Jdbc, jms and some other features look good too.
>>>
>>> I have found only 2 problems (non blocker)
>>>
>>> * After installing ActiveMQ console I got following info on the
>>> console:
>>>
>>>Problem accessing /activemqweb/. Reason: Not Found
>>>
>>>And following log entry:
>>>
>>> 2017-02-01 21:56:03,788 | ERROR | pool-3-thread-1  | WebObserver
>  
>>> | 179 - org.ops4j.pax.web.pax-web-extender-war - 6.0.2 | Error
>scanning
>>> web bundle org.apache.activemq.activemq-web-console [70]:
>>> javax.servlet.annotation.HandlesTypes not found by
>>> org.apache.activemq.activemq-web-console [70]
>>> java.lang.ClassNotFoundException:
>javax.servlet.annotation.HandlesTypes
>>> not found by org.apache.activemq.activemq-web-console [70]
>>> at
>>>
>org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1574)
>>> ~[?:?]
>>>
>>>
>>> * The shell is still not stable - autocompletion sometimes works not
>>> correct (additional spaces), sometimes the layout becomes  chaotic
>>>
>>> Good job!!!
>>>
>>> Kindly regards
>>>
>>> Krzysztof
>>>
>>>
>>>
>>>
>>> On 01.02.2017 20:32, Jean-Baptiste Onofré wrote:
 Hi all,

 I submit Karaf (Container) 4.1.0 release (second attempt) to your
>>> vote.
 Release Notes:

>>>
>https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12332799
 Staging Repository:

>>>
>https://repository.apache.org/content/repositories/orgapachekaraf-1089/
 Git Tag:
 karaf-4.1.0

 Please vote to approve this release:

 [ ] +1 Approve the release
 [ ] -1 Don't approve the release (please provide specific comments)

 This vote will be open for at least 48 hours.

 Thanks,
 Regards
 JB
>>> -- 
>>> Krzysztof Sobkowiak (@ksobkowiak)
>>>
>>> JEE & OSS Architect, Integration Architect
>>> Apache Software Foundation Member (http://apache.org/)
>>> Apache ServiceMix Committer & PMC Member
>>> (http://servicemix.apache.org/)
>>> Senior Solution Architect @ Capgemini SSC
>>> (http://www.capgeminisoftware.pl/)
>
>-- 
>Krzysztof Sobkowiak (@ksobkowiak)
>
>JEE & OSS Architect, Integration Architect
>Apache Software Foundation Member (http://apache.org/)
>Apache ServiceMix Committer & PMC Member
>(http://servicemix.apache.org/)
>Senior Solution Architect @ Capgemini SSC
>(http://www.capgeminisoftware.pl/)

Re: [VOTE] Apache Karaf (Container) 4.1.0 release, RC#2

2017-02-01 Thread Krzysztof Sobkowiak

And the problem with ActiveMQ conole: should it be fixed in ActiveMQ or is it a 
missing bundle or feature which should be additionally installed in K11x to fix 
this problem? Should I open and issue in ActiveMQ or Karaf?

Kindly regards
Krzysztof

On 01.02.2017 22:27, Jean-Baptiste Onofré wrote:
> Hi
>
> Thanks for your tests. Yes for the shell console and rendering issues around 
> completion: it's known, not release blocker but annoying. Clearly it has to 
> be fix for 4.1.1.
>
> Regards
> JB⁣
>
> On Feb 1, 2017, 22:12, at 22:12, Krzysztof Sobkowiak 
>  wrote:
>> +1 (non-binding)
>>
>> I have tested some ActiveMQ and Camel features. The problem with
>> commands after restart has been fixed in the new release candidate.
>> Jdbc, jms and some other features look good too.
>>
>> I have found only 2 problems (non blocker)
>>
>> * After installing ActiveMQ console I got following info on the
>> console:
>>
>>Problem accessing /activemqweb/. Reason: Not Found
>>
>>And following log entry:
>>
>> 2017-02-01 21:56:03,788 | ERROR | pool-3-thread-1  | WebObserver   
>> | 179 - org.ops4j.pax.web.pax-web-extender-war - 6.0.2 | Error scanning
>> web bundle org.apache.activemq.activemq-web-console [70]:
>> javax.servlet.annotation.HandlesTypes not found by
>> org.apache.activemq.activemq-web-console [70]
>> java.lang.ClassNotFoundException: javax.servlet.annotation.HandlesTypes
>> not found by org.apache.activemq.activemq-web-console [70]
>> at
>> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1574)
>> ~[?:?]
>>
>>
>> * The shell is still not stable - autocompletion sometimes works not
>> correct (additional spaces), sometimes the layout becomes  chaotic
>>
>> Good job!!!
>>
>> Kindly regards
>>
>> Krzysztof
>>
>>
>>
>>
>> On 01.02.2017 20:32, Jean-Baptiste Onofré wrote:
>>> Hi all,
>>>
>>> I submit Karaf (Container) 4.1.0 release (second attempt) to your
>> vote.
>>> Release Notes:
>>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12332799
>>> Staging Repository:
>>>
>> https://repository.apache.org/content/repositories/orgapachekaraf-1089/
>>> Git Tag:
>>> karaf-4.1.0
>>>
>>> Please vote to approve this release:
>>>
>>> [ ] +1 Approve the release
>>> [ ] -1 Don't approve the release (please provide specific comments)
>>>
>>> This vote will be open for at least 48 hours.
>>>
>>> Thanks,
>>> Regards
>>> JB
>> -- 
>> Krzysztof Sobkowiak (@ksobkowiak)
>>
>> JEE & OSS Architect, Integration Architect
>> Apache Software Foundation Member (http://apache.org/)
>> Apache ServiceMix Committer & PMC Member
>> (http://servicemix.apache.org/)
>> Senior Solution Architect @ Capgemini SSC
>> (http://www.capgeminisoftware.pl/)

-- 
Krzysztof Sobkowiak (@ksobkowiak)

JEE & OSS Architect, Integration Architect
Apache Software Foundation Member (http://apache.org/)
Apache ServiceMix Committer & PMC Member (http://servicemix.apache.org/)
Senior Solution Architect @ Capgemini SSC (http://www.capgeminisoftware.pl/)

Re: [VOTE] Apache Karaf (Container) 4.1.0 release, RC#2

Hi

Thanks for your tests. Yes for the shell console and rendering issues around 
completion: it's known, not release blocker but annoying. Clearly it has to be 
fix for 4.1.1.

Regards
JB⁣

On Feb 1, 2017, 22:12, at 22:12, Krzysztof Sobkowiak 
 wrote:
>+1 (non-binding)
>
>I have tested some ActiveMQ and Camel features. The problem with
>commands after restart has been fixed in the new release candidate.
>Jdbc, jms and some other features look good too.
>
>I have found only 2 problems (non blocker)
>
>* After installing ActiveMQ console I got following info on the
>console:
>
>Problem accessing /activemqweb/. Reason: Not Found
>
>And following log entry:
>
>2017-02-01 21:56:03,788 | ERROR | pool-3-thread-1  | WebObserver   
>| 179 - org.ops4j.pax.web.pax-web-extender-war - 6.0.2 | Error scanning
>web bundle org.apache.activemq.activemq-web-console [70]:
>javax.servlet.annotation.HandlesTypes not found by
>org.apache.activemq.activemq-web-console [70]
>java.lang.ClassNotFoundException: javax.servlet.annotation.HandlesTypes
>not found by org.apache.activemq.activemq-web-console [70]
>at
>org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1574)
>~[?:?]
>
>
>* The shell is still not stable - autocompletion sometimes works not
>correct (additional spaces), sometimes the layout becomes  chaotic
>
>Good job!!!
>
>Kindly regards
>
>Krzysztof
>
>
>
>
>On 01.02.2017 20:32, Jean-Baptiste Onofré wrote:
>> Hi all,
>>
>> I submit Karaf (Container) 4.1.0 release (second attempt) to your
>vote.
>>
>> Release Notes:
>>
>https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12332799
>>
>> Staging Repository:
>>
>https://repository.apache.org/content/repositories/orgapachekaraf-1089/
>>
>> Git Tag:
>> karaf-4.1.0
>>
>> Please vote to approve this release:
>>
>> [ ] +1 Approve the release
>> [ ] -1 Don't approve the release (please provide specific comments)
>>
>> This vote will be open for at least 48 hours.
>>
>> Thanks,
>> Regards
>> JB
>
>-- 
>Krzysztof Sobkowiak (@ksobkowiak)
>
>JEE & OSS Architect, Integration Architect
>Apache Software Foundation Member (http://apache.org/)
>Apache ServiceMix Committer & PMC Member
>(http://servicemix.apache.org/)
>Senior Solution Architect @ Capgemini SSC
>(http://www.capgeminisoftware.pl/)

Re: [VOTE] Apache Karaf (Container) 4.1.0 release, RC#2

2017-02-01 Thread Krzysztof Sobkowiak

+1 (non-binding)

I have tested some ActiveMQ and Camel features. The problem with commands after 
restart has been fixed in the new release candidate. Jdbc, jms and some other 
features look good too.

I have found only 2 problems (non blocker)

  * After installing ActiveMQ console I got following info on the console:

Problem accessing /activemqweb/. Reason: Not Found

And following log entry:

2017-02-01 21:56:03,788 | ERROR | pool-3-thread-1  | WebObserver
  | 179 - org.ops4j.pax.web.pax-web-extender-war - 6.0.2 | Error 
scanning web bundle org.apache.activemq.activemq-web-console [70]: 
javax.servlet.annotation.HandlesTypes not found by 
org.apache.activemq.activemq-web-console [70]
java.lang.ClassNotFoundException: javax.servlet.annotation.HandlesTypes not 
found by org.apache.activemq.activemq-web-console [70]
at 
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1574)
 ~[?:?]


  * The shell is still not stable - autocompletion sometimes works not correct 
(additional spaces), sometimes the layout becomes  chaotic

Good job!!!

Kindly regards

Krzysztof




On 01.02.2017 20:32, Jean-Baptiste Onofré wrote:
> Hi all,
>
> I submit Karaf (Container) 4.1.0 release (second attempt) to your vote.
>
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12332799
>
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1089/
>
> Git Tag:
> karaf-4.1.0
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 48 hours.
>
> Thanks,
> Regards
> JB

-- 
Krzysztof Sobkowiak (@ksobkowiak)

JEE & OSS Architect, Integration Architect
Apache Software Foundation Member (http://apache.org/)
Apache ServiceMix Committer & PMC Member (http://servicemix.apache.org/)
Senior Solution Architect @ Capgemini SSC (http://www.capgeminisoftware.pl/)

Re: [DISCUSS] Living on the edge... of version range

2017-02-01 Thread Grzegorz Grzybek

2017-02-01 16:57 GMT+01:00 Łukasz Dywicki :

> Main reason is consistency of dependency resolution process. Also if
> you declare dependencies in POM for assembly projects then it's group
> id/artifact id gets resolved before plugin execution.

I sense some fundamental problem in the above assumption. If you use
version ranges in your POM (like "[1.0, 1.1)") then what "gets resolved" is
something from withing the range (according to maven understanding of
ranges), So in your local repository you'll get some metadata (from the
moment of resolution) and some artifact (best fit from metadata). When
(even in same JVM process) Karaf feature resolution is performed and you
have a *copy* of Maven range into feature range, then existing (previously
resolved) metadata+artifact don't mean anything - because according to some
update policy, metadata may be tried to be fetched again. Or even there may
be newer artifact falling into the range available remotely.

> This feeds local
> repository with these artifacts before karaf jumps in making it handy
> for offline development.
>

Discrepancy between OSGi and Maven range is one thing, but we just can't
rely on previously resolved artifacts to satisfy another "version range" →
"version" resolution (org.eclipse.aether.impl.VersionRangeResolver) without
remote access...

>
> If you rely just on plugin itself it will always require access to
> remote repositories since pax-url is not using resolver available in
> maven. I might be wrong on that but that was my observation so far.
>

No it doesn't - Aether constructs it's own
org.eclipse.aether.RepositorySystem and configures it using DI.

My suggestion is - add your own
org.code_house.maven.osgi.resolver.compatible.CompatibleOsgiVersionRangeResolver
to pax-url and modify
org.ops4j.pax.url.mvn.internal.AetherBasedResolver#newRepositorySystem()
method to set it as configured
org.eclipse.aether.impl.VersionRangeResolver *when some new property is
configured* in org.ops4j.pax.url.mvn PID.

I wouldn't change default behavior.

regards
Grzegorz Grzybek

>
> Anyhow if maven part doesn't fit anywhere I can keep it on github for
> now and see how it will evolve.
>
> Best regards,
> Lukasz
>
> 2017-02-01 15:05 GMT+01:00 Guillaume Nodet :
> > Why do we need to change maven's behavior ?
> > The karaf-maven-plugin does not really use maven when downloading things
> > other than the maven dependencies, it always use pax-url-aether to do the
> > downloads.
> >
> > 2017-02-01 14:49 GMT+01:00 Łukasz Dywicki :
> >
> >> It is fine for me too, but we still need this piece of code embeddable
> >> in maven build as maven core extension. That's why I didn't opt for
> >> pax in first place.
> >>
> >> Cheers,
> >> Lukasz
> >>
> >> 2017-02-01 14:32 GMT+01:00 Christian Schneider  >:
> >> > I also think we should better just change on the pax url level.
> Someone
> >> else
> >> > using the AetherBasedResolver might expect the default behaviour.
> >> >
> >> > Christian
> >> >
> >> >
> >> > On 01.02.2017 14:28, Guillaume Nodet wrote:
> >> >>
> >> >> Right.  Not sure it's worth it, but why not.
> >> >> I still think the best location for the osgi-compatible version
> resolver
> >> >> is
> >> >> in pax-url-aether, as it's really the only place it will be used
> afaik,
> >> >> but
> >> >> again, it's no big deal.
> >> >>
> >> >> 2017-02-01 14:14 GMT+01:00 Łukasz Dywicki :
> >> >>
> >> >>> What I was thinking about was something like that:
> >> >>> AetherBasedResolver.class.getResources("META-INF/pax-
> >> >>> customization.properties")
> >> >>> then just parsing it and pushing into ServiceLocator instance
> created
> >> >>> by MavenRepositorySystemUtil. We can do that because
> >> >>> DefaultServiceLocator implementation is mutable as Grzegorz pointed
> >> >>> out. Since we will be in internal package getResources should behave
> >> >>> properly in both cases.
> >> >>>
> >> >>> Cheers,
> >> >>> Lukasz
> >> >>>
> >> >
> >> > --
> >> > Christian Schneider
> >> > http://www.liquid-reality.de
> >> >
> >> > Open Source Architect
> >> > http://www.talend.com
> >> >
> >>
> >
> >
> >
> > --
> > 
> > Guillaume Nodet
>

Re: Problems with 3rd party commands in 4.1.0

2017-02-01 Thread Krzysztof Sobkowiak

I have tested this with the new rc and looks like you have fixed it. Thanks!!

On 01.02.2017 10:57, Christian Schneider wrote:
> I found a bit more now.
>
> The shell.console fragment itself also is in state installed while it should 
> be resolved.
> If I manually refresh shell.core then the fragment shell.console goes to 
> state resolved and the came command bundle can be started.
>
> Christian
>
> On 01.02.2017 10:46, Christian Schneider wrote:
>> I can reproduce the issue.
>> I think it might be a bug in the resolver.
>>
>> What I found:
>> Camel commands import this package: 
>> (&(osgi.wiring.package=org.apache.karaf.shell.console)(version>=3.0.0)(!(version>=5.0.0)))
>>
>> The exported packages show this:
>> org.apache.karaf.shell.console  │ 2.3.0  
>>  │ 42 │ org.apache.karaf.shell.console
>> org.apache.karaf.shell.console  │ 4.1.0  
>>  │ 42 │ org.apache.karaf.shell.console
>>
>> So the package is exported in two versions. The version 2.3.0 would not 
>> match the range camel imports, the 4.1.0 version would match it.
>> I suspect that the resolver behaves differently depending on which version 
>> it checks first. If it checks the 4.1.0 first it works, if it checks the 
>> 2.1.0 version first it fails.
>> I guess it should check both versions and take the working one but 
>> apparently it does not.
>>
>> Unfortunately I do not know the implementation well enough to check or fix 
>> this but maybe it helps Guillaume to find the issue :-)
>>
>> Christian
>>
>> On 31.01.2017 21:42, Krzysztof Sobkowiak wrote:
>>> Hi
>>>
>>> While testing 4.1.0 I have observed following issue.
>>>
>>> karaf@root()> feature:repo-add camel 2.18.2 21:35:06
>>> Adding feature url 
>>> mvn:org.apache.camel.karaf/apache-camel/2.18.2/xml/features
>>> karaf@root()> feature:install camel 21:35:19
>>> karaf@root()> camel 21:35:26
>>> camel   camel:context-list camel:eip-explain   
>>> camel:rest-api-doc camel:route-profile camel:route-start
>>> camel   camel:context-resume camel:eip-explain  
>>>  camel:rest-registry-list camel:route-profile camel:route-stop
>>> camel:component-listcamel:context-resume camel:endpoint-explain 
>>>  camel:rest-registry-list camel:route-reset-stats camel:route-stop
>>> camel:component-listcamel:context-start camel:endpoint-explain  
>>> camel:rest-show camel:route-reset-stats camel:route-suspend
>>> camel:context-inflight  camel:context-start camel:endpoint-list 
>>> camel:rest-show camel:route-resume  camel:route-suspend
>>> camel:context-inflight  camel:context-stop camel:endpoint-list 
>>> camel:route-info camel:route-resume
>>> camel:context-info  camel:context-stop camel:endpoint-stats
>>> camel:route-info camel:route-show
>>> camel:context-info  camel:context-suspend camel:endpoint-stats  
>>>   camel:route-list camel:route-show
>>> camel:context-list  camel:context-suspend camel:rest-api-doc
>>>   camel:route-list camel:route-start
>>>
>>> The commands are available and work. But after Karaf restart they are no 
>>> more available and the log contains following error:
>>>
>>> 2017-01-31 21:37:25,415 | ERROR | FelixStartLevel  | Felix  
>>>   |  -  -  | Bundle org.apache.camel.karaf.camel-karaf-commands 
>>> [57] Error starting mvn:org.apache.camel.karaf/camel-karaf-commands/2.18.2 
>>> (org.osgi.framework.BundleException: Unable to resolve 
>>> org.apache.camel.karaf.camel-karaf-commands [57](R 57.0): missing 
>>> requirement [org.apache.camel.karaf.camel-karaf-commands [57](R 57.0)] 
>>> osgi.wiring.package; 
>>> (&(osgi.wiring.package=org.apache.karaf.shell.console)(version>=3.0.0)(!(version>=5.0.0)))
>>>  [caused by: Unable to resolve org.apache.karaf.shell.console [42](R 42.0): 
>>> missing requirement [org.apache.karaf.shell.console [42](R 42.0)] 
>>> osgi.wiring.host; 
>>> (&(osgi.wiring.host=org.apache.karaf.shell.core)(bundle-version>=0.0.0))] 
>>> Unresolved requirements: [[org.apache.camel.karaf.camel-karaf-commands 
>>> [57](R 57.0)] osgi.wiring.package; 
>>> (&(osgi.wiring.package=org.apache.karaf.shell.console)(version>=3.0.0)(!(version>=5.0.0)))])
>>> org.osgi.framework.BundleException: Unable to resolve 
>>> org.apache.camel.karaf.camel-karaf-commands [57](R 57.0): missing 
>>> requirement [org.apache.camel.karaf.camel-karaf-commands [57](R 57.0)] 
>>> osgi.wiring.package; 
>>> (&(osgi.wiring.package=org.apache.karaf.shell.console)(version>=3.0.0)(!(version>=5.0.0)))
>>>  [caused by: Unable to resolve org.apache.karaf.shell.console [42](R 42.0): 
>>> missing requirement [org.apache.karaf.shell.console [42](R 42.0)] 
>>> osgi.wiring.host; 
>>> (&(osgi.wiring.host=org.apache.karaf.shell.core)(bundle-version>=0.0.0))] 
>>> Unresolved requirements: [[org.apache.camel.karaf.camel-karaf-commands 
>>>

[VOTE] Apache Karaf (Container) 4.1.0 release, RC#2


Hi all,

I submit Karaf (Container) 4.1.0 release (second attempt) to your vote.

Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12332799

Staging Repository:
https://repository.apache.org/content/repositories/orgapachekaraf-1089/

Git Tag:
karaf-4.1.0

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 48 hours.

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

Re: [DISCUSS] Living on the edge... of version range

Main reason is consistency of dependency resolution process. Also if
you declare dependencies in POM for assembly projects then it's group
id/artifact id gets resolved before plugin execution. This feeds local
repository with these artifacts before karaf jumps in making it handy
for offline development.

If you rely just on plugin itself it will always require access to
remote repositories since pax-url is not using resolver available in
maven. I might be wrong on that but that was my observation so far.

Anyhow if maven part doesn't fit anywhere I can keep it on github for
now and see how it will evolve.

Best regards,
Lukasz

2017-02-01 15:05 GMT+01:00 Guillaume Nodet :
> Why do we need to change maven's behavior ?
> The karaf-maven-plugin does not really use maven when downloading things
> other than the maven dependencies, it always use pax-url-aether to do the
> downloads.
>
> 2017-02-01 14:49 GMT+01:00 Łukasz Dywicki :
>
>> It is fine for me too, but we still need this piece of code embeddable
>> in maven build as maven core extension. That's why I didn't opt for
>> pax in first place.
>>
>> Cheers,
>> Lukasz
>>
>> 2017-02-01 14:32 GMT+01:00 Christian Schneider :
>> > I also think we should better just change on the pax url level. Someone
>> else
>> > using the AetherBasedResolver might expect the default behaviour.
>> >
>> > Christian
>> >
>> >
>> > On 01.02.2017 14:28, Guillaume Nodet wrote:
>> >>
>> >> Right.  Not sure it's worth it, but why not.
>> >> I still think the best location for the osgi-compatible version resolver
>> >> is
>> >> in pax-url-aether, as it's really the only place it will be used afaik,
>> >> but
>> >> again, it's no big deal.
>> >>
>> >> 2017-02-01 14:14 GMT+01:00 Łukasz Dywicki :
>> >>
>> >>> What I was thinking about was something like that:
>> >>> AetherBasedResolver.class.getResources("META-INF/pax-
>> >>> customization.properties")
>> >>> then just parsing it and pushing into ServiceLocator instance created
>> >>> by MavenRepositorySystemUtil. We can do that because
>> >>> DefaultServiceLocator implementation is mutable as Grzegorz pointed
>> >>> out. Since we will be in internal package getResources should behave
>> >>> properly in both cases.
>> >>>
>> >>> Cheers,
>> >>> Lukasz
>> >>>
>> >
>> > --
>> > Christian Schneider
>> > http://www.liquid-reality.de
>> >
>> > Open Source Architect
>> > http://www.talend.com
>> >
>>
>
>
>
> --
> 
> Guillaume Nodet

Re: [DISCUSS] Living on the edge... of version range

Why do we need to change maven's behavior ?
The karaf-maven-plugin does not really use maven when downloading things
other than the maven dependencies, it always use pax-url-aether to do the
downloads.

2017-02-01 14:49 GMT+01:00 Łukasz Dywicki :

> It is fine for me too, but we still need this piece of code embeddable
> in maven build as maven core extension. That's why I didn't opt for
> pax in first place.
>
> Cheers,
> Lukasz
>
> 2017-02-01 14:32 GMT+01:00 Christian Schneider :
> > I also think we should better just change on the pax url level. Someone
> else
> > using the AetherBasedResolver might expect the default behaviour.
> >
> > Christian
> >
> >
> > On 01.02.2017 14:28, Guillaume Nodet wrote:
> >>
> >> Right.  Not sure it's worth it, but why not.
> >> I still think the best location for the osgi-compatible version resolver
> >> is
> >> in pax-url-aether, as it's really the only place it will be used afaik,
> >> but
> >> again, it's no big deal.
> >>
> >> 2017-02-01 14:14 GMT+01:00 Łukasz Dywicki :
> >>
> >>> What I was thinking about was something like that:
> >>> AetherBasedResolver.class.getResources("META-INF/pax-
> >>> customization.properties")
> >>> then just parsing it and pushing into ServiceLocator instance created
> >>> by MavenRepositorySystemUtil. We can do that because
> >>> DefaultServiceLocator implementation is mutable as Grzegorz pointed
> >>> out. Since we will be in internal package getResources should behave
> >>> properly in both cases.
> >>>
> >>> Cheers,
> >>> Lukasz
> >>>
> >
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> >
> > Open Source Architect
> > http://www.talend.com
> >
>



-- 

Guillaume Nodet

Re: [DISCUSS] Living on the edge... of version range

It is fine for me too, but we still need this piece of code embeddable
in maven build as maven core extension. That's why I didn't opt for
pax in first place.

Cheers,
Lukasz

2017-02-01 14:32 GMT+01:00 Christian Schneider :
> I also think we should better just change on the pax url level. Someone else
> using the AetherBasedResolver might expect the default behaviour.
>
> Christian
>
>
> On 01.02.2017 14:28, Guillaume Nodet wrote:
>>
>> Right.  Not sure it's worth it, but why not.
>> I still think the best location for the osgi-compatible version resolver
>> is
>> in pax-url-aether, as it's really the only place it will be used afaik,
>> but
>> again, it's no big deal.
>>
>> 2017-02-01 14:14 GMT+01:00 Łukasz Dywicki :
>>
>>> What I was thinking about was something like that:
>>> AetherBasedResolver.class.getResources("META-INF/pax-
>>> customization.properties")
>>> then just parsing it and pushing into ServiceLocator instance created
>>> by MavenRepositorySystemUtil. We can do that because
>>> DefaultServiceLocator implementation is mutable as Grzegorz pointed
>>> out. Since we will be in internal package getResources should behave
>>> properly in both cases.
>>>
>>> Cheers,
>>> Lukasz
>>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>

Re: [DISCUSS] Living on the edge... of version range

2017-02-01 Thread Christian Schneider

I also think we should better just change on the pax url level. Someone 
else using the AetherBasedResolver might expect the default behaviour.


Christian

On 01.02.2017 14:28, Guillaume Nodet wrote:

Right.  Not sure it's worth it, but why not.
I still think the best location for the osgi-compatible version resolver is
in pax-url-aether, as it's really the only place it will be used afaik, but
again, it's no big deal.

2017-02-01 14:14 GMT+01:00 Łukasz Dywicki :


What I was thinking about was something like that:
AetherBasedResolver.class.getResources("META-INF/pax-
customization.properties")
then just parsing it and pushing into ServiceLocator instance created
by MavenRepositorySystemUtil. We can do that because
DefaultServiceLocator implementation is mutable as Grzegorz pointed
out. Since we will be in internal package getResources should behave
properly in both cases.

Cheers,
Lukasz



--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [DISCUSS] Living on the edge... of version range

2017-02-01 12:35 GMT+01:00 Łukasz Dywicki :

> @Guillaume you are right on findEntries part, this will break with
> maven execution.
>

What findEntries part are you talking about ?
I was just referring to the fact that a modified version of
MavenRepositorySystemUtil class would be better embedded directly into
pax-url-aether. Else, you'd have to provide 2 alternative ways to use it,
one by using a fragment and the other one by ensuring that the hacked class
is loaded first in the classloader (in case of a simple classloader).
It just seems easier to me to just move that class in the shaded
pax-url-aether and hack it so that the behavior can be easily controlled
using a boolean on the usual pax-url-aether configuration.



>
> @Grzegorz I do not negate that version, metadata or range resolving
> works. It does with some small exceptions (see PAXURL-342). What
> doesn't work is re-use of ranges from maven build into karaf runtime.
> When you use maven  and aether to build custom assembly
> feature resolver in runtime will not work for certain cases because of
> version edges.
> When you will take a look on these two files:
> https://github.com/splatch/maven-osgi-resolver/blob/
> master/shared/src/test/java/org/code_house/maven/osgi/
> resolver/shared/version/OsgiVersionRangeTest.java
> https://github.com/splatch/maven-osgi-resolver/blob/
> master/test/src/test/java/org/eclipse/aether/util/version/
> GenericVersionRangeTest.java
> and diff between them https://www.diffchecker.com/eyzDSSXU you will
> find quite big area for troubles.
>
> We about to start using ranges in build because we do not want to have
> 3 different minor versions installed without need. Using ranges in
> both places acutally might speed up running integration tests because
> metadata is already fetched and present in local repository. Otherwise
> our integration tests bootstrap takes 2 minutes just to scan remotes
> for new versions (see above pax url issue).
>
> Cheers,
> Lukasz
>
> 2017-02-01 12:02 GMT+01:00 Grzegorz Grzybek :
> > Hello,
> >
> > Current pax-url-aether has already some custom services DInjected into
> > RepositorySystem, like here[1]. Also in Fabric8v1 and in Karaf I did some
> > tricks to implement non-canonical "update releases" scenario[2].
> > So I think adding configuration options for pax-url to modify the way
> > RepositorySystem is configured should not be a problem.
> >
> > What is the ultimate problem you want to solve? Is it (at lowest level)
> the
> > ability to handle the below URLs?:
> >
> > osgi:install mvn:groupId/artifactId/[lowerBound, upperBound)
> >
> > Currently (pax-url 2.5.2) LATEST, RELEASE and SNAPSHOT versions should be
> > handled correctly[3]:
> >  - LATEST instructs AetherBasedResolver to fetch group/artifact
> > metadata.xml and pick latest release OR snapshot
> >  - RELEASE instructs AetherBasedResolver to fetch group/artifact
> > metadata.xml and pick latest release
> >  - SNAPSHOT instructs AetherBasedResolver to fetch group/artifact/version
> > metadata.xml and pick latest snapshot
> >
> > e.g., in Fabric8v1 I added custom org.eclipse.aether.impl.
> MetadataResolver
> > that is able to resolve metadata ("maven-metadata.xml") even in local
> > repositories into which a SNAPSHOT was installed using `mvn clean
> install`
> > - so the metadata is stored in "maven-metadata-local.xml" file - but the
> > repo is used as remote repository (expecting to return
> "maven-metadata.xml"
> > file.
> >
> > Are you using same version ranges in POM and in features.xml? (I don't
> > argue with the fact that version ranges are used at all in POM :).
> >
> > regards
> > Grzegorz
> > ===
> > [1]:
> > https://github.com/ops4j/org.ops4j.pax.url/blob/master/pax-
> url-aether/src/main/java/org/ops4j/pax/url/mvn/internal/
> AetherBasedResolver.java#L1168-L1169
> > [2]:
> > https://ops4j1.jira.com/browse/PAXURL-322?focusedCommentId=37006=
> com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel#comment-37006
> > [3]: http://ggrzybek.blogspot.com/2016/10/using-maven-with-osgi-
> part-3.html
> >
> > 2017-02-01 11:44 GMT+01:00 Guillaume Nodet :
> >
> >> 2017-02-01 11:31 GMT+01:00 Łukasz Dywicki :
> >>
> >> > Thanks for your repiles. If we will manage to get pax-url accepting
> >> > different version range resolving than maven default then I think we
> >> > will not have any troubles with features left. What I was thinking
> >> > about is moving my maven-osgi-resolver to karaf tooling and extending
> >> > pax-url in the way it could pick up version range resolver
> >> > implementation from fragment bundle. This way we could keep current
> >> > behavior which might be used by someone but also let others use end to
> >> > end range support. There are more "extension points" built into
> >> > Aerther which gets normally wired by IoC. Since we can't and we do not
> >> > want to embed yet-another-ioc-tool for low level stuff

Re: [DISCUSS] Living on the edge... of version range

@Guillaume you are right on findEntries part, this will break with
maven execution.

@Grzegorz I do not negate that version, metadata or range resolving
works. It does with some small exceptions (see PAXURL-342). What
doesn't work is re-use of ranges from maven build into karaf runtime.
When you use maven  and aether to build custom assembly
feature resolver in runtime will not work for certain cases because of
version edges.
When you will take a look on these two files:
https://github.com/splatch/maven-osgi-resolver/blob/master/shared/src/test/java/org/code_house/maven/osgi/resolver/shared/version/OsgiVersionRangeTest.java
https://github.com/splatch/maven-osgi-resolver/blob/master/test/src/test/java/org/eclipse/aether/util/version/GenericVersionRangeTest.java
and diff between them https://www.diffchecker.com/eyzDSSXU you will
find quite big area for troubles.

We about to start using ranges in build because we do not want to have
3 different minor versions installed without need. Using ranges in
both places acutally might speed up running integration tests because
metadata is already fetched and present in local repository. Otherwise
our integration tests bootstrap takes 2 minutes just to scan remotes
for new versions (see above pax url issue).

Cheers,
Lukasz

2017-02-01 12:02 GMT+01:00 Grzegorz Grzybek :
> Hello,
>
> Current pax-url-aether has already some custom services DInjected into
> RepositorySystem, like here[1]. Also in Fabric8v1 and in Karaf I did some
> tricks to implement non-canonical "update releases" scenario[2].
> So I think adding configuration options for pax-url to modify the way
> RepositorySystem is configured should not be a problem.
>
> What is the ultimate problem you want to solve? Is it (at lowest level) the
> ability to handle the below URLs?:
>
> osgi:install mvn:groupId/artifactId/[lowerBound, upperBound)
>
> Currently (pax-url 2.5.2) LATEST, RELEASE and SNAPSHOT versions should be
> handled correctly[3]:
>  - LATEST instructs AetherBasedResolver to fetch group/artifact
> metadata.xml and pick latest release OR snapshot
>  - RELEASE instructs AetherBasedResolver to fetch group/artifact
> metadata.xml and pick latest release
>  - SNAPSHOT instructs AetherBasedResolver to fetch group/artifact/version
> metadata.xml and pick latest snapshot
>
> e.g., in Fabric8v1 I added custom org.eclipse.aether.impl.MetadataResolver
> that is able to resolve metadata ("maven-metadata.xml") even in local
> repositories into which a SNAPSHOT was installed using `mvn clean install`
> - so the metadata is stored in "maven-metadata-local.xml" file - but the
> repo is used as remote repository (expecting to return "maven-metadata.xml"
> file.
>
> Are you using same version ranges in POM and in features.xml? (I don't
> argue with the fact that version ranges are used at all in POM :).
>
> regards
> Grzegorz
> ===
> [1]:
> https://github.com/ops4j/org.ops4j.pax.url/blob/master/pax-url-aether/src/main/java/org/ops4j/pax/url/mvn/internal/AetherBasedResolver.java#L1168-L1169
> [2]:
> https://ops4j1.jira.com/browse/PAXURL-322?focusedCommentId=37006=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-37006
> [3]: http://ggrzybek.blogspot.com/2016/10/using-maven-with-osgi-part-3.html
>
> 2017-02-01 11:44 GMT+01:00 Guillaume Nodet :
>
>> 2017-02-01 11:31 GMT+01:00 Łukasz Dywicki :
>>
>> > Thanks for your repiles. If we will manage to get pax-url accepting
>> > different version range resolving than maven default then I think we
>> > will not have any troubles with features left. What I was thinking
>> > about is moving my maven-osgi-resolver to karaf tooling and extending
>> > pax-url in the way it could pick up version range resolver
>> > implementation from fragment bundle. This way we could keep current
>> > behavior which might be used by someone but also let others use end to
>> > end range support. There are more "extension points" built into
>> > Aerther which gets normally wired by IoC. Since we can't and we do not
>> > want to embed yet-another-ioc-tool for low level stuff we would just
>> > need to make aether's ServiceLocator entries customizable. It is
>> > simple Map between role and implementation classes thus would not
>> > require anything more than bundle.findEntries. This way we could also
>> > solve pax-url troubles with wagon not loaded up properly.
>> >
>>
>> Won't that make things a bit more complicated for the karaf maven plugin ?
>> It does not run in OSGi, so the fragment stuff won't work.  If the problem
>> is the compatibility, it may still be easier to put the code in
>> pax-url-eather, and only have a flag to turn the version resolver into an
>> OSGi compatible one, so that the default would be unchanged.
>> I honestly don't mind, I'm just trying to find the best way to handle that.
>>
>>
>> > @Guillaume, we don't need to handle RELEASE flag because this part is
>> > not subject of version range

Re: [DISCUSS] Living on the edge... of version range

2017-02-01 Thread Grzegorz Grzybek

Hello,

Current pax-url-aether has already some custom services DInjected into
RepositorySystem, like here[1]. Also in Fabric8v1 and in Karaf I did some
tricks to implement non-canonical "update releases" scenario[2].
So I think adding configuration options for pax-url to modify the way
RepositorySystem is configured should not be a problem.

What is the ultimate problem you want to solve? Is it (at lowest level) the
ability to handle the below URLs?:

osgi:install mvn:groupId/artifactId/[lowerBound, upperBound)

Currently (pax-url 2.5.2) LATEST, RELEASE and SNAPSHOT versions should be
handled correctly[3]:
 - LATEST instructs AetherBasedResolver to fetch group/artifact
metadata.xml and pick latest release OR snapshot
 - RELEASE instructs AetherBasedResolver to fetch group/artifact
metadata.xml and pick latest release
 - SNAPSHOT instructs AetherBasedResolver to fetch group/artifact/version
metadata.xml and pick latest snapshot

e.g., in Fabric8v1 I added custom org.eclipse.aether.impl.MetadataResolver
that is able to resolve metadata ("maven-metadata.xml") even in local
repositories into which a SNAPSHOT was installed using `mvn clean install`
- so the metadata is stored in "maven-metadata-local.xml" file - but the
repo is used as remote repository (expecting to return "maven-metadata.xml"
file.

Are you using same version ranges in POM and in features.xml? (I don't
argue with the fact that version ranges are used at all in POM :).

regards
Grzegorz
===
[1]:
https://github.com/ops4j/org.ops4j.pax.url/blob/master/pax-url-aether/src/main/java/org/ops4j/pax/url/mvn/internal/AetherBasedResolver.java#L1168-L1169
[2]:
https://ops4j1.jira.com/browse/PAXURL-322?focusedCommentId=37006=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-37006
[3]: http://ggrzybek.blogspot.com/2016/10/using-maven-with-osgi-part-3.html

2017-02-01 11:44 GMT+01:00 Guillaume Nodet :

> 2017-02-01 11:31 GMT+01:00 Łukasz Dywicki :
>
> > Thanks for your repiles. If we will manage to get pax-url accepting
> > different version range resolving than maven default then I think we
> > will not have any troubles with features left. What I was thinking
> > about is moving my maven-osgi-resolver to karaf tooling and extending
> > pax-url in the way it could pick up version range resolver
> > implementation from fragment bundle. This way we could keep current
> > behavior which might be used by someone but also let others use end to
> > end range support. There are more "extension points" built into
> > Aerther which gets normally wired by IoC. Since we can't and we do not
> > want to embed yet-another-ioc-tool for low level stuff we would just
> > need to make aether's ServiceLocator entries customizable. It is
> > simple Map between role and implementation classes thus would not
> > require anything more than bundle.findEntries. This way we could also
> > solve pax-url troubles with wagon not loaded up properly.
> >
>
> Won't that make things a bit more complicated for the karaf maven plugin ?
> It does not run in OSGi, so the fragment stuff won't work.  If the problem
> is the compatibility, it may still be easier to put the code in
> pax-url-eather, and only have a flag to turn the version resolver into an
> OSGi compatible one, so that the default would be unchanged.
> I honestly don't mind, I'm just trying to find the best way to handle that.
>
>
> > @Guillaume, we don't need to handle RELEASE flag because this part is
> > not subject of version range resolution but VersionResolver. This is
> > piece of logic we would not (hopefully) need to amend.
> >
> > If you will take a look on my current implementation there is mixed
> logic:
> > https://github.com/splatch/maven-osgi-resolver/blob/
> > master/compatible/src/main/java/org/code_house/maven/
> > osgi/resolver/compatible/CompatibleOsgiVersionRangeResolver.java#L87
> > https://github.com/splatch/maven-osgi-resolver/blob/
> > master/strict/src/main/java/org/code_house/maven/osgi/resolver/strict/
> > StrictOsgiVersionRangeResolver.java#L80
> >
> > First implementation uses Maven ordering of versions meaning it
> > preffers releases over snapshots in selected range. Second
> > implementation behaves as OSGi, meaning it will ignore snapshot and
> > use regular qualifier comparision but more importantly it will also
> > accept just 3.4.0 as a range without upper bound.
> >
> > Best regards,
> > Lukasz
> >
> > 2017-02-01 9:44 GMT+01:00 Jean-Baptiste Onofré :
> > > Hi Lukasz,
> > >
> > > Thanks for your detailed e-mail and I fully agree with you.
> > >
> > > I guess the first step would be to improve the version range support in
> > > Maven URL, and after in the feature resolver.
> > >
> > > Correct ?
> > >
> > > Regards
> > > JB
> > >
> > >
> > > On 02/01/2017 02:05 AM, Łukasz Dywicki wrote:
> > >>
> > >> Dear receivers,
> > >> I would like to summarize my research and fight to align version range
> > >> handling in

Re: [DISCUSS] Living on the edge... of version range

2017-02-01 11:31 GMT+01:00 Łukasz Dywicki :

> Thanks for your repiles. If we will manage to get pax-url accepting
> different version range resolving than maven default then I think we
> will not have any troubles with features left. What I was thinking
> about is moving my maven-osgi-resolver to karaf tooling and extending
> pax-url in the way it could pick up version range resolver
> implementation from fragment bundle. This way we could keep current
> behavior which might be used by someone but also let others use end to
> end range support. There are more "extension points" built into
> Aerther which gets normally wired by IoC. Since we can't and we do not
> want to embed yet-another-ioc-tool for low level stuff we would just
> need to make aether's ServiceLocator entries customizable. It is
> simple Map between role and implementation classes thus would not
> require anything more than bundle.findEntries. This way we could also
> solve pax-url troubles with wagon not loaded up properly.
>

Won't that make things a bit more complicated for the karaf maven plugin ?
It does not run in OSGi, so the fragment stuff won't work.  If the problem
is the compatibility, it may still be easier to put the code in
pax-url-eather, and only have a flag to turn the version resolver into an
OSGi compatible one, so that the default would be unchanged.
I honestly don't mind, I'm just trying to find the best way to handle that.


> @Guillaume, we don't need to handle RELEASE flag because this part is
> not subject of version range resolution but VersionResolver. This is
> piece of logic we would not (hopefully) need to amend.
>
> If you will take a look on my current implementation there is mixed logic:
> https://github.com/splatch/maven-osgi-resolver/blob/
> master/compatible/src/main/java/org/code_house/maven/
> osgi/resolver/compatible/CompatibleOsgiVersionRangeResolver.java#L87
> https://github.com/splatch/maven-osgi-resolver/blob/
> master/strict/src/main/java/org/code_house/maven/osgi/resolver/strict/
> StrictOsgiVersionRangeResolver.java#L80
>
> First implementation uses Maven ordering of versions meaning it
> preffers releases over snapshots in selected range. Second
> implementation behaves as OSGi, meaning it will ignore snapshot and
> use regular qualifier comparision but more importantly it will also
> accept just 3.4.0 as a range without upper bound.
>
> Best regards,
> Lukasz
>
> 2017-02-01 9:44 GMT+01:00 Jean-Baptiste Onofré :
> > Hi Lukasz,
> >
> > Thanks for your detailed e-mail and I fully agree with you.
> >
> > I guess the first step would be to improve the version range support in
> > Maven URL, and after in the feature resolver.
> >
> > Correct ?
> >
> > Regards
> > JB
> >
> >
> > On 02/01/2017 02:05 AM, Łukasz Dywicki wrote:
> >>
> >> Dear receivers,
> >> I would like to summarize my research and fight to align version range
> >> handling in different parts of karaf related projects. As some of you
> >> might not know version ranges are working differently depending on
> >> context we are working in. In general most of logic stays the same
> >> while there are some edge cases which breaks up everything. But let me
> >> start from begining.
> >>
> >> Karaf is OSGi related project which keeps very nice integration with
> >> maven based repositories thanks to pax-url. Both environments do
> >> support ranges in quite different way, an example of maven range
> >> understanding is described in maven enforcer plugin documentation [1].
> >> Reason why ranges are working differently here and there is a maven
> >> snapshot version and understanding of released version. Osgi framework
> >> does not distinguish any of these. It has knowledge of major, minor
> >> and micro parts of an version and uses them for comparision but the
> >> qualifier is just a text which might be used for sorting artifacts
> >> with same number. This means that for Maven 3.0-SNAPSHOT version is
> >> lower than 3.0. In maven there is also knowledge of alpha, beta, rc,
> >> cr, milestone, ga and sp (service pack) release types [2].
> >>
> >> Now lets come to places which are using or might be using version
> >> ranges in typical Karaf based project:
> >> - OSGi framework for wiring in packages
> >> - pax-url-mvn for installing maven artifacts
> >> - karaf feature core for choosing dependant features
> >> - maven for including dependant artifacts (ie. feature sets/KARs etc)
> >> - karaf-maven-plugin for building assemblies
> >>
> >> When any of range definitions is crossing osgi-maven world problems
> >> starts to happen. For example range such [2.18, 2.19) in maven will
> >> accept 2.19.0-SNAPSHOT while in OSGi it will not. This lead to
> >> situations that these two code parts behave completely differently
> >> (assuming that camel-core feature is just one bundle):
> >> mvn:org.apache.camel/camel-core/${camel.version}
> >> camel-core
> >> This will behave like above but not like bundle

Re: [DISCUSS] Living on the edge... of version range

Thanks for your repiles. If we will manage to get pax-url accepting
different version range resolving than maven default then I think we
will not have any troubles with features left. What I was thinking
about is moving my maven-osgi-resolver to karaf tooling and extending
pax-url in the way it could pick up version range resolver
implementation from fragment bundle. This way we could keep current
behavior which might be used by someone but also let others use end to
end range support. There are more "extension points" built into
Aerther which gets normally wired by IoC. Since we can't and we do not
want to embed yet-another-ioc-tool for low level stuff we would just
need to make aether's ServiceLocator entries customizable. It is
simple Map between role and implementation classes thus would not
require anything more than bundle.findEntries. This way we could also
solve pax-url troubles with wagon not loaded up properly.

@Guillaume, we don't need to handle RELEASE flag because this part is
not subject of version range resolution but VersionResolver. This is
piece of logic we would not (hopefully) need to amend.

If you will take a look on my current implementation there is mixed logic:
https://github.com/splatch/maven-osgi-resolver/blob/master/compatible/src/main/java/org/code_house/maven/osgi/resolver/compatible/CompatibleOsgiVersionRangeResolver.java#L87
https://github.com/splatch/maven-osgi-resolver/blob/master/strict/src/main/java/org/code_house/maven/osgi/resolver/strict/StrictOsgiVersionRangeResolver.java#L80

First implementation uses Maven ordering of versions meaning it
preffers releases over snapshots in selected range. Second
implementation behaves as OSGi, meaning it will ignore snapshot and
use regular qualifier comparision but more importantly it will also
accept just 3.4.0 as a range without upper bound.

Best regards,
Lukasz

2017-02-01 9:44 GMT+01:00 Jean-Baptiste Onofré :
> Hi Lukasz,
>
> Thanks for your detailed e-mail and I fully agree with you.
>
> I guess the first step would be to improve the version range support in
> Maven URL, and after in the feature resolver.
>
> Correct ?
>
> Regards
> JB
>
>
> On 02/01/2017 02:05 AM, Łukasz Dywicki wrote:
>>
>> Dear receivers,
>> I would like to summarize my research and fight to align version range
>> handling in different parts of karaf related projects. As some of you
>> might not know version ranges are working differently depending on
>> context we are working in. In general most of logic stays the same
>> while there are some edge cases which breaks up everything. But let me
>> start from begining.
>>
>> Karaf is OSGi related project which keeps very nice integration with
>> maven based repositories thanks to pax-url. Both environments do
>> support ranges in quite different way, an example of maven range
>> understanding is described in maven enforcer plugin documentation [1].
>> Reason why ranges are working differently here and there is a maven
>> snapshot version and understanding of released version. Osgi framework
>> does not distinguish any of these. It has knowledge of major, minor
>> and micro parts of an version and uses them for comparision but the
>> qualifier is just a text which might be used for sorting artifacts
>> with same number. This means that for Maven 3.0-SNAPSHOT version is
>> lower than 3.0. In maven there is also knowledge of alpha, beta, rc,
>> cr, milestone, ga and sp (service pack) release types [2].
>>
>> Now lets come to places which are using or might be using version
>> ranges in typical Karaf based project:
>> - OSGi framework for wiring in packages
>> - pax-url-mvn for installing maven artifacts
>> - karaf feature core for choosing dependant features
>> - maven for including dependant artifacts (ie. feature sets/KARs etc)
>> - karaf-maven-plugin for building assemblies
>>
>> When any of range definitions is crossing osgi-maven world problems
>> starts to happen. For example range such [2.18, 2.19) in maven will
>> accept 2.19.0-SNAPSHOT while in OSGi it will not. This lead to
>> situations that these two code parts behave completely differently
>> (assuming that camel-core feature is just one bundle):
>> mvn:org.apache.camel/camel-core/${camel.version}
>> camel-core
>> This will behave like above but not like bundle statement:
>>
>> mvn:org.apache.camel.karaf/features/${camel.version}/xml/features
>>
>> There are some attempts to work around that by using versions starting
>> from ie 2.18.1 so version beginning works just fine but still there is
>> problem of range end. To exclude 2.19-SNAPSHOT in maven you must use
>> "2.19.min" which in osgi will acceptversion 2.19.. Obviously there is
>> also no way to influence 3rd party so they do not release version
>> 4.1.0 but 4.1.1 just for our environment pleasure.
>>
>> For me it's quite big issue because hitting us on daily basis. We have
>> quite few modules (around 400) which are usualy moving together but
>> they should be keeping

Re: [VOTE] Apache Karaf (Container) 4.1.0 release


-1 (binding)

Due to a severe issue on the shell commands (the commands are not 
available after a restart due to an issue with the wiring store), I 
propose to cancel this vote to fix and redo a new one.


Regards
JB

On 01/31/2017 12:43 PM, Jean-Baptiste Onofré wrote:

Hi all,

I submit Karaf (Container) 4.1.0 release to your vote.

Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12332799


Staging Repository:
https://repository.apache.org/content/repositories/orgapachekaraf-1088/

Git Tag:
karaf-4.1.0

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 48 hours.

Thanks,
Regards
JB


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

[CANCEL][VOTE] Apache Karaf (Container) 4.1.0 release

Due to the previous e-mail, I cancel this vote to prepare a new one with 
the fix.


Sorry about that.

Regards
JB

On 01/31/2017 12:43 PM, Jean-Baptiste Onofré wrote:

Hi all,

I submit Karaf (Container) 4.1.0 release to your vote.

Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12332799


Staging Repository:
https://repository.apache.org/content/repositories/orgapachekaraf-1088/

Git Tag:
karaf-4.1.0

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 48 hours.

Thanks,
Regards
JB


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

Re: Problems with 3rd party commands in 4.1.0

2017-02-01 Thread Christian Schneider


I found a bit more now.

The shell.console fragment itself also is in state installed while it 
should be resolved.
If I manually refresh shell.core then the fragment shell.console goes to 
state resolved and the came command bundle can be started.


Christian

On 01.02.2017 10:46, Christian Schneider wrote:

I can reproduce the issue.
I think it might be a bug in the resolver.

What I found:
Camel commands import this package: 
(&(osgi.wiring.package=org.apache.karaf.shell.console)(version>=3.0.0)(!(version>=5.0.0)))


The exported packages show this:
org.apache.karaf.shell.console  │ 
2.3.0   │ 42 │ org.apache.karaf.shell.console
org.apache.karaf.shell.console  │ 
4.1.0   │ 42 │ org.apache.karaf.shell.console


So the package is exported in two versions. The version 2.3.0 would 
not match the range camel imports, the 4.1.0 version would match it.
I suspect that the resolver behaves differently depending on which 
version it checks first. If it checks the 4.1.0 first it works, if it 
checks the 2.1.0 version first it fails.
I guess it should check both versions and take the working one but 
apparently it does not.


Unfortunately I do not know the implementation well enough to check or 
fix this but maybe it helps Guillaume to find the issue :-)


Christian

On 31.01.2017 21:42, Krzysztof Sobkowiak wrote:

Hi

While testing 4.1.0 I have observed following issue.

karaf@root()> feature:repo-add camel 2.18.2 21:35:06
Adding feature url 
mvn:org.apache.camel.karaf/apache-camel/2.18.2/xml/features

karaf@root()> feature:install camel 21:35:19
karaf@root()> camel 21:35:26
camel   camel:context-list 
camel:eip-explain   camel:rest-api-doc 
camel:route-profile camel:route-start
camel   camel:context-resume 
camel:eip-explain   camel:rest-registry-list 
camel:route-profile camel:route-stop
camel:component-listcamel:context-resume 
camel:endpoint-explain  camel:rest-registry-list 
camel:route-reset-stats camel:route-stop
camel:component-listcamel:context-start 
camel:endpoint-explain  camel:rest-show 
camel:route-reset-stats camel:route-suspend
camel:context-inflight  camel:context-start 
camel:endpoint-list camel:rest-show 
camel:route-resume  camel:route-suspend
camel:context-inflight  camel:context-stop 
camel:endpoint-list camel:route-info camel:route-resume
camel:context-info  camel:context-stop 
camel:endpoint-statscamel:route-info camel:route-show
camel:context-info  camel:context-suspend 
camel:endpoint-statscamel:route-list camel:route-show
camel:context-list  camel:context-suspend 
camel:rest-api-doc  camel:route-list camel:route-start


The commands are available and work. But after Karaf restart they are 
no more available and the log contains following error:


2017-01-31 21:37:25,415 | ERROR | FelixStartLevel  | 
Felix|  -  -  | Bundle 
org.apache.camel.karaf.camel-karaf-commands [57] Error starting 
mvn:org.apache.camel.karaf/camel-karaf-commands/2.18.2 
(org.osgi.framework.BundleException: Unable to resolve 
org.apache.camel.karaf.camel-karaf-commands [57](R 57.0): missing 
requirement [org.apache.camel.karaf.camel-karaf-commands [57](R 
57.0)] osgi.wiring.package; 
(&(osgi.wiring.package=org.apache.karaf.shell.console)(version>=3.0.0)(!(version>=5.0.0))) 
[caused by: Unable to resolve org.apache.karaf.shell.console [42](R 
42.0): missing requirement [org.apache.karaf.shell.console [42](R 
42.0)] osgi.wiring.host; 
(&(osgi.wiring.host=org.apache.karaf.shell.core)(bundle-version>=0.0.0))] 
Unresolved requirements: 
[[org.apache.camel.karaf.camel-karaf-commands [57](R 57.0)] 
osgi.wiring.package; 
(&(osgi.wiring.package=org.apache.karaf.shell.console)(version>=3.0.0)(!(version>=5.0.0)))])
org.osgi.framework.BundleException: Unable to resolve 
org.apache.camel.karaf.camel-karaf-commands [57](R 57.0): missing 
requirement [org.apache.camel.karaf.camel-karaf-commands [57](R 
57.0)] osgi.wiring.package; 
(&(osgi.wiring.package=org.apache.karaf.shell.console)(version>=3.0.0)(!(version>=5.0.0))) 
[caused by: Unable to resolve org.apache.karaf.shell.console [42](R 
42.0): missing requirement [org.apache.karaf.shell.console [42](R 
42.0)] osgi.wiring.host; 
(&(osgi.wiring.host=org.apache.karaf.shell.core)(bundle-version>=0.0.0))] 
Unresolved requirements: 
[[org.apache.camel.karaf.camel-karaf-commands [57](R 57.0)] 
osgi.wiring.package; 
(&(osgi.wiring.package=org.apache.karaf.shell.console)(version>=3.0.0)(!(version>=5.0.0)))]
 at 
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4111) 
[?:?]
 at org.apache.felix.framework.Felix.startBundle(Felix.java:2117) 
[?:?]
 at 
org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1371) 
[?:?]
 at

Re: Problems with 3rd party commands in 4.1.0

2017-02-01 Thread Christian Schneider


I can reproduce the issue.
I think it might be a bug in the resolver.

What I found:
Camel commands import this package: 
(&(osgi.wiring.package=org.apache.karaf.shell.console)(version>=3.0.0)(!(version>=5.0.0)))


The exported packages show this:
org.apache.karaf.shell.console  │ 
2.3.0   │ 42 │ org.apache.karaf.shell.console
org.apache.karaf.shell.console  │ 
4.1.0   │ 42 │ org.apache.karaf.shell.console


So the package is exported in two versions. The version 2.3.0 would not 
match the range camel imports, the 4.1.0 version would match it.
I suspect that the resolver behaves differently depending on which 
version it checks first. If it checks the 4.1.0 first it works, if it 
checks the 2.1.0 version first it fails.
I guess it should check both versions and take the working one but 
apparently it does not.


Unfortunately I do not know the implementation well enough to check or 
fix this but maybe it helps Guillaume to find the issue :-)


Christian

On 31.01.2017 21:42, Krzysztof Sobkowiak wrote:

Hi

While testing 4.1.0 I have observed following issue.

karaf@root()> feature:repo-add camel 2.18.2 
   
  21:35:06
Adding feature url mvn:org.apache.camel.karaf/apache-camel/2.18.2/xml/features
karaf@root()> feature:install camel 
   
  21:35:19
karaf@root()> camel 
   
  21:35:26
camel   camel:context-list  camel:eip-explain   
camel:rest-api-doc  camel:route-profile camel:route-start
camel   camel:context-resumecamel:eip-explain   
camel:rest-registry-listcamel:route-profile camel:route-stop
camel:component-listcamel:context-resumecamel:endpoint-explain  
camel:rest-registry-listcamel:route-reset-stats camel:route-stop
camel:component-listcamel:context-start camel:endpoint-explain  
camel:rest-show camel:route-reset-stats camel:route-suspend
camel:context-inflight  camel:context-start camel:endpoint-list 
camel:rest-show camel:route-resume  camel:route-suspend
camel:context-inflight  camel:context-stop  camel:endpoint-list 
camel:route-infocamel:route-resume
camel:context-info  camel:context-stop  camel:endpoint-stats
camel:route-infocamel:route-show
camel:context-info  camel:context-suspend   camel:endpoint-stats
camel:route-listcamel:route-show
camel:context-list  camel:context-suspend   camel:rest-api-doc  
camel:route-listcamel:route-start

The commands are available and work. But after Karaf restart they are no more 
available and the log contains following error:

2017-01-31 21:37:25,415 | ERROR | FelixStartLevel  | Felix|  -  -  | Bundle 
org.apache.camel.karaf.camel-karaf-commands [57] Error starting 
mvn:org.apache.camel.karaf/camel-karaf-commands/2.18.2 (org.osgi.framework.BundleException: Unable to 
resolve org.apache.camel.karaf.camel-karaf-commands [57](R 57.0): missing requirement 
[org.apache.camel.karaf.camel-karaf-commands [57](R 57.0)] osgi.wiring.package; 
(&(osgi.wiring.package=org.apache.karaf.shell.console)(version>=3.0.0)(!(version>=5.0.0))) 
[caused by: Unable to resolve org.apache.karaf.shell.console [42](R 42.0): missing requirement 
[org.apache.karaf.shell.console [42](R 42.0)] osgi.wiring.host; 
(&(osgi.wiring.host=org.apache.karaf.shell.core)(bundle-version>=0.0.0))] Unresolved requirements: 
[[org.apache.camel.karaf.camel-karaf-commands [57](R 57.0)] osgi.wiring.package; 
(&(osgi.wiring.package=org.apache.karaf.shell.console)(version>=3.0.0)(!(version>=5.0.0)))])
org.osgi.framework.BundleException: Unable to resolve org.apache.camel.karaf.camel-karaf-commands [57](R 
57.0): missing requirement [org.apache.camel.karaf.camel-karaf-commands [57](R 57.0)] osgi.wiring.package; 
(&(osgi.wiring.package=org.apache.karaf.shell.console)(version>=3.0.0)(!(version>=5.0.0))) 
[caused by: Unable to resolve org.apache.karaf.shell.console [42](R 42.0): missing requirement 
[org.apache.karaf.shell.console [42](R 42.0)] osgi.wiring.host; 
(&(osgi.wiring.host=org.apache.karaf.shell.core)(bundle-version>=0.0.0))] Unresolved requirements: 
[[org.apache.camel.karaf.camel-karaf-commands [57](R 57.0)] osgi.wiring.package; 
(&(osgi.wiring.package=org.apache.karaf.shell.console)(version>=3.0.0)(!(version>=5.0.0)))]
 at

Re: [DISCUSS] Living on the edge... of version range

Hi Lukasz,

Thanks for your detailed e-mail and I fully agree with you.

I guess the first step would be to improve the version range support in
Maven URL, and after in the feature resolver.

Correct ?

Regards
JB

On 02/01/2017 02:05 AM, Łukasz Dywicki wrote:

Dear receivers,
I would like to summarize my research and fight to align version range
handling in different parts of karaf related projects. As some of you
might not know version ranges are working differently depending on
context we are working in. In general most of logic stays the same
while there are some edge cases which breaks up everything. But let me
start from begining.

Karaf is OSGi related project which keeps very nice integration with
maven based repositories thanks to pax-url. Both environments do
support ranges in quite different way, an example of maven range
understanding is described in maven enforcer plugin documentation [1].
Reason why ranges are working differently here and there is a maven
snapshot version and understanding of released version. Osgi framework
does not distinguish any of these. It has knowledge of major, minor
and micro parts of an version and uses them for comparision but the
qualifier is just a text which might be used for sorting artifacts
with same number. This means that for Maven 3.0-SNAPSHOT version is
lower than 3.0. In maven there is also knowledge of alpha, beta, rc,
cr, milestone, ga and sp (service pack) release types [2].

Now lets come to places which are using or might be using version
ranges in typical Karaf based project:
- OSGi framework for wiring in packages
- pax-url-mvn for installing maven artifacts
- karaf feature core for choosing dependant features
- maven for including dependant artifacts (ie. feature sets/KARs etc)
- karaf-maven-plugin for building assemblies

When any of range definitions is crossing osgi-maven world problems
starts to happen. For example range such [2.18, 2.19) in maven will
accept 2.19.0-SNAPSHOT while in OSGi it will not. This lead to
situations that these two code parts behave completely differently
(assuming that camel-core feature is just one bundle):
mvn:org.apache.camel/camel-core/${camel.version}
camel-core
This will behave like above but not like bundle statement:
mvn:org.apache.camel.karaf/features/${camel.version}/xml/features

There are some attempts to work around that by using versions starting
from ie 2.18.1 so version beginning works just fine but still there is
problem of range end. To exclude 2.19-SNAPSHOT in maven you must use
"2.19.min" which in osgi will acceptversion 2.19.. Obviously there is
also no way to influence 3rd party so they do not release version
4.1.0 but 4.1.1 just for our environment pleasure.

For me it's quite big issue because hitting us on daily basis. We have
quite few modules (around 400) which are usualy moving together but
they should be keeping contract/interfaces on micro versions. This
inconsistency lives in Karaf and Pax Url since very long time and
current project infrastructure is not ready to changing that. From
other hand keeping this inconsistent will lead to ultimate fail some
day and users frustration as well (see KARAF-4105 [3]). Worth to point
that this issue pointed out brieefly this issue but didn't solve cause
but aligned just one place to maven's logic while keeping all others
the same.

I took my chance and managed to get maven understanding osgi version
ranges thanks to core extensions mechanism they have [4]. I also
managed to correct shaded aether inside pax-url [5] so it use version
ranges in same way as maven. What I completely failed is making a
custom distro built with my pax-url. Since pax-url-mvn is a startup
bundle I can't use overrides for changing it's version and I can't
influence its classes using fragment bundle (yet). To get my own
pax-url I would ned to get rid of framework, but then I have to copy
bunch of resources. It would be fine for temporary prosthesis but I
can't rely on it forever. I also got into troubles with
karaf-maven-plugin when setting extra dependency with "my own aether".

As you now know - there is lots of troubles with version ranges making
their usage in end-to-end build very difficult. I would love to get
this solved as soon as possible in 4.1 without holding current
release. Aligning all these version range handling is definitelly
doable because from Maven/Aether perspective there is an SPI for that.
We just need to deliver it our own VersionRangeResolver interface [6].
Open question is shall we keep ordering of versions same as maven
breaking up a little osgi range understanding here.

[1]
http://maven.apache.org/components/enforcer/enforcer-rules/versionRanges.html
[2]
https://github.com/eclipse/aether-core/blob/1.0.x/aether-util/src/main/java/org/eclipse/aether/util/version/GenericVersion.java#L183
[3] https://issues.apache.org/jira/browse/KARAF-4105
[4] http://markmail.org/message/z6x27umabwqhdjvy
[5]

Re: [DISCUSS] Living on the edge... of version range