Exclude temporary Realm files from Gradle build
Realm provides a database viewer called "Realm Studio" that allows users to browse the contents of their database. When the application is used to view a database, it creates several "temporary" files in the directory of the database, namely:
- A
.realm.lock
file. - A
.realm.note
file. - A
.realm.management
directory containing:
- A
access_control.control.mx
file. - A
access_control.new_commit.cv
file. - A
access_control.pick_writer.cv
file. - A
access_control.write.mx
file.
- A
In the context of Android, a preexisting Realm database is sometimes shipped with an application by placing the database in the /assets
directory. Thus, when the Realm Studio is used to view this database, the aforementioned files are generated in /assets
. For unknown reasons, this causes Gradle to hang indefinitely after the :app:generateDebugAssets
task, apparently at the :app:mergeDebugAssets
task.
As such, i'd like to find a way to exclude these files from the build. I've tried several methods, such as:
applicationVariants.all { variant ->
if (variant.buildType.name == 'debug') {
variant.mergeAssets.doLast {
delete(fileTree(dir: variant.mergeAssets.outputDir, includes: ['**/*.cv', '**/*.mx', '**/*.lock', '**/*.note']))
}
}
}
and other methods, like:
sourceSets.main.assets.exclude 'appData.realm.management'
sourceSets.main.assets.exclude 'appData.realm.management/access_control.control.mx'
sourceSets.main.assets.exclude 'appData.realm.management/access_control.new_commit.cv'
sourceSets.main.assets.exclude 'appData.realm.management/access_control.pick_writer.cv'
sourceSets.main.assets.exclude 'appData.realm.management/access_control.write.mx'
sourceSets.main.assets.exclude 'appData.realm.lock'
sourceSets.main.assets.exclude 'appData.realm.note'
to no avail.
How can one instruct Gradle to exclude these files when running a build?
EDIT: Small snippet of repeated output from ./gradlew -d app:mergeDebugAssets
:
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
[org.gradle.process.internal.health.memory.MemoryManager] Emitting OS memory status event {Total: 8589934592, Free: 2572066816}
[org.gradle.launcher.daemon.server.health.LowMemoryDaemonExpirationStrategy] Received memory status update: {Total: 8589934592, Free: 2572066816}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 1431830528, Committed: 308281344}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting OS memory status event {Total: 8589934592, Free: 2567909376}
[org.gradle.launcher.daemon.server.health.LowMemoryDaemonExpirationStrategy] Received memory status update: {Total: 8589934592, Free: 2567909376}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 1431830528, Committed: 308281344}
[org.gradle.launcher.daemon.server.Daemon] DaemonExpirationPeriodicCheck running
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
[org.gradle.process.internal.health.memory.MemoryManager] Emitting OS memory status event {Total: 8589934592, Free: 2564087808}
[org.gradle.launcher.daemon.server.health.LowMemoryDaemonExpirationStrategy] Received memory status update: {Total: 8589934592, Free: 2564087808}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 1431830528, Committed: 308281344}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting OS memory status event {Total: 8589934592, Free: 2560860160}
[org.gradle.launcher.daemon.server.health.LowMemoryDaemonExpirationStrategy] Received memory status update: {Total: 8589934592, Free: 2560860160}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 1431830528, Committed: 308281344}
[org.gradle.launcher.daemon.server.Daemon] DaemonExpirationPeriodicCheck running
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
...
android gradle android-gradle realm build.gradle
add a comment |
Realm provides a database viewer called "Realm Studio" that allows users to browse the contents of their database. When the application is used to view a database, it creates several "temporary" files in the directory of the database, namely:
- A
.realm.lock
file. - A
.realm.note
file. - A
.realm.management
directory containing:
- A
access_control.control.mx
file. - A
access_control.new_commit.cv
file. - A
access_control.pick_writer.cv
file. - A
access_control.write.mx
file.
- A
In the context of Android, a preexisting Realm database is sometimes shipped with an application by placing the database in the /assets
directory. Thus, when the Realm Studio is used to view this database, the aforementioned files are generated in /assets
. For unknown reasons, this causes Gradle to hang indefinitely after the :app:generateDebugAssets
task, apparently at the :app:mergeDebugAssets
task.
As such, i'd like to find a way to exclude these files from the build. I've tried several methods, such as:
applicationVariants.all { variant ->
if (variant.buildType.name == 'debug') {
variant.mergeAssets.doLast {
delete(fileTree(dir: variant.mergeAssets.outputDir, includes: ['**/*.cv', '**/*.mx', '**/*.lock', '**/*.note']))
}
}
}
and other methods, like:
sourceSets.main.assets.exclude 'appData.realm.management'
sourceSets.main.assets.exclude 'appData.realm.management/access_control.control.mx'
sourceSets.main.assets.exclude 'appData.realm.management/access_control.new_commit.cv'
sourceSets.main.assets.exclude 'appData.realm.management/access_control.pick_writer.cv'
sourceSets.main.assets.exclude 'appData.realm.management/access_control.write.mx'
sourceSets.main.assets.exclude 'appData.realm.lock'
sourceSets.main.assets.exclude 'appData.realm.note'
to no avail.
How can one instruct Gradle to exclude these files when running a build?
EDIT: Small snippet of repeated output from ./gradlew -d app:mergeDebugAssets
:
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
[org.gradle.process.internal.health.memory.MemoryManager] Emitting OS memory status event {Total: 8589934592, Free: 2572066816}
[org.gradle.launcher.daemon.server.health.LowMemoryDaemonExpirationStrategy] Received memory status update: {Total: 8589934592, Free: 2572066816}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 1431830528, Committed: 308281344}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting OS memory status event {Total: 8589934592, Free: 2567909376}
[org.gradle.launcher.daemon.server.health.LowMemoryDaemonExpirationStrategy] Received memory status update: {Total: 8589934592, Free: 2567909376}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 1431830528, Committed: 308281344}
[org.gradle.launcher.daemon.server.Daemon] DaemonExpirationPeriodicCheck running
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
[org.gradle.process.internal.health.memory.MemoryManager] Emitting OS memory status event {Total: 8589934592, Free: 2564087808}
[org.gradle.launcher.daemon.server.health.LowMemoryDaemonExpirationStrategy] Received memory status update: {Total: 8589934592, Free: 2564087808}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 1431830528, Committed: 308281344}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting OS memory status event {Total: 8589934592, Free: 2560860160}
[org.gradle.launcher.daemon.server.health.LowMemoryDaemonExpirationStrategy] Received memory status update: {Total: 8589934592, Free: 2560860160}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 1431830528, Committed: 308281344}
[org.gradle.launcher.daemon.server.Daemon] DaemonExpirationPeriodicCheck running
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
...
android gradle android-gradle realm build.gradle
None of the above solution works ? Any error message ?
– ToYonos
Dec 5 '18 at 10:01
add a comment |
Realm provides a database viewer called "Realm Studio" that allows users to browse the contents of their database. When the application is used to view a database, it creates several "temporary" files in the directory of the database, namely:
- A
.realm.lock
file. - A
.realm.note
file. - A
.realm.management
directory containing:
- A
access_control.control.mx
file. - A
access_control.new_commit.cv
file. - A
access_control.pick_writer.cv
file. - A
access_control.write.mx
file.
- A
In the context of Android, a preexisting Realm database is sometimes shipped with an application by placing the database in the /assets
directory. Thus, when the Realm Studio is used to view this database, the aforementioned files are generated in /assets
. For unknown reasons, this causes Gradle to hang indefinitely after the :app:generateDebugAssets
task, apparently at the :app:mergeDebugAssets
task.
As such, i'd like to find a way to exclude these files from the build. I've tried several methods, such as:
applicationVariants.all { variant ->
if (variant.buildType.name == 'debug') {
variant.mergeAssets.doLast {
delete(fileTree(dir: variant.mergeAssets.outputDir, includes: ['**/*.cv', '**/*.mx', '**/*.lock', '**/*.note']))
}
}
}
and other methods, like:
sourceSets.main.assets.exclude 'appData.realm.management'
sourceSets.main.assets.exclude 'appData.realm.management/access_control.control.mx'
sourceSets.main.assets.exclude 'appData.realm.management/access_control.new_commit.cv'
sourceSets.main.assets.exclude 'appData.realm.management/access_control.pick_writer.cv'
sourceSets.main.assets.exclude 'appData.realm.management/access_control.write.mx'
sourceSets.main.assets.exclude 'appData.realm.lock'
sourceSets.main.assets.exclude 'appData.realm.note'
to no avail.
How can one instruct Gradle to exclude these files when running a build?
EDIT: Small snippet of repeated output from ./gradlew -d app:mergeDebugAssets
:
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
[org.gradle.process.internal.health.memory.MemoryManager] Emitting OS memory status event {Total: 8589934592, Free: 2572066816}
[org.gradle.launcher.daemon.server.health.LowMemoryDaemonExpirationStrategy] Received memory status update: {Total: 8589934592, Free: 2572066816}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 1431830528, Committed: 308281344}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting OS memory status event {Total: 8589934592, Free: 2567909376}
[org.gradle.launcher.daemon.server.health.LowMemoryDaemonExpirationStrategy] Received memory status update: {Total: 8589934592, Free: 2567909376}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 1431830528, Committed: 308281344}
[org.gradle.launcher.daemon.server.Daemon] DaemonExpirationPeriodicCheck running
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
[org.gradle.process.internal.health.memory.MemoryManager] Emitting OS memory status event {Total: 8589934592, Free: 2564087808}
[org.gradle.launcher.daemon.server.health.LowMemoryDaemonExpirationStrategy] Received memory status update: {Total: 8589934592, Free: 2564087808}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 1431830528, Committed: 308281344}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting OS memory status event {Total: 8589934592, Free: 2560860160}
[org.gradle.launcher.daemon.server.health.LowMemoryDaemonExpirationStrategy] Received memory status update: {Total: 8589934592, Free: 2560860160}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 1431830528, Committed: 308281344}
[org.gradle.launcher.daemon.server.Daemon] DaemonExpirationPeriodicCheck running
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
...
android gradle android-gradle realm build.gradle
Realm provides a database viewer called "Realm Studio" that allows users to browse the contents of their database. When the application is used to view a database, it creates several "temporary" files in the directory of the database, namely:
- A
.realm.lock
file. - A
.realm.note
file. - A
.realm.management
directory containing:
- A
access_control.control.mx
file. - A
access_control.new_commit.cv
file. - A
access_control.pick_writer.cv
file. - A
access_control.write.mx
file.
- A
In the context of Android, a preexisting Realm database is sometimes shipped with an application by placing the database in the /assets
directory. Thus, when the Realm Studio is used to view this database, the aforementioned files are generated in /assets
. For unknown reasons, this causes Gradle to hang indefinitely after the :app:generateDebugAssets
task, apparently at the :app:mergeDebugAssets
task.
As such, i'd like to find a way to exclude these files from the build. I've tried several methods, such as:
applicationVariants.all { variant ->
if (variant.buildType.name == 'debug') {
variant.mergeAssets.doLast {
delete(fileTree(dir: variant.mergeAssets.outputDir, includes: ['**/*.cv', '**/*.mx', '**/*.lock', '**/*.note']))
}
}
}
and other methods, like:
sourceSets.main.assets.exclude 'appData.realm.management'
sourceSets.main.assets.exclude 'appData.realm.management/access_control.control.mx'
sourceSets.main.assets.exclude 'appData.realm.management/access_control.new_commit.cv'
sourceSets.main.assets.exclude 'appData.realm.management/access_control.pick_writer.cv'
sourceSets.main.assets.exclude 'appData.realm.management/access_control.write.mx'
sourceSets.main.assets.exclude 'appData.realm.lock'
sourceSets.main.assets.exclude 'appData.realm.note'
to no avail.
How can one instruct Gradle to exclude these files when running a build?
EDIT: Small snippet of repeated output from ./gradlew -d app:mergeDebugAssets
:
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
[org.gradle.process.internal.health.memory.MemoryManager] Emitting OS memory status event {Total: 8589934592, Free: 2572066816}
[org.gradle.launcher.daemon.server.health.LowMemoryDaemonExpirationStrategy] Received memory status update: {Total: 8589934592, Free: 2572066816}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 1431830528, Committed: 308281344}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting OS memory status event {Total: 8589934592, Free: 2567909376}
[org.gradle.launcher.daemon.server.health.LowMemoryDaemonExpirationStrategy] Received memory status update: {Total: 8589934592, Free: 2567909376}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 1431830528, Committed: 308281344}
[org.gradle.launcher.daemon.server.Daemon] DaemonExpirationPeriodicCheck running
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
[org.gradle.process.internal.health.memory.MemoryManager] Emitting OS memory status event {Total: 8589934592, Free: 2564087808}
[org.gradle.launcher.daemon.server.health.LowMemoryDaemonExpirationStrategy] Received memory status update: {Total: 8589934592, Free: 2564087808}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 1431830528, Committed: 308281344}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting OS memory status event {Total: 8589934592, Free: 2560860160}
[org.gradle.launcher.daemon.server.health.LowMemoryDaemonExpirationStrategy] Received memory status update: {Total: 8589934592, Free: 2560860160}
[org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 1431830528, Committed: 308281344}
[org.gradle.launcher.daemon.server.Daemon] DaemonExpirationPeriodicCheck running
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
...
android gradle android-gradle realm build.gradle
android gradle android-gradle realm build.gradle
edited Dec 17 '18 at 22:52
Orbit
asked Nov 27 '18 at 0:02
OrbitOrbit
67832562
67832562
None of the above solution works ? Any error message ?
– ToYonos
Dec 5 '18 at 10:01
add a comment |
None of the above solution works ? Any error message ?
– ToYonos
Dec 5 '18 at 10:01
None of the above solution works ? Any error message ?
– ToYonos
Dec 5 '18 at 10:01
None of the above solution works ? Any error message ?
– ToYonos
Dec 5 '18 at 10:01
add a comment |
3 Answers
3
active
oldest
votes
I think the problem is that you did not delete the .realm.management
directory.
android {
...
applicationVariants.all { variant ->
if (variant.buildType.name == 'debug') {
variant.mergeAssets.doLast {
delete(fileTree(dir: variant.mergeAssets.outputDir, includes: ['**/.realm.management', '**/*.lock', '**/*.note']))
}
}
}
}
assets directory contents:
assets directory contents in apk:
this looks almost alike the approach already presented along with the question.
– Martin Zeitler
Dec 12 '18 at 12:13
@MartinZeitler: Yes, you are right. I've added'**/.realm.management'
to be deleted.
– aminography
Dec 12 '18 at 12:15
the basic issue might be conflicting exclusive file access. I might be wrong (concerning aapt & assets), but would assume that empty directories are in general not being packaged.
– Martin Zeitler
Dec 12 '18 at 12:31
@aminography I noticed that your.realm.management
directory in the screenshot provided is not prefixed with "appData", i.e.appData.realm.management/
. Did this solution work for you? It did not appear to resolve the issue.
– Orbit
Dec 17 '18 at 21:35
@aminography almost have to up-vote this, for providing the screenshot of the assets directory, which enabled my to write thatcleanupRealm
task. else I would not have known what to write.
– Martin Zeitler
Dec 17 '18 at 22:56
add a comment |
guess you might be using an elder version of Realm Studio,
because according to issue #842 and pull request #847, those directories should meanwhile be properly cleaned up - and also report, in case not - instead of stalling. the current version 3.12 should have that fixed (basically any release after the 18th of June). if that should not help, the best you can do is to report it below issue #842; or file a new one issue, which is referencing issue #842. also check the file-system permissions, that the user which runs gradle is permitted to delete there; manually moving files out of the way "might" help, so the current user may re-create them and then subsequently is able to delete his own files.
both methods using gradle are workarounds - because it should not happen in the first place.
in order to obtain further information "why it stalls", run this command in the terminal:
./gradlew -d app:generateDebugAssets
respectively on Windows (the question does neither indicate the OS nor the Realm Studio version):
gradlew.bat -d app:generateDebugAssets
edit: one could even delete these files before each build:
task cleanupRealm(type: Delete) {
delete project.projectDir.path + "/src/main/assets/.realm.management"
delete project.projectDir.path + "/src/main/assets/appData.realm.lock"
delete project.projectDir.path + "/src/main/assets/appData.realm.note"
}
tasks.whenTaskAdded { task ->
if (task.name == "preDebugBuild" || task.name == "preReleaseBuild") {
task.dependsOn cleanupRealm
}
}
which changes the task graph to:
:app:checkDebugClasspath
:app:cleanupRealm
:app:preBuild
:app:preDebugBuild
I believe the description and code shown in the linked PRs has to do with Electron's renderer process and relative files containing arenderer-
pattern, as they don't appear to be related to this issue. I am running the latest release of Realm Studio. Your suggestion to manually run the task was great, asapp:generateDebugAssets
completes successfully.:app:generateDebugAssets UP-TO-DATE
had been the last thing printed while building in Android Studio, however the real culprit appears to be:app:mergeDebugAssets
, which repeatedly prints logs regarding thedaemon addresses registry
.
– Orbit
Dec 17 '18 at 21:48
@Orbit and when you'd run./gradlew -d :app:mergeDebugAssets
? it might be waiting to get access to a shared lock, which it does not get ...
– Martin Zeitler
Dec 17 '18 at 22:28
The task hangs at 75%. I'll add a small snippet of the output that gets repeatedly logged at that point, as the full output is quite large, to the original post. Note that./gradlew -s app:mergeDebugAssets
shows no exceptions. Also, note that without these "temporary" Realm files, this task usually completes within a few seconds.
– Orbit
Dec 17 '18 at 22:47
@Orbit just added the task which creates this situation. it's not tested, because I don't have these files - but at least the task is added properly, has the correct type and I'm convinced that only the paths might vary. nevertheless it could fail, when any of these files is opened with an exclusive lock.
– Martin Zeitler
Dec 17 '18 at 23:01
YourcleanupRealm
task works great, though i've changed the call to usedelete project.projectDir.path
instead. This deletes these temporary files on every Gradle sync and every build. Any idea as to why the issue withmergeDebugAssets
was occuring? Is there a way to simply have the build ignore these files instead of deleting them?
– Orbit
Dec 17 '18 at 23:12
|
show 3 more comments
Try that :
android {
aaptOptions {
ignoreAssetsPattern "!*.cv:!*.mx:!*.lock:!*.note"
}
}
From aapt
binary from build-tools
folder :
./aapt
[...]
--ignore-assets
Assets to be ignored. Default pattern is:
!.svn:!.git:!.ds_store:!*.scc:.*:<dir>_*:!CVS:!thumbs.db:!picasa.ini:!*~
Where should theaaptOptions
block go? Both options I tried (insideandroid {}
and another inandroid { buildTypes {} }
) did not appear to solve the issue.
– Orbit
Dec 11 '18 at 22:20
Yes it's in theandroid
block. It does not work at all ?
– ToYonos
Dec 12 '18 at 0:49
ignoreAssetsPattern = ignoreAssetsPattern + "..."
would add instead of replace.
– Martin Zeitler
Dec 12 '18 at 12:14
@ToYonos Correct, it does not appear to resolve the issue. Note that before settingignoreAssetsPattern
,ignoreAssets
andignoreAssetsPattern
are both null.
– Orbit
Dec 17 '18 at 22:14
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53490891%2fexclude-temporary-realm-files-from-gradle-build%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
I think the problem is that you did not delete the .realm.management
directory.
android {
...
applicationVariants.all { variant ->
if (variant.buildType.name == 'debug') {
variant.mergeAssets.doLast {
delete(fileTree(dir: variant.mergeAssets.outputDir, includes: ['**/.realm.management', '**/*.lock', '**/*.note']))
}
}
}
}
assets directory contents:
assets directory contents in apk:
this looks almost alike the approach already presented along with the question.
– Martin Zeitler
Dec 12 '18 at 12:13
@MartinZeitler: Yes, you are right. I've added'**/.realm.management'
to be deleted.
– aminography
Dec 12 '18 at 12:15
the basic issue might be conflicting exclusive file access. I might be wrong (concerning aapt & assets), but would assume that empty directories are in general not being packaged.
– Martin Zeitler
Dec 12 '18 at 12:31
@aminography I noticed that your.realm.management
directory in the screenshot provided is not prefixed with "appData", i.e.appData.realm.management/
. Did this solution work for you? It did not appear to resolve the issue.
– Orbit
Dec 17 '18 at 21:35
@aminography almost have to up-vote this, for providing the screenshot of the assets directory, which enabled my to write thatcleanupRealm
task. else I would not have known what to write.
– Martin Zeitler
Dec 17 '18 at 22:56
add a comment |
I think the problem is that you did not delete the .realm.management
directory.
android {
...
applicationVariants.all { variant ->
if (variant.buildType.name == 'debug') {
variant.mergeAssets.doLast {
delete(fileTree(dir: variant.mergeAssets.outputDir, includes: ['**/.realm.management', '**/*.lock', '**/*.note']))
}
}
}
}
assets directory contents:
assets directory contents in apk:
this looks almost alike the approach already presented along with the question.
– Martin Zeitler
Dec 12 '18 at 12:13
@MartinZeitler: Yes, you are right. I've added'**/.realm.management'
to be deleted.
– aminography
Dec 12 '18 at 12:15
the basic issue might be conflicting exclusive file access. I might be wrong (concerning aapt & assets), but would assume that empty directories are in general not being packaged.
– Martin Zeitler
Dec 12 '18 at 12:31
@aminography I noticed that your.realm.management
directory in the screenshot provided is not prefixed with "appData", i.e.appData.realm.management/
. Did this solution work for you? It did not appear to resolve the issue.
– Orbit
Dec 17 '18 at 21:35
@aminography almost have to up-vote this, for providing the screenshot of the assets directory, which enabled my to write thatcleanupRealm
task. else I would not have known what to write.
– Martin Zeitler
Dec 17 '18 at 22:56
add a comment |
I think the problem is that you did not delete the .realm.management
directory.
android {
...
applicationVariants.all { variant ->
if (variant.buildType.name == 'debug') {
variant.mergeAssets.doLast {
delete(fileTree(dir: variant.mergeAssets.outputDir, includes: ['**/.realm.management', '**/*.lock', '**/*.note']))
}
}
}
}
assets directory contents:
assets directory contents in apk:
I think the problem is that you did not delete the .realm.management
directory.
android {
...
applicationVariants.all { variant ->
if (variant.buildType.name == 'debug') {
variant.mergeAssets.doLast {
delete(fileTree(dir: variant.mergeAssets.outputDir, includes: ['**/.realm.management', '**/*.lock', '**/*.note']))
}
}
}
}
assets directory contents:
assets directory contents in apk:
edited Dec 12 '18 at 12:10
answered Dec 12 '18 at 11:30
aminographyaminography
6,26521533
6,26521533
this looks almost alike the approach already presented along with the question.
– Martin Zeitler
Dec 12 '18 at 12:13
@MartinZeitler: Yes, you are right. I've added'**/.realm.management'
to be deleted.
– aminography
Dec 12 '18 at 12:15
the basic issue might be conflicting exclusive file access. I might be wrong (concerning aapt & assets), but would assume that empty directories are in general not being packaged.
– Martin Zeitler
Dec 12 '18 at 12:31
@aminography I noticed that your.realm.management
directory in the screenshot provided is not prefixed with "appData", i.e.appData.realm.management/
. Did this solution work for you? It did not appear to resolve the issue.
– Orbit
Dec 17 '18 at 21:35
@aminography almost have to up-vote this, for providing the screenshot of the assets directory, which enabled my to write thatcleanupRealm
task. else I would not have known what to write.
– Martin Zeitler
Dec 17 '18 at 22:56
add a comment |
this looks almost alike the approach already presented along with the question.
– Martin Zeitler
Dec 12 '18 at 12:13
@MartinZeitler: Yes, you are right. I've added'**/.realm.management'
to be deleted.
– aminography
Dec 12 '18 at 12:15
the basic issue might be conflicting exclusive file access. I might be wrong (concerning aapt & assets), but would assume that empty directories are in general not being packaged.
– Martin Zeitler
Dec 12 '18 at 12:31
@aminography I noticed that your.realm.management
directory in the screenshot provided is not prefixed with "appData", i.e.appData.realm.management/
. Did this solution work for you? It did not appear to resolve the issue.
– Orbit
Dec 17 '18 at 21:35
@aminography almost have to up-vote this, for providing the screenshot of the assets directory, which enabled my to write thatcleanupRealm
task. else I would not have known what to write.
– Martin Zeitler
Dec 17 '18 at 22:56
this looks almost alike the approach already presented along with the question.
– Martin Zeitler
Dec 12 '18 at 12:13
this looks almost alike the approach already presented along with the question.
– Martin Zeitler
Dec 12 '18 at 12:13
@MartinZeitler: Yes, you are right. I've added
'**/.realm.management'
to be deleted.– aminography
Dec 12 '18 at 12:15
@MartinZeitler: Yes, you are right. I've added
'**/.realm.management'
to be deleted.– aminography
Dec 12 '18 at 12:15
the basic issue might be conflicting exclusive file access. I might be wrong (concerning aapt & assets), but would assume that empty directories are in general not being packaged.
– Martin Zeitler
Dec 12 '18 at 12:31
the basic issue might be conflicting exclusive file access. I might be wrong (concerning aapt & assets), but would assume that empty directories are in general not being packaged.
– Martin Zeitler
Dec 12 '18 at 12:31
@aminography I noticed that your
.realm.management
directory in the screenshot provided is not prefixed with "appData", i.e. appData.realm.management/
. Did this solution work for you? It did not appear to resolve the issue.– Orbit
Dec 17 '18 at 21:35
@aminography I noticed that your
.realm.management
directory in the screenshot provided is not prefixed with "appData", i.e. appData.realm.management/
. Did this solution work for you? It did not appear to resolve the issue.– Orbit
Dec 17 '18 at 21:35
@aminography almost have to up-vote this, for providing the screenshot of the assets directory, which enabled my to write that
cleanupRealm
task. else I would not have known what to write.– Martin Zeitler
Dec 17 '18 at 22:56
@aminography almost have to up-vote this, for providing the screenshot of the assets directory, which enabled my to write that
cleanupRealm
task. else I would not have known what to write.– Martin Zeitler
Dec 17 '18 at 22:56
add a comment |
guess you might be using an elder version of Realm Studio,
because according to issue #842 and pull request #847, those directories should meanwhile be properly cleaned up - and also report, in case not - instead of stalling. the current version 3.12 should have that fixed (basically any release after the 18th of June). if that should not help, the best you can do is to report it below issue #842; or file a new one issue, which is referencing issue #842. also check the file-system permissions, that the user which runs gradle is permitted to delete there; manually moving files out of the way "might" help, so the current user may re-create them and then subsequently is able to delete his own files.
both methods using gradle are workarounds - because it should not happen in the first place.
in order to obtain further information "why it stalls", run this command in the terminal:
./gradlew -d app:generateDebugAssets
respectively on Windows (the question does neither indicate the OS nor the Realm Studio version):
gradlew.bat -d app:generateDebugAssets
edit: one could even delete these files before each build:
task cleanupRealm(type: Delete) {
delete project.projectDir.path + "/src/main/assets/.realm.management"
delete project.projectDir.path + "/src/main/assets/appData.realm.lock"
delete project.projectDir.path + "/src/main/assets/appData.realm.note"
}
tasks.whenTaskAdded { task ->
if (task.name == "preDebugBuild" || task.name == "preReleaseBuild") {
task.dependsOn cleanupRealm
}
}
which changes the task graph to:
:app:checkDebugClasspath
:app:cleanupRealm
:app:preBuild
:app:preDebugBuild
I believe the description and code shown in the linked PRs has to do with Electron's renderer process and relative files containing arenderer-
pattern, as they don't appear to be related to this issue. I am running the latest release of Realm Studio. Your suggestion to manually run the task was great, asapp:generateDebugAssets
completes successfully.:app:generateDebugAssets UP-TO-DATE
had been the last thing printed while building in Android Studio, however the real culprit appears to be:app:mergeDebugAssets
, which repeatedly prints logs regarding thedaemon addresses registry
.
– Orbit
Dec 17 '18 at 21:48
@Orbit and when you'd run./gradlew -d :app:mergeDebugAssets
? it might be waiting to get access to a shared lock, which it does not get ...
– Martin Zeitler
Dec 17 '18 at 22:28
The task hangs at 75%. I'll add a small snippet of the output that gets repeatedly logged at that point, as the full output is quite large, to the original post. Note that./gradlew -s app:mergeDebugAssets
shows no exceptions. Also, note that without these "temporary" Realm files, this task usually completes within a few seconds.
– Orbit
Dec 17 '18 at 22:47
@Orbit just added the task which creates this situation. it's not tested, because I don't have these files - but at least the task is added properly, has the correct type and I'm convinced that only the paths might vary. nevertheless it could fail, when any of these files is opened with an exclusive lock.
– Martin Zeitler
Dec 17 '18 at 23:01
YourcleanupRealm
task works great, though i've changed the call to usedelete project.projectDir.path
instead. This deletes these temporary files on every Gradle sync and every build. Any idea as to why the issue withmergeDebugAssets
was occuring? Is there a way to simply have the build ignore these files instead of deleting them?
– Orbit
Dec 17 '18 at 23:12
|
show 3 more comments
guess you might be using an elder version of Realm Studio,
because according to issue #842 and pull request #847, those directories should meanwhile be properly cleaned up - and also report, in case not - instead of stalling. the current version 3.12 should have that fixed (basically any release after the 18th of June). if that should not help, the best you can do is to report it below issue #842; or file a new one issue, which is referencing issue #842. also check the file-system permissions, that the user which runs gradle is permitted to delete there; manually moving files out of the way "might" help, so the current user may re-create them and then subsequently is able to delete his own files.
both methods using gradle are workarounds - because it should not happen in the first place.
in order to obtain further information "why it stalls", run this command in the terminal:
./gradlew -d app:generateDebugAssets
respectively on Windows (the question does neither indicate the OS nor the Realm Studio version):
gradlew.bat -d app:generateDebugAssets
edit: one could even delete these files before each build:
task cleanupRealm(type: Delete) {
delete project.projectDir.path + "/src/main/assets/.realm.management"
delete project.projectDir.path + "/src/main/assets/appData.realm.lock"
delete project.projectDir.path + "/src/main/assets/appData.realm.note"
}
tasks.whenTaskAdded { task ->
if (task.name == "preDebugBuild" || task.name == "preReleaseBuild") {
task.dependsOn cleanupRealm
}
}
which changes the task graph to:
:app:checkDebugClasspath
:app:cleanupRealm
:app:preBuild
:app:preDebugBuild
I believe the description and code shown in the linked PRs has to do with Electron's renderer process and relative files containing arenderer-
pattern, as they don't appear to be related to this issue. I am running the latest release of Realm Studio. Your suggestion to manually run the task was great, asapp:generateDebugAssets
completes successfully.:app:generateDebugAssets UP-TO-DATE
had been the last thing printed while building in Android Studio, however the real culprit appears to be:app:mergeDebugAssets
, which repeatedly prints logs regarding thedaemon addresses registry
.
– Orbit
Dec 17 '18 at 21:48
@Orbit and when you'd run./gradlew -d :app:mergeDebugAssets
? it might be waiting to get access to a shared lock, which it does not get ...
– Martin Zeitler
Dec 17 '18 at 22:28
The task hangs at 75%. I'll add a small snippet of the output that gets repeatedly logged at that point, as the full output is quite large, to the original post. Note that./gradlew -s app:mergeDebugAssets
shows no exceptions. Also, note that without these "temporary" Realm files, this task usually completes within a few seconds.
– Orbit
Dec 17 '18 at 22:47
@Orbit just added the task which creates this situation. it's not tested, because I don't have these files - but at least the task is added properly, has the correct type and I'm convinced that only the paths might vary. nevertheless it could fail, when any of these files is opened with an exclusive lock.
– Martin Zeitler
Dec 17 '18 at 23:01
YourcleanupRealm
task works great, though i've changed the call to usedelete project.projectDir.path
instead. This deletes these temporary files on every Gradle sync and every build. Any idea as to why the issue withmergeDebugAssets
was occuring? Is there a way to simply have the build ignore these files instead of deleting them?
– Orbit
Dec 17 '18 at 23:12
|
show 3 more comments
guess you might be using an elder version of Realm Studio,
because according to issue #842 and pull request #847, those directories should meanwhile be properly cleaned up - and also report, in case not - instead of stalling. the current version 3.12 should have that fixed (basically any release after the 18th of June). if that should not help, the best you can do is to report it below issue #842; or file a new one issue, which is referencing issue #842. also check the file-system permissions, that the user which runs gradle is permitted to delete there; manually moving files out of the way "might" help, so the current user may re-create them and then subsequently is able to delete his own files.
both methods using gradle are workarounds - because it should not happen in the first place.
in order to obtain further information "why it stalls", run this command in the terminal:
./gradlew -d app:generateDebugAssets
respectively on Windows (the question does neither indicate the OS nor the Realm Studio version):
gradlew.bat -d app:generateDebugAssets
edit: one could even delete these files before each build:
task cleanupRealm(type: Delete) {
delete project.projectDir.path + "/src/main/assets/.realm.management"
delete project.projectDir.path + "/src/main/assets/appData.realm.lock"
delete project.projectDir.path + "/src/main/assets/appData.realm.note"
}
tasks.whenTaskAdded { task ->
if (task.name == "preDebugBuild" || task.name == "preReleaseBuild") {
task.dependsOn cleanupRealm
}
}
which changes the task graph to:
:app:checkDebugClasspath
:app:cleanupRealm
:app:preBuild
:app:preDebugBuild
guess you might be using an elder version of Realm Studio,
because according to issue #842 and pull request #847, those directories should meanwhile be properly cleaned up - and also report, in case not - instead of stalling. the current version 3.12 should have that fixed (basically any release after the 18th of June). if that should not help, the best you can do is to report it below issue #842; or file a new one issue, which is referencing issue #842. also check the file-system permissions, that the user which runs gradle is permitted to delete there; manually moving files out of the way "might" help, so the current user may re-create them and then subsequently is able to delete his own files.
both methods using gradle are workarounds - because it should not happen in the first place.
in order to obtain further information "why it stalls", run this command in the terminal:
./gradlew -d app:generateDebugAssets
respectively on Windows (the question does neither indicate the OS nor the Realm Studio version):
gradlew.bat -d app:generateDebugAssets
edit: one could even delete these files before each build:
task cleanupRealm(type: Delete) {
delete project.projectDir.path + "/src/main/assets/.realm.management"
delete project.projectDir.path + "/src/main/assets/appData.realm.lock"
delete project.projectDir.path + "/src/main/assets/appData.realm.note"
}
tasks.whenTaskAdded { task ->
if (task.name == "preDebugBuild" || task.name == "preReleaseBuild") {
task.dependsOn cleanupRealm
}
}
which changes the task graph to:
:app:checkDebugClasspath
:app:cleanupRealm
:app:preBuild
:app:preDebugBuild
edited Dec 17 '18 at 23:40
answered Dec 12 '18 at 11:48
Martin ZeitlerMartin Zeitler
17.5k34169
17.5k34169
I believe the description and code shown in the linked PRs has to do with Electron's renderer process and relative files containing arenderer-
pattern, as they don't appear to be related to this issue. I am running the latest release of Realm Studio. Your suggestion to manually run the task was great, asapp:generateDebugAssets
completes successfully.:app:generateDebugAssets UP-TO-DATE
had been the last thing printed while building in Android Studio, however the real culprit appears to be:app:mergeDebugAssets
, which repeatedly prints logs regarding thedaemon addresses registry
.
– Orbit
Dec 17 '18 at 21:48
@Orbit and when you'd run./gradlew -d :app:mergeDebugAssets
? it might be waiting to get access to a shared lock, which it does not get ...
– Martin Zeitler
Dec 17 '18 at 22:28
The task hangs at 75%. I'll add a small snippet of the output that gets repeatedly logged at that point, as the full output is quite large, to the original post. Note that./gradlew -s app:mergeDebugAssets
shows no exceptions. Also, note that without these "temporary" Realm files, this task usually completes within a few seconds.
– Orbit
Dec 17 '18 at 22:47
@Orbit just added the task which creates this situation. it's not tested, because I don't have these files - but at least the task is added properly, has the correct type and I'm convinced that only the paths might vary. nevertheless it could fail, when any of these files is opened with an exclusive lock.
– Martin Zeitler
Dec 17 '18 at 23:01
YourcleanupRealm
task works great, though i've changed the call to usedelete project.projectDir.path
instead. This deletes these temporary files on every Gradle sync and every build. Any idea as to why the issue withmergeDebugAssets
was occuring? Is there a way to simply have the build ignore these files instead of deleting them?
– Orbit
Dec 17 '18 at 23:12
|
show 3 more comments
I believe the description and code shown in the linked PRs has to do with Electron's renderer process and relative files containing arenderer-
pattern, as they don't appear to be related to this issue. I am running the latest release of Realm Studio. Your suggestion to manually run the task was great, asapp:generateDebugAssets
completes successfully.:app:generateDebugAssets UP-TO-DATE
had been the last thing printed while building in Android Studio, however the real culprit appears to be:app:mergeDebugAssets
, which repeatedly prints logs regarding thedaemon addresses registry
.
– Orbit
Dec 17 '18 at 21:48
@Orbit and when you'd run./gradlew -d :app:mergeDebugAssets
? it might be waiting to get access to a shared lock, which it does not get ...
– Martin Zeitler
Dec 17 '18 at 22:28
The task hangs at 75%. I'll add a small snippet of the output that gets repeatedly logged at that point, as the full output is quite large, to the original post. Note that./gradlew -s app:mergeDebugAssets
shows no exceptions. Also, note that without these "temporary" Realm files, this task usually completes within a few seconds.
– Orbit
Dec 17 '18 at 22:47
@Orbit just added the task which creates this situation. it's not tested, because I don't have these files - but at least the task is added properly, has the correct type and I'm convinced that only the paths might vary. nevertheless it could fail, when any of these files is opened with an exclusive lock.
– Martin Zeitler
Dec 17 '18 at 23:01
YourcleanupRealm
task works great, though i've changed the call to usedelete project.projectDir.path
instead. This deletes these temporary files on every Gradle sync and every build. Any idea as to why the issue withmergeDebugAssets
was occuring? Is there a way to simply have the build ignore these files instead of deleting them?
– Orbit
Dec 17 '18 at 23:12
I believe the description and code shown in the linked PRs has to do with Electron's renderer process and relative files containing a
renderer-
pattern, as they don't appear to be related to this issue. I am running the latest release of Realm Studio. Your suggestion to manually run the task was great, as app:generateDebugAssets
completes successfully. :app:generateDebugAssets UP-TO-DATE
had been the last thing printed while building in Android Studio, however the real culprit appears to be :app:mergeDebugAssets
, which repeatedly prints logs regarding the daemon addresses registry
.– Orbit
Dec 17 '18 at 21:48
I believe the description and code shown in the linked PRs has to do with Electron's renderer process and relative files containing a
renderer-
pattern, as they don't appear to be related to this issue. I am running the latest release of Realm Studio. Your suggestion to manually run the task was great, as app:generateDebugAssets
completes successfully. :app:generateDebugAssets UP-TO-DATE
had been the last thing printed while building in Android Studio, however the real culprit appears to be :app:mergeDebugAssets
, which repeatedly prints logs regarding the daemon addresses registry
.– Orbit
Dec 17 '18 at 21:48
@Orbit and when you'd run
./gradlew -d :app:mergeDebugAssets
? it might be waiting to get access to a shared lock, which it does not get ...– Martin Zeitler
Dec 17 '18 at 22:28
@Orbit and when you'd run
./gradlew -d :app:mergeDebugAssets
? it might be waiting to get access to a shared lock, which it does not get ...– Martin Zeitler
Dec 17 '18 at 22:28
The task hangs at 75%. I'll add a small snippet of the output that gets repeatedly logged at that point, as the full output is quite large, to the original post. Note that
./gradlew -s app:mergeDebugAssets
shows no exceptions. Also, note that without these "temporary" Realm files, this task usually completes within a few seconds.– Orbit
Dec 17 '18 at 22:47
The task hangs at 75%. I'll add a small snippet of the output that gets repeatedly logged at that point, as the full output is quite large, to the original post. Note that
./gradlew -s app:mergeDebugAssets
shows no exceptions. Also, note that without these "temporary" Realm files, this task usually completes within a few seconds.– Orbit
Dec 17 '18 at 22:47
@Orbit just added the task which creates this situation. it's not tested, because I don't have these files - but at least the task is added properly, has the correct type and I'm convinced that only the paths might vary. nevertheless it could fail, when any of these files is opened with an exclusive lock.
– Martin Zeitler
Dec 17 '18 at 23:01
@Orbit just added the task which creates this situation. it's not tested, because I don't have these files - but at least the task is added properly, has the correct type and I'm convinced that only the paths might vary. nevertheless it could fail, when any of these files is opened with an exclusive lock.
– Martin Zeitler
Dec 17 '18 at 23:01
Your
cleanupRealm
task works great, though i've changed the call to use delete project.projectDir.path
instead. This deletes these temporary files on every Gradle sync and every build. Any idea as to why the issue with mergeDebugAssets
was occuring? Is there a way to simply have the build ignore these files instead of deleting them?– Orbit
Dec 17 '18 at 23:12
Your
cleanupRealm
task works great, though i've changed the call to use delete project.projectDir.path
instead. This deletes these temporary files on every Gradle sync and every build. Any idea as to why the issue with mergeDebugAssets
was occuring? Is there a way to simply have the build ignore these files instead of deleting them?– Orbit
Dec 17 '18 at 23:12
|
show 3 more comments
Try that :
android {
aaptOptions {
ignoreAssetsPattern "!*.cv:!*.mx:!*.lock:!*.note"
}
}
From aapt
binary from build-tools
folder :
./aapt
[...]
--ignore-assets
Assets to be ignored. Default pattern is:
!.svn:!.git:!.ds_store:!*.scc:.*:<dir>_*:!CVS:!thumbs.db:!picasa.ini:!*~
Where should theaaptOptions
block go? Both options I tried (insideandroid {}
and another inandroid { buildTypes {} }
) did not appear to solve the issue.
– Orbit
Dec 11 '18 at 22:20
Yes it's in theandroid
block. It does not work at all ?
– ToYonos
Dec 12 '18 at 0:49
ignoreAssetsPattern = ignoreAssetsPattern + "..."
would add instead of replace.
– Martin Zeitler
Dec 12 '18 at 12:14
@ToYonos Correct, it does not appear to resolve the issue. Note that before settingignoreAssetsPattern
,ignoreAssets
andignoreAssetsPattern
are both null.
– Orbit
Dec 17 '18 at 22:14
add a comment |
Try that :
android {
aaptOptions {
ignoreAssetsPattern "!*.cv:!*.mx:!*.lock:!*.note"
}
}
From aapt
binary from build-tools
folder :
./aapt
[...]
--ignore-assets
Assets to be ignored. Default pattern is:
!.svn:!.git:!.ds_store:!*.scc:.*:<dir>_*:!CVS:!thumbs.db:!picasa.ini:!*~
Where should theaaptOptions
block go? Both options I tried (insideandroid {}
and another inandroid { buildTypes {} }
) did not appear to solve the issue.
– Orbit
Dec 11 '18 at 22:20
Yes it's in theandroid
block. It does not work at all ?
– ToYonos
Dec 12 '18 at 0:49
ignoreAssetsPattern = ignoreAssetsPattern + "..."
would add instead of replace.
– Martin Zeitler
Dec 12 '18 at 12:14
@ToYonos Correct, it does not appear to resolve the issue. Note that before settingignoreAssetsPattern
,ignoreAssets
andignoreAssetsPattern
are both null.
– Orbit
Dec 17 '18 at 22:14
add a comment |
Try that :
android {
aaptOptions {
ignoreAssetsPattern "!*.cv:!*.mx:!*.lock:!*.note"
}
}
From aapt
binary from build-tools
folder :
./aapt
[...]
--ignore-assets
Assets to be ignored. Default pattern is:
!.svn:!.git:!.ds_store:!*.scc:.*:<dir>_*:!CVS:!thumbs.db:!picasa.ini:!*~
Try that :
android {
aaptOptions {
ignoreAssetsPattern "!*.cv:!*.mx:!*.lock:!*.note"
}
}
From aapt
binary from build-tools
folder :
./aapt
[...]
--ignore-assets
Assets to be ignored. Default pattern is:
!.svn:!.git:!.ds_store:!*.scc:.*:<dir>_*:!CVS:!thumbs.db:!picasa.ini:!*~
edited Dec 12 '18 at 8:37
answered Dec 5 '18 at 10:11
ToYonosToYonos
11.7k22747
11.7k22747
Where should theaaptOptions
block go? Both options I tried (insideandroid {}
and another inandroid { buildTypes {} }
) did not appear to solve the issue.
– Orbit
Dec 11 '18 at 22:20
Yes it's in theandroid
block. It does not work at all ?
– ToYonos
Dec 12 '18 at 0:49
ignoreAssetsPattern = ignoreAssetsPattern + "..."
would add instead of replace.
– Martin Zeitler
Dec 12 '18 at 12:14
@ToYonos Correct, it does not appear to resolve the issue. Note that before settingignoreAssetsPattern
,ignoreAssets
andignoreAssetsPattern
are both null.
– Orbit
Dec 17 '18 at 22:14
add a comment |
Where should theaaptOptions
block go? Both options I tried (insideandroid {}
and another inandroid { buildTypes {} }
) did not appear to solve the issue.
– Orbit
Dec 11 '18 at 22:20
Yes it's in theandroid
block. It does not work at all ?
– ToYonos
Dec 12 '18 at 0:49
ignoreAssetsPattern = ignoreAssetsPattern + "..."
would add instead of replace.
– Martin Zeitler
Dec 12 '18 at 12:14
@ToYonos Correct, it does not appear to resolve the issue. Note that before settingignoreAssetsPattern
,ignoreAssets
andignoreAssetsPattern
are both null.
– Orbit
Dec 17 '18 at 22:14
Where should the
aaptOptions
block go? Both options I tried (inside android {}
and another in android { buildTypes {} }
) did not appear to solve the issue.– Orbit
Dec 11 '18 at 22:20
Where should the
aaptOptions
block go? Both options I tried (inside android {}
and another in android { buildTypes {} }
) did not appear to solve the issue.– Orbit
Dec 11 '18 at 22:20
Yes it's in the
android
block. It does not work at all ?– ToYonos
Dec 12 '18 at 0:49
Yes it's in the
android
block. It does not work at all ?– ToYonos
Dec 12 '18 at 0:49
ignoreAssetsPattern = ignoreAssetsPattern + "..."
would add instead of replace.– Martin Zeitler
Dec 12 '18 at 12:14
ignoreAssetsPattern = ignoreAssetsPattern + "..."
would add instead of replace.– Martin Zeitler
Dec 12 '18 at 12:14
@ToYonos Correct, it does not appear to resolve the issue. Note that before setting
ignoreAssetsPattern
, ignoreAssets
and ignoreAssetsPattern
are both null.– Orbit
Dec 17 '18 at 22:14
@ToYonos Correct, it does not appear to resolve the issue. Note that before setting
ignoreAssetsPattern
, ignoreAssets
and ignoreAssetsPattern
are both null.– Orbit
Dec 17 '18 at 22:14
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53490891%2fexclude-temporary-realm-files-from-gradle-build%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
None of the above solution works ? Any error message ?
– ToYonos
Dec 5 '18 at 10:01