Table class overhauled, main package cleaned up.

[finn-wa]

Changelog

This fork was made as part of a university project. These changes have been implemented:

• Removed abstract modifier from Table class to allow it to be instantiated directly. This is less confusing than instantiating through BaseTable, and allows the user to employ the <T extends PDPage> generic functionality without writing their own Table sub-class.
• Split Table<T> into two classes (as it was huge, and had too many responsibilities):
  • TableDrawer<T> does all of the drawing and nothing else. Its only public method is draw().
  • Table stores the styling and the Rows.
    This change makes it easier to write the same table to different documents and makes the code easier to understand.
• Added Table.Builder for more user-friendly construction of Table objects.
• TableDrawer<T> is now the only class which interacts with PageProvider<T>, so the <T> parameterisation was removed from the Table, Row, and Cell classes.
• BaseTable now acts as an adapter for sending deprecated method calls to the new objects.

Cleaned up root of main package:

• Moved ImageCell class into Image sub-package.
• Moved HTMLNode and TableCell into new HTML sub-package.
• Deleted deprecated BoxableUtils class.
• Deleted dead classes (AbstractPageTemplate, AbstractTemplatedTable).

Made building from source easier:

• Removed Gradle, left Maven. Couldn't get it to import into Eclipse error-free with both build tools present.
• Added .project, .classpath, .settings files to .gitignore.

Miscellaneous fixes:

• Replaced deprecated PDPageContentStream constructors
• Fixed some outdated header checks
• Removed Guava dependency as it was barely doing anything

[dhorions]

Hi @finn-wa , it's great to see the effort you put into this.
I will try to find time to review this . Perhaps @Frulenzo also has some thoughts on these changes?

Thanks,

Dries

[Frulenzo]

First, thank you very much @finn-wa for code review, refactoring and enhancements. I will definetly take a look over weekend and write my thoughts about it.

[ogmios-voice]

I had no problem importing the Gradle project using Eclipse 2019-03 (v4.11) and the built-in Buildship plugin 3.0.1.v20181217-1554. You just need to add the following line to build.gradle:

apply plugin: 'eclipse' 

But ultimately the goal of a build tool is to automate the building etc. process, helping with the import into an IDE is just a plus (of course a quite useful and timesaving one). You can edit the code any way you want to, it has nothing to do with building it.
Thus I'm against removing Gradle.

[PavelCibulka]

Guava removal is much needed.

[johnmanko]

Guava removal is much needed.

@PavelCibulka See pending PR #247

[johnmanko]

These look like great changes, but I have concerns of the target java versions. I think it's safe to assume that Java 1.8 might be the highest target version unless this project releases both 1.8 and a 1.9+ module versions.

• There is still a LOT of 1.8 code out there not ready to move to 1.8.
• Maybe projects can't move a module build. In fact, this very project is prevented from moving to a module build because of it's dependency guava, which Google won't make a module release for. You found that out, I'm sure, which is why you removed it from pom.xml
• If bumping to Java 1.8, might want to consider bumping commons-io (Bump commons-io from 2.4 to 2.7 #229). Also, see fix: #233, #236, #237, #239, #241, #246 #247/Issue and PR management in order to create a new release #248.

I don't know the codebase well enough to a full and complete endorsement, but if shouldn't take long for @dhorions and @Frulenzo to inspect, as it looks like simple changes.

Nice job, @finn-wa !