bundle / content api redesign

Jay Shaughnessy jshaughn at redhat.com
Tue Feb 5 15:34:15 UTC 2013


Ignore my previous reply,  it was supposed to be off-list. Obviously I 
don't know how to use e-mail...   Anyway, an actual reply is coming...

On 2/5/2013 10:15 AM, Jay Shaughnessy wrote:
> Off-List
>
> On 2/5/2013 7:02 AM, Lukas Krejci wrote:
>> 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
> I'm sorry, but I take offense to the repeated use of the word "hack" 
> with respect to the Bundle data model.  It was actually the result of 
> many revisions, with input from many parties, and an evolving set of 
> requirements.  I agree that all that revision may have been somewhat 
> detrimental to the finished product but it is far from a mess.  It's 
> actually a clear separation of the storage model and the deployment 
> model.
>
> Anyway, I'll write more On-list.
>
>>   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
>>>
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>
> _______________________________________________
> 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