forked from ra4king/CircuitSim
-
Notifications
You must be signed in to change notification settings - Fork 4
/
build.gradle
130 lines (115 loc) · 4.86 KB
/
build.gradle
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
plugins {
id 'java'
// Apply the application plugin to add support for building a Java application
id 'application'
}
// Define the main class for the application
mainClassName = 'com.ra4king.circuitsim.gui.CircuitSimRunner'
group 'CircuitSim'
ext.moduleName = 'Project.com.ra4king.circuitsim.gui'
sourceCompatibility = JavaVersion.VERSION_14
// In this section you declare where to find the dependencies of your project
repositories {
// Use mavenCentral for resolving dependencies
mavenCentral()
}
dependencies {
implementation 'com.google.code.gson:gson:2.10'
implementation "org.openjfx:javafx-base:22:win"
implementation "org.openjfx:javafx-base:22:linux-aarch64"
implementation "org.openjfx:javafx-base:22:linux"
implementation "org.openjfx:javafx-base:22:mac-aarch64"
implementation "org.openjfx:javafx-base:22:mac"
implementation "org.openjfx:javafx-controls:22:win"
implementation "org.openjfx:javafx-controls:22:linux-aarch64"
implementation "org.openjfx:javafx-controls:22:linux"
implementation "org.openjfx:javafx-controls:22:mac-aarch64"
implementation "org.openjfx:javafx-controls:22:mac"
implementation "org.openjfx:javafx-graphics:22:win"
implementation "org.openjfx:javafx-graphics:22:linux-aarch64"
implementation "org.openjfx:javafx-graphics:22:linux"
implementation "org.openjfx:javafx-graphics:22:mac-aarch64"
implementation "org.openjfx:javafx-graphics:22:mac"
implementation "org.openjfx:javafx-swing:22:win"
implementation "org.openjfx:javafx-swing:22:linux-aarch64"
implementation "org.openjfx:javafx-swing:22:linux"
implementation "org.openjfx:javafx-swing:22:mac-aarch64"
implementation "org.openjfx:javafx-swing:22:mac"
testImplementation 'org.junit.jupiter:junit-jupiter-api:5.9.0'
testImplementation 'org.mockito:mockito-core:4.11.0'
testImplementation 'com.google.truth:truth:1.1.3'
testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.9.0'
}
test {
useJUnitPlatform()
}
jar {
duplicatesStrategy = DuplicatesStrategy.EXCLUDE
into 'resources', {
from 'resources'
}
inputs.property("moduleName", moduleName)
manifest {
attributes(
'Automatic-Module-Name': moduleName,
'Main-Class': mainClassName
)
}
// Skip native libraries for aarch64-supported platforms initially.
// Why let Windows .dlls slip by? The naive answer is that there aren't
// even aarch64 builds for JavaFX, so the architecture is not a concern
// since we can always assume amd64. The truthful answer is that our
// strategy for dealing with amd64/aarch64 dlls is to put them in
// different subdirectories in the jar, and then extract them to a
// temporary directory at runtime based on the running architecture.
// Unfortunately, on Windows, we can't delete the native .dlls from the
// temporary directory while the JVM is still running, since it hasn't
// closed the .dlls, meaning Windows keeps all those .dlls locked.
// So the solution we take here is to use this cross-architecture hack
// for macOS/Linux native libraries and leave the Windows native
// libraries alone.
from configurations.runtimeClasspath.collect { it.isDirectory() ? it : zipTree(it).matching {
exclude '*.dylib'
exclude '*.so'
}}
// Okay, now put native libraries for macOS/Linux in their own
// architecture-specific directories inside the fat jar. We can tell ARM
// from x86 libraries by checking the filename of their containing jar
// (strangely, x86 is never mentioned in the jar names explicitly —
// instead, it's the absence of aarch64). At runtime, we will extract
// the libraries for the current architecture so that JavaFX can load them.
into 'amd64', {
from configurations.runtimeClasspath.filter { it.isFile()
&& it.getName().contains('javafx')
&& !it.getName().contains("aarch64") }
.collectMany { zipTree(it).matching {
include '*.dylib'
include '*.so'
}.getFiles() }
}
into 'aarch64', {
from configurations.runtimeClasspath.filter { it.isFile()
&& it.getName().contains('javafx')
&& it.getName().contains("aarch64") }
.collectMany { zipTree(it).matching {
include '*.dylib'
include '*.so'
}.getFiles() }
}
}
compileJava {
inputs.property("moduleName", moduleName)
doFirst {
options.compilerArgs = [
'--module-path', classpath.asPath,
'--add-modules', 'javafx.controls,javafx.swing',
'-Xlint:unchecked'
]
classpath = files()
}
}
task createJar(type: Copy) {
dependsOn 'jar'
into "$buildDir/libs"
from configurations.runtimeClasspath
}