(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.