Hi all,

I just submitted a PR: https://github.com/apache/incubator-iotdb/pull/332

So I invested a great portion of Sunday and most of today to clean up the build 
a bit. Here comes a summary to what I found and changed:

  *   Nothing is built outside the target directory anymore
     *   I moved the static parts of the client and server distributions to 
“src/assembly/resources” and added an assembly that builds the client and 
server inside the target directory (You need to update the documentation on 
this)
     *   The sever is now available at server/target/iotdb-server-0.9.0-SNAPSHOT
     *   The client is now available at 
client/target/iotdb-client-0.9.0-SNAPSHOT
     *   I updated the integration tests to work with these new locations
  *   I updated the distribution module (binary-distribution) to simply include 
and unpack the client and server assemblies, which greatly simplifies the 
assembly itself.
  *   In the integration-tests you use a process builder to get the current 
working directory … you can access this in the “user.dir” System property.
  *   There was a large mixture of artifacts with different versions in the 
classpath.
     *   I set all external dependencies to the same versions using a big 
dependencyManagement block in the master pom
     *   I removed the explicit version of every external dependency and moved 
it into the main dependencyManagement block in the root pom (except 
dependencies only used in the examples, for these I added a 
dependencyManagement block in the example pom). This way you instantly identify 
external dependencies.
     *   I added an enforcer rule to fail the build if two differing versions 
of one artifact are being used in the build (This should eliminate this problem 
from re-occuring)
     *   I replaced the usage of “${project.version}” with the real version 
(There is no need to manually update these versions and this way when looking 
at the pom you instantly know the version … keep in mind if an artifact is 
deployed to maven central, the user doesn’t have the code and therefore he 
always has to scroll up to the top in order to see which version is used)
  *   There were some imports related to Jdk 11 no longer providing some APIs, 
I moved those imports to a maven profile, which is activated based on the JDK 
version
  *   HDFSInputTest created a file in “spark/test/” … if the test failed, the 
rat plugin would complain the next time it’s run, I let it create the file in 
the “target” directory

However I did notice that there is quite a number of artifacts still in the 
classpath that have different maven coordinates, but very similar content:

  *   com.fasterxml.jackson.* and org.codehaus.jackson (1.9.13) (Not dangerous 
as they have different package names)
  *   javax.activation:activation (1.1.1) and 
javax.activation:javax.activation-api (1.2.0) (Probably not dangerous as the 
API versions are pretty similar, but the package names are equal)
  *   javax.servlet:javax.servlet-api (3.1.0) and javax.servlet:servlet-api 
(2.5) (Possibly dangerous as there is a difference in the major version, which 
usually implies incompatible changes)
  *   …
  *   I added an enforcer rule, that reports this type of problems, but 
commented it out as there is quite a bit of this throughout the project which 
would have to be cleaned up  first.

I checked the full build with all tests on Oracle-Java 8, Open-JDK 11, 
Oracle-JDK 12.

Chris

Reply via email to