bundle / content api redesign

Lukas Krejci lkrejci at redhat.com
Tue Feb 5 12:02:14 UTC 2013


Yes, this needs to be well discussed and I appreciate your comments and the time you're putting into deciphering my tangled thoughts ;)

Before we go into the details on a call, I'd like to clear up the feeling you both seem to have gotten from the wiki page.

So far I've been dealing with the storage of the new system. To be frank, the storage of bundles is a hack and is duck-taped on to the the content system storage and that's why I chose content storage nomenclature over the bundle one (and I'd repeat - nomenclature, not the semantics). But that does NOT mean I want to deprecate bundle functionality. I'd say I'm doing quite a reverse. If you look at the new classes like PackageDestination, they closely mimick what bundle subsystem does and that is on purpose - I want to maintain the workflows of the bundle subsystem (even if I use different names for things) while also clearing up the domain model of the whole thing. So while some core concepts of the content subsystem stay - like PackageType and Package - they stay there because they are a) used by the bundle subsystem today, too, and b) because they fit well into the overall scheme.

I think one more aspect was important to me when I created this - the bundle subsystem is using the content subsystem for storage so ripping the content domain classes from under the bundles would, IMHO, be a more complex refactoring than doing the way I did. The content classes stay (even if only by name) and are enhanced and the bundle classes still can use these guys without us having to do semantic somersaults in our heads whenever we need to talk about the "old and new" at the same time.

But overall I am not too fussed about the naming. If you think we should stick with the bundle naming but you like the overall idea of the unified model then I am the happiest guy in the world - it would be the first time my design would stand your scrutiny :)

Lukas

----- Original Message -----
> From: "John Mazzitelli" <mazz at redhat.com>
> To: "rhq-devel" <rhq-devel at lists.fedorahosted.org>
> Sent: Monday, February 4, 2013 9:42:20 PM
> Subject: bundle / content api redesign
> 
> (This is more for Lukas, but it seems appropriate to discuss over the
> rhq-devel ML)
> 
> Lukas,
> 
> Jay and I went through the Bundles vs. Content design page,
> 
> https://docs.jboss.org/author/display/RHQ/Bundles+vs.+Content+-+On+Its+Head
> 
> In general the ideas sound good.
> 
> However, there are two things I'm questioning:
> 
> 1) this is a major re-design/re-implementation - I'm not sure if we
> need to be concerned with backward compatibility with the older
> content API (i.e. I think we should release this in RHQ 5 timeframe,
> the new major release should indicate it contains some backward
> incompatible changes with RHQ 4).
> 
> 2) (this is the bigger concern), it seems like you deferred to
> maintaining the Content/Package API and deprecated the Bundle API.
> In my opinion, we should do this in reverse. We should maintain the
> Bundle API (merging in the Content/Package API where applicable) and
> deprecate the Content/Package API.
> 
> Bundles has been a successful feature - more people are using it and
> like it (and they are using it successfully for things we didn't
> anticipate) compared to the Content/Package API (few people use it,
> and fewer like it :-)
> 
> The Content/Package classes are what needs to be deprecated, not the
> Bundle classes. I would recommend that where you say things like:
> 
>    Bundle
>       @Deprecated NON_ENTITY computed from Package
>    ...
>    BundleVersion
>       @Deprecated NON_ENTITY computed from PackageVersion
> 
> should instead be flipped like:
> 
>    Package
>       @Deprecated NON_ENTITY computed from Bundle
>    ...
>    PackageVersion
>       @Deprecated NON_ENTITY computed from BundleVersion
> 
> 
> and things like:
> 
>    PackageVersionDeployment NEW CLASS
>        exact copy of BundleDeployment, which become @Deprecated
>        NON_ENTITY
>    ...
>    PackageDestination NEW CLASS
>       copy of BundleDestination, which becomes @Deprecated NON_ENTITY
> 
> should instead just use the Bundle classes (BundleDeployment,
> BundleDestination) and just add data fields to the entities as
> necessary.
> 
> We can discuss further as to why Content/Package API is being
> retained and Bundle API is being deprecated, but those are my
> immediately thoughts.
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> 


More information about the rhq-devel mailing list