Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Step 8 - Where are the rx... methods? #19

Open
junglie85 opened this issue Nov 5, 2017 · 5 comments
Open

Step 8 - Where are the rx... methods? #19

junglie85 opened this issue Nov 5, 2017 · 5 comments
Assignees
Projects

Comments

@junglie85
Copy link

In Step 8, introducing RxJava the code examples refer to various methods such as rxDeletePage(id), yet there are no methods beginning with rx in the WikiDatabaseService verticle.

The Impl class has rxified the method contents, but then the signatures don't match with what is being called in HttpServerVerticle and I get errors to that extent (namely, complaints at the lack of result handler).

There is also reference to io.vertx.guides.wiki.database.rxjava.WikDatabaseService as the return type of createProxy(), yet this package does not exist in the example.

Have I missed something here? Or could you provide some clarification? Are there any plans to update this to RxJava2?

@junglie85
Copy link
Author

Okay, so it's produced by the code gen plugin. I don't recall that being mentioned in the guide and it's very confusing. Perhaps it would be possible to elaborate, such as how it knows to prefix the methods with rx and what the role of the @VertGen and @GenIgnore annotations are?

@vietj
Copy link
Contributor

vietj commented Nov 6, 2017

this is explained in the rx documentation, the doc should indeed elaborate about it and point to the rx doc

@junglie85
Copy link
Author

The only mention of code generation in the Rx documentation is that the Vert.x rxified API is code generated. It doesn't explain that this is how rx service proxies should be produced, why the createProxy method needs to have rxjava (or reactivex) in its package name, nor what annotations are needed. It also requires picking through the codegen documentation.

This is the sort of thing I personally consider as an essential explanation in a guide, picking up where package documentation leaves off. Up until step-8, it's spot on and very good at explaining what is going on and how different elements of the Vert.x ecosystem interoperates, then it just kind of drops off.

I know all of these things take time, and I'm very grateful for the hard work that has been put into this guide so far.

@jponge jponge self-assigned this Nov 6, 2017
@jponge jponge added this to Backlog in Development Apr 26, 2018
@rsippl
Copy link
Contributor

rsippl commented Oct 30, 2019

Adding <classifier>processor</classifier> to the vertx-service-proxy dependency in pom.xml seems to fix the code generation. Without this, I'm getting this error:

java.lang.Error: Unresolved compilation problems: 
	The import io.vertx.guides.wiki.database.reactivex cannot be resolved

@rsippl
Copy link
Contributor

rsippl commented Oct 30, 2019

Actually I was wrong, I'm getting the error above in step 8 regardless of the classifier setting. If I'm running

mvn clean
mvn package

everything seems fine. If I'm running it again, the test phase fails. Basically, it fails every second time I run the above, this happens because mvn clean doesn't work as expected. The first invocation of mvn clean removes just the generated classes, i.e. the .java files in src/main/generated, and the corresponding .class files, plus the jar files from the target dir, leaving the other class files in that same dir. A subsequent build doesn't detect the missing files, presumably because useIncrementalCompilation is set to false, and the tests fail because of missing classes. After that, a mvn clean removes the target dir completely (I don't get why).

There are three fixes:

  1. remove the whole maven-clean-plugin plugin section from pom.xml (but then a mvn clean won't delete the generated .java files anymore)
  2. add ${project.basedir}/target to the maven-clean-plugin section
  3. set useIncrementalCompilation to true

To me, 2. seems best because it leads to the expected behavior on mvn clean: run both the generated classes and the target dir.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development
  
Backlog
Development

No branches or pull requests

4 participants