Hi Nick, I'm not quite sure what you're doing, so let's try clear some question marks from my view. core features in higher version, are you merely updating to newer available versions or are you creating "new" versions which will collide in future if those bundles are actually bumped to that version?
Is it possible that some other bundles/features do have requirements for certain features which are exactly the version from the std. repo. As an example take the http feature and the http commands, those commands require certain pax-web- bundles in certain versions. So might it be possible that you have some "transitive" dependencies in there somewhere? Could you give us a view of the customized features you got? regards, Achim 2015-09-17 16:50 GMT+02:00 Nick Baker <[email protected]>: > Hey All, > > We’re supplying customized versions for some of the core features: http, > kar in order to provide different bundles. These features are all versioned > higher than the stock ones and are indeed being used instead of the stock > ones at runtime. > > The issue is that in assembly these override features’ bundles are not > being added to the system/ repository. Production environments are > downloading them from maven which is unacceptable for our customers. It > seems that features-add-to-repository isn’t honoring the highest-version > feature the same way the FeaturesService is. > > Anyone run into this one before? I’m about to create a bogus feature with > these bundles, referenced in the assembly simply to get around the problem > but it’s not a long-term solution. > > Thanks, > Nick > -- Apache Member Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead blog <http://notizblog.nierbeck.de/> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> Software Architect / Project Manager / Scrum Master
