Hi Sean,
I’ve embedded some questions &
comments regarding your proposal.
Regards,
Leo
-----Original Message-----
From: cdt-dev-admin@xxxxxxxxxxx
[mailto:cdt-dev-admin@xxxxxxxxxxx] On Behalf
Of Sean Evoy
Sent: Thursday, April
15, 2004 3:58 PM
To: cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev] Managed Build
System Versioning Strategy
OK,
Here,
as promised, is my suggestion for versioning the managed build system.
The
ManagedBuildManager is the heart of the build system in terms of reading in the
manifest where the tool definitions are located (plugin.xml) and loading build
information for existing projects (.cdtbuild). It needs to know whether or not
it can read the a given manifest or project file and make sense of what it
finds. This will be very important going forward, since we know that the schema
for defining tools is not sufficient for everyone's needs. As the schema
changes, so too will the manifest and, by extension, the project files.
I
propose creating a hard-coded PluginVersionIdentifier in the ManagedBuildManager.
A version identifier is comprised of a major, minor, and service component (all
integers), and a string qualifier. For example, reading the version from an
integration build would get an identifier like 2.0.0."200404140811".
For simplicity, the hard-coded version identifier in the build manager will not
have a qualifier, just the major, minor, and service components. The version
element is the only thing that has to be manually kept up-to-date by the
development team. I realize that hard-coding is a big, red flag for most
people, but in order to test, the info has to be stored somewhere. I am open to
alternative locations for the version info, of course.
When
the ManagedBuildManager is asked to load the tool definitions, it will ask the
plugin what version it is (this is encoded in the plugin manifest and easily
available through the plugin descriptor). If the hard-coded version is
compatible with the version coming back from the plugin it will load it. If
not, it will throw a build exception. Really, it is a stretch to even imagine
that this will ever happen, but you never know ....
[Leo] The plugin version is the value
of the plugin element, version attribute in the plugin.xml file? If so, are
we going to dictate what this value needs to be when defining a managed build plugin?
We currently use that attribute for our product version. Would it be
better to define a new attribute of the target element, e.g. managedBuildVersion?
What do you mean by “it is a stretch
to even imagine that this will ever happen”? Do you mean that
you intend to support old target/tool definition schemas forever? That’s
OK, I’m just not sure what you meant.
Project build settings are also persisted in a file.
The build manager will write out a ProcessingInstruction containing the string
equivalent of its hard-coded version. When a project file is read in some time
in the future, the string will be compared to the hard-coded version, and one
of three things will happen. If the file version is greater than the hard-coded
version in the build manager reading the file, it will throw a build exception.
[Leo] What code will display a
dialog box with an error message that the user can understand?
If the file version is
compatible, it will read the file. If the file version is lower, it will call a
project file conversion routine to update the file (this might be a NOP if
there is no substantive changes between the two versions) and then read it.
Issues
in no particular order:
·
The absence of a
ProcessingInstruction indicates that a file is from CDT 1.2.x and needs to be
upgraded.
·
The only project files we have
to worry about right now are 1.2.x files, so we can defer the discussion of our
post-2.0 project file upgrade strategy if we agree that the underlying
logic/implementation is sufficient.
·
As we move forward, we may have
to impose a limit on how many version we will upgrade (i.e. by the time 4.0
rolls around will we have to be able to load 1.2.x project files?)
·
Should we update project files
silently or ask the user. A refusal results in not reading in the settings (but
the project will still be in the workspace). Acceptance means the cdtbuild file
is updated.
[Leo] I think we have to ask.
The reason is that after the conversion, the .cdtbuild file will no longer work
with older versions of Eclipse.
·
Should the project converter be
defined as an executable extension in the manifest (so people implementing a
toolchain can supply their own for their customizations).
[Leo] This raises a more “global”
issue and is related to the previous item. Imagine Eclipse 4.0 comes out
and .project files need to be converted, .cdtproject files need to be converted,
.cdtbuild files need to be converted, and vendor specific files need to be
converted. Does the user get asked for each one? This is bad since
the user needs to convert all of them or none of them or they will end up with
a project that is not usable with 3.0 or 4.0! This requires some coordination,
for example an extension point that any plugin can extend that gets called when
upgrading a project from an earlier version of Eclipse. I haven’t
thought about this in any detail, but the extension interface might have 2
methods:
- isConversionNecessary(oldVersion,
newVersion) – Eclipse would ask each plugin that provides an
extension whether it needs to perform a conversion. If any plugin
answers “yes”, then Eclipse displays the UI asking if the user
wants to convert.
- Convert(oldVersion, newVersion)
– If the user agrees to the conversion and the plugin answered “yes”,
Eclipse calls this method to allow the plugin to do the conversion.
Please let me know if there is anything critical that I
have overlooked and feel free to supply any feedback you have. Of course, time
is of the essence ....
Thanks,
Sean
Evoy
Rational Software - IBM Software Group
Ottawa, Ontario, Canada
