Page History

...

Build and generate Eclipse files (the conservative method):

For master - without using local maven repository; 

$ mkdir workspace
$ cd workspace
$ git clone https://github.com/apache/hive.git
$ cd hive
$ mvn clean install -DskipTests
$ mvn package eclipse:clean
$ mvn eclipse:eclipse -DdownloadSources -DdownloadJavadocs
$ cd itests
$ mvn clean install -DskipTests
$ mvn eclipse:clean
$ mvn eclipse:eclipse Pitests -DskipTests -DdownloadSources -DdownloadJavadocs

In Eclipse define M2_REPO in Preferences -> Java -> Build Path -> Classpath Variables to either:

Mac Example

/Users/$USER/.m2/repository

NOTE: The presence of the package target is crucial in sucessfully generating the project files.

NOTE: I would also recommend to wipe out or rename the org/apache/hive subtree of the local m2 repo prior to generating the project files; and you may want to check after its execution that it does not contain any files - if it does contain something; then your project files may not be fully independent of downloaded maven artifacts.

This will work on all branches; but keep in mind that in this case you are installing the hive artifacts into your local repository.

$ mkdir workspace
$ cd workspace
$ git clone https://github.com/apache/hive.git
$ cd hive
$ mvn clean install -DskipTests
$ mvn eclipse:clean
$ mvn eclipse:eclipse -DdownloadSources -DdownloadJavadocs
$ cd itests
$ mvn clean install -DskipTests
$ mvn eclipse:clean
$ mvn eclipse:eclipse -DdownloadSources -DdownloadJavadocs

In Eclipse define M2_REPO in Preferences -> Java -> Build Path -> Classpath Variables to either:

Mac Example

/Users/$USER/.m2/repository

Linux Linux Example

/home/$USER/.m2/repository

...

• Compile the Hive source from the top level Hive directory:

  Code Block
  language text
  mvn clean install -DskipTests

• Compile the itests:

  Code Block
  language text
  cd itests mvn clean install -DskipTests

• Run the test and generate the output file using the appropriate -Dtest (ex. TestMinimrCliDriver; see itests/qtest/pom.xml for the names of other test suites):

  Code Block
  language text
  cd qtest mvn clean install -DskipTests

• Run the test and generate the output file using the appropriate -Dtest (ex. TestMinimrCliDriver; see itests/qtest/pom.xml for the names of other test suites):

  Code Block
  language text
  cd qtest mvn test -Dtest=TestMinimrCliDriver -Dqfile=<filename>.q -Dtest.output.overwrite=true

• Add your output file to ql/src/test/results/clientpositive/<filename>.q.out (or /clientnegative if it is a negative test).

With the above steps, you can create a patch which has a .java file, a .q file and a .q.out file.

Why isn't the itests pom connected to the root pom?

• test -Dtest=TestMinimrCliDriver -Dqfile=<filename>.q -Dtest.output.overwrite=true

• Add your output file to ql/src/test/results/clientpositive/<filename>.q.out (or /clientnegative if it is a negative test).

With the above steps, you can create a patch which has a .java file, a .q file and a .q.out file.

Why isn't the itests pom connected to the root pom?

It would be great to have it connected, but it would make it harder to use mvn test locally. The best option would be to utilize the failsafe plugin for integration testing; but it needs a bit different setup, and its harder to use for now...If you'd like to give that a try, by all means, go ahead.

There is an option to attach all the itest subprojects to the main project by enabling this with -Pitests.

There are some good and bad sides using this, it's introduced as a profile to clearly communicate that the integration tests are attached to the main project.

The good is that you may use freely -Pitests to run integration tests from the root project without the need of mvn install

mvn test -q -Pitests -Dtest=TestCliDriver -Dqtest=sample2.q

And by having -Pitests around you are always compiling the integrations tests to...this can improve compile time error detection.

The bad thing is that a simple mvn test -Pitests will start executing all integration testsThe qfile tests in itests require the packaging phase. The Maven test phase is after compile and before packaging. We could change the qfile tests to run during the integration-test phase using the "failsafe" plugin but the "failsafe" plugin is different than surefire and IMO is hard to use. If you'd like to give that a try, by all means, go ahead.

Why does a test fail with a NullPointerException in MiniDFSCluster?

...