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.
The official Twitter account is @DPFManager
Visit our Blog to get the the latest events and news from around the DPF Manager.
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.
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.
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.
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.
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 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 firstname.lastname@example.org: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
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
The project is structured in two well separated parts. In the future, these parts will be two separated projects.
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:
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).
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:
There are two packages:
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:
And two classes for the configuration and constants definition:
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.
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.
First of all, a little explanation of what does each module:
A simple module structure is like this:
These 4 classes must extend a specific abstract class:
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.
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.
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.
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.