Project Home
Project Home
Discussion Forums
Project Information
Project Info
wiki2979: F27DetailedDesign (Version 3)

Getting list of F27 packages#

Data Provider#

  • The data provider uses a package definition file hosted on F27 to get the list of packages

Package definition file#

  • Similar to a memento. It contains packages details including:
    • Title - name of the package
    • Release - package version
    • CPU - target CPU variant
    • Vendor - package provider (mainly QNX)
    • Repository - The F27 repository (e.g.
    • Location - the F27 hosting URL within the repository (e.g. trunk/services/system)
    • Description - the package detailed description
  • The definition file will be maintained by F27 admin (?)
  • The file is publicly accessible, can be downloaded without authentication. Location of the file is - TBD
  • The IDE does not cache any package information locally but always queries this the definition file in every new import section

How packages are defined?#

  • What is the granularity?
  • Source or binary format?
  • Make sure packages are build-able before posting?

Gettting F27 login information#

There are two ways to get the user name and password

A per repository login prompt#

  • Similar to the update manager login panel
  • User can have different username and password on different repositories (possible?)
  • Username and password are recorded to "Team -> SVN -> Password Management" for future re-use

A preference page to save login username and password#

  • Applicable when using the same login info for all repositories
  • Has to encypt the password. Leverage the platform "Secure Storage" mechanism (?)
  • Still has limitation - save in workspace only. Shall it be able to exported to other workspace?

Parsing dependencies#

Dependencies definition#

  • Defined in the "module.tmpl" <requires> tab, example for trunk/services/system
	<!-- Dependencies -->
		<part build="false" location="lib/elf"/>
		<part build="true"  location="lib/c"/>
		<part build="false" location="hardware/startup/lib"/>
		<part build="false" location="utils/m/mkasmoff"/>

Build the dependency hierarchy#

  • For complete dependency, all the referenced packages' module.tmpl files have to be fetched locally and parsed
  • At this phase, we only fetch module.tmpl files, not the whole package tree

Presenting packages#

The model#

Refactor existing model#

  • Abstract the existing source package model to a "globalSourcePackage"
  • Refactor current source zip file model to be one implementation of the "globalSourcePackage"
  • Create a new remote package model as another implementation of the "globalSourcePackage"
  • Refactor all the model classes (BSP, sourcePackage) using the same manner

The remote package model#

  • The remote package model is an abstract model by itself with different implementation for remote binary file and remote source tree
  • Based on the contents of the package definition file and the package dependency hierarchy, the remote package model is built as a tree like structure
  • Each tree node is represented by a "packageItem" class. It has properties like "title", "release", "cpu", "repositoryLocation", "dependOn", "dependBy", etc. And helper methods to get/set properties
  • A "packageManager" class holds the model objects and is responsible to manage the tree node. It has methods like "add", "remove", "convertTo", etc.
  • Interfaces will be used to defined API to the tree node and the manager so that they can be extended to different type of packages.

The U.I.#



Checking out packages#


Creating projects#