Does not seem to work with multi module projects

[pmlopes]

I've a set of gradle modules (each a vert.x module) and on the root I've a settings.gradle with:

include a
include b

But this fails to build since the paths are not correct and when running tests it cannot resolve the property:

System.getProperty("vertx.modulename")

[darylteo]

They need to be included as compile/test dependencies, no?

Daryl

On Monday, July 14, 2014, Paulo Lopes [email protected] wrote:

I've a set of gradle modules (each a vert.x module) and on the root I've a
settings.gradle with:

include a
include b

But this fails to build since the paths are not correct and when running
tests it cannot resolve the property:

System.getProperty("vertx.modulename")

—
Reply to this email directly or view it on GitHub
#21.

[pmlopes]

no, the modules do not depend on each other. Running the tests fails because the TestVerticle tries to load gradle.properties from the project dir but does not inherit the top level properties...

[pmlopes]

i only reference other projects at runtime, so it would be nice to only depend on the mod zip

[darylteo]

So what you're saying is we have three issues here.

• some build problem when you're "including" other modules
• a testing problem with system environment properties.
• something about depending on the mod.zip

I have not actually spent any time on this project so my memory of the project is quite rusty. I will look into making this a more smooth experience. But I guess I need to know more about what you're trying to accomplish.

For now, to fix the enviornment properties, can you manually set the environment property on the test task. http://www.gradle.org/docs/current/dsl/org.gradle.api.tasks.testing.Test.html

test {
   environment 'vertx.modulename' 'name.of.module'
}

I'm not really sure why you would want to create dependency on zip. Is it because you're trying to run multiple modules within the project?

[darylteo]

Right, the way I have been doing runtime dependencies between vert.x modules is the following:

// root Project including project A
copyMod.dependsOn ':projectA:copyMod'
__watch.dependsOn ':projectA:__watch'

Now, gradle will copyMod both projects as necessary.

---

My proposed action to streamline this process is to avoid creating anything fancy. I would ideally like to use Gradle's dependency mechanism.

dependencies {
  runtime project(':projectA')
}

Then, for each runtime dependency that is

• a project
• with vert.x plugin

Apply the two task dependencies I mention above.

That should solve the runtime issue.

[darylteo]

@pmlopes I haven't used the official template for awhile. Can you tell me if integration tests work from within the IDE?

I have working integration tests from gradle, but not from within IntelliJ.

[darylteo]

I just don't see how testtools expects to accurately run tests on latest sources.

It grabs a few environment variables from the build script, then deploys the module. However, there's no guarantee that the module we're deploying is the latest one since we haven't called copyMod. In multi-project environments, this is even worse if we're trying to deploy from a different subproject. Failing that, it also depends on the presence of a vertx.properties/gradle.properties file that it can pull a specific property from... from a plugin perspective its poor form. I don't like forcing people to maintain consistency against some template.

It seems more reliable to debug the gradle test task itself (I am able to do this in IntelliJ, not sure about Eclipse as of this moment) so I may recommend this as the proper way to perform test debugging. I am confident that calling test task also properly builds and deploys all relevant modules.

Perhaps Tim is using some sort of mangling of vertx_mods etc. to pull a module from the IDE's output dir (like runModIDEA and such).

Anyway I've made a couple of improvements over the past couple of days. Aside from the above, I will probably push it out tomorrow.

[darylteo]

So it looks like they've gotten rid of modules for vertx 3.0.

i.e. most of the stuff I have been doing is going to be absolutely useless when that comes.

Great. They always find new ways of making the stuff I do absolutely pointless.

[darylteo]

Sorry but there's absolutely no point working on things that are just going to be pointless when 3.0 comes. The next version of this plugin will focus on cooperating with 3.0.

[imavroukakis]

There's a lot of us still on the 2.x branch and won't just jump to 3.x when it comes out, your plugin is still mega-useful 👍