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

Bug 315127

Summary:	aggregator, in batch mode, should output its own version number
Product:	[Technology] CBI	Reporter:	David Williams <david_williams>
Component:	CBI p2 Repository Aggregator	Assignee:	Project Inbox <b3.aggregator-inbox>
Status:	RESOLVED FIXED	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	filip.hrbek, henrik.lindberg
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	Windows 7
Whiteboard:

Description David Williams

2010-05-31 14:52:40 EDT

Especially since the the aggregator is not yet to the point where we use only its milestone builds, or something (where we sometimes update it to pick up a specific fix, etc), it would be good practice to record its version in the routine output to the log. This would be handy for those in the know to find out if some (past) build included a version with some fix ... but also be an easy way to record 'the aggregator has changed, some differences in build results, or checking, might be due to new version of aggregator'. 

I'm opening as enhancement, since not really a known problem. But I do think is is a pretty important releng practice. 

Thanks,

Comment 1 Filip Hrbek

2010-06-01 06:51:42 EDT

This sounds like a good idea. However, what is the "aggregator's version"? There are lots of bundles of different versions.

As I am thinking more about it, I think that this is more general than for the aggregator. I would consider as useful to have this capability for all b3 headless applications.

I can see two possible solutions:

1) Add a global option --printConfig [filter]
2) Implement a b3 CLI command printConfig [--filter <filter>]

The optional "filter" parameter allows to specify a regexp filter for bundle names to be displayed. For example, the filter could look like "^org\.eclipse\.b3\.aggregator\..*".

I am not sure which of the two solution is better:
1: it would be easy to add this option to any command.
2: it would be more standard (such as "java -version"), however, it would require calling two commands in sequence or calling a script file containing the "printConfig" command and the actual command.

What do you think?

Comment 2 David Williams

2010-06-01 10:02:25 EDT

I think not having a separate command would be good. (for example, compiler output usually prints version of itself in output, at least then -log specified). 

But, not sure which/how much. I was originally just thinking of "feature version" ... but, given other recent discussions, realize that may not be best reflection of what bundles are currently installed/running. Is there one, or two main or core bundles that reflect the meaty function? Then perhaps those. But, otherwise, guess there's not harm in listing them all. 

IMHO, it should just happen (require no commands, or filters, etc). But could maybe be tied to --logLevel: debug or info, list the versions; warning, debug (presumably the user wants less output), so could omit list versions in these settings. 

HTH

Comment 3 Henrik Lindberg

2010-06-01 10:54:52 EDT

I think using logLevel is good - when producing the debug output, you generally want to know as much as possible.

In addition to that I think it is good to have commands to list the versions of things installed.
How about a versatile version command:

version
Prints product / highest feature versions and hint to use more detailed commands

version -all
Prints product, feature and bundle versions

version -features
List of features and their versions
version -bundles
List of bundles and their versions

Comment 4 Filip Hrbek

2010-06-01 11:48:42 EDT

Yes, using the --logLevel=DEBUG as an indicator for printing out the configuration sounds good to me. I suggest to move the --logLevel and --eclipseLogLevel options from aggregator to the b3 cli base.

I'm still in doubt what we should print out. If we want to print products and features we probably need to explore current p2 profile (or am I mistaken?). This introduces a dependency to several p2 bundles (current b3 cli base is not dependent on anything from p2).

What about this:

1) Option --logLevel or --eclipseLogLevel is set to DEBUG

Print names and versions of all bundles in current runtime (no need to include p2 functionality)

2) Command version [--all|--features|--bundles]

Print information about product / features / bundles using p2. This command could be provided by a separate bundle which would depend on p2 bundles.

Comment 5 David Williams

2010-06-01 12:01:19 EDT

I'm fine with simplest possible approach. Which sounds like to print all b3 bundle versions. 

Could maybe be improved or fine tuned in future.

Comment 6 Filip Hrbek

2010-06-02 12:23:59 EDT

Done in the simplest way - when --logLevel or --eclipseLogLevel is set to DEBUG, a list of bundles and their versions is logged (with debug level) as soon as the process begins.

Changes have been published on the update site.

Comment 7 David Williams

2016-09-16 15:56:57 EDT

[Bookkeeping change only. Moving bugs to the new "home" of aggregator, CBI.
No change to assignee for resolved and verified bugs.]