Community
Participate
Working Groups
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,
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?
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
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
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.
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.
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.
[Bookkeeping change only. Moving bugs to the new "home" of aggregator, CBI. No change to assignee for resolved and verified bugs.]
