Community
Participate
Working Groups
Build Identifier: Add a new option like "-listInstalledRoots" that will list the roots from a given profile. The list print information (as current -list) option in the format <iu id>/<iu version>. The mandatory parameters for this to work are: -destination -profile Reproducible: Always
Created attachment 178959 [details] Proposed patch The proposed patch adds the option as specified. Beside that it also adds a public method that is able to make use of all DirectorApplication infrastructure/goodies in order to return all the installed root IUs.
Thanks for the patch. I'll take a look at it. One minor change though, I believe we want to query on the property PROP_PROFILE_ROOT_IU instead. This will list all the "root" things which appear in the About dialog under the Installation details.
Created attachment 178966 [details] patch Updated patch to query on the profile root property. Also I've removed the public method since it is inconsistent with the other methods in the class. If a client wishes to find the profile roots, they are able to perform a simple query.
Please give the attached patch a try to see if it works the way you expect. I want to make sure our definition of "root" is the same before releasing anything. Thanks.
Created attachment 178969 [details] patch Actually we have a User-Visible Query already so I just changed the code to use that.
(In reply to comment #5) Yep, that is better as is consequent with other parts. I was actually pending between the two properties. But I had an example from Pascal and he may comment on why he used the property with STRICT/OPTIONAL values.
(In reply to comment #3) Actually my interest was on the public method not printing them. I agree I can query the profile myself but i'm in the process to create another enhancement request/patch that will use similar option/public method combination for listing available versions for a specified list of IUs. ANd in that case will save me a lot of trouble to reuse existing infrastructure/code in DirectorApplication. ActuallyI wished that the DirectorApplication would be just a thin utility around a set of action classes that perform divers actions/retrive info as director application does. If I would given the chance I would refactor this into class into a parsing/validating method for arguments and then instantiate and execute divers action classes such as PerformProvision, PerformRollback, ListInstalledRoots, ListAvailableRoots where all of this list ones would first give an list of things that are then printed to System out. Of course that all of them would share some base class that sets up the needed infra such as services or repositories.
Ok, I've released the current patch and let's use bug 325403 to discuss the public method issue.
