The article [[JWT_Modifications| Modifying JWT-WE]] provides information on how several recurring tasks (like adding preferences to the preferences menu) can be accomplished.

The article [[JWT_Modifications| Modifying JWT-WE]] provides information on how several recurring tasks (like adding preferences to the preferences menu) can be accomplished.

+

+

+

== Collaborative Development process ==

+

+

The core idea is that what is committed has to fit in JWT on all counts : vision, architecture and legal aspects.

+

+

Here is a more detailed outline of how things are typically done :

+

* first needs and requirements are discussed on the mailing list or on bugzilla(s), as well as whether it fits in the vision

+

* then a technical solution is proposed, specified and discussed on bugzilla(s), as well as whether it fits in the architecture

+

* then an implementation is proposed as a patch (or possibly a branch, to avoid if possible) and posted on the bugzilla

+

* it is reviewed by other committers on the following points : requirements, technical points and whether it fits in JWT's architecture ; and by project leads on whether it also complies to Eclipse and JWT IP and other organisational requirements (CVS layout and naming, dependencies...)

+

* finally, if it is approved by project leads, it is committed by a committer (the author if he is committer).

+

+

Obviously for small things like simple bug patches, a very simple approval is required. If it has only technical (and not vision or architectural) impacts, the approval of the person responsible for the code being patched might be enough.

+

+

And once a developer has comitted an initial codebase as specified in a given bugzilla, he can commit incremental improvements to it and only have to mention such improvements in this (open !) bugzilla's comments. More precisely, he doesn't need to write a new bugzilla for each and every commit he do es! Once someone's in the process of developing a feature that has already been specified in the bugzilla, he can keep on committing until it's done, at the condition he mentions it on the bugzilla.

+

+

Once a new feature has been developed,

+

* the author must document it in the wiki. If it allows to extend and customize JWT, it must be documented or linked in the dedicated wiki page. As much as possible, a sample and a tutorial should be written on the wiki (how to use it, or how to extend, depending on the case).

+

* it is reviewed by fellow committers and project leads, who can ask for improvements or refactoring so as it better fits in the JWT architecture (CVS layout etc.), or better doc or samples

+

* the bugzilla is closed !

+

* at some point, it will be included in a release (usually the next one), and showcased in the release review slides and in the release news.

Working with the JWT Source Code

Installing JWT Source Code from CVS

For information on how to access the JWT source code, the layout of the CVS repositories and the dependencies of JWT components, please refer to JWT CVS Information.
For write access to the CVS you need to replace the anonymous access with your Eclipse committer account data.

How to Extend/Modify JWT

Legal Stuff

Extending the Workflow Editor

The article Extending JWT-WE contains information on how JWT can be extended by user-defined plugins that provide e.g. external actions or additional views.

Modifying the Workflow Editor

The article Modifying JWT-WE provides information on how several recurring tasks (like adding preferences to the preferences menu) can be accomplished.

Collaborative Development process

The core idea is that what is committed has to fit in JWT on all counts : vision, architecture and legal aspects.

Here is a more detailed outline of how things are typically done :

* first needs and requirements are discussed on the mailing list or on bugzilla(s), as well as whether it fits in the vision
* then a technical solution is proposed, specified and discussed on bugzilla(s), as well as whether it fits in the architecture
* then an implementation is proposed as a patch (or possibly a branch, to avoid if possible) and posted on the bugzilla
* it is reviewed by other committers on the following points : requirements, technical points and whether it fits in JWT's architecture ; and by project leads on whether it also complies to Eclipse and JWT IP and other organisational requirements (CVS layout and naming, dependencies...)
* finally, if it is approved by project leads, it is committed by a committer (the author if he is committer).

Obviously for small things like simple bug patches, a very simple approval is required. If it has only technical (and not vision or architectural) impacts, the approval of the person responsible for the code being patched might be enough.

And once a developer has comitted an initial codebase as specified in a given bugzilla, he can commit incremental improvements to it and only have to mention such improvements in this (open !) bugzilla's comments. More precisely, he doesn't need to write a new bugzilla for each and every commit he do es! Once someone's in the process of developing a feature that has already been specified in the bugzilla, he can keep on committing until it's done, at the condition he mentions it on the bugzilla.

Once a new feature has been developed,

the author must document it in the wiki. If it allows to extend and customize JWT, it must be documented or linked in the dedicated wiki page. As much as possible, a sample and a tutorial should be written on the wiki (how to use it, or how to extend, depending on the case).

it is reviewed by fellow committers and project leads, who can ask for improvements or refactoring so as it better fits in the JWT architecture (CVS layout etc.), or better doc or samples

the bugzilla is closed !

at some point, it will be included in a release (usually the next one), and showcased in the release review slides and in the release news.

How to prepare a new Release

Legal Process

Make sure CQs have been approved for all components on the CVS which should be released (IP Log). This may take a while, so submit them early.

Make sure the internal version of the Workflow Editor and all its plugins is set to the new release version

The converter must be updated to the newest file format

Ensure that all keybindings for Eclipse commands (menu/toolbar) are set correctly

Make sure the licence information is valid (notice.html)

Update the release notes

2. Generating Packages

Generate new Javadocs for each component to be released

Generate a release package and a source package for the Workflow Editor

Generate a release package and a source package for the WE View Creator

Generate release and source packages for all WE Plugins

Update the example processes and create a ZIP archive

Sign packages

3. Deploying

Tag the release state of the Workflow Editor, View Creator and the Plugins on the CVS as a new version (e.g. v040)

Archive old release (move files to "archive.eclipse.org") and upload new release packages to the download server "download.eclipse.org" (in a new directory with subdirectories for plugins and documentation)

Update the links of archived and new downloads on the wiki download page ( Downloads) and related Wiki pages

Preparing

Generating Packages

Signing the Packages

2. Move or copy the files to be signed to the Downloads Staging area.
You cannot sign files anywhere else. The Staging Area is at /opt/public/download-staging.priv/, and it is structured like the downloads area. If you don't have a staging directory, or if you cannot access it, please contact webmaster.

Adapting the Eclipse Update Site

In order to adapt the Eclipse update site you need to create a feature first. This shall include all plugins that will be deployed.

Creating the feature

You'll first need to create a new feature project via the "File -> New -> Other..." dialog.

Then, open the feature.xml to specify all your requirements. The name of the feature, who the provider is, etc. You should also specify the copyright and licensing information there, add the plugins you want to be part of the feature and then compute the dependencies. Afterwards you can go back to the overview page and go through the steps in the Exporting area.

First, synchronize your plugins with their versions in the workspace, specify the Build configuration and then Export the feature.

In this dialog you will be asked where to create this new feature. Since we want to create a new update-site it makes sense to select already the path of this update site. You can specify several options there and start the process of signing the JAR (if not happened already) and can then click on Finish.

Creating the update-site

The feature overview allows you also to create an update site project in the Publishing area. There you can open the update site map (site.xml) and specify the feature as well as system requirements. Finally, build the feature and your update-site will be finished.

Now all there is needed is that you upload your update-site to the Eclipse-server. Probably you'll have a directory structure as the following: