Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 325371

Summary:

[director] Add option to list installed roots to DirectorApplication

Product:

[Eclipse Project] Equinox

Reporter:

Alin Dreghiciu <adreghiciu>

Component:

Assignee:

DJ Houghton <dj.houghton>

Status:

RESOLVED FIXED

QA Contact:

Severity:

enhancement

Priority:

Version:

unspecified

Target Milestone:

3.7 M3

Hardware:

All

OS:

All

Whiteboard:

Attachments:

Description	Flags
Proposed patch	none
patch	none
patch	none

Description Alin Dreghiciu

2010-09-15 11:47:32 EDT

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

Comment 1 Alin Dreghiciu

2010-09-15 12:05:54 EDT

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.

Comment 2 DJ Houghton

2010-09-15 12:40:48 EDT

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.

Comment 3 DJ Houghton

2010-09-15 13:12:22 EDT

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.

Comment 4 DJ Houghton

2010-09-15 13:35:26 EDT

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.

Comment 5 DJ Houghton

2010-09-15 14:05:50 EDT

Created attachment 178969 [details]
patch

Actually we have a User-Visible Query already so I just changed the code to use that.

Comment 6 Alin Dreghiciu

2010-09-15 16:58:40 EDT

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

Comment 7 Alin Dreghiciu

2010-09-15 17:09:18 EDT

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

Comment 8 DJ Houghton

2010-09-16 15:36:48 EDT

Ok, I've released the current patch and let's use bug 325403 to discuss the public method issue.