what's the kind of a Class that with annotations @ProxyGen but without @VertxGen

[okou19900722]

@ProxyGen
public interface Test {
    @Fluent
    Test foo();
}

this method will add to anyJavaTypeMethods because of the kind of Test is ClassKind.OTHER

[okou19900722]

it throw that "error: TestVertxEBProxy is not abstract and does not override abstract method foo() in Test"

[vietj]

I think that interfaces with @ProxyGen and without @VertxGen should be rejected

[okou19900722]

https://github.com/vert-x3/vertx-service-proxy/pull/75

[adnanel]

Sorry for bumping, but in my project (using vertx 3.5.4) I had this working and in the generated proxy it contained the proxy methods, but now that we upgraded to 3.6.0CR1 (for a fix we required) I am indeed getting incomplete classes (same error that @okou19900722 stated).

I was always under the impression that I don't need VertxGen unless I want stub services generated, but I tried it anways alongisde ProxyGen but then getting this error:

Error:(20, 1) java: Could not generate model for com.our.package.EBOurService: [Error: could not create constructor: null]
  [Near : {... var futMethod = new io.vertx.codegen.MethodInfo( ....}]
               ^
  [Line: 1, Column: 798]

In fact, the service generates OK with VertxGen, but I still get the error, thus the complete build fails.

What am I missing? An example service that's failing to generate:

import io.vertx.codegen.annotations.Fluent;
import io.vertx.codegen.annotations.GenIgnore;
import io.vertx.codegen.annotations.ProxyGen;
import io.vertx.codegen.annotations.VertxGen;
import io.vertx.core.AsyncResult;
import io.vertx.core.Handler;
import io.vertx.core.Vertx;
import io.vertx.core.eventbus.DeliveryOptions;

@ProxyGen
@VertxGen
interface EBCluster1Service {
    String ADDRESS = "api.service.cluster1";
    String NAME = "cluster1";

    @GenIgnore
    static EBCluster1Service create(Cluster1Service delegate) {
        return new EBCluster1ServiceImpl(delegate);
    }

    @GenIgnore
    static EBCluster1Service createProxy(Vertx vertx, DeliveryOptions deliveryOptions) {
        return new EBCluster1ServiceVertxEBProxy(vertx, EBCluster1Service.ADDRESS, deliveryOptions);
    }

    @Fluent
    EBCluster1Service pong(String message, Handler<AsyncResult<String>> handler);
}

[diabolicallabs]

Me too. My interface is more or less the same. I'm using 3.6.0 release version.

EodService.java:[17,8] Could not generate model for com.diabolicallabs.quant.eoddata.EodService: [Error: could not create constructor: null]
[Near : {... var futMethod = new io.vertx.codegen.MethodInfo( ....}]

Removing @VetxGen seems to fix it but then I can't generate clients for non-Java languages.

[vietj]

can you provide a reproducer project @diabolicallabs ?

[diabolicallabs]

Working on it...

David Bush

[vietj]

thanks

[diabolicallabs]

In creating the reproducer, I found the problem. I had a maven dependency with a transitive dependency on an older version of vertx-rx-java 3.2.1. Updating that solved the problem.

Here is the reproducer if you're interested: https://github.com/diabolicallabs/codegen-reproducer

Thank you for your interest Julien.

[vietj]

I'm getting

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.3:compile (default-compile) on project quant-split: Compilation failure
[ERROR] /Users/julien/java/reproducers/codegen-reproducer/quant-split/src/main/java/com/diabolicallabs/quant/split/SplitPersistService.java:[15,8] Could not generate model for com.diabolicallabs.quant.split.SplitPersistService: [Error: unresolvable property or identifier: handlerSuperType]
[ERROR]   [Near : {... @end{', '}@end{}@if{handlerSuperType != null}@if{a ....}]
[ERROR]                                    ^
[ERROR]   [Line: 31, Column: 355]
[ERROR] 
[ERROR] -> [Help 1]

is that what you have too ?

[vietj]

it is weird because we are not using anymore MVEL and that is MVEL templating....

[vietj]

the problem is that you have code depending on old vertx versions:

[INFO] +- com.diabolicallabs:vertx-cron:jar:3.2.1.1:compile
[INFO] |  +- (io.vertx:vertx-core:jar:3.2.1:compile - omitted for conflict with 3.6.0)
[INFO] |  +- io.vertx:vertx-rx-java:jar:3.2.1:compile
[INFO] |  |  +- io.reactivex:rxjava:jar:1.0.14:compile
[INFO] |  |  \- (io.vertx:vertx-core:jar:3.2.1:compile - omitted for conflict with 3.6.0)
[INFO] |  +- io.vertx:vertx-unit:jar:3.2.1:compile
[INFO] |  |  \- (io.vertx:vertx-core:jar:3.2.1:compile - omitted for conflict with 3.6.0)
[INFO] |  +- (io.vertx:vertx-hazelcast:jar:3.2.1:compile - omitted for conflict with 3.6.0)
[INFO] |  +- junit:junit:jar:4.12:compile
[INFO] |  |  \- org.hamcrest:hamcrest-core:jar:1.3:compile
[INFO] |  \- org.quartz-scheduler:quartz:jar:2.2.2:compile
[INFO] |     +- c3p0:c3p0:jar:0.9.1.1:compile
[INFO] |     \- org.slf4j:slf4j-api:jar:1.7.7:compile

[vietj]

this load the vertx 3.2.1 generators which are executed

[vietj]

changing the dep to:

        <dependency>
            <groupId>com.diabolicallabs</groupId>
            <artifactId>vertx-cron</artifactId>
            <version>3.2.1.1</version>
            <exclusions>
                <exclusion>
                    <groupId>io.vertx</groupId>
                    <artifactId>vertx-core</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>io.vertx</groupId>
                    <artifactId>vertx-rx-java</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>io.vertx</groupId>
                    <artifactId>vertx-unit</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>io.vertx</groupId>
                    <artifactId>vertx-hazelcast</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

builds fine for me