Community
Participate
Working Groups
Please add a new "composite" element which contains multiple aggregations. This would involve: - coming up with a decent name for the new top level element and possibly also for the old one which now can (and will) appear multiple times as a child node of the new top level element - implementing a transformer of old models to the new format - updating the editor to handle the new model (e.g., the code dealing with sending/handling notifications of changes in the editor expects the current structure of the model; when the structure is changed, the notifications may not propagate as expected or even result in hard errors)
The following was implemented in revision #1440: - updated the model - updated the editor Note that the changes to the model are backwards compatible, so no explicit transformer is needed. We may still want to change the name of the "Aggregation" node, so leaving the issue open.
The aggregator engine also needs to be updated to make use of the new model structure. This was implicit in the intent of this enhancement but probably should have been called out explicitly.
The engine has been updated to run verification and metadata mirroring phases in a loop for each defined "aggregate" including the main/implicit one. The artifact mirroring is still run only once and it mirrors artifacts for all the defined aggregates.
Isn't this enhancement now complete?
The way things are expressed in the new model right now is perceived as somewhat counter intuitive. We need to simplify the model to make it more clear what sets of IU's that are validated together. For lack of better term, let's call such a set a "Validation Set" (VS) for now. Validation Set: A set of IU's that will be validated once for each configuration. In many cases it will be desirable to "extend" a VS. VS B extends VS A The meaning is that VS B now contains everything from VS A and then some. This declaration isn't very meaningful by itself but it makes a lot more sense when we also add: VS C extends VS A B and C now shares everything in A but but different (and possibly conflicting) additions. With this construct it is often sensible to regard VS A as "abstract" in the sense that it should not be validated on its own. I suggest that we change the current Aggregator model so that it contains the following: Aggregator contains: 0..* validationSets (ValidationSet) 0..* configurations (Configuration) 0..* contacts (Contact) 0..* mavenMappings ValidationSet contains: 0..* extends (non containing references to ValidationSet) 0..* contributions (Contribution) 0..* customCategories (CustomCategory) 0..* validationRepositories The transformer for old models will simply create one VS and move all contributions, custom categories, and validationRepositories into it. The VS is all about describing the aggregation input and how things are validated. It should not affect how the result is constituted. In particular, dividing things into different VSs doesn't mean that we create different repositories on output.
This seems like a good proposal to me. It addresses the primary requirements: * to be able to have multiple versions of the same singleton IU in the same repo. * to make the model structure more intuitive when doing the above.
Fixed in revision 1500.
*** Bug 338409 has been marked as a duplicate of this bug. ***
I will confess I've only skim read this enhancement request, and understand basic idea ... but, not sure what it would look like in practice. Has the doc (manual) been updated? Are there examples given there? And ... if not ... I'm sure I'll see it "in use" eventually ... so not urgent. I won't update the aggregator used for Simultaneous release right away (since, I am on vacation :) so feel free to remind me if/when someone starts using this and needs it updated. Thanks,
*** Bug 314016 has been marked as a duplicate of this bug. ***
Confirmed fixed.
.
[Bookkeeping change only. Moving bugs to the new "home" of aggregator, CBI. Made no changes to assignee's for closed bugs, even though some were old inbox.]
