Introduction: components and project organization

"A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties." -- Clemens Szyperski. Component Software: Beyond Object-Oriented Programming. Boston, MA: Addison-Wesley, 1998. See also Wikipedia: http://en.wikipedia.org/wiki/Software_componentry

From these definitions follows that:

  • a component is not a service
  • a component is not a service implementation
  • a component is a reusable packaging/distribution unit
  • a component is specified by consumed and provided services

The definition above can be applied very well for all types of components - EJB, COM, NepomukComponent?... NepomukComponents? are complex components (composite components), and they can be built up from many low-level components. So one "logical" component - like "rdfrepository" - can contain many bundles (low-level OSGi components) - like "*.log", "*.service.rdfapi", "*.service.rdfapi.impl" and so on. And there is no contradiction here: each Nepomuk component can be prepared as a set of plug-ins with corresponding features and they will be downloaded/installed as a single installation unit. This installation unit is characterized by its consumed/provided services. So the definition above covers Nepomuk components as well...

Project types

We have the following set of entities in the system:

  • library projects - libraries/frameworks used in our applications and in our service implementations:
    • third party libraries - ex: apache-commons, log4j, ant, sesame2, jena...
    • internal libraries - our own utility classes and tools (ex: WikiModel?, uri parsing libraries, graph visualization libraries, ...)
  • service projects - these projects contain definitions of service interfaces + some standard utility libraries based only on these interfaces. These projects should be independent on the underlying OSGi platform. These projects can be considered as simple libraries providing only interfaces, but they should be explicitly distinguished by their names. Examples: RDF API, DataWrapper API, Security API...
  • service implementation projects - each service implementation project depends on the corresponding service project and (eventually) some library projects; Normally these projects does not contain any dependences on the platform (OSGi...) and they can be re-used in others contexts.
  • component projects - each component project does not implement services, but it uses existing implementations. It creates run-time instances of services and registers them in the underlying platform (OSGi). So component can be considered as a service activator and service registrar. We can consider that each component contains the following two "parts":
    • component activator project - is a java project which instantiates, activates and configures all services exposed by this component; this project depends on third party libraries, service projects and service implementation projects
    • component feature - each component feature regroups all projects required to deploy this component
  • application projects - each application project contains an implementation of the internal logic specific for this application; an application consumes services provided by various components; we can have many different applications differentiating only by used components.
  • product projects - each product project corresponds exactly to one application project. Product projects contain all required configurations and scripts to build the corresponding applications.

Example project layout

As an example I propose project layout for an rdf repository:

  • org.semanticdesktop.comp.rdfrepository.feature - a component feature regrouping all projects contained in this component (all projects listed below); All these projects will be distributed "at once" using Update Sites configurations or they will be included in products.
  • org.semanticdesktop.comp.rdfrepository - RDF Repository component; The OSGI activator of this plugin has to create a new instance of a class (classes) implementing the RDF API defined below, configure them and register them in the underlying OSGi platform. This project depends on:
    • org.semanticdesktop.service.rdfapi
    • org.semanticdesktop.service.rdfapi.impl
    • org.openrdf.sesame2
    • org.semanticdesktop.common.log
  • org.semanticdesktop.service.rdf - contains a definition of the RDF API; This project has no external dependences. It can be used as a simple java library in any context (not only in OSGi)
  • org.semanticdesktop.service.rdf.impl - contains a default implementation of the RDF API. This project can be used in any context as a simple java library (and not only under OSGi). This project depends on the following projects:
    • org.semanticdesktop.service.rdf
    • org.openrdf.sesame2
  • org.openrdf.sesame2 - a third-party library used as a basis for the implementation of the RDF API; It can be used as a simple java library.
  • org.semanticdesktop.common.log - contains logging libraries (log4j, apache-commons) configured to work under OSGi context

Application configuration has the following structure:

  • org.semanticdesktop.server.app - a server application containing all required java code to launch the application. By default it contains an implementation of the org.eclipse.core.runtime.IPlatformRunnable interface + all branding stuff for the application.
  • org.semanticdesktop.server.product - this project contains runtime configuration to launch the application (two products can use the same application but different configurations) + all automatic build scripts + all TeamProjectSets? to initialize the development environment

Not covered topics

  • Documentation projects - in theory each plugin should provide a corresponding set of documentation files available through the Eclipse Help system.... It would be nice to define it in the future.
  • Branding stuff - set of required additional materials which have to be found in each project/plugin (like "about.html", "plugin.properties" or "feature.properties", icons, README.txt ...)