Version new rules #743
Version new rules #743
Conversation
changed a while ago to EntitySpecResolver; removes references to catalog items and hokey lookup
expand tests. some obscure ordering items are different now.
… tests, and usages
and bundle finder supports either, and does the conversion for you
support for persistence, and test
…ionedName OSGi versions are taken at the very last moment, allowing us to preserve brooklyn-recommended syntax throughout nearly all our code; and lookups/matches in OSGi space compare the OSGi-target
|
unrelated non-det test failure |
|
LGTM |
|
hi Alex, looks good but I did have some comments and concerns especially around the comparison of versions. I recorded the comments against #737 and #740 (and in apache/brooklyn-docs#198) rather than here, probably should just have put them here but was going in order!... let me know what you think. |
|
Updated with fixes to upstream PRs. |
|
I've had a further think about the versions as discussed in #740. In a (long) nutshell:
Re. the latter I'm imagining a case like your 'acme-cluster' (mail link) where someone has released a series of drafts, say, but I will have to understand that this will exclude
|
geomacy
left a comment
geomacy
left a comment
There was a problem hiding this comment.
Approved with one caveat in #743 (comment)
|
very good spot on as for OSGi ranges that may be a bit of a headache, or at least potentially a surprise to OSGi users. however so long as we can make it follow our scheme it should be fine: i would think anyone using a combination of qualified and unqualified versions would expect semver semantics where unqualified is last. in osgi people using qualifiers presumably always do so, and are used to using a datestamp or something similar to ensure ordering is correct and it will almost certainly still be correct. (IE I don't imagine anyone would intentionally use |
Auto wrap YAML BOMs as catalog bundles Wraps pure-YAML BOMs uploaded to catalog in a bundle, creating a name and version if needed. This allows us to see all items added as a unit. This will allow us to prefer loading co-defined items (though that's not fully done, still relies on preferring search path when doing item lookup), and to edit or remove that item as a set (crucially we now keep the BOM, previously we discarded it!). Docs changed to reflect this and explain differences in another PR. The basic wrapping was pretty simple but a surprising number of subtleties emerged which this fixes: * java scanning doesn't work in OSGi; docs and errors make this clear * impacts replacement semantics (now it does a hash on the bundle to make most things the same, though a re-post of a non-SNAPSHOT BOM that doesn't declare a bundle will now fail because the random bundle name is stored on the item as containingBundle and is different on a re-post; and needed extra work to remove leaked anonymous bundles) * had to change the way we set up the libraries / search path, to exclude this "bundle" (mainly so tests are unchanged, but also improves efficiency for simple BOMs; also the code is cleaner now) And there is one thing that emerged that I *haven't* fixed: on rebind it became vital to handle the situation where dependent bundles might not be loaded before the depender bundle; see failing test`testLongReferenceSequence`. Not entirely sure how to do this /cc @neykov @geomacy @aledsage. Depends on #743.
4 participants
Implements the behaviour discussed on ML re version syntax.
Places where OSGi syntax is required (ie registering/searching OSGi bundles) convert to the OSGi syntax. Everywhere else uses the version string exactly as supplied by the caller. Places where mappings to OSGi are not unique result in warnings.
The fixes the issue described in #672, and
catalog.bomfiles can (should) now use familiar maven/semver versions (#.#.#-qual) which most people seem to use everywhere else. This is converted to OSGi syntax (#.#.#.qual) when creating the bundle, or comparing with installed bundles, but that's all hidden from users (unless they go deep into OSGi).You can supply OSGi syntax (or even crazy things like
v1) in thecatalog.bom, and the syntax supplied is exactly what will be used in the Brooklyn catalog. There will be warnings if it does not follow the recommended syntax but they can be ignored.This builds on (and closes) #737 and #740, depending whether people want to review those independently or in the context of this.
Merge apache/brooklyn-docs#198 once this is merged.