This chapter describes ways of getting involved in and contributing to the GATE project. Sections
12.1 and 12.2 are good places to start. Sections 12.3 and 12.4 describe protocol and provide
information for committers; we cover creating new plugins and updating this user guide. See
Section 12.2 for information on becoming a committer.

The GATE bug tracker can be found on SourceForge, here. When reporting bugs, please give as
much detail as possible. Include the GATE version number and build number, the platform on
which you observed the bug, and the version of Java you were using (1.6.0_03, etc.). Include steps
to reproduce the problem, and a full stack trace of any exceptions, including ‘Caused by …’. You
may wish to ﬁrst check whether the bug is already ﬁxed in the latest nightly build. You may also
request new features.

Patches may be submitted on SourceForge. The best format for patches is an SVN diﬀ against the
latest subversion. The diﬀ can be saved as a ﬁle and attached; it should not be pasted into the bug
report. Note that we generally do not accept patches against earlier versions of GATE. Also,
GATE is intended to be compatible with Java 6, so if you regularly develop using a later version of
Java it is very important to compile and test your patches on Java 6. Patches that use
features from a later version of Java and do not compile and run on Java 6 will not be
accepted.

If you intend to submit larger changes, you might prefer to become a committer! We welcome
input to the development process of GATE. The code is hosted on SourceForge, providing
anonymous Subversion access (see Section 2.2.3). We’re happy to give committer privileges to
anyone with a track record of contributing good code to the project. We also make the current
version available nightly on the ftp site.

GATE provides a ﬂexible structure where new resources can be plugged in very easily. There are
three types of resources: Language Resource (LR), Processing Resource (PR) and Visual Resource
(VR). In the following subsections we describe the necessary steps to write new PRs and VRs, and
to add plugins to the nightly build. The guide on writing new LRs will be available
soon.

The plugins are many and the list is constantly expanding. The naming convention aims to impose
order and group plugins in a readable manner. When naming new plugins, please adhere to the
following guidelines:

Words comprising plugin names should be capitalized and separated by underscores
Like_So. This means that they will format nicely in GATE Developer. For example,
‘Inter_Annotator_Agreement’.

Plugin names should begin with the word that best describes their function. Practically,
this means that words are often reversed from the usual order, for example, the
Chemistry Tagger plugin should be called ‘Tagger_Chemistry’. This means that for
example parsers will group together alphabetically and thus will be easy to ﬁnd when
someone is looking for parsers. Before naming your plugin, look at the existing plugins
and see where it might group well.

Each resource (LR,PR) has some predeﬁned actions associated with it. These actions appear in a
context menu that appears in GATE Developer when the user right clicks on any of the resources.
For example if the selected resource is a Processing Resource, there will be at least four actions
available in its context menu: 1. Close 2. Hide 3. Rename and 4. Reinitialize. New actions in
addition to the predeﬁned actions can be added by implementing the gate.gui.ActionsPublisher
interface in either the LR/PR itself or in any associated VR. Then the user has to implement the
following method.

public List getActions() {
return actions;
}

Here the variable actions should contain a list of instances of type javax.swing.AbstractAction. A
string passed in the constructor of an AbstractAction object appears in the context menu. Adding
a null element adds a separator in the menu.

There are at least four important listeners which should be implemented in order to listen to the
various relevant events happening in the background. These include:

CreoleListener

Creole-register keeps information about instances of various resources and refreshes
itself on new additions and deletions. In order to listen to these events, a class should
implement the gate.event.CreoleListener. Implementing CreoleListener requires users
to implement the following methods:

A traditional GATE document contains text and a set of annotationSets. To get
notiﬁed about changes in any of these resources, a class should implement the
gate.event.DocumentListener. This requires users to implement the following methods:

public void contentEdited(DocumentEvent event);

public void annotationSetAdded(DocumentEvent event);

public void annotationSetRemoved(DocumentEvent event);

AnnotationSetListener

As the name suggests, AnnotationSet is a set of annotations. To listen to the addition and
deletion of annotations, a class should implement the gate.event.AnnotationSetListener and
therefore the following methods:

public void annotationAdded(AnnotationSetEvent event);

public void annotationRemoved(AnnotationSetEvent event);

AnnotationListener

Each annotation has a featureMap associated with it, which contains a set of feature names
and their respective values. To listen to the changes in annotation, one needs
to implement the gate.event.AnnotationListener and implement the following
method:

Each resource (PR and LR) can have its own associated visual resource. When double clicked, the
resource’s respective visual resource appears in GATE Developer. The GATE Developer GUI is
divided into three visible parts (See Figure 12.1). One of them contains a tree that shows the
loaded instances of resources. The one below this is used for various purposes - such as to display
document features and that the execution is in progress. This part of the GUI is referred to as
‘small’. The third and the largest part of the GUI is referred to as ‘large’. One can
specify which one of these two should be used for displaying a new visual resource in the
creole.xml.

Every document has its own document viewer associated with it. It comes with a single component
that shows the text of the original document. GATE provides a way to attach new GUI plugins to
the document viewer. For example AnnotationSet viewer, AnnotationList viewer and Co-Reference
editor. These are the examples of DocumentViewer plugins shipped as part of the core GATE
build. These plugins can be displayed either on the right or on top of the document viewer.
They can also replace the text viewer in the center (See ﬁgure 12.1). A separate button
is added at the top of the document viewer which can be pressed to display the GUI
plugin.

Below we show a template class deﬁnition, which can be used to develop a new DocumentViewer
plugin.

Often a CREOLE plugin may contain an example application to showcase the PRs it contains.
These ‘ready made’ applications can be made easily available through GATE Developer by
creating a simple PackagedController subclass. In essence such a subclass simply references a
saved application and provides details that can be used to create a menu item to load the
application.

The following example shows how the example application in the Tagger_Measurement plugin is
added to the menus in GATE Developer.

The menu parameter is used to specify the folder structure in which the menu item will be placed.
Typically its value will just be a single menu name, but it can be a semicolon-separated list of
names, which will map to a series of sub-menus. For example "Languages;German" would create a
“Languages” menu with a “German” sub-menu, which in turn would contain the menu item for this
application.

Each new resource added as a plugin should contain its own subfolder under the
%GATEHOME%/plugins folder with an associated creole.xml ﬁle. A plugin can have one or more
resources declared in its creole.xml ﬁle and/or using source-level annotations as described in
section 4.7.

If you add a new plugin and want it to be part of the build process, you should create a build.xml
ﬁle with targets ‘build’, ‘test’, ‘distro.prepare’, ‘javadoc’ and ‘clean’. The build target should build
the JAR ﬁle, test should run any unit tests, distro.prepare should clean up any intermediate ﬁles
(e.g. the classes/ directory) and leave just what’s in Subversion, plus the compiled JAR ﬁle and
javadocs. The clean target should clean up everything, including the compiled JAR and any
generated sources, etc. You should also add your plugin to ‘plugins.to.build’ in the top-level
build.xml to include it in the build. This is by design - not all the plugins have build ﬁles, and of
the ones that do, not all are suitable for inclusion in the nightly build (viz. SUPPLE, Section
18.2).

Note that if you are currently building gate by doing ‘ant jar’, be aware that this does not build
the plugins. Running just ‘ant’ or ‘ant all’ will do so.

Hopefully the structure of this ﬁle is fairly self explanatory. Each CreolePlugin element must
contain a url attribute which points to a CREOLE directory, i.e. a directory which contains a
creole.xml ﬁle as described in Section 4.7: note that for plugins distributed via this method
the ID and VERSION attributes of the CREOLE-DIRECTORY element must be provided.
The URL can be either absolute (as in the ﬁrst example) or relative; relative URLs
will be resolved against the location of the XML ﬁle. Each CreolePlugin can also,
optionally, contain a downloadURL attribute. If present this should point to a zip ﬁle
containing a compiled copy of the plugin. If the downloadURL is not present then we assume
that it can be found as a ﬁle called creole.zip in the directory referenced by the url
attribute.

Regardless of the location of the zip ﬁle containing the plugin, it should, at the top level,
contain a single directory which in turn contains the full plugin including creole.xml
etc.

The GATE User Guide is maintained in the GATE subversion repository at SourceForge. If you
are a developer at Sheﬃeld you do not need to check out the userguide explicitly, as it will appear
under the tao directory when you check out sale. For others, you can check it out as follows:
svn checkout https://svn.sourceforge.net/svnroot/gate/userguide/trunk userguide

The user guide is written in LATEX and translated to PDF using pdflatex and to HTML
using tex4ht. The main ﬁle that ties it all together is tao_main.tex, which deﬁnes the
various macros used in the rest of the guide and \inputs the other .tex ﬁles, one per
chapter.

A standard POSIX shell environment including GNU Make. On Windows this generally
means Cygwin, on Mac OS X the XCode developer tools and on Unix the relevant
packages from your distribution.

A copy of the userguide sources (see above).

A LATEX installation, including pdﬂatex if you want to build the PDF version, and
tex4ht if you want to build the HTML. MiKTeX should work for Windows, texlive
(available in MacPorts) for Mac OS X, or your choice of package for Unix.

The BibTeX database big.bib. It must be located in the directory above
where you have checked out the userguide, i.e. if the guide sources are in
/home/bob/svn/userguide then big.bib needs to go in /home/bib/svn. Sheﬃeld
developers will ﬁnd that it is already in the right place, under sale, others will need
to download it from http://gate.ac.uk/sale/big.bib.

Once these are all assembled it should be a case of running make to perform the actual build. To
build the PDF do make tao.pdf, for the one page HTML do make index.html and for the several
pages HTML do make split.html.

The PDF build generally works without problems, but the HTML build is known to hang on
some machines for no apparent reason. If this happens to you try again on a diﬀerent
machine.

To make changes to the guide simply edit the relevant .tex ﬁles, make sure the guide still builds
(at least the PDF version), and check in your changes to the source ﬁles only. Please do not
check in your own built copy of the guide, the oﬃcial user guide builds are produced by a Hudson
continuous integration server in Sheﬃeld.

If you add a section or subsection you should use the \sect or \subsect commands rather than
the normal LaTeX \section or \subsection. These shorthand commands take an optional ﬁrst
parameter, which is the label to use for the section and should follow the pattern of
existing labels. The label is also set as an anchor in the HTML version of the guide. For
example a new section for the ‘Fish’ plugin would go in misc-creole.tex with a heading
of:

\sect[sec:misc-creole:fish]{The Fish Plugin}

and would have the persistent URL http://gate.ac.uk/userguide/sec:misc-creole:fish.

If your changes are to document a bug ﬁx or a new (or removed) feature then you should also add
an entry to the change log in recent-changes.tex. You should include a reference to the full
documentation for your change, in the same way as the existing changelog entries do. You should
ﬁnd yourself adding to the changelog every time except where you are just tidying up or
rewording existing documentation. Unlike in the other source ﬁles, if you add a section or
subsection you should use the \rcSect or \rcSubsect. Recent changes appear both
in the introduction and the appendix, so these commands enable nesting to be done
appropriately.

Section/subsection labels should comprise ‘sec’ followed by the chapter label and a
descriptive section identiﬁer, each colon-separated. New chapter labels should begin
‘chap:’.

Try to avoid changing chapter/section/subsection labels where possible, as this may break links to
the section. If you need to change a label, add it in the ﬁle ‘sections.map’. Entries in this ﬁle are
formatted one per line, with the old section label followed by a tab followed by the new section
label.

The quote marks used should be ‘ and ’.

Titles should be in title case (capitalise the ﬁrst word, nouns, pronouns, verbs, adverbs and
adjectives but not articles, conjunctions or prepositions). When referring to a numbered
chapter, section, subsection, ﬁgure or table, capitalise it, e.g. ‘Section 3.1’. When merely
using the words chapter, section, subsection, ﬁgure or table, e.g. ‘the next chapter’, do
not capitalise them. Proper nouns should be capitalised (‘Java’, ‘Groovy’), as should
strings where the capitalisation is signiﬁcant, but not terms like ‘annotation set’ or
‘document’.

The user guide is rebuilt automatically whenever changes are checked in, so your change should
appear in the online version of the guide within 20 or 30 minutes.