Since I had to review this addon for potential inclusion in the system of a customer, I noticed a serious problem with the packaging and dependency management. The Repository AMP ships a lot of JARs that it should have never included. Version 1.4.0 ships:
jetty-http-7.4.0.v20110414.jar
jetty-security-7.4.0.v20110414.jar
junit-remote-3.jar
junit-4.11.jar
jetty-io-7.4.0.v20110414.jar
pdf-toolkit-repo-1.4.0.jar
slf4j-api-1.7.12.jar
spring-test-3.0.6.RELEASE.jar
args4j-2.0.16.jar
jetty-server-7.4.0.v20110414.jar
itextpdf-5.0.6.jar
jetty-continuation-7.4.0.v20110414.jar
jetty-servlet-7.4.0.v20110414.jar
hamcrest-core-1.3.jar
jetty-util-7.4.0.v20110414.jar
Most of the JARs are only used for testing since the single test class (TestPDFActionFormFilter) is located in the src/main/java path instead of the more appropriate src/test/java path for unit tests. In at least one instance (SLF4J API) the inclusion of the JAR may pose a compatibility problem for anyone installing the AMP, since the version of the JAR may be different from what is being used in a specific Alfresco Repository version, and abritrary classpath loading order (often dependent on OS file listing order) could end up loading the wrong version.
Since I had to review this addon for potential inclusion in the system of a customer, I noticed a serious problem with the packaging and dependency management. The Repository AMP ships a lot of JARs that it should have never included. Version 1.4.0 ships:
Most of the JARs are only used for testing since the single test class (TestPDFActionFormFilter) is located in the src/main/java path instead of the more appropriate src/test/java path for unit tests. In at least one instance (SLF4J API) the inclusion of the JAR may pose a compatibility problem for anyone installing the AMP, since the version of the JAR may be different from what is being used in a specific Alfresco Repository version, and abritrary classpath loading order (often dependent on OS file listing order) could end up loading the wrong version.