Embed Size (px)
Citation preview
Mercury Instant Messaging Project Document
Mike Dacey [email protected] Student#: 100102153
Directed Studies Supervisor: Tony White
December 1 2004
2
Table Of Contents Mercury Instant Messaging Project Document................................................................... 1 Introduction......................................................................................................................... 4 Glossary .............................................................................................................................. 6 Section 1 – Design .............................................................................................................. 7 1.1 – Requirements ....................................................................................................... 7
Functional Requirements ................................................................................................ 7 Non-Functional Requirements ........................................................................................ 8
1.2 - Use Cases.............................................................................................................. 9 Description...................................................................................................................... 9 Assumptions.................................................................................................................... 9 Actors............................................................................................................................ 10 UC-1: Configure Eclipse Instant Messaging ................................................................ 11 UC-2: Developers Add Users ....................................................................................... 12 UC-3: Developer adds new IM recipient. ..................................................................... 13 UC-4: The Developer checks out a file......................................................................... 14 UC-5: The Developer Commits a file. .......................................................................... 15
1.3 - Description of Classes ........................................................................................ 16 Design Decisions .......................................................................................................... 16
Eclipse Plug-in - Getting started ............................................................................... 16 Enhancing resource views......................................................................................... 16 Handling user editing and changes to resources ....................................................... 17 Streamlining repository-related tasks ....................................................................... 17 Enhancing platform integration ................................................................................ 17
Components and Classes............................................................................................... 18 Project Management Component.............................................................................. 18 Networking/Messaging Component ......................................................................... 18 User Interface Component ........................................................................................ 19 Users Component...................................................................................................... 19
1.4 - Message Sequence Charts .................................................................................. 20 Message Sequence Chart – Share Project..................................................................... 20 Message Sequence Chart – IM Session Construction................................................... 21 Message Sequence Chart – IM Message Construction................................................. 22
1.5 - Class Diagrams ................................................................................................... 23 Class Listing.................................................................................................................. 23
1.6 - Message Specification .............................................................................................. 24 Section 2 – Implementation and Observations ................................................................. 26 2.1 - Implementation Notes......................................................................................... 26 2.2 JabberD ....................................................................................................................... 27
Introduction............................................................................................................... 27 Background............................................................................................................... 27 Core Functionality .................................................................................................... 27
2.3 Exodus Client.............................................................................................................. 29 2.4 Muse API .................................................................................................................... 30 2.5 Eclipse......................................................................................................................... 31
3
2.5 Future Considerations / Conclusions .......................................................................... 33 2.6 Installation and Usage................................................................................................. 34
Installation Instructions................................................................................................. 34 Sample Usage Script ..................................................................................................... 35
4
Introduction The Mercury Instant Messaging Project represents a variation of the original Concord Project. The original Concord was a “configuration management system for the Eclipse software development environment which uses email as the transport mechanism. The purpose of the system is to allow multiple developers to work on a common code base, and as additions and changes are made to the code, they are propagated to the other developers by email.”1 The Mercury Instant Messaging Project represents an almost totally new code base and replaces the previous email transport with Instant Messaging. Due to their similar problem space this project shares some of the original requirements and use cases that were part of the original Concord. Instant Messaging is now widely used and represents a quick and efficient means of communication between individuals and groups. The intent of the Mercury Instant Messaging Project is not to reinvent an Instant Messaging server or client but to enable Eclipse to participate with other developers in an existing Instant Messaging configuration regardless of the Instant Messaging server or client. (i.e. Jabber, Yahoo Messenger, ICQ, Napster, AIM, Gnutella and XML Remote Procedure Call(XML-RPC)) In order to narrow the scope of this project I have decided to utilize the following:
• Instant Messaging Server – Jabber Server • Instant Messaging Client – Exodus • Instant Messaging Java API – Muse open source Jabber APIs • Configuration Management – Mercury used the original Concord Project as an
example for creating a wrapper to a real repository like CVS or Clearcase. Concord and Mercury’s Configuration Management was provided by sub classing the RepositoryProvider class. All actions on CM related menu items result in sending out an Instant Messages to everyone in the Development Group. The project could be further extended in the future by implementing command line calls to a selected CM application such as ClearCase, CVS, etc….
There are benefits from a security point of view to using a private Open Source IM server and client. The server and client can be run from within a secure work environment within an Intranet providing security for proprietary code and information. There are a number of companies and Government Departments where this kind of security would be essential The Muse API is described on its WEB site as follows: “The Muse API is a Java API with the goal of integrating all network-collaboration services into one. The API will give an easy-to-use interface that allows you to log on to multiple services (i.e. ICQ, AIM, MSN, Yahoo Messenger, IRC, Napster, Gnutella, Jabber, XMLRPC). There will be a client GUI Framework to combine the use of all these services under one easy-to-access API so that you can write GUI clients with much less effort.”
5
The goal is to setup a private Instant Messaging environment using the Jabber server and Exodus client. Once established the Muse API will be used by Eclipse to send Instant Messages to those registered within a Development Group informing them of any CM related activities. The software itself will be written in Java and will include a suitable user interface for adding, editing and removing users from the Development Group. While this group will mainly consist of developers it could also include anyone in management interested in the ongoing activities that are taking place. In keeping with the previous project I will begin with the formal requirements of the system. From these requirements the functionality of the system is captured in Use Cases. Each formal requirement will be addressed in at least one use case. For further information see “Concord Project Document Patrick Dubroy <[email protected]> Student #: 100281158 Directed Studies Supervisor: Prof. Tony White Monday, December 22, 2003” Message Sequence Charts will be utilized to visualize the flow of messages that are sent between classes in the system. To conclude the design Class Diagrams will be used to show the class structure and their relationships. The second section of the document will discuss the details of the implementation. This section includes a postmortem of the various design decisions made and areas within the code that either succeeded or failed. In conclusion suggestions are made on what future additions could be attempted.
6
Glossary Workspace The set of all projects managed by Eclipse, including all of the contents of
the projects
Project A top-level folder in the workspace. Individual projects can be associated with Mercury in the Eclipse workspace, and their contents shared with other developers.
Development Group The list of people who are participating in collaborative development on a Mercury project. Each Mercury project has exactly one development group associated with it
Resource Any component of the Eclipse workspace, including a project. A resource usually corresponds directly to a file or folder on the file system.
Local Repository The configuration management system local to the developer. Each Mercury user has a local repository, which is accessible to him when other developers are not online. Mercury will provide a simple implementation of a local repository, but the interface is intended to support other systems, such as CVS.
Release To communicate the contents of a resource or set of resources to the other members of the development group.
Commit To put the current revision of a resource into the repository. Committing to the local repository is analogous to releasing to the development group.
Revision A snapshot of a resource at a specific point in time. Each revision has an identifier unique to the resource, i.e., the name of the resource and the revision identifier unambiguously determine the contents of the revision.
Version A symbolic name associated with a specific revision of a resource. A resource may have more than one version, and the same version may be associated with more than one resource. Also: To version a resource is to associate a version with a resource in the repository.
7
Section 1 – Design 1.1 – Requirements
Functional Requirements FR-1. The system should be a plug-in for Eclipse 3.0 FR-2. The system must have an installed version of a Jabber Server running and accessible. FR-3. The users must have access to the Exodus Client application. FR-4. The users must have accounts setup via Exodus on the Jabber Server. FR-5. The system is bounded by the nature of the Instant Messaging environment. Users who are not currently on-line will not receive Instant Messages and Instant Messages will not be resent. FR-6. The system should allow multiple developers to work on a local copy/stream of a project, propagating Instant Messages as actions take place against the repository. FR-7. The format of the Instant Message (e.g. XML) is dependent on the MUSE API implementation. FR-8. Using the same Instant Messaging account a developer should be able to subscribe to more than one project using this system, where the subscriber list for each project may be different. The system uses the Mercury Repository and should send Instant Messages for the following actions. FR-9. Share Project – begin collaborative development on a local project, i.e. adds at least one other developer to the list of collaborators. A resource added to source control sends an Added to Source Control Instant Message. FR-10. The system should provide a user interface for adding and deleting developers in the list of collaborators, and modifying the information for a developer, e.g. changing his Instant Messaging address. FR-11. Checkout – The system sends a Checkout Instant messages. FR-12. Commit – The system sends a Commit Instant Message.
8
Non-Functional Requirements NFR-1. The network must support Instant Messaging and allow outgoing Instant Messages. NFR-2. The system must use an Instant Messaging account that the user has set up on the Jabber Server.
9
1.2 - Use Cases
Description The following use cases describe the functionality of the Mercury Instant Messaging project. Each use case maps to one or more functional requirements. The main actor in these use cases will be a single Mercury user.
Assumptions Software projects are usually set up directly with the projects repository such as CVS, Clearcase, etc… The repository administrator grants developers access to those repositories. We can therefore make the following assumption:
1. There is no need for developers to accept invitations to be members of a group since membership takes place while setting up the users repository permissions.
2. When a user shares his project he is simply putting that project under CM control. Those who are members of that group will have access after updating their view of the code.
10
Actors There are four actors who take part in the Mercury Instant Messaging project. A Developer is a Mercury Instant Messaging user. Developer is then generalized into a Project Owner. A Project Owner is a Developer who shares a project with a development group. In addition the Mercury Instant Messaging project interacts with two external systems, the Jabber Server and Exodus Client.
11
UC-1: Configure Eclipse Instant Messaging To setup Eclipse Instant Messaging each team member must select the Mercury Repository and enter into the Development Group those IM users that they wish to communicate with. Actors: Project Owner Triggering Event: TE-1.1 – Project Owner selects “Share Project” in Eclipse and selects Mercury as the repository provider. Pre-Condition: None Sequence Use Case ID Description Tractability UC-1.1 The Project Owner selects
the project to share and selects the Mercury repository.
FR-1, FR-9
UC-1.2 The Project Owner enters the Instant Messaging Addresses of the collaborators on his Team
FR-6, FR-10
UC-1.3 A new Project Instant Messaging Group containing the collaborators entered is added to the Eclipse workspace.
FR-1, FR-10, Fr-8
12
UC-2: Developers Add Users Developers setup the Instant Messaging environment after loading the Project. Actors: Developers Triggering Event: TE-1.1 – Developers receive notification of a resource placed under source control. Pre-Condition: None Sequence Use Case ID Description Tractability UC-1.1 The project is associated
with Mercury in the Eclipse workspace as an existing project.
FR-6, FR-10
UC-1.2 All Developers enter the Instant Messaging Addresses of the collaborators on his Team
FR-1
UC-1.3 A new Project Instant Messaging Group containing the collaborators entered is added to the local Eclipse workspace.
FR-1, FR-10, FR-8
UC-1.4 An Instant Message is sent to each online collaborator whose Instant Messaging Address was entered, whenever a resource is added to source control.
FR-2, FR-3, FR-4, FR-5, Fr-7
13
UC-3: Developer adds new IM recipient. Developer adds a new IM recipient. Actors: Developers Triggering Event: TE-1.1 – User request IM notification. Pre-Condition: None Sequence Use Case ID Description Tractability UC-1.1 The Developer adds a new
Instant Messaging Recipient to the Development Group.
FR-10
14
UC-4: The Developer checks out a file. Developer checks out a file. Actors: Developers Triggering Event: TE-1.1 – Developer requires to change a file. Pre-Condition: None Sequence Use Case ID Description Tractability UC-1.1 The Developer checks out a
file. This triggers an Instant Message to be sent to everyone in the Development Group.
FR-11
15
UC-5: The Developer Commits a file. Developer commits their changes to a file. Actors: Developers Triggering Event: TE-1.1 – Developer decides to commit changes to a file. Pre-Condition: None Sequence Use Case ID Description Tractability UC-1.1 The Developer decides to
commit their changes to a file. This triggers an Instant to be sent to everyone in the Development Group.
FR-12
16
1.3 - Description of Classes
Design Decisions As with the Concord project, Mercury is designed as a plug-in for the Eclipse environment. The Eclipse Plug-in architecture is well defined and requires that the programmer follow patterns that have been established by the Eclipse community. Following these well-publicized procedures ensures that your plug-ins maintain good behaviour both with Eclipse and other plug-ins. The Eclipse Platform Plug-in Developer Guide (http://help.eclipse.org/help21/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/team_howto.htm) has been used for this project and provides step-by-step instructions on Building An Integrated Team Provider. Mercury consists of one Eclipse plug-in contained in the packages com.mdacey.mercury and was developed using the following guide from the Eclipse Platform Plug-in Developers Guide.
Eclipse Plug-in - Getting started Define a RepositoryProvider that represents your implementation.
• Define your provider using org.eclipse.team.core.repository.
• Subclass RepositoryProvider and implement the necessary methods.
Provide a configuration wizard so that users can associate your provider with their projects.
• Contribute a wizard using org.eclipse.team.ui.configurationWizards.
Add your actions to the Team menu.
• Add your actions to the Team menu. • Use the popupMenus extension to
define the menu items.
Enhancing resource views Add provider-specific properties to the properties page for a resource.
• Use the propertyPages extension to show team-specific properties for your resource.
Implement specialized decorators to show team-related attributes
• Contribute decorators to resource views.
Reduce clutter by filtering out any
• Use team-private resources to hide implementation files and folders.
17
resources that are used in implementing team support.
Handling user editing and changes to resources Intervene in the saving of resources so you can check permissions before a user changes a file.
• Implement the fileModificationValidator hook.
• Use validateSave to prevent or intervene in saving of files.
Intervene before a user edits a file to see if it's allowed.
• Implement the fileModificationValidator hook.
• Use validateEdit to prevent or intervene in saving of files.
Track changes to resources in the workspace so you can allow associated changes in the repository.
• Use the move/Delete hooks to prevent or enhance moving and deleting of resources.
• See IMoveDeleteHook for more detail about what you can do.
Enable the use of linked resources • See Team and linked resources
Streamlining repository-related tasks
Provide an easy way to export a description of your projects.
• Use project sets to export your projects without exporting the content so that users can rebuild projects from the repository.
Reduce clutter in the repository by ignoring files that can be regenerated.
• Honor the ignore extension when handling files and use ignore for your plug-ins derived files.
Enhancing platform integration
Add provider-specific preferences to the preferences page.
• Add your preferences to the Team category.
• Build your preference page using workbench support.
Implement custom views to show detailed information about repositories or their resources.
• Use the views extension to contribute a view.
• See the CVS provider's repository view for an example.
Add your views or actions to existing workbench perspectives if appropriate.
• Use the perspectiveExtension extension to add your plug-ins shortcuts or views to existing perspectives.
Implement a repository-specific perspective to streamline repository
• Use the perspectives extension to define your own perspective, views, short cuts, and page layout.
18
administration or browsing.
The package com.mdacey.mercury contains the MercuryTeamProvider class, which is a subclass of RepositoryProvider. The main intent of the MercuryTeamProvider is to provide a Delegate for a real Repository such as Clearcase, CVS, etc… As in the original Concord Project the main thrust was to show how emails and in this case Instant Messages could be propagated to other team members when using a Repository. Both projects provide an example of how these features can be added. The Muse API provides an API that allows the user to communicate with a Jabber Server and indirectly with an Exodus (Jabber) client.
Components and Classes
Project Management Component MercuryTeamProvider The MercuryTeamProvider will provide an interface between core Mercury classes and a project in the Eclipse workspace. An instance of the MercuryTeamProvider will be instantiated for each project associated with a Mercury Repository. MercuryPlugin The MercuryPlugin extends AbstractUIPlugin and is the core interface into the plug-in architecture for Eclipse. The MercuryPlugin will be responsible for providing Mercury access to the Eclipse environment and has responsibilities such as obtaining all Mercury owned projects from the Eclipse environment.
Networking/Messaging Component MercuryIMSessionManger – Manages an Instant Message Session and sending IM messages. MercuryMessage The abstract superclass for all instant messages. MercuryMessage will provide common behaviour for all Mercury IM messages. CheckoutMessage – Instant Message sent when a file is checked out. CheckinCommitMessage – Instant Message sent when a file is checked in. AddToVersionControlMessage – Instant Message sent when a user places a resource under version control.
19
User Interface Component RepositorySharingWizard Part of the requirements stated in the Eclipse Platform Plug-in Developer Guide - Getting Started Table, is the implementation of a SharingWizard. The SharingWizard is used to associate a project with a specific repository, in this case the Mercury Repository. The SharingWizard extends the org.eclipse.team.ui. configurationWizards extension point with a class, which implements IConfigurationWizard. For convenience, SharingWizard extends the abstract class org.eclipse.jface.wizard.Wizard. Checkout Action – This action will trigger sending a CheckoutMessage. Commit Action – This action will trigger sending a CheckinCommitMessage. AddToVersionControl Action – This action will trigger sending an AddToVersionControlMessage. ModifyDevelopmentGroupAction This action triggers the IMDevelopmentGroupDialog to be displayed allowing the user to modify the Projects Development Group.
Users Component Developer – An instance of a Mercury Developer DevelopmentGroup – An instance of a group of developers working on a specific Project
20
1.4 - Message Sequence Charts
Message Sequence Chart – Share Project
21
Message Sequence Chart – IM Session Construction
22
Message Sequence Chart – IM Message Construction
23
1.5 - Class Diagrams
Class Listing
24
1.6 - Message Specification The Muse API provides Java libraries allowing the programmer to concentrate on developing Instant Messaging applications instead of low-level connections and transport issues. Muse uses XML to encode all of its communications but hides all the details from the end user! While the actual structure and creation of the XML is out of the programmer’s hands it is still worthwhile to review the structure of this protocol for exchanging messages. The following was extracted from “Jabber away with instant messaging” written by Jason Kitchen. “Let's review the take a look at the XML exchanges that occur when we connect to the server, log in, and send the message as described in the code above. In the following XML exchange, the messages received by the client (our example code) are prefixed with RECV, and messages sent to the server are prefixed with SEND:
SEND: <?xml version="1.0" encoding="UTF-8" ?> <stream:stream to="localhost" xmlns="jabber:client" xmlns:stream="http://etherx.jabber.org/streams"> RECV: <stream:stream from="localhost" id="3D160545">
All Jabber exchanges occur in the context of an XML stream. During the lifetime of the connection between our client code and the Jabber server, two complete XML documents transfer a fragment at a time. The initial exchange shown above allows the client to start sending the XML-streamed document to the server and the server to start sending the XML-streamed document to the client. You can find the full details of XML streaming in various reference texts and, of course, the Jabber specification (see Resources).
Next, a request for authorization information is sent to the server:
SEND: <iq xmlns="jabber:client" type='get' id='id_10028'> <query xmlns="jabber:iq:auth"> <username>user</username> </query> </iq> RECV: <iq xmlns="jabber:client" type='result' id='id_10028'> <query xmlns="jabber:iq:auth"> <username>user</username> <password />
25
<digest/> <sequence>482</sequence> <token>3D15E63A</token> <resource /> </query> </iq>
The preceding fragment shows the first exchange in the user authentication process. To begin, the client asks the server what authentication methods are available for the given user. The server fragment answers with the following authentication methods:
• Plain text: <password /> tag • Zero-knowledge authentication: Uses the <sequence> and <token> tags • <digest/>: Like plain text, but the password is SHA-1 (Secure Hash Algorithm)-
encoded with the user's plain text password
We actually use <digest/>, as illustrated in the following fragment: SEND: <iq xmlns="jabber:client" type='set' id='id_10030'> <query xmlns="jabber:iq:auth"> <username>user</username> <hash>425c73373237061edcc5f23ba239c6cc69556f5c</hash> <resource>Home</resource> </query> </iq> RECV: <iq xmlns="jabber:client" type='result' id='id_10030'></iq> At this point, the user is logged in to the server and can begin sending or receiving messages: SEND: <message xmlns="jabber:client" type='headline' id='id_10032' to='user2@localhost'> <thread xmlns="jabber:client">id_10033</thread> <subject xmlns="jabber:client">Hello world</subject> <body xmlns="jabber:client">Hello world</body> </message> The above fragment shows the test headline message we send to the receiver user2@localhost. You might have noticed one recurring element in the preceding protocol fragments: the ID tag. Because the session can consist of multiple asynchronous conversations, the ID tag matches queries to responses. “
26
Section 2 – Implementation and Observations
2.1 - Implementation Notes The goal of this project was to send Instant Messages to a specific group of developers participating on a project triggered by a Configuration Management event. The project succeeded in achieving this goal and was an interesting example of software integration and coding. The Mercury project utilized the following:
• JabberD Server • Exodus Client • Muse API • Eclipse 3.0
The project was a combination of software integration and development. The JabberD Server, Exodus client, and Eclipse Plugin Architecture were integrated together to provide a new type of service for the target developer. If more time were available the Repository wrapper could have forwarded its calls to a real repository such as CVS. The Muse API and Eclipse Plugin Architecture required both coding and configuration to achieve the required functionality. Of the two I found the Eclipse Plugin Architecture the trickiest to master since configuration errors were only found at runtime. Since the compiler could not help, the normal result was either “nothing”, ( the plugin was not loaded ) or a generic error stating that the event thread had caught an Exception. Particularly baffling was the inability of Eclipse to find external jar files, even when you told it where to look! Little is given in the way of explaining how this should be done, only a good Google (search engine) finally found an answer. However, by the number of similar developers on the Internet who seemed confused I was not alone. Fortunately once you realize the trick it’s very clear what Eclipse wants!! My initial mistake was to use a Java application to experiment with the Muse API. All worked flawlessly. Then, as I finished the Eclipse Plugin development I thought I could just copy my Muse code in and have it work. But no… Eclipse didn’t want to find my muse jar file. This was definitely painful till I figured it out!! The following is a quick review of the major components used in this project. I will give a small introduction and follow it by excerpts from the various component user manuals to give a feel for the various components.
27
2.2 JabberD JabberD is the origional Jabber server implementation. It is open source, and was easy to install, stable and was available for a variety of platforms such as UNIX, Linux, Windows and Mac OS X. I found that all that was necessary to get going was to install the application and run the server. It seemed to just work, what a delight!! The following is from the JabberD admin guide and serves as a quick introduction to the product.
Introduction This document describes how to install, configure, and administer jabberd 1.4.x. The jabberd server is the original open-source server implementation of the Jabber protocol, and is the most popular software for deploying Jabber either inside a company or as a public IM service. However, there exist numerous other Jabber server implementations, including a number of open-source projects as well as commercial offerings (see the server software list). As the organization that manages the Jabber protocol, the Jabber Software Foundation (JSF) does not discriminate between Jabber implementations. At the same time, the JSF recognizes that most Jabber deployments start out by using the jabberd server, and thus has attempted to encourage the spread of Jabber technology by documenting how to install, configure, and administer the jabberd server. For support related to jabberd, server administrators are encouraged to subscribe to the JADMIN mailing list (archive). For further information about Jabber, refer to the website of the Jabber Software Foundation.
Background The Jabber project was started by Jeremie Miller in 1998 as a free and open alternative to the proprietary IM services offered by AIM, ICQ, MSN, and Yahoo. The first public notice of the project occurred on Slashdot in January 1999. The core of the Jabber project has always been the jabberd server, a modular server that is written in C and that uses the GNU pth threading library. After over a year of development, jabberd 1.0 was released in May 2000. The interim 1.2 version was released in October 2000, followed by version 1.4 in January 2001, version 1.4.1 in April 2001, version 1.4.2 in February 2002, and version 1.4.3 in November 2003. Concurrently to jabberd 1.4.x, jabberd 2 is developed, with its first stable release in December 2003. jabberd 2 is practically rewritten from scratch and for example features SQL support. The jabberd 1.4.x server aims to be fully compliant with the XMPP protocol managed by the Jabber Software Foundation. However, as the XMPP protocol is a recent standard, jabberd 1.4.3 does not provide some XMPP features. Nevertheless, it is able to connect with both XMPP compliant servers and clients.
Core Functionality In essence, a Jabber server does the following:
28
• accepts TCP socket connections from compatible clients and server-side components
• manages XML streams to and from those clients and components • delivers the core Jabber data types (<message/>, <presence/>, and <iq/>) to
authorized clients and components • maintains session information for connected clients (usually IM users) • if necessary, opens connections to and validates connections from other Jabber
servers, then routes data to them • stores information on behalf of components and especially IM users, including
each user's contact list and some client preferences Additional features -- such as multi-user chat, user directories, and interoperability with legacy IM systems (AIM, ICQ, MSN, and Yahoo) -- are not part of the core messaging and presence functionality of a Jabber server and therefore are not addressed in this guide. Please see the Jabber Component Guide for further information about adding these features to your Jabber server.
29
2.3 Exodus Client Exodus is a Jabber compliant client that is easy to use and has a nice look and feel. Exodus is fairly easy to learn and has proven to be very stable. The following is from the Exodus web site http://exodus.jabberstudio.org/. Exodus is a new Jabber ™ client being developed to be a "successor" to the very popular client Winjab. It's smaller, faster, easier to use, and looks better.
Get Exodus
• Download Exodus • You can visit the Jabberstudio Project page to file bug
reports, and make feature requests. This page also has news announcements and releases available.
• Daily builds are here.
Mailing Lists
• Exodus Discussion & Announcements is a list for general discussion and announcements.
• Exodus-Dev Mailing list is devoted to discussing compilation issues, feature requests, design issues, etc.
Get Involved If you're interested in working on the development of Exodus, please feel free to checkout the source code. Make sure to the read the readme.txt located in the main exodus directory before emailing me about compilation issues.
30
2.4 Muse API I was introduced to the Muse APIs by an article named “Jabber away with instant messaging” by Jason Kitchen. This article formed the basis for the instant messaging in Mercury. I found that Muse was very easy to use and understand and has proven to be quite stable. The following is an excerpt from the read me file included with muse, you can find their web site at http://www.echomine.org/. Echomine Muse API Echomine Muse API gives you one easy-to-use set of APIs and frameworks for you to connect with other communication services such as Gnutella, ICQ, MSN, Yahoo, AIM, IRC, FTP, etc. It implements the protocols and then adds an extra layer on top of the protocols so that access to all the services go through one unified API (similar to how JDBC works). License Echomine Muse API is distributed under the Apache Software License. See the enclosed license file for more information regarding legal issues on using this API. Installation Just add the required libraries in the lib/ directory into your classpath and you're ready to go. Muse API is meant to be a low-level developer API so it does not contain any application that can be run. Well, there are some example codes under the examples/ directory. Take a look and then you're ready to create your own application!
31
2.5 Eclipse Eclipse 3.0 is a popular development environment that seems to be everywhere in today’s software community. A number of private and government departments are using Eclipse because of its stable, feature rich offering and due to its free access. In fact IBM feels strongly enough about Eclipse that it has based its main development tool WebSphere on the Eclipse platform. WebSphere is in fact a selection of plugins developed for Eclipse and released under the IBM brand. The following is from the Eclipse web site:
Eclipse.org is the website of the Eclipse Foundation.
Eclipse is an open platform for tool integration built by an open community of tool providers. Operating under an open source paradigm, with a common public license that provides royalty free source code and world wide redistribution rights, the eclipse platform provides tool developers with ultimate flexibility and control over their software technology.
Eclipse has formed an independent open eco-system around royalty-free technology and a universal platform for tools integration. Eclipse based tools give developers freedom of choice in a multi-language, multi-platform, multi-vendor environment. Eclipse provides a plug-in based framework that makes it easier to create, integrate and utilize software tools, saving time and money. By collaborating and exploiting core integration technology, tool producers can leverage platform reuse and concentrate on core competencies to create new development technology. The Eclipse Platform is written in the Java language and comes with extensive plug-in construction toolkits and examples. It has already been deployed on a range of development workstations including Linux, QNX, OSx and Windows based systems. A full description of the Eclipse community and white papers documenting the design and use of the Eclipse Platform are available at http://www.eclipse.org.
Industry leaders Borland, IBM, MERANT, QNX Software Systems, Rational Software3, Red Hat, SuSE, TogetherSoft3 and Webgain2 formed the initial eclipse.org Board of Stewards in November 2001. In March of 2002, the board unanimously voted to add new members, Serena, Sybase and Fujitsu. At the June 2002 meeting of the Board of Stewards, Hitachi, Instantiations, MontaVista, Scapa Technologies and Telelogic were added to the board membership. In September 2002, ETRI, HP, MKS and SlickEdit were unanimously elected to the Board of Stewards. Also at the September board meeting, Oracle's membership was approved. Catalyst Systems, Flashline, Parasoft, SAP, teamstudio and TimeSys became members in December 2002. The board of stewards was very pleased to welcome the Object Management Group (OMG) as an associate member. In March 2003 the board welcomed associate member the Fraunhofer Institute, and
32
stewards representing Ericsson, LogicLibrary, M7 Corpororation, QA Systems and SilverMark, Inc. We are now pleased to include stewards from Advanced Systems Concepts, Genuitec and INNOOPRACT Informationssysteme GmbH. In May of 2003 the board welcomed new members CanyonBlue, Ensemble Systems, Intel, Micro Focus, Tensilica and Wasabi.
On Feb 2, 2004 the Eclipse Board of Stewards announced Eclipse's reorganization into a not-for-profit corporation. Originally a consortium that formed when IBM released the Eclipse Platform into Open Source, Eclipse became an independent body that will drive the platform’s evolution to benefit the providers of software development offerings and end-users. All technology and source code provided to this fast-growing ecosystem will remain openly available and royalty-free.
33
2.5 Future Considerations / Conclusions The Mercury project is a good blueprint of integrating Instant Messaging within an existing application. In this case the application is Eclipse and therefore WebSphere. There are a number other areas where the addition of Instant Messaging into an application would be a considerable asset. Specifically Instant Messages that are autonomously generated within a secure environment. This project has given me the chance to experiment with both Instant Messaging and Eclipse Plug-in development. Instant Messaging and Muse provide an effective solution to those software projects where quick notifications between applications are part of the software specifications. Professionally, the Eclipse Plugin development experience has been a definite asset as I have already been able to apply its benefits in my work environment. In conclusion I think that this was an excellent choice for an Honours Project. It has provided me with a marketable set of skills and leaves behind a prototype that future Carleton students can use for further studies in this area.
34
2.6 Installation and Usage
Installation Instructions
1. Download JabberD from http://jabberd.jabberstudio.org/1.4/ and save it onto the designated server for your network. Then follow the installation procedures published with JabberD.
2. Download Exodus from http://exodus.jabberstudio.org/ and save it onto all
participating workstations on your network. Again follow the installation procedures published with Exodus.
3. Now setup a normal Instant Messaging environment. Each member will request
that an Instant Messaging relationship be established with every other member. Test your setup; you must be able to send Instant Messages to everyone that will be participating.
4. Download Eclipse 3.0 from http://www.eclipse.org/ and save it onto each
workstation, again follow the installation instructions that came with the download.
5. Now unzip the Mercury distribution into the Eclipse installation directory, i.e. the
directory which contains the Eclipse executable and the plugins subdirectory.
6. Now download the org.apache.xerces_4.0.13 plugin from Apache and install this in the plugin directory of Eclipse 3.0, it is required by Mercury. A copy is included on the CD that accompanies this project.
7. Download the Muse API at http://open.echomine.org/cowiki/1.html and copy the
following jar files into the ./plugins/com.mdacey.mercury_1.-.0/lib directory. • commons-logging.jar • crimson-1.1.3.jar • jakarta-oro.jar • jdom.jar • jsse.jar • log4j.jar • muse-0.8a4.jar • xml-apis.jar
35
Sample Usage Script 1. Start the JabberD Server. 2. Start the Exodus Client. Your Instant Messaging environment must already be
setup. 3. Start Eclipse. 4. From the Window menu, select "Preferences". 5. On the "Mercury" preference page, select a repository directory. This should be
an empty, existing directory. 6. On the "Instant Messaging" preference page (under Mercury), enter your Instant
Messaging settings. 7. Now create a new project in the Eclipse workspace. 8. Now add a class to the project. 9. Right-click on the selected project, and select "Team->Share Project...". 10. Select "Mercury" as the repository type. 11. Add at least one other developer to the development group. 12. Click "Finish". 13. If you wish you can repeat steps 1-4 on a new copy of Eclipse in a fresh
workspace. This is not necessary to test the Instant Messaging functionality however.
14. Now select the file that you created earlier and select Notice that only the “Add to Source Control” menu item is enabled. Select “Add to Source Control”.
15. You should see Instant Messages sent to everyone in the Development Group. The message indicates that the file was put under source control.
16. Right click on the file, now the menu item “Checkout” is highlighted. Select the “Checkout” menu item. An Instant Message is sent to everyone in the Development Group stating that the file has been checked out.
17. Now select the file again and right click on it. Notice that the “Checkin” menu item is enabled but not the “Checkout” and “Add to Version Control” menu items. Select “Checkin”. An Instant Message is sent to everyone in the Development Group.
18. Now select the file again and right click. Select the “Edit Development Group” menu item. Add or remove a developer from the Development Group. Experiment to discover that the changes have worked.
