EmForge Project Structure

Followed picture contains draft structure of EmForge Project.

Important note - it is not like it is now - but it is how it should be. To follow this structure we are going to make some refactoring of project (in parallel with development of new features).

Project should be separated into several layers - and accessing from one layer to another may not be done throw some middle ware - one one-to-one.

This refactoring will include several steps:

Moving classes into org.emforge packages.

I want to avoid usage of ru.emdev and separating Project-Management classes into package separated from EmForge classes. Everything will be under org.emforge

Package structure will be about followed:

• org.emforge - will contain interfaces for services;
  • org.emforge.xfer - will contain transfer objects (currently they contains TO suffix - later we will avoid it). Transfer objects - is objects, used for transferring via Web-Services and renderng in the GUI. It should simplest POJO classes - so, we will able easily pass them via requests (without any Lazy-initialization problems). They will not contain any logic (like Task.close now) - all logic will be in services
  • org.emforge.web - general Web-GUI related classes;
  • org.emforge.bpm - will contain all logic related to working with bpm. It will also contains BpmService implemenetation
  • org.emforge.bpm.web - everything related to BPM GUI.
  • org.emforge.pm - everything related to project management
  • org.emforge.pm.web - same - Project Management related Web-GUI classes

and same for wiki, comments and so on...

Migrating all logic into new services operated new TO objects

Major target of this refactoring - we will have one service impementation to use every-there. JSF GUI will work with same services, as any external tools - with only difference - JSF GUI will work directly - and External Tools will work via Web-Service layer

Splitting project into separate projects:

We will have followed projects:

• emforge-api - will contain only services interfaces (org.emforge package) and transfer objects. May be used for writting clients, worked via web-services in Java.
• emforge-core - will contain implementation of services and all other classes
• emforge-jsf - will contain JSF controllers - so, all GUI will be in separate project
• emforge-servicetests - project with set of tests, operated via Web-Services;
• emforge-acceptancetests - set of tests, tested EmForge with different database. May be quite big and should be used only before releasing new version.

Migrating to Seam.

This question need to investigate a little bit more. Seam has many ready-to-use components, as well as may be integrated with Spring, and has jBPM integrated into it...

But - we really will need to make some investigation before making decision.

Most refactoring (except Seam) should be done during March.