Over time I've seen the processFile() method of these three print file processors converge into a single concept:
org.area515.resinprinter.job.ZipImagesFileProcessor
org.area515.resinprinter.twodim.TwoDimensionalPlatformPrintFileProcessor
org.area515.resinprinter.job.STLFileProcessor
2D file types won't be an issue since they will all just extend from the TwoDimentionalPrintFileProcessor. The AbstractPrintFileProcessor already does 90% of the work for you, but we still have to create some boiler plate code. I'd like to have developers who want to work on file processors focus only on the logic necessary to render their files to an images, not multi-threaded job submission. Even though all they have to do is just copy and paste the code from another PrintFileProcessor, you shouldn't have to do that.
Over time I've seen the processFile() method of these three print file processors converge into a single concept: org.area515.resinprinter.job.ZipImagesFileProcessor org.area515.resinprinter.twodim.TwoDimensionalPlatformPrintFileProcessor org.area515.resinprinter.job.STLFileProcessor
2D file types won't be an issue since they will all just extend from the TwoDimentionalPrintFileProcessor. The AbstractPrintFileProcessor already does 90% of the work for you, but we still have to create some boiler plate code. I'd like to have developers who want to work on file processors focus only on the logic necessary to render their files to an images, not multi-threaded job submission. Even though all they have to do is just copy and paste the code from another PrintFileProcessor, you shouldn't have to do that.