Skip to main content
Jump to: navigation, search

ECF/Shared Code Plugin

Revision as of 18:28, 9 June 2006 by (Talk | contribs) (Communication Channel)


Project Lead: Marcelo Mayworm

Mentor(s): Scott Lewis, Ken Gilmer

Project Motivation

The Shared Code Plug-in (SCP) is an Eclipse plug-in exclusively allocated to share source code between Eclipse users, providing a mechanism to take charge of search, retrieval and sharing. The SCP idea is to provide developers with an easy-to-use interface to search for source code and share source code among developers, which can be leveraged in the applications. Developers can make yours source code on Eclipse Workspace available to a lot of people, adding special metadata into these source code, making way for others developers find easy source code, in ways never possible before. SCP is based in a peer-to-peer communications and file sharing, therefore, the intention is to use the Eclipse Communication Framework (ECF) as base, because ECF provides an open source framework supporting the creation of communications-based applications on the Eclipse platform, using a peer-to-peer network. SCP focuses on the development of tool of collaborative.


  • Developer types criteria and select metadata to the search.
  • Metadata Terms maybe embedded in source code so Developers may cite a particular entry with the specific form(maybe Eclipse’s makers or annotations). Metadata Terms are available to the search, and used for Developers gives information about yours source code. Metadata Terms are based on Dublin Core:
    • Data create
    • Last update
    • Language
    • Title
    • Creator
    • Subject and Keywords
    • Description
    • Resource Identifier
    • Source
    • Coverage
    • Rights Management
  • The search executed by developers, will be sending to the peers (others developers with the SCP). Each peer will take out the criteria search and find source code in the Eclipse workspace that meets their needs. SCP will find Metadata terms, class name, imports, code block, comment block, method return and others criterions.
  • Developers want the ability to regulate access to their workspace, and to govern how the SCP will respond to searches. Social aspects for usage of these source code collaboration will have raised demand for security policies and restrictions. For example, maybe some workspace contents are associated with a 'public domain' group (which has public access only), while other source in the workspace is associated with other groups (for example EPL licensed code, commercial open source, commercial closed source, etc - Within each group could be appropriate sharing and search policies. SCP will have a set of roles and policies that can be applied to collaborative settings. These roles and policies can be customized.
  • The peers that received the request, will send to the requester a list of response, this list contain peer name, source code file name, method name(if possible), date, last update, number of results and a possible page rank.
  • The requester selects a bundle of choice, and the SCP download the files.
  • SCP copies the files to shared area in the requester, and make them available from a view.


Project's schedule is in SCP Schedule, you can be well aware of tasks and status about the project.

Technical Issues

Communication Channel

SCP make a broadcasting search requests from peer A(requestor) to peers N. When peer N1 matches on the search term, it sends the match to Peer A, not all the peers in the group. The messaging model imply in a request/response model. We decided have two channels: one to broadcast requests to peers N, and another to receive responses - only to requestors. The request message should contain a Return Address that indicates where to send the reply message. A simple solution was get ID of the requestor, using method getFromContainerID() in IChannelMessageEvent, and send the response using sendMessage(ID receiver, byte [] message), which sends to a particular receiver container. Any peer that wants to respond can simply initiate a direct connection with the requestor. Figure 1 shows the scenario.

If different messages to the same replier require replies to different places, the replier can determine from each request message where to send the reply for that request. A Return Address(ID name) is put in the header of a message because it's not part of the application data(Java files) being transmitted. Each replier needs to deal with several requests, so there is a mechanism Produce/Consumer into each peer, storing each message received in a message queue implementation. Process consumers look at messages inside the queue consuming any of the messages.


Screenshots were produced from the SCP and placed where it can be easily seen - Screenshots SCP.


All the relevant characteristics of SCP Architecture can be figured out in ScpArchitecture.


This session is a nice place to talk abou ideas and clues with other people about SCP - Talks.

Futere Work

Server Cache Mechanism

Peer Cache Mechanism




Copyright © Eclipse Foundation, Inc. All Rights Reserved.