DynaFile is coupled to Maven.

[ghost]

https://github.com/vlingo/vlingo-common/blob/master/src/main/java/io/vlingo/common/compiler/DynaFile.java#L14-L17

Gradle generate the classes in another folder, like out/production/classes. It causes vlingo to just be compatible to Maven projects.

[d-led]

while the target directories are indeed based on the Maven convention, as the classes are loaded at run-time, the code generation and caching logic works in gradle or a fat jar context just as well. Check out this project: https://github.com/d-led/hello_vlingo (all 3 version run in CI)

[ghost]

I opened the issue because, indeed, it hasn't worked on Gradle for development. I was sure it works on release mode.

I could create a repository with an example Gradle project if it helps. Maybe I missed something, but I created the project with Maven to be sure it was due to Gradle.

Let me know if you need more information, like versioning, about this issue.

On Sun, Jul 15, 2018, 17:27 Dmitry Ledentsov notifications@github.com wrote:

while the target directories are indeed based on the Maven convention, as the classes are loaded at run-time, the code generation and caching logic works in gradle or a fat jar context just as well. Check out this project: https://github.com/d-led/hello_vlingo (all 3 version run in CI)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/vlingo/vlingo-common/issues/4#issuecomment-405099167, or mute the thread https://github.com/notifications/unsubscribe-auth/AFQzdYjcjw97AWVysWMXDPIL6Idnv7h5ks5uG197gaJpZM4VQNio .

[VaughnVernon]

In the Gradle docs I can't find an explicit and official generated source location for Gradle or how to determine at runtime which environment is in use. I could use help here, if even making it a configuration.

[d-led]

That would be indeed helpful to know which context you are talking about exactly, e.g. IntellJ or Eclipse and what difference you mean between release and development. Just bumped the vlingo-actors version to see if it still works. It does: https://travis-ci.org/d-led/hello_vlingo/builds/404155607

[d-led]

@aleixmorgadas it would be nice if you could set up an example project that could be to debug

[ghost]

I created the vlingo-http-gradle-issue-4 repository with the minimum code to throw the error.

The IDE used is IntelliJ & I started the application in the same IDE. The same structure with Maven works.

Here some stack trace (skipped some lines)

vlingo/http: Generating handler dispatcher for main: com.github.aleixmorgadas.vlingohttpgradle.HelloWorldResource
vlingo/http: Generating handler dispatcher for test: com.github.aleixmorgadas.vlingohttpgradle.HelloWorldResource
vlingo/http: Failed to load resource: hello because: Resource cannot be created for: com.github.aleixmorgadas.vlingohttpgradle.HelloWorldResource
java.lang.IllegalArgumentException: Resource instance with dispatcher for com.github.aleixmorgadas.vlingohttpgradle.HelloWorldResource not created because: Cannot generate resource dispatcher class for com.github.aleixmorgadas.vlingohttpgradle.HelloWorldResource because there is no corresponding:
target/test-classes/com/github/aleixmorgadas/vlingohttpgradle/HelloWorldResource.class
    at io.vlingo.http.resource.Resource.tryGenerateCompile(Resource.java:127)
//. ......
    at com.github.aleixmorgadas.vlingohttpgradle.Application.main(Application.java:10)
Caused by: java.lang.IllegalArgumentException: Cannot generate resource dispatcher class for com.github.aleixmorgadas.vlingohttpgradle.HelloWorldResource because there is no corresponding:
target/test-classes/com/github/aleixmorgadas/vlingohttpgradle/HelloWorldResource.class
    at io.vlingo.http.resource.ResourceDispatcherGenerator.generateFor(ResourceDispatcherGenerator.java:87)
    at io.vlingo.http.resource.Resource.tryGenerateCompile(Resource.java:122)
    ... 8 more
Exception in thread "main" java.lang.IllegalStateException: Resource cannot be created for: com.github.aleixmorgadas.vlingohttpgradle.HelloWorldResource
    at io.vlingo.http.resource.Loader.resourceFor(Loader.java:79)

[VaughnVernon]

@aleixmorgadas Thanks for the stack trace and sample project. I have struggled to find anything specific in Gradle docs and various forum discussions regarding where generated source should be located. Can you make a recommendation based on your experience with Gradle and IntelliJ? My thought is to provide a configuration root for both main and test. The following is an example for vlingo-http.properties, or would be included in your DSL configuration.

#=====================================
# generated resource dispatchers
#=====================================

resource.dispatcher.generated.sources.main = target/generated-sources/
resource.dispatcher.generated.sources.test = target/generated-test-sources/
resource.dispatcher.generated.classes.main = target/classes/
resource.dispatcher.generated.classes.test = target/test-classes/

The values would be replaced for Gradle and/or IntelliJ. Please provide your thoughts.

[VaughnVernon]

@aleixmorgadas @d-led I implemented this as I stated above. It's all pushed to vlingo-actors master and vlingo-http master. Here are the two sets of configurations:

# vlingo-actors.properties
proxy.generated.sources.main = target/generated-sources/
proxy.generated.sources.test = target/generated-test-sources/
proxy.generated.classes.main = target/classes/
proxy.generated.classes.test = target/test-classes/
----------------------------
# vlingo-http.properties
resource.dispatcher.generated.sources.main = target/generated-sources/
resource.dispatcher.generated.sources.test = target/generated-test-sources/
resource.dispatcher.generated.classes.main = target/classes/
resource.dispatcher.generated.classes.test = target/test-classes/

[ghost]

Unrelated to the issue per se, why do you need to compile the classes at run time?

Regarding the solution by configuration, it works, but I think vlingo is relying a lot to configuration files, it should provide better error reporting to help the developer find the issues/solutions earlier. En example is that, if vlingo-actors.properties file isn't present, it throws a NullPointerException and should throw something more descriptive, my 5 cents.

[ghost]

Checked. Working with the latest version 0.4.0

[VaughnVernon]

@aleixmorgadas Thanks. I answer your questions here.

1. We don't require runtime code generation and compilation unless the developer has not arranged for proxies to be pre-generated. For vlingo-actors you can use the vlingo-maven-plugin. See the vlingo-maven-plugin-test for usage. For vlingo-http the vlingo-maven-plugin has not yet been enabled for dispatcher proxy generation support. Still, using runtime dynamically generated proxies is nice for testing, because you can quickly change/refactor the tested and test code before it is well-designed green.

2. There are configuration files now, but very minimal configuration is required. It has always been my intention to support fluent configuration APIs, but right now I am focused on more important features/functionality. As you can see most of the projects are at 0.5.0 or less. This is something that developers of the tools should be willing to work with for a short time until there is time to make it more seamless. If you can't live with that right now for some reason please change it.

3. The configuration is minimal, and in vlingo-actors there is no consumer-programmer configuration necessary for reasonable default behavior (remove vlingo-actors.properties and use World.start("worldname" true) and see). Yes, current default behavior for proxy generation is for Maven, not Gradle, but it's simple to understand why when considering overall industry usage of Maven. It's not a judgment as to which build tool is better, it's just a matter of numbers of projects/users.