Hi, Christofer, thank you so much for your detailed suggestion. It is a good chance to let us know how a clear and canonical maven project is.
I have organized all of these issues and open 3 issues at Github: #502, #503, #504 * https://github.com/thulab/iotdb/issues/502 * https://github.com/thulab/iotdb/issues/503 * https://github.com/thulab/iotdb/issues/504 And, all guys (current committers), it is time to fight. As for the release-profile, I have no experience about that. We will try our best to fix it, and may ask for more help. :D As for the generated codes, especially for Thrfit, I have some question. Generating Thrift code on Windows is easy, you just need a thrfit.exe file. But for Linux and Mac OS, you have to install the thrift yourself. And you must make sure that the version of the thrift is the same with us (v0.9). If someone does not install thrift, Maven will says that something like `/usr/local/bin/thrift does not exist`, and the maven build will failed. Besides, we can find some other projects also check in the generated thrift code, like Apache Cassandra v2.0[1]. Reference: [1] https://github.com/apache/cassandra/tree/cassandra-2.0/interface Best, ----------------------------------- Xiangdong Huang School of Software, Tsinghua University 黄向东 清华大学 软件学院 Christofer Dutz <[email protected]> 于2018年12月12日周三 上午4:49写道： > > Hi all, > > So I was curious, checked out the code and ran a build. I had to disable one test (more details down the document), but in the end I got a successful build. Congrats on that … some of us – especially one other of your mentors - know at least one project where it takes a little more setting up to get it to build ;-) > > Here comes a list of things we will need changing for Apache (And or in order to avoid a lot of problems in the future): > > > * The parent pom in the root has to be set to “org.apache:apache:21” (or the latest version of that) > * As far as I know the ASF doesn’t like the “developers” section in the pom files > * All non-binary files need the ASF header (Yes … all of them … I know this will not be the most glorious job, but it has to be done) > * Module Grafana > * The parent of this module is not within the project scope. This quite often causes problems with the maven tooling and when releasing, the module it will not inherit the settings of the apache parent. This has to be changed (Try adding the iotdb-parent as parent and adding the missing configuration options from the spring-boot-starter-parent. This way you don’t have to redefine all the settings you can no longer inherit from the iotdb-parent. > * Module service-rpc and tsfile: > * You are defining a “release” profile which is obviously intended for releasing. This will not apply as apache releases are performed with the “apache-release” profile. So if important stuff is to be done here (it actually shouldn’t) > * From a quick look all defined there is also done by the profile defined in the “apache-release” profile in the “apache” parent pom. So all except the exclusion for package names including “thrift” could simply be removed. (Maybe it’s worth configuring the maven-javadoc-plugin in a pluginManagement section of the root to exclude them in general and get rid of the “release” profiles in general) > * Especially the staging part has to be removed as you will be staging to repository.apache.org instead of the oss sonatype repo. > > Things I personally would suggest to change: > > > * Don’t use a property to define the version of the artifacts that are part of the build (project.version) (The release plugin updates this for you and believe me I have encountered a lot of problems with this approach in my last 10 years of managing Maven projects as a consultant) > * Why are you generating code (thrift) and checking that in? I would strongly suggest to always generate the code, move the thrift files to “src/main/thrift” and have the build generate things ot its usual location “target/generated-sources/thrift” (or something like that … the last part of the path may differ) > * General observations: > * Replace the antrun plugin with the dependencies plugin for copying the libs to the iotdb/lib directory (antrun is highly deprecated) > * No need to re-define the license, scm, distribution management in sub-modules > * Try to unify the plugin definitions in the root pom. > * The “release” profile could be causing problems in a real release (will not be executed as with apache it’s called “apache-release”) > * You are relying on Java 8 so the Jodatime library is included in general there is no need to use the external library and the included classes could be used) > * It might we worth defining an “example” module which contains real maven buildable examples (some projects even move them to a separate examples repository) right now there is no way to automatically detect that the code has changed and the example no longer matches that API. > * I wouldn’t produce fat jars (using the assembly plugin) as this bundles classes in to a library that might be used in another application that has dependencies to the same libraries but in a different version … trust me … these are the worst problems to track down. > * Module iotdb: > * Have the MANIFEST.MF generated by maven instead. > * You have a dependency on the antlr3 maven plugin. Instead you should depend on the antlr-runtime artifact that matches your antlr3 version. > * What is the “kvmatch-iotdb” artifact referring to? Seems it is not part of this project. > * Why are you manually configuring an additional compilation in the pre-integration-test phase? There is no code in “src/it/java” > * One test is failing because I’m in a different time zone: Failed tests: test(cn.edu.tsinghua.iotdb.sql.DateFormatTest): expected:<…02-01T11:12:35.000+0[1]:00> but was:<…02-01T11:12:35.000+0[8]:00> (cn.edu.tsinghua.iotdb.sql.DateFormatTest.test has most references ending with “+08:00” which makes the tests only run in one time-zone) > * cn.edu.tsinghua.iotdb.queryV2.engine.control.OverflowFileStreamManager uses the deprecated internal SUN API which is not available in Java 11 anymore > * Module jdbc: > * You are adding a “interface/thrift” directory to the sources, but that doesn’t exist. > * Module service-rpc: > * Move the interfaces thirft files to “src/main/thrift” and have the code generated on every build to “target/generated-sources” (default) > * Don’t check in generated code. > * Module tsfile_ > * In general the same remarks apply as to the service-rpc module > * Module spark > * You have included *.tsfile in your “.gitglobal” but seem to have forced in a “tsfile”-file in the test resources (Things can get quite messy in such situations if the file is ever changed, as the IDE will never detect changes and never commit any changes to that file) > * Module Hadoop > * Looks a little unfinished … so I won’t go into details here. > > So much for a quick run through the project … If you want, I could be of assistance with the actual transformation … I know I could probably address most in half a day and that most people would probably take a lot longer. After all we want you to learn the Apache way … not to learn setting up projects ;-) (Other mentors please correct me if I’m wrong) > > So … I’ll call it a night or my girlfriend will get angry ;-) > > Chris > >
