Re: [4.2.0.M1] - Assembly build failed with endorsed libraries

Ok, I will remove this tag. Thanks Le 7 nov. 2017 00:17, Jean-Baptiste Onofré a écrit : > > Hi, > > As Karaf 4.2.x targets Java 9, we had to change some stuff. As endorsed > doesn't > exist anymore in Java 9, tag should stay empty. > > Regards > JB > > On 11/06/2017

Re: [4.2.0.M1] - Assembly build failed with endorsed libraries

Hi, As Karaf 4.2.x targets Java 9, we had to change some stuff. As endorsed doesn't exist anymore in Java 9, tag should stay empty. Regards JB On 11/06/2017 09:12 PM, Francois Papon wrote: Hi, I just change the Karaf version of my custom distribution from 4.1.2 to 4.2.0.M1 and the maven

[4.2.0.M1] - Assembly build failed with endorsed libraries

Hi, I just change the Karaf version of my custom distribution from 4.1.2 to 4.2.0.M1 and the maven build failed on the assembly. The endorsed librairies are found by the plugin in the local repository but not copy in the lib/endorsed target directory. Here the plugin declaration with          

Re: version resolving

hi Guillaume, it starts with: Caused by: shaded.org.eclipse.aether.resolution.VersionRangeResolutionException: No highest version found for org.ops4j.pax.cdi:pax-cdi-features:xml:features:[1.0.0.RC1,2) but then it works! thank you for your help... m. On pondelok, 6. novembra 2017 14:26:28

Re: version resolving

In particular, change the etc/org.ops4j.pax.url.mvn.cfg with org.ops4j.pax.url.mvn.repositories= \ http://repo1.maven.org/maven2@id=central Also, remove your local ~/.m2/repository/org/ops4j/pax/cdi/pax-cdi-features It should do the trick. 2017-11-06 14:12 GMT+01:00 Guillaume Nodet

Re: version resolving

This is not really a bug imho, but there's no way to specify better the version range in maven. In order to work around this behavior, you need to remove maven snapshot repositories containing pax-cdi. This way, it should not be resolved. 2017-11-06 13:53 GMT+01:00 Michal Hlavac

Re: version resolving

it means that there is bug in CXF, right? Because I can't build offline karaf distribution with cxf-3.2.0 It searches for 1.0.0-SNAPSHOT on first start m. On pondelok, 6. novembra 2017 13:11:28 CET Guillaume Nodet wrote: Those version resolution are done by pax-url-aether which uses the

Re: version resolving

Those version resolution are done by pax-url-aether which uses the aether library (the same one used by maven). I think the behavior is correct, see https://cwiki.apache.org/confluence/display/MAVENOLD/Dependency+Mediation+and+Conflict+Resolution 2017-11-06 12:06 GMT+01:00 Michal Hlavac

Fragment-Bundle to pax-logging not getting resolved

Hey guys, i have stumbled upon some strage behaviour in the recent Karaf versions (4.1.2 and 4.1.3). However, it was working in Karaf 4.1.1 What I am trying to accomplish: I want to use a custom log42 Log Layout, so I am creating an extension bundle for the pax-logging bundle. I created a sample

version resolving

Hi, I would like to ask about version resolving in repository element of feature file. I am asking because of line 21 in https://github.com/apache/cxf/blob/cxf-3.2.1/osgi/karaf/features/src/main/resources/features.xml mvn:org.ops4j.pax.cdi/pax-cdi-features/[1.0.0.RC1,2)/xml/features When I

Re: Karaf Bundle stuck in “Starting”-status when trying to install feature programmatically

I'm not exactly sure what happens, especially, the fact that you're saying there's no log is weird. If you are programmatically calling the FeaturesService, can you make sure all exceptions caught from those calls are logged too ? Because I don't think the service will log an exception before