Re: Findings in the build
Hi Chris,
thanks fort he changes.
I checked the PR and all artefact seem to be as they should be.
So are there any other issues to be addressed before spinning up the next round
(RC3)?
Julian
Am 05.08.19, 14:46 schrieb "Christofer Dutz" :
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
Findings in the build
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
Re: [CANCELLED][VOTE] Apache IoTDB (Incubating) 0.8.0 RC2
Look forward to the next RC! --- Xiangdong Huang School of Software, Tsinghua University 黄向东 清华大学 软件学院 Julian Feinauer 于2019年8月5日周一 下午5:27写道： > Hi Justin, > > thanks for the reminder. > But, in this situation I consider the issue that major (and it is to have > binaries in a source release) that I see this as a veto. > And as I know that Chris is already working on a fix I think its nicer for > us to enter the stage with a reasonable clean release and sort out as many > "initial problems" as possible. > > But, agree, the next RC should make it... or the one after... or ... : ) > > Julian > > Am 05.08.19, 11:24 schrieb "Justin Mclean" : > > Hi, > > > due to the binding -1 Vote of Chris and the major issues he raised > (and I guess nobody will argue about) I hereby cancel the Vote for 0.8.0 > RC2. > > Just a reminder that vote can still pass with -1 votes, -1 are not > vetos. There's been a couple votes I’ve voted -1 one that still passed. > > > For all (P)PMCs: > > Don’t worry, this is not uncommon for a first Apache Release and > will get better and better with every release you do. > > I think I recall one that had 14 RCs, hopefully we’ll not reach that > number. > > Thanks, > Justin > >
Re: [CANCELLED][VOTE] Apache IoTDB (Incubating) 0.8.0 RC2
Hi Justin, thanks for the reminder. But, in this situation I consider the issue that major (and it is to have binaries in a source release) that I see this as a veto. And as I know that Chris is already working on a fix I think its nicer for us to enter the stage with a reasonable clean release and sort out as many "initial problems" as possible. But, agree, the next RC should make it... or the one after... or ... : ) Julian Am 05.08.19, 11:24 schrieb "Justin Mclean" : Hi, > due to the binding -1 Vote of Chris and the major issues he raised (and I guess nobody will argue about) I hereby cancel the Vote for 0.8.0 RC2. Just a reminder that vote can still pass with -1 votes, -1 are not vetos. There's been a couple votes I’ve voted -1 one that still passed. > For all (P)PMCs: > Don’t worry, this is not uncommon for a first Apache Release and will get better and better with every release you do. I think I recall one that had 14 RCs, hopefully we’ll not reach that number. Thanks, Justin
Re: [CANCELLED][VOTE] Apache IoTDB (Incubating) 0.8.0 RC2
Hi, > due to the binding -1 Vote of Chris and the major issues he raised (and I > guess nobody will argue about) I hereby cancel the Vote for 0.8.0 RC2. Just a reminder that vote can still pass with -1 votes, -1 are not vetos. There's been a couple votes I’ve voted -1 one that still passed. > For all (P)PMCs: > Don’t worry, this is not uncommon for a first Apache Release and will get > better and better with every release you do. I think I recall one that had 14 RCs, hopefully we’ll not reach that number. Thanks, Justin
[jira] [Created] (IOTDB-158) iotdb metrics server
穆喜军 created IOTDB-158: - Summary: iotdb metrics server Key: IOTDB-158 URL: https://issues.apache.org/jira/browse/IOTDB-158 Project: Apache IoTDB Issue Type: New Feature Reporter: 穆喜军 Attachments: image-2019-08-05-16-36-57-434.png Can we add a web page like this? We can look at the execution history and time of the SQL !image-2019-08-05-16-36-57-434.png! -- This message was sent by Atlassian JIRA (v7.6.14#76016)
