As Valentin says, ARIES-361 made substantial improvements to the way in which we interact with OBR. This wasn't so much a bug fix as a complete rewrite.
-- Mark On 24 January 2011 07:51, Valentin Mahrwald <[email protected]> wrote: > The NoOpResolver by design does really what it says: nothing :) > > That means it will ignore any dangling package, service or require bundle > dependencies and simply go by what is in the EBA. For that reason the > NoOpResolver implementation is highly unfit for any real use outside testing. > In almost all cases you want the OBRAriesResolver instead. > > As for where this capability was added: the key players are > BundleResource.java, which is used by the RepositoryGenerator when creating > the OBR metadata. This takes require bundles into account by delegating to a > ModelledResource, which does the base parsing for required bundles. Most of > this was done in the area of ARIES-361. > > Regards, > > Valentin > > On 24 Jan 2011, at 06:06, Rex Wang wrote: > >> I just noticed: >> The NoOpResolver. This resolver assumes that all the required bundles are >> contained by value in the application and simply returns the information >> about the bundles in the application. >> >> Is that design to deal with the require-bundle headers? >> >> -Rex >> >> 2011/1/24 Rex Wang <[email protected]> >> >>> Hi devs, >>> >>> The jira https://issues.apache.org/jira/browse/ARIES-549 reports the >>> problem. >>> >>> But David says this should have been resolved in 0.3. I view the svn logs >>> of the OBRAriesResolver, but can not find any item corresponds to this >>> problem. >>> Can anybody give me any clue (or revision numbers) how this problem was >>> resolved? >>> >>> regards, >>> >>> -- >>> Lei Wang (Rex) >>> rwonly AT apache.org >>> >> >> >> >> -- >> Lei Wang (Rex) >> rwonly AT apache.org > >
