L.S.,
Let me raise the issue for making the features-maven-plugin a bit more version-aware, as that seems to be the one that everyone agrees on already. For the version range on the features cross-references: Pax Mvn Url should be able to deal with version ranges already, so I'm guessing it uses the maven metadata already for this but I'm pretty sure one of the Pax Url developers around here will correct me if I'm wrong. Anyway, if that already works that way, it may be enough to just add maven-metadata.xml files to the system folder if we want to use version ranges on the bundles. For the features cross-references, I think it would be a good thing to look at the installed features descriptors first and not even bothering to let Pax Mvn Url do the dynamic resolution if we already have a suitable features descriptor installed for the version range in the URL. For the OBR discussion: The current implementation already resolves the optional imports based on the bundles installed and the ones listed in the feature to be installed. My first suggestion would not be to find a 'full' OBR repository file somewhere and just resolve all the optionals. Not only would that pull in way too much, it would also be very hard to control the actual version being used while building something like ServiceMix on top of Karaf. I was rather thinking to expand the OBR repository contents somewhat, either by adding information from other features than the one being installed or by indexing what's already sitting in the system folder as Dan suggested - either solution should work fine and would provide some balance between being able to control what's being used and still allow the OBR resolver to consider a few more options when picking the best set of versions available for a given task. Regards, Gert Vanthienen ------------------------ FuseSource Web: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ On Tue, Oct 25, 2011 at 12:52 AM, Daniel Kulp <[email protected]> wrote: > On Tuesday, October 25, 2011 12:11:57 AM Gert Vanthienen wrote: > > Reply versus reply all seems to become a difficult thing for my mind at > this > > time of the day ;) > > LOL.... > > inline.... > > > > >> > 2. Improve the features descriptor to allow specifying a > > >> > requirement > > >> > > >> (other > > >> > > >> > descriptor) with a version range and only install an additional > > >> > features>> > > >> url > > >> > > >> > if the requirement is not met (to avoid installing more than one > > >> > version>> > > >> of > > >> > > >> > the same descriptor) > > >> > > >> +1. Honestly, I'd like to see that on bundles as well: > > >> > > >> <bundle>mvn:org.apache.ws.security/wss4j/[1.6,1.7)</bundle> > > >> > > >> Useful when not using the OBR. > > > > > > Absolutely - we do want to make sure it can do that without requiring > > > full Maven resolution with metadata and things like that, as that > > > information is currently not available in the system folder. Perhaps > > > an implementation that looks in the system folder for a bundle matching > > > this requirement and then falls back to e.g. the 1.6 version when > > > there's no bundle there?> > > At that point, if there is a mvn URL, could it resolve it via the mvn > mechanisms? AKA, get the mavenmetadata.xml and look for the latest? > > Another option may be something like: > > <bundle range="[1.6,1.7)">mvn:org.apache.ws.security/wss4j/1.6.2</bundle> > > Where we specify an exact version, but provide an optional range that we > would > find "acceptable". This may be slightly more backwords compatible too if > the current versions ignore unknown attributes. (I'm really not sure) > > > > >> > 3. Allow the features service to resolve all boot features with a > > >> > single>> > > >> obr > > >> > > >> > in-memory repository to ensure picking up the latest and greatest > > >> > from > > >> > > >> the > > >> > > >> > available bundles > > >> > > >> #3, while interesting, leads to a bunch of other issues that would > > >> require a > > >> lot more testing and likely a lot of changes to the other project > > >> features.xml > > >> files. I was chatting with gnodet about this the other day as well. > > >> The > > >> OBR stuff really only considers imports and dependencies that are not > > >> marked > > >> optional. Thus, with something like CXF that has a bunch of things > > >> that are > > >> optional, if you use the OBR, a lot of things that used to work would > > >> no > > >> longer work. > > > > > > There's an option available for the org.apache.karaf.features.obr PID > > > that allows the OBR resolver to take optional imports into account as > > > well and try to resolve as many of those as possible, this has been > > > implemented to allow using the OBR resolver in e.g. ServiceMix where we > > > were bumping into similar issues with optional imports as the ones > > > you're looking at with CXF probably. > > Well, I think there needs to be something in between. If you resolve ALL > the > optionals, it will definitely take a lot longer and likely grab a LOT more > bundles. Especially if you have a full OBR there. CXF would pull in > all > kinds of stuff like eclipse stuff and sdo and jibx and all kinds of stuff > that wouldn't be there if not using an OBR. It's basically "resolve the > optionals for which we have the jars already there". If not already there, > don't bother. > > > Dan > > > > >> It might be good if the OBR resolver was able to look at the locally > > >> available > > >> bundles to resolve the imports as well. Doesn't need to go out to > > >> the > > >> internet and such, but at least check what has been pre-installed into > > >> the system dir. > > > > > > Yeah, that's why I suggested to do it for the boot features as a whole > - > > > a lot of those bundles, in a typical scenario, will already be sitting > > > in the local system folder anyway and if they're not there, the boot > > > features installation would be downloading them anyway so there's not > > > much overhead there in just doing the OBR resolution on those bundles > > > as a whole instead of by feature (as it is implemented now). > > > > > >> Dan > > >> > > >> > #1 looks very reasonable to me, so I'll raise that his in the > > >> > morning. > > >> > > >> How > > >> > > >> > about the other two? Any other suggestions to fix some of the > > >> > problems mentioned in this thread? > > >> > > > >> > Regards, > > >> > > > >> > Gert > > >> > > >> > On Oct 19, 2011 6:11 PM, "Johan Edstrom" <[email protected]> wrote: > > >> -- > > >> Daniel Kulp > > >> [email protected] > > >> http://dankulp.com/blog > > >> Talend - http://www.talend.com > > > > > > Regards, > > > > > > Gert > -- > Daniel Kulp > [email protected] > http://dankulp.com/blog > Talend - http://www.talend.com >
