"-Add support for deploying to single resources, rather than just groups"

That was in the very original design, but we purposefully decided against it and changed it to be group-oriented only (I'd have to go back to see if I can find notes on why I decided against it). Changing this to go back to individual resource deployments will potentially effect a lot - from the db schema to the server SLSBs.

Mazz, can you update this issue describing the work you have done and push it 
to QA

-Add support for deploying to JBAS instances

There is now the ability to target bundles directly to JBossAS resources. If your group is a compatible group and its type is JBossAS, you can deploy directly to the JBossAS under its Deploy Directory or Install Directory - the user gets to choose directly on the UI which one they want.

-Add support for deploying to single resources, rather than just groups

Even though you can't target single resources explicitly, the bundle deploy wizard now makes it very easy to build new groups on the fly directly from the wizard and you can select a single resource while doing so. You click the "new group" button from the wizard, and from there you get a selection dialog box from which you can select a single resource and click "OK". Essetially, this is what you would be doing ANYWAY if we were to support explicit deployment to a single resource (you would still have to go through some UI workflow and click-through to select the resource you want). But here, that UI workflow creates a group for you and that group (which can contain a single resource if you want) is what it used to deploy the bundle to.

Verified on Version: 4.1.0-SNAPSHOT Build Number: 7739090

Verified deploying bundle to JBoss As server instance with options 'Install Directory' and 'Profile Directory'. Also verified deploying to single resource by using the "new group" button from the bundle deployment wizard and selecting a single resource.

Marking as verified.

I took the time to see if I can find any history behind the decision to support only groups for bundle deployment. I don't have any definitive notes, but the decision appears to have been made in or around May 2010.

This diff to the wiki page is around that time (this doesn't have much to go on though):

http://rhq-project.org/pages/diffpages.action?originalId=4784483&pageId=5570620

Here is the schema design prior to the decision (I think this schema supported resource-only deployments):

http://rhq-project.org/download/attachments/4423832/bundle-schema-5.png

and this is the new schema that supports group-only deployments:

http://rhq-project.org/download/attachments/4423832/bundle-schema-6.png

here's the history of the image attachment - you can see the schema design through history:

http://rhq-project.org/pages/viewpageattachments.action?pageId=4423835

Notice that group and resources were linked to a single relationship rhq_bundle_res_deploy (so this had one "res_deploy" table but it had linkage to either resource OR group). In schema-6, we ripped that duality out and added the concept of the destination which had a single relationship to group. The issue was being able to cleanly support the cases where you either had a resource (or disparate set of resources) linked to a bundle, vs. a group. Obviously, we'd prefer the user use an actual group than use a set of disparate and individual resources when linking to the bundle (think of how we would have to support that in the UI - we'd need a way to select a "group" of resources and assign them to the bundle but not use groups - doesn't make sense, we already have the concept and implementation of compatible groups - hence we just used that and shared the concept with bundles). That leaves us with the question of how to support the use-case of deploying to a single resource. I believe the thinking was, why introduce this complex and harder to maintain duality for a use-case that will be rare (deploying bundles to a single resource - back then, we were envisioning the bundles subsystem to be mainly useful to people who wanted to push out software to clusters of machines - not just individual one-off installations). We didn't think it was that important to support the concept of deploying to a single resource, when we could already support that with a group containing a single resource in it. Thus, because we CAN support that use-case WITHOUT introducing the duality of relationships, we decided to not allow resources to be explicitly related to bundles - we do it implicitly through resource destinations-groups.

Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago.