I am currently using the old tanuki version 3.2.3, and moving to the newest one 3.5.25.
I followed the upgrading documentation: modify my script, change the jar and binary wrapper… etc.
Debugging during the JVM launch, I could see that every additional param defined in my wrapper.conf appears as follows:
DEBUG | wrapper | 2014/07/03 13:41:08 | Command[0] : java
DEBUG | wrapper | 2014/07/03 13:41:08 | Command[1] : -Djava.system.class.loader=myClass
DEBUG | wrapper | 2014/07/03 13:41:08 | Command[2] : -Dcom.sun.management.jmxremote=true
But there are some extra params, and I don´t know where they are set up:
DEBUG | wrapper | 2014/07/03 13:41:08 | Command[30] : -Dwrapper.version=3.2.3
DEBUG | wrapper | 2014/07/03 13:41:08 | Command[31] : -Dwrapper.native_library=wrapper
DEBUG | wrapper | 2014/07/03 13:41:08 | Command[32] : -Dwrapper.service=TRUE
DEBUG | wrapper | 2014/07/03 13:41:08 | Command[33] : -Dwrapper.cpu.timeout=10
Specially annoying is the version one. It is still the old one. Does anybody know where I could change this configuration params?
Wrapper (Version 3.2.3) http://wrapper.tanukisoftware.org
Thanks!
Best
Tanuki library was imported by a dependency. Doesn´t matter the properties in my project, they will be overwritten.
The solution: using maven discard these dependencies or overwrite them.
Related
I just followed the tutorial, I am at the first
cargo build --release
This is the error I am getting, any idea why this would happen?
error[E0432]: unresolved import `sc_client_api::RemoteBackend`
--> node/src/service.rs:4:39
|
4 | use sc_client_api::{ExecutorProvider, RemoteBackend};
| ^^^^^^^^^^^^^
| |
| no `RemoteBackend` in the root
| help: a similar name exists in the module: `StateBackend`
I solved this by removing RemoteBackend from the import at node/src/service.rs.
Just change the line (for me it was Line 4) at node/src/service.rs from
use sc_client_api::{ExecutorProvider, RemoteBackend};
to
use sc_client_api::ExecutorProvider;
While working with the tutorial cargo build --release resulted in the following error message:
error[E0432]: unresolved import `sc_client_api::RemoteBackend`
--> node/src/service.rs:4:39
|
4 | use sc_client_api::{ExecutorProvider, RemoteBackend};
| ^^^^^^^^^^^^^
| |
| no `RemoteBackend` in the root
| help: a similar name exists in the module: `StateBackend`
The help message provided some clue as to what was happening. Checking the node/src/service.rs file, I found that RemoteBackend was never referenced anywhere else in the file. So I simply removed it from the imports, and the build process was completed successfully.
I am working on the Solana contract with rust language.
When I execute cargo build, it returns ok result.
But when I execute cargo +bpf build --target bpfel-unknown-unknown --release, it returns below the error console.
error[E0432]: unresolved import `crate::sys`
--> /home/ubuntu/.cargo/registry/src/github.com-1ecc6299db9ec823/socket2-0.4.2/src/sockaddr.rs:5:12
|
5 | use crate::sys::{
| ^^^
| |
| unresolved import
| help: a similar path exists: `crate::socket::io::sys`
error[E0432]: unresolved imports `crate::sys`, `crate::sys`
--> /home/ubuntu/.cargo/registry/src/github.com-1ecc6299db9ec823/socket2-0.4.2/src/socket.rs:21:12
|
21 | use crate::sys::{self, c_int, getsockopt, setsockopt, Bool};
| ^^^ ^^^^ no `sys` in the root
| |
| unresolved import
| help: a similar path exists: `crate::socket::io::sys`
...
Please let me know if you faced this kinda issue before.
On-chain programs are limited in what resources they can access. For example, you can't access the internet or filesystem. Your program seems to be relying on some of these forbidden packages.
Here's more info from the documentation about using rand, which is also not allowed: https://docs.solana.com/developing/on-chain-programs/developing-rust#depending-on-rand
Context:
Problem found while upgrading from Nodejs 6 to 12 and with that the project's dependencies.
Using dynamoose 2.3
Containerized application using docker-compose: backend and dynamodb instance only
Docker file for dynamodb:
FROM openjdk:latest
\# Bundle dynamodb
COPY . .
EXPOSE 8000
CMD [ "java", "-jar", "DynamoDBLocal.jar" ]
Problem: when lifting up the containers, after the backend initializes the dynamodb instance throws the errors below, causing any subsequent query or call to stall and return on timeout on the backend's side.
Error:
dynamodb_1 | Sep 03, 2020 8:14:36 AM com.almworks.sqlite4java.Internal log
dynamodb_1 | WARNING: [sqlite] SQLiteDBAccess$10#b6f156c: job exception
dynamodb_1 | com.almworks.sqlite4java.SQLiteException: [1] DB[1] prepare() DROP INDEX Foobar*HVI; [near "*": syntax error]
dynamodb_1 | at com.almworks.sqlite4java.SQLiteConnection.throwResult(SQLiteConnection.java:1436)
dynamodb_1 | at com.almworks.sqlite4java.SQLiteConnection.prepare(SQLiteConnection.java:580)
dynamodb_1 | at com.almworks.sqlite4java.SQLiteConnection.prepare(SQLiteConnection.java:635)
dynamodb_1 | at com.almworks.sqlite4java.SQLiteConnection.prepare(SQLiteConnection.java:622)
dynamodb_1 | at com.amazonaws.services.dynamodbv2.local.shared.access.sqlite.AmazonDynamoDBOfflineSQLiteJob.getPreparedStatement(AmazonDynamoDBOfflineSQLiteJob.java:138)
dynamodb_1 | at com.amazonaws.services.dynamodbv2.local.shared.access.sqlite.SQLiteDBAccess$10.dropGSISQLiteIndex(SQLiteDBAccess.java:1221)
dynamodb_1 | at com.amazonaws.services.dynamodbv2.local.shared.access.sqlite.SQLiteDBAccess$10.dropIndices(SQLiteDBAccess.java:1169)
dynamodb_1 | at com.amazonaws.services.dynamodbv2.local.shared.access.sqlite.SQLiteDBAccess$10.doWork(SQLiteDBAccess.java:1155)
dynamodb_1 | at com.amazonaws.services.dynamodbv2.local.shared.access.sqlite.SQLiteDBAccess$10.doWork(SQLiteDBAccess.java:1152)
dynamodb_1 | at com.amazonaws.services.dynamodbv2.local.shared.access.sqlite.AmazonDynamoDBOfflineSQLiteJob.job(AmazonDynamoDBOfflineSQLiteJob.java:97)
dynamodb_1 | at com.almworks.sqlite4java.SQLiteJob.execute(SQLiteJob.java:372)
dynamodb_1 | at com.almworks.sqlite4java.SQLiteQueue.executeJob(SQLiteQueue.java:534)
dynamodb_1 | at com.almworks.sqlite4java.SQLiteQueue.queueFunction(SQLiteQueue.java:667)
dynamodb_1 | at com.almworks.sqlite4java.SQLiteQueue.runQueue(SQLiteQueue.java:623)
dynamodb_1 | at com.almworks.sqlite4java.SQLiteQueue.access$000(SQLiteQueue.java:77)
dynamodb_1 | at com.almworks.sqlite4java.SQLiteQueue$1.run(SQLiteQueue.java:205)
dynamodb_1 | at java.base/java.lang.Thread.run(Thread.java:832)
I suspect this is happening when creating the tables through Dynamoose's model() which under the hood calls aws' DynamoDB createTable method.
I'm currently just analysing the upgrade to nodejs 12 and dynamoose 2.3. In local I would prefer to have it run to test other parts of the project, so I don't mind updating indexes and recreating tables, but wish to know where this syntax error is coming from to fix it and carry on.
Question: Is it possible that the aws-sdk or dynamoose cause a DynamoDB local instance to attempt to drop an index with an SQLite syntax error?
The problem is that Dynamoose 0.8.7 used to support Schemas with attributes that were both hashkey and had an index marked as global. When jumping to the latest version, some breaking changes made it add characters like '*' to their queries and thus making SQLite complain.
Example:
const FoobarSchema = new dynamoose.Schema({
foo: {
type: String,
hashkey: true,
index: {
global:true
}
}
});
const Foobar = dynamoose.model('Foobar', FoobarSchema, Options); // Blow up
I'm new to the project and DynamoDb. I don't understand what was the reasoning behind having those two conditions together and whether it should be supported or not. I'll dig deeper into this when I have the chance and update this.
Deleting the "shared-local-instance.db" file in my "docker/dynamodb" folder resolved the issue for me (the file is generated again on docker-compose up and everything runs fine)
I am using guice architecture upon developing my spark strreaming program. It can run in my eclipse without any error. However, after compiling and deployed with spark-submit command, it returns an error:
java.lang.NoClassDefFoundError: com/google/common/base/Preconditions
After googling through, I noticed that this error only appears if we are using guice 3.0. But I am using guice 4.0. My spark version is 1.5.2, and my cloudera version is 5.3.2. Is there any work around on this error?
Unfortunately for you, Spark v1.5.2 depends on com.google.inject:guice:3.0.
So I suspect that what is happening is that that your project is pulling both:
Guice 4.0 (as a direct dependency stated in your dependencies file like pom.xml or build.sbt); and
Guice 3.0 (a transitive dependency pulled by Spark v1.5.2)
Basically your classpath ends up being a mess, and depending on the way classes are loaded by the classloader at runtime you will (or will not) experience such kind of errors.
You will have to use the already provided version of Guice (pulled by Spark) or start juggling with classloaders.
UPDATE:
Indeed the org.apache.spark:spark-core_2.10:1.5.2 pulls com.google.inject:guice:3.0 :
+-org.apache.spark:spark-core_2.10:1.5.2 [S]
+ ...
...
+-org.apache.hadoop:hadoop-client:2.2.0
| +-org.apache.hadoop:hadoop-mapreduce-client-app:2.2.0
| | +-com.google.protobuf:protobuf-java:2.5.0
| | +-org.apache.hadoop:hadoop-mapreduce-client-common:2.2.0
| | | +-com.google.protobuf:protobuf-java:2.5.0
| | | +-org.apache.hadoop:hadoop-mapreduce-client-core:2.2.0
| | | | +-com.google.protobuf:protobuf-java:2.5.0
| | | | +-org.apache.hadoop:hadoop-yarn-common:2.2.0 (VIA PARENT org.apache.hadoop:hadoop-yarn:2.2.0 and then VIA ITS PARENT org.apache.hadoop:hadoop-project:2.2.0)
| | | | | +-com.google.inject:guice:3.0
...
The spark-core pom.xml is here.
The hadoop-yarn-common pom.xml is here.
The hadoop-yarn pom.xml is here.
The hadoop-project pom.xml is here.
On Android Studio 0.8.2, I am trying to create an app that integrates with Twitter using Spring. Had innumerable build problems until I created a blank activity that I'm just using the test my Gradle build.
Every time I try to connect to spring-social-twitter, the build fails. If I comment out the Twitter dependency, the app compiles. I'm pretty sure this has nothing to do with the app itself, because I'm testing it on a blank app.
What am I doing wrong?
My build.gradle file:
apply plugin: 'com.android.application'
android {
compileSdkVersion 20
buildToolsVersion "20.0.0"
defaultConfig {
applicationId "com.example.testapplication"
minSdkVersion 8
targetSdkVersion 20
versionCode 1
versionName "1.0"
}
buildTypes {
release {
runProguard false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
packagingOptions {
exclude 'META-INF/ASL2.0'
exclude 'META-INF/LICENSE'
exclude 'META-INF/license.txt'
exclude 'META-INF/NOTICE'
exclude 'META-INF/notice.txt'
}
}
configurations.compile {
exclude module: 'spring-core'
exclude module: 'spring-web'
exclude module: 'commons-logging'
}
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
compile 'com.android.support:appcompat-v7:20.+'
compile 'org.springframework.android:spring-android-rest-template:1.+'
compile 'org.springframework.android:spring-android-auth:1.+'
compile 'org.springframework.android:spring-android-core:1.+'
compile 'org.springframework.security:spring-security-crypto:3.+'
compile 'org.springframework.social:spring-social-core:1.+'
compile 'org.springframework.social:spring-social-twitter:1.+' // <- The offending line
compile 'com.fasterxml.jackson.core:jackson-databind:2.3.2'
}
The error:
Error:Execution failed for task ':app:dexDebug'.
> com.android.ide.common.internal.LoggedErrorException: Failed to run command:
C:\Android\android-studio\sdk\build-tools\android-4.4W\dx.bat --dex --num-threads=4 --output C:\Workspace\TestApplication\app\build\intermediates\dex\debug C:\Workspace\TestApplication\app\build\intermediates\classes\debug C:\Workspace\TestApplication\app\build\intermediates\dependency-cache\debug C:\Workspace\TestApplication\app\build\intermediates\pre-dexed\debug\aopalliance-1.0-b64c80122d373c2ee241b55db78eac4c4c550a82.jar C:\Workspace\TestApplication\app\build\intermediates\pre-dexed\debug\classes-528f16ed29eae5d85d8c6f1ee7d32d83803e6e6d.jar C:\Workspace\TestApplication\app\build\intermediates\pre-dexed\debug\classes-fa1cd323aa3b243f3f4157cb5e43b3768ee49e9b.jar C:\Workspace\TestApplication\app\build\intermediates\pre-dexed\debug\internal_impl-20.0.0-d4c263ffd0c244f7b9af8079e5d62faa86242454.jar C:\Workspace\TestApplication\app\build\intermediates\pre-dexed\debug\jackson-annotations-2.3.0-c8c500c4e2e271888f48319f1d0f4ee141245e21.jar C:\Workspace\TestApplication\app\build\intermediates\pre-dexed\debug\jackson-core-2.3.2-5a10979c76ddf0300365195ed3dcdf3bbf65dba0.jar C:\Workspace\TestApplication\app\build\intermediates\pre-dexed\debug\jackson-databind-2.3.2-a027503e6b72a7b1487e8e935334766d26725e1b.jar C:\Workspace\TestApplication\app\build\intermediates\pre-dexed\debug\javax.inject-1-e86c6ad046940b581fcf8f69e7965f8f5d1cfaf6.jar C:\Workspace\TestApplication\app\build\intermediates\pre-dexed\debug\spring-android-auth-1.0.1.RELEASE-d09921850d19080abfdeefe1fde904485c1b37c8.jar C:\Workspace\TestApplication\app\build\intermediates\pre-dexed\debug\spring-android-core-1.0.1.RELEASE-d006eb074ec6bcaf01f1fcb65dcc840f72c538d1.jar C:\Workspace\TestApplication\app\build\intermediates\pre-dexed\debug\spring-android-rest-template-1.0.1.RELEASE-f254c94632ca185a2fee85575fea1e4e9e68766f.jar C:\Workspace\TestApplication\app\build\intermediates\pre-dexed\debug\spring-aop-4.0.2.RELEASE-87af05a1d636417a8a1c074a0d93dbc6c5902550.jar C:\Workspace\TestApplication\app\build\intermediates\pre-dexed\debug\spring-beans-4.0.2.RELEASE-5afb5560550de06352f4871e0c5351c296555245.jar C:\Workspace\TestApplication\app\build\intermediates\pre-dexed\debug\spring-context-4.0.2.RELEASE-ae3ec0e430000b49e6dabc34fb702e4db3ab96ad.jar C:\Workspace\TestApplication\app\build\intermediates\pre-dexed\debug\spring-expression-4.0.2.RELEASE-1cfe445710559e2affa6317c573db04b9638c918.jar C:\Workspace\TestApplication\app\build\intermediates\pre-dexed\debug\spring-security-crypto-3.2.4.RELEASE-e5c641be2ba64d1b5bda6b6e9778a6043726fc96.jar C:\Workspace\TestApplication\app\build\intermediates\pre-dexed\debug\spring-social-config-1.1.0.RC1-0646da07e81cc32f0ff7a641a47b589c6ee71ed6.jar C:\Workspace\TestApplication\app\build\intermediates\pre-dexed\debug\spring-social-core-1.1.0.RC1-f762fce97f3b62664de8e04d427fea101bc74da1.jar C:\Workspace\TestApplication\app\build\intermediates\pre-dexed\debug\spring-social-twitter-1.1.0.RC1-66dcadc997a346a9caac49e5e66d0d6d60d6e684.jar C:\Workspace\TestApplication\app\build\intermediates\pre-dexed\debug\spring-social-web-1.1.0.RC1-753970492ed13f57671662ceb587dd9aa4f2c882.jar C:\Workspace\TestApplication\app\build\intermediates\pre-dexed\debug\spring-webmvc-4.0.2.RELEASE-a6c8053426ad57c5e0b1eb2de9405ef3c0e118b1.jar C:\Workspace\TestApplication\app\build\intermediates\pre-dexed\debug\support-annotations-20.0.0-bab26a85db10fdf51a5bd499a182514bd4080ed4.jar
Error Code:
2
Output:
UNEXPECTED TOP-LEVEL EXCEPTION:
com.android.dex.DexException: Multiple dex files define Lorg/springframework/beans/BeansException;
at com.android.dx.merge.DexMerger.readSortableTypes(DexMerger.java:594)
at com.android.dx.merge.DexMerger.getSortedTypes(DexMerger.java:552)
at com.android.dx.merge.DexMerger.mergeClassDefs(DexMerger.java:533)
at com.android.dx.merge.DexMerger.mergeDexes(DexMerger.java:170)
at com.android.dx.merge.DexMerger.merge(DexMerger.java:188)
at com.android.dx.command.dexer.Main.mergeLibraryDexBuffers(Main.java:439)
at com.android.dx.command.dexer.Main.runMonoDex(Main.java:287)
at com.android.dx.command.dexer.Main.run(Main.java:230)
at com.android.dx.command.dexer.Main.main(Main.java:199)
at com.android.dx.command.Main.main(Main.java:103)
I can get you farther along, but you may get stuck at the next problem.
If I load up your build file (and reproduce your build error), when I go into the IDE and ask it to take me to the BeansException class, I get this:
You can see that BeansException is defined in two different places, which isn't allowed in Android builds, thus the error you're seeing. You need to set up your build such that each class is defined in one place.
Doing a little more sleuthing, you can use this command to see your dependency tree. From your application's module directory, run this command:
../gradlew dependencies
The relevant part of the output is here:
_debugApk - ## Internal use, do not manually configure ##
+--- com.android.support:appcompat-v7:20.+ -> 20.0.0
| \--- com.android.support:support-v4:20.0.0
| \--- com.android.support:support-annotations:20.0.0
+--- org.springframework.android:spring-android-rest-template:1.+ -> 1.0.1.RELEASE
| \--- org.springframework.android:spring-android-core:1.0.1.RELEASE
+--- org.springframework.android:spring-android-auth:1.+ -> 1.0.1.RELEASE
| +--- org.springframework.android:spring-android-core:1.0.1.RELEASE
| +--- org.springframework.android:spring-android-rest-template:1.0.1.RELEASE (*)
| +--- org.springframework.security:spring-security-crypto:3.1.3.RELEASE -> 3.2.4.RELEASE
| \--- org.springframework.social:spring-social-core:1.0.2.RELEASE -> 1.1.0.RC1
+--- org.springframework.android:spring-android-core:1.+ -> 1.0.1.RELEASE
+--- org.springframework.security:spring-security-crypto:3.+ -> 3.2.4.RELEASE
+--- org.springframework.social:spring-social-core:1.+ -> 1.1.0.RC1
+--- org.springframework.social:spring-social-twitter:1.+ -> 1.1.0.RC1
| +--- com.fasterxml.jackson.core:jackson-databind:2.3.0 -> 2.3.2
| | +--- com.fasterxml.jackson.core:jackson-annotations:2.3.0
| | \--- com.fasterxml.jackson.core:jackson-core:2.3.2
| +--- org.springframework.security:spring-security-crypto:3.2.0.RELEASE -> 3.2.4.RELEASE
| +--- org.springframework.social:spring-social-core:1.1.0.RC1
| +--- org.springframework.social:spring-social-config:1.1.0.RC1
| | +--- org.springframework.social:spring-social-web:1.1.0.RC1
| | | +--- javax.inject:javax.inject:1
| | | +--- org.springframework:spring-webmvc:4.0.2.RELEASE
| | | | +--- org.springframework:spring-beans:4.0.2.RELEASE
| | | | +--- org.springframework:spring-context:4.0.2.RELEASE
| | | | | +--- org.springframework:spring-aop:4.0.2.RELEASE
| | | | | | +--- aopalliance:aopalliance:1.0
| | | | | | \--- org.springframework:spring-beans:4.0.2.RELEASE
| | | | | +--- org.springframework:spring-beans:4.0.2.RELEASE
| | | | | \--- org.springframework:spring-expression:4.0.2.RELEASE
| | | | \--- org.springframework:spring-expression:4.0.2.RELEASE
| | | \--- org.springframework.social:spring-social-core:1.1.0.RC1
| | \--- org.springframework.social:spring-social-core:1.1.0.RC1
| +--- com.fasterxml.jackson.core:jackson-core:2.3.0 -> 2.3.2
| \--- com.fasterxml.jackson.core:jackson-annotations:2.3.0
\--- com.fasterxml.jackson.core:jackson-databind:2.3.2 (*)
From this we can see that org.springframework.social:spring-social-twitter:1.+ eventually includes org.springframework:spring-beans:4.0.2.RELEASE through its transitive dependencies (which you found out because you isolated this as the line causing your build problem), but that means if it's already being bundled into the spring-android-core jar, it's redundant. I don't see another dependency on spring-beans from spring-android-core; perhaps that class is just packaged into the jar and isn't even a dependency.
At any rate, you can use this syntax in your dependencies to tell Gradle to not pick up a transitive dependency:
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
compile 'com.android.support:appcompat-v7:20.+'
compile 'org.springframework.android:spring-android-rest-template:1.+'
compile 'org.springframework.android:spring-android-auth:1.+'
compile 'org.springframework.android:spring-android-core:1.+'
compile 'org.springframework.security:spring-security-crypto:3.+'
compile 'org.springframework.social:spring-social-core:1.+'
compile('org.springframework.social:spring-social-twitter:1.+') {
exclude module: 'spring-beans'
}
compile 'com.fasterxml.jackson.core:jackson-databind:2.3.2'
}
If I do this, then no more dex multiple-files-define-a-class error. However, I now get this similar but different duplicate-files error, which I can muse about a bit but I'm not sure if I could fix it without writing a test app that instantiates Spring, which is beyond the scope of what I'll do in a SO answer ;)
:app:packageDebug
Error: duplicate files during packaging of APK /Users/sbarta/AndroidStudioProjects/MyApplication/app/build/outputs/apk/app-debug-unaligned.apk
Path in archive: META-INF/spring.schemas
Origin 1: /Users/sbarta/.gradle/caches/modules-2/files-2.1/org.springframework.social/spring-social-config/1.1.0.RC1/7afae4a4f83c64c4fd382c77708866e82900e799/spring-social-config-1.1.0.RC1.jar
Origin 2: /Users/sbarta/.gradle/caches/modules-2/files-2.1/org.springframework/spring-context/4.0.2.RELEASE/6d6a781d99215990da8b398e1cdf09594a683209/spring-context-4.0.2.RELEASE.jar
You can ignore those files in your build.gradle:
android {
packagingOptions {
exclude 'META-INF/spring.schemas'
}
}
:app:packageDebug FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':app:packageDebug'.
> Duplicate files copied in APK META-INF/spring.schemas
File 1: /Users/sbarta/.gradle/caches/modules-2/files-2.1/org.springframework.social/spring-social-config/1.1.0.RC1/7afae4a4f83c64c4fd382c77708866e82900e799/spring-social-config-1.1.0.RC1.jar
File 2: /Users/sbarta/.gradle/caches/modules-2/files-2.1/org.springframework.social/spring-social-config/1.1.0.RC1/7afae4a4f83c64c4fd382c77708866e82900e799/spring-social-config-1.1.0.RC1.jar
What this means is that there are two META-INF/spring.schemas files being included from two different places, which is also not permitted. However, you don't have the flexibility here of telling dex to ignore just one of them; you can tell it to ignore all of them via:
android {
packagingOptions {
exclude 'META-INF/spring.schemas'
}
}
in your build file. I have a feeling that Spring needs that schemas file (which one, though???), so if you do this, your app may still not work. Experiment and thrash around with it, and if you're still having problems, though, you can post another question and maybe get more specialized help.
I'm not sure what the root of this problem is. Is it a packaging error in the Spring libraries that there are multiple schema files? Or are you expected to resolve this? Or do other build systems just Do The Right Thing? I'm not sure.
Okay, this is far from what one would call a satisfactory solution, but the thing compiles, so I'm "pleased".
Whatever the root of the problem is, it seems to be specific to spring-social-twitter version 1.1.0. I changed the build.gradle line to read:
compile 'org.springframework.social:spring-social-twitter:1.0.5.RELEASE'
rather than the ...spring-social-twitter:1.+' I had before and it now compiles fine. Haven't tested the working aspects yet, but that will be a set of altogether different questions.
The method for finding this was, I assure you, no less ridiculous than the actual "solution".