Thanks Roy, really appreciated! I'll review your patch in the weekend.

@yDelouis the javadocs says we should define at least one converter, but the validator allows an empty array, it only invalidates in case of passing null. Which is the correct behavior, the javadoc or the current validation code?

@WonderCsabo, javadoc is not consistent with the code. In the code, we allow the user to set no converters. I think we should fix the code since rest requests won't work without converters.

Edit : This could be changed when the version 2.0 is released. (No converters -> we keep the default one, one or more converters, we clear default one and add specified ones).

@royclarkson if i may, can i ask you to change the validation code and the tests? After that, we could completely get rid of if (converters != null && !converters.isEmpty()), since the user must have at least one converter.

In Spring for Android 1.0, you could set an empty list of converters, but in 2.0 the setter now throws an IllegalArgumentException for an empty list. But the setter isn't being used in Android Annotations. Instead, the getter is used and the list is cleared before adding the converters from the annotation. To be consistent with 2.0, I agree with @yDelouis's comment:

Edit : This could be changed when the version 2.0 is released. (No converters -> we keep the default one, one or more converters, we clear default one and add specified ones).

However, while 1.0 is a dependency, I agree that at least one is required. I'll work on that change and send it your way. Thanks!

NOT ready to merge. The test in the latest push is failing. It feels like it should be working, but I'm unclear on the internals of the validation. I did manually verify using the functional test projects that it would generate a class with an empty set of converters before the validation change and would not after the change (class not found). Any thoughts or guidance?

It is not enough to invalidate, you should add an actual error, like this:

if (converters == null || converters.isEmpty()) {
    valid.invalidate();
    annotationHelper.printAnnotationError(element, "You must define at least one converter!");
    return;
}

Ah, I see. Thanks. I've pushed another change with that addition.

It seems there are other incompatibilities with 2.0. I just changed to 2.0.0.M1 and now the exchange method we are calling in the generated code is ambigous:

Failed tests: client_with_path_variables(org.androidannotations.rest.RestTest): Expected no errors, found androidannotations\AndroidAnnotations\androidannotations\target\generated-test\org\androidannotations\rest\ClientWithPathVariable_.java:36: error: reference to exchange is ambiguous, both method exchange(java.lang.String,org.springframework.http.HttpMethod,org.springframework.http.HttpEntity,java.lang.Class,java.util.Map) in org.springframework.web.client.RestTemplate and method exchange(java.lang.String,org.springframework.http.HttpMethod,org.springframework.http.HttpEntity<?>,org.springframework.core.ParameterizedTypeReference,java.util.Map<java.lang.String,? ) in org.springframework.web.client.RestTemplate match(..)

@royclarkson can you give us some feedback for my comments?

@royclarkson some feedback?

Yes, there are new exchange method signature to accommodate the use of ParameterizedTypeReference, which is the basis for the new generics support. I'll update my local copy and check out the specifics.

@WonderCsabo sorry for the delay here. I'm working on getting the next milestone release out soon and thought it best to wait to validate against that.

OK, thanks, just le us know if you need anything.

Not 100% sure how to append to someone else's PR, but this will get past the ambiguous case and my project compiles once again:

vincentjames501@97d24d6

I didn't add a test because the test will fail when we update the test dependency to 2.x (that is if we don't include my commit).

Great, thanks. I think @royclarkson will include this in the final PR if we go this way.

@royclarkson M2 is out. :)

Rebased, cleaned and merged as of commit 69be5fc. Thanks @royclarkson and @vincentjames501 for your contributions!