Factory Control
Most developers in the world work in their own different local environments. The Quant team has established a few rules to minimize confusion when team members import their own source code or other developers' source code, or register libraries, even in such environments.
This method is called Factory Control. Simply put, it is a system designed so that you don't have to take separate notes on where the source code you developed is located or how to manage versions.
When one developer's project needs to be accessed by another developer within the team, reusable resources or fully shareable directories are always located in the "public" directory at the project root. Therefore, you just need to create a "public" directory in the project root. Slight adjustments are possible depending on the language or framework, and this is not a strict rule. The Quant team prioritizes team member freedom above all else.
To utilize this "public" directory, set the <PROJECT_NAME>_PUBLIC_DIR environment variable. For example, if the project name is "Entanglement", you would set the ENTANGLEMENT_PUBLIC_DIR environment variable to the path of that "public" directory.
We have agreed to always write environment variables in uppercase snake case.
In Java Projects
Java projects can largely use two build tools. We mainly use the Gradle build tool, but Maven can also be used depending on the developer's preference. I will explain the central management method for each tool.
The explanation also includes cases for multi-module projects, so don't worry.
Before that, there is one common fact. We decided to set global variables used in build files in the local environment at the highest level of the system, not in the individual project's (root) build file. This is the user home directory where the build file is installed. In the case of the macOS operating system (and for Gradle), it can be the ~/.gradle/gradle.properties path.
Gradle Projects
You can add a gradle.properties file to the Gradle user home directory and manage global variables there. If you want to deploy (publish) your project to the Maven Central Repository or the Quant Shared Repository, you can store necessary information such as user ID, password, and identifier number as follows.
# Maven Central Repository and deployment settings
mavenCentralUsername=mavenUsername
mavenCentralPassword=mavenPassword
SONATYPE_HOST=CENTRAL_PORTAL
# ...
# Signing information required for deployment
signing.keyId=pubKey
signing.password=keyPassword
signing.secretKeyRingFile=path/to/secretFile.gpg
# Quant settings
quantPublicDir=/path/to/quant/public
# Common group name management in individual projects
commonGroupId=space.qu4nt
Call these global variables in individual projects and use them as follows (based on Kotlin DSL).
// ...Plugins, overall project and variable settings
val quantPublicDir: String by project
val commonGroupId: String by project
group = commonGroupId
version = "1.0.0"
sourceSets {
main {
resources {
srcDirs += File("${quantPublicDir}/my-project")
}
}
test {
resources {
srcDirs += File("${quantPublicDir}/my-project-test")
}
}
}
// ... Other repository and dependency settings
Ta-da! Now your project can efficiently reference common (test) resources and manage groups! It is also easy when you want to deploy the project. If your project is a multi-module project, you can perform sourceSets settings for sub-modules.
// Root module build.gradle.kts
val quantPublicDir: String by project
val commonGroupId: String by project
allprojects {
group = commonGroupId
version = "1.0.0"
repositories {
mavenCentral()
}
}
subprojects {
sourceSets {
main {
resources {
srcDirs += File("${quantPublicDir}/my-project")
}
}
test {
resources {
srcDirs += File("${quantPublicDir}/my-project-test")
}
}
}
// ... Sub-module dependencies, etc. settings
}
This way, you can call the resources you want to reference in sub-modules as well. Even if your projects are overflowing, you can respond flexibly and maintain them conveniently.
Maven Projects
Maven projects can configure builds through the pom.xml file. Maven manages global settings through the settings.xml file located in the .m2 folder of the user home directory. If the file does not exist, you must create a new one. This file is used to define authentication information or global properties, similar to Gradle's gradle.properties.
First, you need to define and activate a profile for the Quant team's environment settings in the ~/.m2/settings.xml file as follows.
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
https://maven.apache.org/xsd/settings-1.0.0.xsd">
<servers>
<server>
<id>ossrh</id>
<username>mavenUsername</username>
<password>mavenPassword</password>
</server>
</servers>
<profiles>
<profile>
<id>quant-environment</id>
<properties>
<quant.public.dir>/path/to/quant/public</quant.public.dir>
<common.group.id>space.qu4nt</common.group.id>
</properties>
</profile>
</profiles>
<activeProfiles>
<activeProfile>quant-environment</activeProfile>
</activeProfiles>
</settings>
Now you can use the quant.public.dir and common.group.id variables globally. Let's call them in the individual project's pom.xml to add resources.
Since Maven basically recognizes only src/main/resources as a resource directory, you must explicitly modify the <resources> section within the <build> tag to include external paths in resources.
<project xmlns="http://maven.apache.org/POM/4.0.0" ...>
<groupId>${common.group.id}</groupId>
<artifactId>my-project</artifactId>
<version>1.0.0</version>
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
</resource>
<resource>
<directory>${quant.public.dir}/my-project</directory>
<filtering>false</filtering>
</resource>
</resources>
<testResources>
<testResource>
<directory>src/test/resources</directory>
</testResource>
<testResource>
<directory>${quant.public.dir}/my-project-test</directory>
</testResource>
</testResources>
</build>
</project>
If your project has a Multi-module structure, you only need to perform this setting once in the parent pom.xml (Parent POM). Sub-modules inherit the parent's settings, so all sub-modules automatically reference the common resource directory.
<project ...>
<groupId>${common.group.id}</groupId>
<artifactId>entanglement-parent</artifactId>
<version>1.0.0</version>
<packaging>pom</packaging>
<modules>
<module>entanglement-core</module>
<module>entanglement-api</module>
</modules>
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
</resource>
<resource>
<directory>${quant.public.dir}/my-project</directory>
</resource>
</resources>
</build>
</project>
Maven's inheritance structure is very powerful. If a specific sub-module does not need common resources, you can override the inherited settings by redefining <resources> in that module's pom.xml.
Developer Pipeline Application
The Quant team is preparing a Quant pipeline application called Garden to allow individual team members to more flexibly perform tasks such as freely publishing their projects and requesting feedback or modifications from other team members. This application is only available to Quant team members, but it may be changed to public later. Basically, it is closed so that it cannot be accessed from the outside, so gentle measures are possible when mistakes are made, and it will also be used mainly in the development of post-quantum encryption communication lines.
Garden is still in the planning stage, so it seems it will take quite some time from production to team member deployment and public release, but it will be developed in an instant once large-scale projects such as EntanglementLib or Blue-Bridge are completed. That's because EntanglementLib took less than two months to be released on GitHub as a one-person development.
First of all, I will organize this content separately under this category so that you can easily and quickly check if there are any changes at any time.