Searching artifacts across SCA domain

Candidate: Wojtek Janiszewski <wojtek.janiszewski AT gmail DOT com>

1. General

2. Project description

2.1 (Project goal)

Implementation of search feature should cover three main areas, which are indexing, searching and presentation. Such separation gives us modularity, which implies reuse of components and ability to test easily.

2.2 Indexing

Indexing would be backed by Apache Lucene indexing mechanisms. It should include all available contributions. Each contribution should be scanned for files known for Apache Tuscany and every file should be indexed in various contexts:

• indexing file content
• indexing file path and name
• indexing file QName 

Adding, updating or removing contribution should cause reindexing such element.

Every indexed item (every possible contribution member) should have some identifier, which could be used as reference for other items.

Every item should be linked to some parent items:

• contribution parent, which is mandatory - every file belongs to some contribution
• direct parent (optional, can be many) which could be composite file, component declaration, binding, implementation, service, reference etc.

Additionally we could have some some connection to runtime artifacts, so contribution could contain links to nodes which hosts them. This would be indirect connection to runtime element for every contribution member.

2.3 Searching

Searching would be backed by Apache Lucene search engine.

Custom search API for Apache Tuscany would be available via SCA component and would allow to do searches based on:

• "fetch by phrase" - search phrases similiar to what we do in Google, which would be based on combination of following:
  • file names or file contents
  • artifact types
  • artifact QNames, URIs
  • wildcards, regular expressions, logic expressions
• "fetch by item" method
  • getting item (with references to its parents and children) given as argument

Such search component can be reused in various scenarios, it can be exposed via one of Apache Tuscany bindings. In this case we would like to use such component as a feed for web based UI.

2.4 Presentation

2.4.1 Navigation

Navigation could be performed in two ways:

1. By using search box where user can type query, for "fetch by phrase" search method

2. By using links to items where user can navigate through references ("fetch by item" method). Such links could be found in several places:

• search start page - with links to available contributions
• result element view containing links to parents and children

Search box could have facilities which could help entering queries:

• JavaScript/AJAX hints while typing query, it would show suggestions for:
  • artifact types
  • indexed QNames
  • most popular searches
  • query syntax

2.4.2 Results

Display layout would be common for both "fetch by phrase" and "fetch by item". Every search would be displayed as list of results. For long result lists paging would be applied. Furthermore having sort feature would improve navigation through results list:

• sorting by path, QName
• sorting by contribution
• sorting by direct parent

View for each search result element should contain:

• highlighted phrase which matches search query
• preview link (if item is readable)
• link to parent contribution
• links to runtime nodes (fetched from contribution)
• links to direct parent (composite, component, binding etc.)
• links to children elements
  • for contributions it would be all files which forms contribution
  • for others (composites, components, bindings etc.) it will be all directctly declared children elements

3. Timeline

Before May 23

Getting started

May 23 - July 5

First phase of the development

July 6 - July 13

Midterm evaluation

Submitting mid-term evaluation.

July 14 - August 9

Second phase of the development

August 10 - August 17

• Code/documentation review.

August 18 - September 24

Final evaluation

Submitting final evaluation