Community
Participate
Working Groups
Under our current process, all widget projects have a 3 digit version number in their name; Major.Minor.Service, where the following rules apply: * A change to a Major version number indicates that existing API has been changed * A change to a Minor version number indicates that new API has been added, but existing API remains the same * A change to a Service version number indicates that code has been changed, but all API remains the same (i.e. bug fix) Due to the fact that our widget projects are stored in CVS with a version number in the name, it is necessary to create a new project in CVS for each EDT release, so that we do not ship two versions of a widget project with the same version number and different content. The purpose of this enhancement is to define a process that eliminates the need for the creation of a new widget project in CVS with each release of EDT, while still providing a version number in the widget project name. To achieve this goal, a project will be placed in CVS for each set of widgets, without a version number in the name. For example, "org.eclipse.edt.rui.widgets". During the build process, we will create a new project that adds a pre-defined version number. For example, "org.eclipse.edt.rui.widgets_0.7.0". Whenever we release a new version of EDT, we will tag the project in CVS with the version number that was used for the release (i.e. 0.7.0 in the example above) so that we can easily determine what content was shipped in a given release. Considerations: * The current widget projects has a version number in the CSS file, and the name of this file is referenced in every widget in the projects. The name of this file, and its references, will need to be updated in the main widget project to remove the version number, and we can either leave the name without a version number in the shipped version of the project, or we can write an ant-task to update the version number during a build (http://stackoverflow.com/questions/823909/how-ant-can-get-a-value-read-from-a-file-into-a-property-value). I believe this information is mostly redundant, since it is in a project with a version number already, so we may just want to leave the version numbers off of the CSS files. * During the build process, the .project file will need to be updated to add a version number to the project name. * The file includeDojo.html contains a string with the project version number in the egl.dojoProvider variable, "egl.dojoProvider = "Local Workspace, 1.6.1, project: org.eclipse.edt.rui.dojo_0.7.0";". We can either update this string like we will for the .project file, or we can remove the version number. While it will be easier to change the version number of a widget project with this enhancement, there are other tasks that must be completed when a widget project version number changes, and these will remain the same: IDE Updates - Update the RUI Project wizard to include the new project version Sample Updates - Update references to the latest widget project (RUI technical sample, Dojo Sample, etc.) Build Updates - Update the map files to include the new project
Hi Brian, 1. Does it mean that we will have the following widget projects in cvs, all withour version number? Widget projects for build - org.eclipse.edt.rui.widgets - org.eclipse.edt.rui.dojo - org.eclipse.edt.rui.dojo.remote The development widget projects (we can keep the version number to 0.7.0 because we only use their contents, but I suggest to remove the versions) - org.eclipse.edt.rui.dojo.widgets - org.eclipse.edt.rui.dojo.runtime.local - org.eclipse.edt.rui.dojo.runtime.remote 2. I think we have to update the egldd file name in build time. It seems the changes for widget component is only: Remove the version number for the css file.
Why rename the DD file? It doesn't need a version in its name, just like the CSS file doesn't need a version in its name. The version of the project dictates the version of all contained files.
(In reply to comment #2) > Why rename the DD file? It doesn't need a version in its name, just like the > CSS file doesn't need a version in its name. The version of the project > dictates the version of all contained files. The default egldd file always has the same name with the project name("." is changed to "_"). Since the final project name has a version number, I assume the egldd also need a version number. I don't know if it is mandatory. Ignore the comment if it is not true.
That isn't mandatory, it's just how we create the default in the new project wizard. We can call it whatever we want. I think it would be less confusing if it always had the same name, just like with the CSS file.
I can take ownership of this one, since it should be mostly 'stand-alone'.
changing target from M1 to M2
I have checked in my changes for this work. There are now two new widget projects in CVS: org.eclipse.edt.rui.dojo.widgets org.eclipse.edt.rui.widgets All widget changes should go in these projects, and not the versions with _0.7.0 in the name. I have merged all changes that I could find, but please verify that these changes are up to date. To be clear, the org.eclipse.edt.rui.dojo.widgets_0.7.0 and org.eclipse.edt.rui.widgets_0.7.0 projects are no longer being used by the build. I am keeping this work item opened for the time being while I test for possible issues.
I have updated http://wiki.eclipse.org/EDT:Widgets with the details of this change. I have not deleted the content of the '0.7.0' widget projects from CVS yet, in case we find that we need something from these projects. For example, the dojo_0.7.0 project in CVS contains many more .js files than we are now including in the dojo local runtime project. I discussed this difference with Ji Yong, and we believe the difference is ok, and that the files found in the dojo_0.7.0 project were unused, but additional testing may prove otherwise.
close
