Hello Mike, thanks a lot for your detailed feedback. Sorry to hear you are unable to use it for the reasons you have mentioned and i will work on those to sort the issues out.
Regarding your concerns, please find my answer to them below.

For various reasons, we cannot upgrade to Spring 3.1, but for some reason, your SQS adapter uses a ConversionService implementation only available in 3.1. I don't know why your SQS adapter needs to handle any conversion at all. Isn't that the job of Message Transformers?
The messages sent to SQS can only contain string payload, where as, we cannot restrict the Spring integration message sent to the outbound adapter to have a payload of type String only. It can contain any type as long as the conversion service can convert the object to string and vice versa. This is where the conversion service comes into picture. In its absence, the user would have to convert the user provided object to a type string say using transformers as you suggested (which should also contain the original class type so that it can be converted back to the object ) and vice versa upon receiving the string message from the SQS queue. Also, when I developed this library, i had kept in mind spring integration version 2.1.x which makes use of conversion services as well.
I will however go though this thing again and rethink on it to eliminate the use of conversion services.

BTW, what version of spring and spring integration are you using ?

While the XML configuration offered by your XSD makes dropping in the functionality very simple, it does not allow for overriding various components. It would be great if I could just point it to a reference of my sqsClient, which might be a slightly different implementation rather than the default (add encryption, etc.). Also, you use a default Json message transformer, but don't have the configuration in place to use a different message transformer, or even customize the configuration of the Json transformer. We have some Jackson modules that are necessary to serialize/deserialize our data, but we can't add that in with the XSD configuration.
This shouldn't be too difficult to allow accepting an instance of sqs client and the transformer to use. There is an interface org.springframework.integration.aws.sqs.core.Amazo nSQSOperations which has methods to send, receive and delete messages from the SQS queue. Providing an implementation of this interface should override the default implementation that is used to send and receive messages.
Allowing to accept a user provided (de)serializer is possible as well which should override the default JSON one. We will be accepting an implementation of the interface org.springframework.integration.aws.sqs.core.Amazo nSQSMessageTransformer

The class org.springframework.integration.aws.sqs.core.Amazo nSQSMessage is a container for the various headers,payload and the original type of the payload received by the adapter. This instance needs to be serialized into a string value that is sent as the payload of the SQS queue and then deserialize it back to the AmazonSQSMessage instance.

I'm not sure why you need to use your own interface to describe the AwsCredentials. AwsCredentials is already an interface for which there are multiple implementations. We have one that retrieves our credentials from a secure store, but can't use it with your library because it doesn't implement your interface
The reason why AWS credentials are represented using the interface org.springframework.integration.aws.core.AmazonWSC redentials is because i didn't want any dependency for the end user on AWS SDK classes. For example, if we start allowing the user to provide an implementation of the AmazonSQSOperations, the implementation can very well be implemented using some propitiatory implementation of perhaps using the REST API but not using AWS SDK. In that case, just for the AWS credentials class we'll have to include the SDK classes. Can you give me some more details about the issue you are facing on this one. I am sure we can find some solution to it which may possibly need a new/custom implementation of the
org.springframework.integration.aws.core.AmazonWSC redentials


So to summarize,
I can address your concern 2, on providing me with some details your concern 3 can also be addressed ( i'm hoping to )
For the 1st concern, its a tough call. Eliminating the conversion service means effectively restricting the adapter to accept messages with string payload only. However, if that is the case, the adapter implementation gets simplified to a great extent eliminating the need of a conversion service and thus addressing your concern one. The problem is to decide a draw a line on what needs to be provided, or, is the responsibility of the end user and what needs to be handled by the adapter.

Can you perhaps briefly give your use case that can help provide a better adapter implementation?
Mark, Oleg, Gary, Gunnar
Can you throw some light on this and share your thoughts/views on it? I'll need you'll help for sorting the issue faced by using the conversion service