renatoathaydes / ceylon-gradle-plugin

A simple Gradle plugin to manage Ceylon projects.
22 stars 6 forks source link

Building a module and its separate test module #8

Open lucono opened 8 years ago

lucono commented 8 years ago

The plugin works great, and now supports testModule, testRoots and testResourceRoots properties.

What's an example build.gradle setup for a module and its separate test module, with each having their various dependencies?

Thanks.

renatoathaydes commented 8 years ago

Here's an example of a module with a separate test module:

https://github.com/renatoathaydes/ceylon-gradle-plugin/tree/master/ceylon-gradle-plugin-tests/module-with-tests-sample

Notice that there are several examples in the ceylon-gradle-plugin-tests directory.

Would separate overrides.xml files be generated for the primary module and test modules or would it be a single overrides file?

No. The overrides file is only generated for the main project. As the test project imports the main project, it should inherit all its dependencies.

If you have some specific problems due to this limitation, please let me know.

How might it be setup to possibly work in the Ceylon eclipse IDE for the separate primary and test modules (with the test module having a dependency on the primary module)?

I can import the above sample without issues in Eclipse by creating a new project and selecting "existing root" as the project's root, which includes both the main module and the test module. Have you had problems doing that?

lucono commented 8 years ago

When the test module has maven dependencies that themselves have transitive dependencies that also need to be imported, but are not part of the imports of the main module under test, how do you make them available to the test module without individually importing them all in the test module's module.ceylon file?

One example is:

import "org.springframework.boot:spring-boot-starter-test" "1.3.2.RELEASE";

which itself has these dependencies:

<artifact groupId='org.springframework.boot' artifactId='spring-boot-starter-test' version='1.3.2.RELEASE'>
  <add groupId='junit' artifactId='junit' version='4.12' shared='true' />
  <add groupId='org.hamcrest' artifactId='hamcrest-core' version='1.3' shared='true' />
  <add groupId='org.mockito' artifactId='mockito-core' version='1.10.19' shared='true' />
  <add groupId='org.objenesis' artifactId='objenesis' version='2.1' shared='true' />
  <add groupId='org.hamcrest' artifactId='hamcrest-library' version='1.3' shared='true' />
  <add groupId='org.springframework' artifactId='spring-core' version='4.2.4.RELEASE' shared='true' />
  <add groupId='commons-logging' artifactId='commons-logging' version='1.2' shared='true' />
  <add groupId='org.springframework' artifactId='spring-test' version='4.2.4.RELEASE' shared='true' />
</artifact>
renatoathaydes commented 8 years ago

Currently, the way to solve the problem would be to make your project two separate gradle sub-projects:

-- parent-project |-- prod-module |-- test-module

test-module should depend on prod-module. Each sub-project can have its own overrides file. Add the dependencies in the test-module's source module file... don't declare test-module's testModule as by default, the module itself is used as a test module, so you can run your tests by doing:

gradlew :parent-project:test-module testCeylon

I am not sure this can be done all automatically by getting the plugin to generate overrides files for both production and test modules. It may get confusing for users. But I will think carefully about this.