Community
Participate
Working Groups
I've checked in 3 new plug-ins that need to be included in COSMOS build: org.eclipse.cosmos.dc.mdr.registration org.eclipse.cosmos.dc.mdr.registration.client org.eclipse.cosmos.dc.mdr.registration.common All three plug-ins are checked into the data-collection module. If possible, they can be included under the same feature as the following three plug-ins: org.eclipse.cosmos.dc.mdr org.eclipse.cosmos.dc.mdr.client org.eclipse.cosmos.dc.mdr.common
Fixed in the build (COSMOS-1.0.0-200802051005). Please verify
Jagmit, are you just including these plugins in the SDK zip? Ali, I suppose we need to include the demo federating CMDB in the demo as well. We will need to define the running packaging for the federating CMDB as well. I'm reopening this bug just to make sure we have go that covered.
yes I am including these plugins only in SDK package.
It was collectively agreed not to include the sample federating CMDB as part of COSMOS code base. The plug-in will only be used for testing purposes. So this defect can be closed as long as the following three plug-ins are included in the SDK package: org.eclipse.cosmos.dc.mdr.registration org.eclipse.cosmos.dc.mdr.registration.client org.eclipse.cosmos.dc.mdr.registration.common Thanks.
Ali, There are enhancements for the UI to invoke registration operations. How do those functions work without packaging the federation code with the demo?
I believe the general understanding was to enable the functions only when consumers registered a federating CMDB. The UI enhancements will not be enabled/visible with COSMOS alone.
Yes the UI that is specific to CMDBf functionality will be hidden if there are no federating cmdb present. Similarly, the UI functionality will be visible if there is a federing cmdb present. This brings up a point. How will the UI determine if a federating CMDB is present? Will it query the broker for meta data information? Also what properties will determine if the Data manager is a federating CMDB? Are there standard properties?
Hubert, correct me if I'm wrong but doesn't the broker client already provide a mechanism to query for specific type of data managers? For example the following call retrieves all data managers that are management data repositories (MDRs): brokerClient.getServices(MuwsConstants.MANAGEABILITY_CAPABILITY_QNAME, IMdrQuery.NAMESPACE_URI) A similar call can be used to retrieve all federating CMDBs: brokerClient.getServices(MuwsConstants.MANAGEABILITY_CAPABILITY_QNAME, IFederatingCMDB.NAMESPACE_URI)
Yes, it is possible to ask the broker for EPRs of federating CMDB only. This bug is about the build aspect of registration work. If federating CMDB code is not packaged in demo zip file, then the registration UI will not be visible at all in the end-to-end demo. How do we deliver an enhancement that cannot be executed in the download? The sample federating CMDB is checked into CVS, so it's already part of the "COSMOS code base". I suppose you just don't want to build it. I'm bringing this up because it affects the UI, and I want to make sure Sheldon is aware of it too.
Here's my opinion: The UI enhancement referred is being developed to better enable adopters that intend to register a federating CMDB with COSMOS. It's not intended for users who wish to use COSMOS as-is. However, I do understand your concern and I don't have any problems with including the sample as part of the demo package. I believe Mark originally had some concerns. Mark, please indicate if you're fine with including the sample. The concern is that COSMOS will be ineffective in advertising UI enhancements around registration if there are no samples illustrating them.
My concern was that I did not want to give the impression that we were providing a federating CMDB--even a sample one. Even the comments below, we refer to this as a "sample federating CMDB"--that's not even close to what it is. We need to be clearly stating that what's in CVS as a registration test client and nothing more than that. If we position the work in this way, then it's ok to include this in the build to enable a "registration validation" or "registration test" scenario in the build.
Can you provide me the input, as what is required to be done at the build side. to fix this bug
Jagmit, The only work that remains to be completed is to include "org.eclipse.cosmos.example.mdr.registration" as part of the demo package. The plug-in is available under: HEAD/org.eclipse.cosmos/examples. Thanks.
Ali: This plugin org.eclipse.cosmos.example.mdr.registration, is to be packaged under which feature.
Ali: Also like to know, the plugin "org.eclipse.cosmos.example.mdr.registration" is to be packaged under which directory of cosmos demo.
> Also like to know, the plugin "org.eclipse.cosmos.example.mdr.registration" is > to be packaged under which directory of cosmos demo. Package it under the same feature containing "org.eclipse.cosmos.example.mdr". Thanks.
The directory structure should also be similar to example.mdr (i.e. it should be contained under cosmos-demo/webapps)
Ali: Noticed that on including the new plugin "org.eclipse.cosmos.example.mdr.registration". It is breaking the build. This plugin has the dependency on the plugin org.eclipse.hyades.test.tools.core. which is not there.
Removed dependencies on org.junit and org.eclipse.hyades.test.tools.core. This change should fix the problem.
Ali mentioned, completion of this bug depends on the Bug 218840. Saurabh, please notify me, when the Bug 218840 is completed.
Bug 218840 is completed. You can go ahead with the fixing of this bug.
Ali: This defect was fixed in the yesterday announced i9 candidate driver. Is no remaining, work is required to be done. Should I mark this defect as fixed.
Jagmit, You can close a defect whenever you think the necessary work is complete. The reporter can re-open the defect if there is anything missing. Go ahead and mark it as fixed.
Marking this defect as fixed.
closing
