Bugzilla – Full Text Bug Listing
| Summary: | [About] About dialog should populate version info from plugin.xml | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Dean Roberts <dean.t.roberts> |
| Component: | UI | Assignee: | Andrew Irvine <airvine> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | dj.houghton, greg_adams, jeem, n.a.edgar |
| Version: | 2.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | |||
|
Description
Dean Roberts
The version stored in the plugin.xml is a machine readable value, which may or
may not be synchronized with that in the about.properties. So reading this
value would not be good for two reasons
1/ It may not be human readable
2/ It may not be the correct version you wish displayed.
Have you thought about changing the about.properites such that the version is
read from the about.mappings file as {1}? I am guessing that currently the
about.mappings file is currently only one file that is either linked or copied
to the appropriate directories, updated each loadbuild. If the version was
kept in this file I am assuming some loadbuild scripts would also need to be
modified.
No - the version in plugin.xml is ALWAYS synchronized with the version of the plugin in the plugin.xml. Or put another way, the about dialog box is meant to display the version of the plugin. The version of the plugin is always the version as it appears in the plugin.xml file. Yes we have thought about changing build scripts and using the mapping file. However, the map file is used to change values that are only known at build time, such as the build id. The plugin version is known at runtime, there should be no need add extra complexity to the builder to copy a runtime value from one location to another. *** Bug 21333 has been marked as a duplicate of this bug. *** The advantages of using the existing about.mappings mechanism to fill in a feature version number into the feature's about blurb are (a) it does not require additional ad hoc knowledge and processing in the workbench About dialog code, and (b) it is NL friendly and does not require re-translation of the blurb just because the version changes. IMHO the best place to address this is somewhere in the build scripts. Sorry, but I just can not buy this.
I think it is perfectly reasonable that About Dialog Code knows that it should
have to display the plugins version number somewhere. In fact I would say
that the About Dialog Code's blurbManager could try and substitute the plugin
version number for ${v} anywhere in the blurb text.
Forgetting about our build process for a minute. It is VERY odd that a user
would have a plugin version in their plugin.xml that is ignored by the about
dialog. We are going to tell the user that they have to update their plugin
version in two places in the same plugin directory.
Remember that plugin developers do not necessarily use our build process. If
I have to dream up some goofy way for the build process to read and parse
plugin.xml to extract the version number and then copy hat value to
about.mappings so that, in effect, the value gets recopied back to
about.properties, then every plugin build manager is going to have to invent
the same song and dance.
In fact, I would go a step further and suggest that we consider that
about.properties values should somehow be folded into plugin.xml and/or
plugin.properties. Then the About Dialog Code blurbManager could also
subsititue a copyright message for {c} and an appName for {a}...
The version info from the plugin.xml is a machine-readable representation, and
is not necessarily the correct thing to show to a human.
For example, for the org.eclipse.platform feature, the version in the
plugin.xml is 2.1.0, but the about blurb currently shows 2.1.
However, we or other developers may decide that the machine-readable version is
fine to show to users. So I am not averse to adding a mechanism for
substituting certain well-defined variables into the about text (although I'd
prefer something like ${pluginVersion} or ${featureVersion} to ${v}).
This way, the developer has 3 choices:
1. they can enter the version text manually in the about.properties (what we do
currently)
2. they can use the ${pluginVersion} variable
3. they can use the about.mapping mechanism ({0} etc.)
I know Dean favours 2, since that simplifies the build process.
But we have to start with the user - what do we want to show them?
I like Nick's suggestion with the caveat that we would, by default, slam
everything to ${pluginVersion} and then let those teams that wish to display
something different take ownership of keeping this up to date.
If $(pluginVersion} was always replaced by the full version id, uses that wanted to display something shorter (like "2.1" or "Release 2") could do it manually (Nick's option 1). I think it would be fine to show the full version id for the Eclipse SDK features. So Dean's suggestion of replacing "2.1" by $(pluginVersion} would work well. So we will add support for this. Jeem, should we use ${pluginVersion} or
${featureVersion}? If ${pluginVersion} do you see ${featureVersion} as being
at all useful?
We probably don't need the leading $ either. Need to ensure the {}'s don't
confuse MessageFormat. If they do, we'll need some other pattern, e.g.
$pluginVersion.
We should probably call it ${featureVersion} - it is a feature about dialog
after all. Do we have an cheap way to get the feature version id?
Released for 20030125 build.
The Version number is read from the feature.xml file, by an existing method.
To take advantage of this functionality the about.properties needs to be
updated to use the variable $featureVersion as follows:
OLD:
# about.properties
# contains externalized strings for about.ini
# java.io.Properties file (ISO 8859-1 with "\" escapes)
# fill-ins are supplied by about.mappings
# This file should be translated.
appName=Eclipse
blurb=Eclipse Platform\n\
\n\
Version: 2.1\n\
Build id: {0}\n\
\n\
(c) Copyright IBM Corp. and others 2000, 2002. All rights reserved.\n\
Visit http://www.eclipse.org/platform\n\
\n\
This product includes software developed by the\n\
Apache Software Foundation http://www.apache.org/
NEW:
# about.properties
# contains externalized strings for about.ini
# java.io.Properties file (ISO 8859-1 with "\" escapes)
# fill-ins are supplied by about.mappings
# This file should be translated.
appName=Eclipse
blurb=Eclipse Platform\n\
\n\
Version: $featureVersion\n\
Build id: {0}\n\
\n\
(c) Copyright IBM Corp. and others 2000, 2002. All rights reserved.\n\
Visit http://www.eclipse.org/platform\n\
\n\
This product includes software developed by the\n\
Apache Software Foundation http://www.apache.org/
To avoid possible translations issues I changed the format of the
about.mappings and about.properties files.
about.properties: substitute {1} for the current verion number
about.mappings: add the line 1=$featureVersion
For example.
# about.mappings
# contains fill-ins for about.properties
# java.io.Properties file (ISO 8859-1 with "\" escapes)
# This file does not need to be translated.
0=200301151011
1=$featureVersion <--New
---
# about.properties
# contains externalized strings for about.ini
# java.io.Properties file (ISO 8859-1 with "\" escapes)
# fill-ins are supplied by about.mappings
# This file should be translated.
blurb=Eclipse Java Development Tools\n\
\n\
Version: {1}\n\ <- New, currently it is written Version: 2.1,
Build id: {0}\n\
\n\
(c) Copyright IBM Corp. and others 2000, 2003. All rights reserved.\n\
Visit http://www.eclipse.org/jdt
Jim has requested a solution that does not involve the .mappings file. I will update this bug once it is available. Fix submitted for 20030205 build.
Changes to about.properties are required to take advantage of this
functionality: the variable {featureVersion} needs to be added. In addition
the comment indicating translation should not occur to any value between {} is
recommended.
# about.properties
# contains externalized strings for about.ini
# java.io.Properties file (ISO 8859-1 with "\" escapes)
# fill-ins are supplied by about.mappings
# This file should be translated.
#
# Do not translate any values surrounded by {}
appName=Eclipse
blurb=Eclipse Platform\n\
\n\
Version: {featureVersion}\n\
Build id: {0}\n\
\n\
(c) Copyright IBM Corp. and others 2000, 2003. All rights reserved.\n\
Visit http://www.eclipse.org/platform\n\
\n\
This product includes software developed by the\n\
Apache Software Foundation http://www.apache.org/
|