With version 6.1.1 of Datalogics PDF Java Toolkit, our Engineering team built a whole new set of samples that focus on best practices with PDF and Java. That doesn’t mean that what we were shipping before was wrong or bad, the old samples were more like proof that PDF Java Toolkit functioned as expected. To be honest, with the old samples we found that sometimes the samples didn’t function as we expected!
To help keep us honest with ourselves and, more importantly, with our customers, we have made the GitHub repository that contains our samples, tests, and input files publicly available. Go check it and the samples out and if you spot a problem, let us know by creating an issue! Let’s take a quick look at how to work with the samples.
Our new samples are organized by package and we hope you find them as easy to navigate as we have so far. As with other Java projects, the source code for the samples are distributed amongst a number of packages, each with its own unique name and purpose. The current set of package names that ship with Datalogics PDF Java Toolkit 6.3.1 are as follows
- creation – focuses on creating PDF files, either from nothing or by converting other file formats to PDF
- extraction – focuses on getting information out of PDF files, i.e. extracting the text of a PDF
- forms – focuses on working with AcroForms
- images – focuses on common image processing like downsampling
- manipulation – a “catch-all” for some of the common workflows that we typically hear customers asking about
- printing – focuses on using the Java APIs to print a PDF
- signature – focuses on handling digital signatures in a PDF
- util – another “catch-all” for classes that we found useful while building the samples and will eventually be refactored into PDF Java Toolkit itself
The Maven project
With our old set of samples, we shipped some batch and shell scripts to help with compiling and running the samples as well as an Eclipse project. With the jump to version 6 of PDF Java Toolkit, though, we thought it was time to move forward a little and the samples project was moved from being an Eclipse project to using Maven. The move to Maven was not an easy choice to make, however, we feel it was the right one to make at this time. Using Maven to build the samples provides a level of flexibility and maintainability that we did not have before.
Supplying an Eclipse project got us into all sorts of conversations about what other IDEs we should support out of the box and the move to Maven allows us to easily support any IDE that has a Maven plugin. Maintaining the Maven project moving forward is also less resource intensive than maintaining projects for multiple IDEs and multiple versions of multiple IDEs and allows us to focus on what we are good at, working with the PDF file format!
Compiling and running
The most straightforward way to compile and run the new samples is by letting the machine do the work! Don’t spend time typing in commands at the command line (I mean you can, I still do this for some things like working with Git) and let the IDE be your friend. Eclipse, IntelliJ, and Netbeans all either support Maven out of the box these days or have a plugin that adds support for Maven projects.
Once you have your preferred IDE (with Maven support) open and ready to go, all there is to it is to import the samples project, point your IDE’s project import process at the samples directory and let it put the pieces together. After a minute or two of connecting the pieces and parts and fetching the dependencies, you are ready to build and run any of the samples.
Having trouble getting the samples going and want a little more hands-on help? Contact our support team at firstname.lastname@example.org . Don’t see a sample that shows how to do what you need it to? Let us know by suggesting we create a sample.