[location-iwg] Incubation proposal Description

[Jody Garnett <jody.garnett@xxxxxxxxx>]

Now we are getting a bit closer to home, a project "description". I like the friendly instructions provided by the template. In response to this the two examples travel is widely different directions.

MPC provides a set of goals, I don't think this is appropriate as we have a working codebase.

Aether provides a very detailed (and technical description) with links out to their existing sonyatype project including class diagrams. This approach is more suitable, however a detailed technical description gets away from the user-friendly focus of uDig. As such I have gone with our project goals as expressed by our name, keeping the technical description in reserve as  description of the initial contribution. 

If appropriate I can link to an eclipse white paper on the project (http://www.eclipse.org/community/casestudies/refractionsfinal.pdf)?

Applying this to Location tech: This section was the hardest to fill in without describing "location tech" fundamentals such as what a GIS is, and the value of spatial data and why you would want some. Can I assume this proposal is directed at the LocationTech mailing list; or is it intended for the wider eclipse community? If so it would be handy to have a "what the heck is location tech" page which I could cite in order to cover the basics.

uDig Proposal (https://github.com/uDig/udig-docs/blob/master/admin/proposal/proposal.html):

<!-- 
Describe the project here. Be concise, but provide enough information that
somebody who doesn't already know very much about your project idea or domain
has at least a fighting chance of understanding its purpose.
 -->

<p>uDig is an open source desktop application framework, built with Eclipse Rich Client (RCP) technology. uDig provides
a complete Java solution for desktop GIS data access, editing, and viewing.</p>

<ul>
<li><b>U</b>ser friendly: familiar graphical environment for GIS users;</li>
<li><b>D</b>esktop appliation: running as a thick client, natively user interface on Windows, Mac OS/X and Linux</li>
<li><b>I</b>nternet: supporting standard (WMS, WFS, WCS,KML) and de facto (GeoRSS, tiles) geospatial web services</li>
<li><b>G</b>IS: framework for spatial data exploration and analysis</li>

</ul>

MPC EXAMPLE (http://eclipse.org/proposals/mpc/)

The following are the goals and plan items for the MPC project:

1. Awesome end user experience for finding and installing Eclipse solutions

• Easily ability to navigate up to 5000 different catalog entries:

  • support for browsing different markets and categories of MP

  • search-based navigation and filtering, including 1) license types, 2) maturity of product, 3) provider name and 4) maybe some others?

  • Navigation by recently added and updated

  • Navigation by community favorite

  • Find by same author/vendor

• Display relevant information

  • Each solution listing in the MP client should be able to present the following: 1) logo of listing, 2) Solution name, 3)Provider name, 4) short description and 5) a link to more detailed information.

  • Optionally show screen shots and/or videos; depending on bandwidth this might be just

• Guaranteed Single click install

  • One click install button will result in the solution being added to Eclipse

  • MP Client needs to be smart enough to only show solutions that can successfully install into the existing Eclipse installation. This includes checking for valid update sites, version compatibility, pre-requisites, etc. We need to get as close as possible to a guaranteed install.

  • A user should be able to select multiple solutions for installation.

  • When multiple solutions are picked for integration, their compatibility should be checked.

  • After a user has installed a solution, they should have the option to add the solution to their favorite list on MP. This would require the user to log into MP.

  • If a solution listing doesn't have an install option, there should be an option to be able to show the listing but for 'more info' redirect to the listing web site.

2. Support for different external sources of solution listings (ex. Eclipse release train repo, third party repos)

• Client should have an option to switch to different listing providers. This would be list switching search providers in a browser.

• If the provider is changed, the provider UI and data would be presented.

• The client search functionality should be able to work with other providers. Getting more information after the search results, like a browse more or more details, would take the user to the external provider UI.

• the MP client needs to have the ability to accept incoming requests from external providers to install a solution. This needs to include support from an html page.

3. Awesome end-user experience for uninstalling Eclipse solutions

• MP Client should be able to remember what solutions have already been installed. Previously installed solutions should visually show this in the listings.

• MP Client should allow the user to uninstall a solution.

Aether EXAMPLE (http://eclipse.org/proposals/technology.aether/)

Aether is a library for working with artifact repositories. Aether deals with the specification of local repository, remote repository, developer workspaces, artifact transports, and artifact resolution. Aether's primary implementation is for Maven repositories and is the resolution engine used in Maven 3.x.

The primary task of Aether is to resolve transitive dependencies. This task can be split into two sub tasks:

• Determine the coordinates of the artifacts that make up the transitive dependencies.
• Resolve the files for the artifacts that have been identified in step 1.

Artifacts and their dependencies among each other form a dependency graph. So in other words, step 1 means to calculate this dependency graph and step 2 is a simple graph traversal that fetches the file for each artifact in the dependency graph. In Aether, this dependency graph can be easily inspected and extension points are provided to allow for more control over the construction of the dependency graph. To understand those extension points, we will have a closer look at the way the dependency graph is constructed.

Starting from a given root dependency like org.sonatype.aether:aether-impl:1.7, the repository system first reads the corresponding artifact descriptor (i.e. the POM). The artifact descriptor tells about direct dependencies, dependency management and additional remote repositories to consider during the resolution. For each direct dependency, a dependency selector is given a chance to exclude the dependency from the graph. If the dependency is included, a dependency manager applies dependency management (if any). Next, the declared dependency version is expanded to a list of matching versions from the repositories. For a simple version like "1.0", the resulting list contains only that version. For a version range like "[1.0,2.0)", the version list generally contains multiple versions. For each matching version of the dependency, a child node is added to the dependency graph. Recursion of the process for each child dependency is controlled by a dependency traverser.

The above process creates a dependency graph that often contains duplicate or conflicting dependencies and as such is called a dirty graph. A chain of dependency graph transformers is then used to trim this graph down and to form the resolved dependency graph.

So more technically, the dependency graph that the repository system returns to its caller is affected by instances of org.sonatype.aether.collection.DependencySelector, org.sonatype.aether.collection.DependencyManager, org.sonatype.aether.collection.DependencyTraverser and org.sonatype.aether.collection.DependencyGraphTransformer. Users of the repository system can directly control those extension points when creating the repository system session by providing implementations that fit their needs.

For example, a dependency selector can process exclusions on child dependencies, exclude optional dependencies or dependencies with certain unwanted scopes. A dependency traverser can be used to decide whether the dependencies of a (fat) WAR should be included in the dependency graph or not. Dependency graph transformers can identify and mark conflicting nodes in the dirty tree and resolve conflicting versions or scopes by pruning unwanted parts from the graph.

The class MavenRepositorySystemSession from maven-aether-provider provides a session that mimics the resolution rules used by Maven. In case you want to customize the graph construction, feel free to have a look at the source of its constructor to learn about the implementation classes being used there to achieve Maven style behavior, you might want to reuse some of those for your own repository system session as well. Maven plugins can easily get access to the current repository system session via the usual parameter injection, see Using Aether in Maven Plugins for the actual code bits.

There's also a UML Class Diagram that illustrates a subset of the API graphically.