So I added maven dependencies for the Karaf CXF features and then the Camel Karaf features as provided dependencies. I removed the <repository> entry I used to have in my feature.xml for Camel. Now when I try to build my features XML, Maven can't resolve the pax-features-xml because the feature repository URL uses an escaped [ for the feature range:
Downloading from...../org/ops4j/pax/cdi/pax-cdi-features/%5B1,2)/pax-cdi-features-%5B1,2)-features.xml Then it goes on to say, "The following artifacts could not be resolved: org.ops4j.pax.cdi:pax-cdi-features:xml:features:[1,2) (absent)" I'm using Karaf 4.4.3, Is that feature coming from the Karaf enterprise KAR? My features.xml isn't specifying that repository nor any of those features in the descriptor I am generating. Ryan On Wed, Aug 9, 2023 at 11:56 PM Ryan Moquin <[email protected]> wrote: > I'm revisiting this now, I had tried to blacklist the feature.xml which > didn't work. My issue isn't that I'm against having a feature template, I > already do that as needed to make sure my feature.xml comes out how I > want. It seems like the easiest and quickest thing would be for me to copy > all the camel features into one of my feature.xml files so that I can then > include a version of CXF that doesn't have a range so the feature can be > generated. I also had just noticed that the Karaf plugin generates > warnings about this problem: > > Matched URI can't use version ranges: > mvn:org.apache.cxf.karaf/apache-cxf/[3,4)/xml/features > > As well about these: > Matched URI can't use version ranges: > mvn:org.ops4j.pax.cdi/pax-cdi-features/[1,2)/xml/features > Matched URI can't use version ranges: > mvn:org.hibernate.validator/hibernate-validator-osgi-karaf-features/[6.2,6.2]/xml/features > > I'm not specifying to use either of those two other repos, but it feels > like after I get around the cxf issue, I'm then going to need to copy over > the contents of pax-cdi-features and > hibernate-validator-osgi-karaf-features into one of my features file as > well? It looks like those are going to be the next to fail since they are > listed after the cxf one in the log. That's the only way I can think of to > manually get around this. Or is there something else I'm missing? > > Thanks!! > > Ryan > > On Mon, May 15, 2023 at 3:08 PM [email protected] <[email protected]> > wrote: > >> Unless you have particularly complicated needs, I would think that >> generating is *better* in theory. It means you only have to maintain >> your dependency tree once, rather than twice. >> >> >> >> However, currently generation is in that valley where it’s useful for >> basic cases, but not robust enough to be able to declaratively say how to >> handle “problem” dependencies, or to layer more complicated things like >> conditionals or capabilities on top. >> >> >> >> I’m running into a similar issue now with the features-add-to-repository >> mojo, where it doesn’t support the same excluding/blacklisting that the >> assembly mojo does. (I’m trying to upgrade our camel finally, a little at a >> time, but the 2.20 feature files have a broken cxf dependency and it’s >> making things difficult. I’m about to just make an assembly and throw >> everything away but the system/ directory.) >> >> >> >> *From: *Ryan Moquin <[email protected]> >> *Date: *Monday, May 15, 2023 at 1:05 PM >> *To: *[email protected] <[email protected]> >> *Subject: *Re: Feature XML generation >> >> I like the idea of keeping it around to at least assist in the generation >> of features. At that point, I don't mind tweaking and customizing it, it's >> just a pain to have to do it all by hand when there are a lot of >> dependencies. >> >> >> >> >> >> On Sun, May 14, 2023 at 3:05 PM Jean-Baptiste Onofré <[email protected]> >> wrote: >> >> Hi Paul, >> >> fair enough, but as soon as you need a "complex/detailed" features >> repo, you need a XML template, so basically writing the repo by hand >> :) >> >> Regards >> JB >> >> On Thu, May 11, 2023 at 8:50 PM Paul Fraser <[email protected]> wrote: >> > >> > Hi JB, >> > >> > "I'm thinking about removing the generate mojo as some point." >> > >> > Please do not remove it, it is most useful when using Vaadin which >> pulls in many bundles. >> > >> > Paul Fraser >> > >> > On 12/05/2023 3:00 am, Jean-Baptiste Onofré wrote: >> > > Hi Ryan >> > > >> > > IMHO, it's always better to create the features XML by hand (and >> verify). >> > > >> > > I'm thinking about removing the generate mojo as some point. >> > > >> > > Regards >> > > JB >> > > >> > > On Tue, May 9, 2023 at 3:58 PM Ryan Moquin <[email protected]> >> wrote: >> > >> I've been getting the same error as mentioned in KARAF-5999 ( >> https://issues.apache.org/jira/browse/KARAF-5999), but I'm just trying >> to generate the features xml for a subproject. This of course happened >> after I upgraded everything to Camel 3 due to the CXF feature range usage. >> Is this going to be fixed soon? I need to decide if I need to either >> revert back to the older Camel or figure out another solution to this error: >> > >> >> > >> Failed to execute goal >> org.apache.karaf.tooling:karaf-maven-plugin:4.2.16:features-generate-descriptor >> (create-features) on project dp-processor: Unable to create features.xml >> file: org.apache.maven.plugin.MojoExecutionException: Cannot locate file >> for feature: org.apache.cxf.karaf:apache-cxf:xml:features:[3,4) at null -> >> [Help 1] >> > >> >> > >> Hopefully it's something that can be rectified soon. >> > >> >> > >> Thanks! >> > >> Ryan >> >>
