Programmatically deploying groovy verticles in source subdirectory

[J Pimmel]

Hi

I'm a day into tinkering with some Vert.x and had a question about my approach.

My project is very simple. At the project root directory i have App.groovy and then i have a source dir in the project

 - src/main/groovy/

within which I have placed a com.foo.Test.groovy (under directory com/foo)..

This arises because (in the interest of not locating all my code at the root project directory) I have been trying to use src/main/groovy but no matter what I do the vertx runner doesn't find groovy files I refer to, even when I explicitly add them to the CLASSPATH env variable. When I use the -cp command, I don't see my specified directories being listed on System.getProperty('java.lang.classpath') - hence why I added it to CLASSPATH to force the issue to see if that would work.

What is the recommended approach for organising groovy project code?

Thanks

Jerome

[J Pimmel]

Oh and my App.groovy is attempting to programatically deploy a worker verticle

container.deployWorkerVerticle("com.foo.Test",  container.config, 1) {
    logger.error "Done"
}

but all I get is

Cannot find verticle com.foo.Test

J

[J Pimmel]

Everything works as expected when all classes are in the root directory and after I fixed the following to refer to the .groovy file

container.deployWorkerVerticle("Test.groovy",  container.config, 1) {

[bytor99999]

This might help in creating a maven build.

http://perfectworldprogramming.com/configuring-maven-to-build-your-vertx-module/

I wrote that for my project where I had the same structure as yours. I have groovy scripts at the root, but groovy classes in packages in my src/main/java … directory.

The build will take the classes in packages and package it up into a jar file that is then placed in the lib directory of my vertx module where the scripts are at the root of the module, but the classes are packaged up in a jar.

Good Luck

Mark

[Tim Fox]

Please can you show your code for com.foo.Test.groovy?

Is this is a script? Or a Groovy class?

[J Pimmel]

Hi Mark

Thanks for the references to how you structure your project. I have ended up arriving at a similar structure, that being Groovy scripts at the root and other specialist objects which I might defer into src/main/groovy. I'm not making a module as such but trying to make a bunch of verticles in an 'app' which work together through the eventbus; thus I don't need to precompile anything to get access to the groovy classes in src/main/groovy at runtime from my root level groovy scripts, providing that the directory is on the classpath.

Through this process, what I'm seeing is that one consequence of organizing code into src/main/nnnn means everything there lacks access to the intrinsic 'vertx' and 'container' objects which the root level scripts are decorated with. Unlike Grails where there are static singletons so that you can access things like grailsConfig, applicationContext and other key things in a global manner, I didn't see any equivalent static accessors in the API docs.

Whilst I could very well pass references to vertx and container/config to instances at runtime, I've not done much more than the above - my code is lean enough that I realized there wasn't a justifiable need to proliferate objects/classes but rather that I should refactor down into more verticles, each with clear singular purpose.

Cheers

Jerome

[J Pimmel]

Tim

My hypothetical example was using a Groovy script rather than a class. In summary, from what my tests I've assumed for now that you have to use scripts at the root level; scripts which live in a classpath (even if the package is properly marked) aren't going to load when specified on the command line, eg:

vertx run com.foo.Test.groovy -cp path/to/{com.foo.Test}

Jerome

[Tim Fox]

We used to use Singletons, but after much pressure I removed them some
time back. The reason being, Singletons make it hard to run more than
one Vert.x instead embedded, and make unit testing hard.

> packages in my src/main/java � directory.

> --
> You received this message because you are subscribed to the Google
> Groups "vert.x" group.
> To view this discussion on the web, visit
> https://groups.google.com/d/msg/vertx/-/Z3f4Pk7qBoAJ.
> To post to this group, send an email to ve...@googlegroups.com.
> To unsubscribe from this group, send email to
> vertx+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/vertx?hl=en-GB.


--
Tim Fox

Vert.x - effortless polyglot asynchronous application development
http://vertx.io
twitter:@timfox

[Tim Fox]

If Test.groovy is a script then you will need to tell Vert.x where it is so it can be deployed, e.g.:

container.deployWorkerVerticle("src/main/Test.groovy",  container.config, 1) {

    logger.error "Done"
}

Currently, you are specifying a classname, this doesn't make a lot of sense since Test.groovy is not a class with the name com.foo.Test it's a script.

[J Pimmel]

Tim

Yeah, i fully understand - am not a fan of singletons tbh and they do cause all kinds of problems wrt unit testing.

That said it would be nice to have some facility to provide access to the vertx / container instances; just not sure which convention would be appropriate

Jerome

[J Pimmel]

Thanks for this. Will try it out

[bytor99999]

Yes, in a couple of classes we do pass the eventbus to classes in src/main/java in the constructor so they have access to it. Not a big deal for us.

Mark

On Tuesday, December 4, 2012 11:35:23 AM UTC-8, J Pimmel wrote: