DEVELOPERS

AREA

WELCOME TO THE DEVELOPERS COMMUNITY

This is the special area for developers where all kind of contributions are welcome.

Feel free & explore all resources now!

Discussion

The developers forum is used for announcements and discussion about DPF Manager.

The github issues list the place for discussion of DPFManager features and bugs.

For chat about DPF manager development conect to irc.freenode.net server in the #DPFManager-Developers channel with an IRC client or connect with a web client here.

The official Twitter account is @DPFManager

Visit our Blog to get the the latest events and news from around the DPF Manager.

Learning

Visit the user documentation to learn ablout DPF manager instalation and use.

In the API documentation get all the information about DPF manager framework.

StackOverflow dpf-manager tag collects all questions and awnsers about DPF-Manager.

Development

All development takes place at Github into the developer branch.

In the issue tracker is where the bugs are submited.

The DPF manager development and next features are able in github milestones list.

If you are interested in contributing to DPF Manager, please first read the contribution guide.

All the contributions should follow the contribution workflow defined in the contribution guide.

CONTRIBUTE

Thank you for your interest in contributing to DPFManager,
there are multiple ways and places you can contribute and we're here to help facilitate that.

Code contributions

Contributing a Feature or Fix

If you have identified an issuer or you want to develop a new feature there are a few steps that you need to follow and adquire some kwnoledge.

knowledge required

Contributing with a Feature or a Fix will require a lot of interaction with Git. Git provide a lot of documentation incuding a freely available git-scm book.

Contribute will require knowlage around the concept of the Pull Request, If you need help please read the Github documentation.

Build and test the aplication would require the use of Maven. you could know more about maven in the Maven getting started guide.

DPF manager projects strive to use a common set of styles for code and documentation. This facilitates a team of developers working on the same code base. we use the Google Java Code Style you can download the checkstyle for your java ide from here.

All the code has to be properly documented using Javadoc. you can learn more form Javadoc in the official Oracle guide.

Prepare your Environment

You should have previously installed and configured Git. It's important to note that for your contribution to be accepted you will need to have configured the email address and real name. You will also need to have created an ssh key and associated it with your GitHub Account.

DPF Manager use Maven for build and test automatization. you can find how to Download, Install and Run Maven in their official project web page.

Fork

Fork the DPF Manager repository which you're looking to contribute. This is the first and most fundamental step for being able to contribute. This is your own personal copy of the project which is ready for you to start exploring with your changes.

The following projects are managed by the DPF Manager and available for you to fork and contribute to.

Once you have forked the project on GitHub, then you'll need to clone and checkout a copy from your own repository.

$ git clone git@github.com:username/DPFManager.git
$ cd DPFManager

You now have a fresh checkout of the repository, next you should add the upstream repository as a remote that you'll be able to use to refresh your version and stay in sync while working on your changes.

$ git remote add upstream git://github.com/username/DPFManager.git $ git fetch upstream

Branch

Contributions for the project should happen on a separate branch, and you should name the branch something easily identifiable. For instance if you're going to be fixing issue #1234 consider naming your branch to fix-issue-1234 .

Project structure

The project is structured in two well separated parts. In the future, these parts will be two separated projects.

  • Conformance checker: This is the specific part that checks the files.
  • Shell: This is the big part. Here we have the core, the interfaces and the modules of the project.

Conformance checker

The conformance checker package contains the Conformane Checker Interface, a logger, the configuration classes and the conformance checkers.

By default there are two conformance checkers, the external conformance checker that simply runs an external exe with a given set of parameters, and the TIFF conformance checker.

Conformance checkers consist in four main components:

  • Implementation Checker.
  • Metadata Fixer.
  • Policy Checker.
  • Reporting Creation.

In the TIFF Conformance checker package the implementation checker and the policy checker are not there because they imported from external dependencies.

The metadata fixer is formed by fixes and autofixes. And the reporting classes write the output report in different formats (XML, JSON, HTML and PDF).

Shell

DPFManager shell is structured by modules that can be used by both graphical interface and command line. These modules hold the main logic of the application.

The four main packages of the shell are:

  • Application: Here are the launchers and the application initialization.
  • Core: The core classes, there are some adapters, configurations and the main classes.
  • Interfaces: All the classes related to the interfaces (graphical and console).
  • Modules: Here reside all the modules of DPFManager. The main logic.

Application

There are two packages:

  • App: The classes for initialize the application.
  • Launcher: The application launchers. The noui launchers (Console and server) hold the logic of reading the input parameters and verify those.

Core

The main classes are inside core/app package. There are three main apps, one launches only the graphical interface (MainGuiApp), other launches only the command line (MainConsoleApp). The last one is the main app, which launches one interface or other depending of the parameters (MainApp).

In this package we can find:

  • Adapter: There are adapters of some JacpFX classes.
  • App: The main classes as said before.
  • Config: There are the all the ID’s of the views, modules, etc.
  • Context: The context for sending messages.
  • Messages: Some messages classes.
  • Mvc: The implementation of Model View Controller classes.
  • Util: Some utility classes. The most used is NodeUtil.

And two classes for the configuration and constants definition:

  • DpfManagerConstants: The constants of the application.
  • DpfManagerProperties: The properties read from the properties file of the application.

Interfaces

The graphical interfaces use a plugin named JacpFX. This plugin holds the structure of the views and also has a messages system for communicate the views and the modules.

The command line uses a simple direct message system simulating the one used by the graphical interface, so we can use the same code for communication without JacpFX.

Graphical interface

We structured our application in 7 main perspectives. Each perspective has its own view component, and the top and bottom components, shared by all perspectives. We have a perspective for each different screen, so we have one for the conformance checker tab, the reports tab, etc.

For the top and bottom component, we use a singleton fragment, making it the same for all perspectives.

The main views components use a FXML declaration. Also it has a Model View Controller structure, for clarify the code.

The communication between the different components or with the modules is explained later.

Command line interface

After the parameters are read and verified in the launcher, these are passed to a controller, ConsoleController (for console mode) and ServerController (for server mode). In these controllers resides the logic of deciding what to do with the input parameters and send it to the specific module.

Modules

First of all, a little explanation of what does each module:

  • Client: Sends check requests to the server.
  • ConformanceChecker: It contains the logic of checking a file with the conformance checker.
  • Interoperability: Configuring the conformance checkers.
  • Database: Holds all the interaction with the database.
  • Messages: All the messages written to the console or alerts are treated by this module.
  • Periodic: Holds all the interaction with the operating system tasks.
  • Report: It contains the logic of creating a report for a check.
  • Server: The main logic of the server mode. Receives requests and processes them.
  • Threading: It contains the logic of the multithreading.
  • Timer: It’s an internal timer for executing background tasks.

Module structure

A simple module structure is like this:

These 4 classes must extend a specific abstract class:

  • TestService extends DpfService.
  • TestMessage extends DpfMessage.
  • TestController extends DpfSpringController.
  • TestModule extends DpfModule.

The messages sent to this module are treated by the TestModule (for GUI interface) or the TestController (for CMD mode). This two classes has a reference to the main service class of this module (TestService), so the shared logic is in the service, that can be used by both GUI and CMD. The messages used by this module, should be inside the messages package.

Spring plugin

These modules are automatically instantiated by a simple implementation of Spring plugin.

For CMD, spring will auto-scan the whole package modules. So it will find all the controllers and services.

For GUI, the JacpFX plugin will initialize all the modules (DpfModule). The services will be initialized by spring, but, we cannot scan the whole modules package like CMD, because it will find the controllers too. So the GUI spring will scan all core packages inside each module. Be sure to add this core package to the DpfSpringGui.xml declaration.

Communication

The base of the communication is the JacpFX messaging. This method can send a general object to one perspective, component or module, identified by one ID. Instead of sending a general object, we will always send an object that extends DpfMessage, otherwise the message will be ignored. The entire ID’s of the modules, perspectives, etc. are in three files, inside the package shell/core/config.

In the GUI mode, these messages are sent to a queue, making it asynchronous.

For the CMD mode, we simulated this GUI behaviour with the spring context, but made it synchronous.

For sending a message, we use the context object (JacpFX context or Spring ApplicationContext). We have access to the context inside the main GUI elements (Components, perspectives and fragments) and inside the modules (DpfSpringController and DpfModule). For the module service, the context is set by the controller or module, creating the DpfContext, that will use the JacpFX context or the Spring context, depending on the interface.

PORTABLE FILES

Download the packages and start using the software now,
with this portable files you have all the necessary files to work with it offline, and even modify the source code.
Read the manual for more details on how to build the project.

Build environment

Executables

Source code

Release 3.2.1 (28/04/2017)

Build environment

Executables

Source code

Release 3.2 (31/03/2017)

Build environment

Executables

Source code

Release 3.1.2 (28/02/2017)

Build environment

Executables

Source code

Release 3.1.1 (02/02/2017)

Build environment

Executables

Source code

Release 3.1 (30/12/2016)

Build environment

Executables

Source code

Release 3.0.1 (02/12/2016)

Build environment

Executables

Source code

Release 3.0 (28/10/2016)

Build environment

Executables

Source code

Release 2.6 (30/08/2016)

Build environment

Executables

Source code

Release 2.5 (30/08/2016)

Build environment

Executables

Source code

Release 2.4 (01/08/2016)

Build environment

Executables

Source code

Release 2.3 (28/06/2016)

Build environment

Executables

Source code

Release 2.2 (30/05/2016)

Build environment

Executables

Source code

Release 2.1.2 (13/05/2016)

Build environment

Executables

Source code

Release 2.1 (29/04/2016)

Build environment

Executables

Source code

Release 2.0 (04/04/2016)

Build environment

Executables

Source code

Release 1.4 (29/01/2016)

Build environment

Executables

Source code

Release 1.3 (24/12/2015)

Build environment

Executables

Source code

Release 1.2.3 (10/12/2015)

Build environment

Executables

Source code

Release 1.2 (28/10/2015)

Build environment

Executables

Source code

Release 1.1.1 (02/10/2015)

Build environment

Executables

Source code

Release 1.1 (29/09/2015)

Build environment

Executables

Source code

Release 1.0 (31/07/2015)