You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Here are some miscellaneous common practices to follow when developing for the DANS Data Station Architecture. It is assumed that you are using IntelliJ. If
5
+
this is not the case, please adapt accordingly.
6
+
7
+
Code Style
8
+
----------
9
+
10
+
* Install the IntelliJ [code style] and [inspections]. Format the source code with these settings in our own projects. Resolve the warnings
11
+
indicated by the inspections.
12
+
* In Dataverse try to minimize code changes due to reformatting, so only apply formatting to code that you have changed anyway.
13
+
* In the POM file keep the order the of the elements as follows (note that some are optional):
14
+
*`modelVersion`
15
+
*`parent`
16
+
*`groupId`
17
+
*`artifactId`
18
+
*`version`
19
+
*`name`
20
+
*`url`
21
+
*`description`
22
+
*`inceptionYear`
23
+
*`properties`
24
+
*`scm`
25
+
*`dependencyManagement`
26
+
*`dependencies`
27
+
*`build`
28
+
*`repositories`
29
+
*`distributionManagement`
30
+
*`profiles`
31
+
32
+
### Lombok
33
+
34
+
Use [Lombok]{:target=_blank} for:
35
+
36
+
* Adding loggers with the `@Slf4j` annotation (this names the logger after the fully qualified class name automatically).
37
+
* Creating getters, setters and constructors on value objects (i.e. the main purpose of the object is to store values and not to perform operations).
38
+
39
+
Dependency Management
40
+
---------------------
41
+
Dependency management of Java projects is done with Maven. Projects should inherit from `dd-parent`. The first thing that most projects will include is
42
+
`io.dropwizard:dropwizard-core`.
43
+
44
+
Testing
45
+
-------
46
+
47
+
* Unit test names should be as descriptive as possible. Since this will often involve creating long test names, use `snake_case` instead of `camelCase` here.
48
+
* Unit tests will often need to write some temporary data to disk. The location for this is `<project-dir>/target/test/<ClassNameOfUnitTest>`. By working under
49
+
`target` we make sure the unit tests don't interfere with the project itself or the test files we are using for [debugging](#debugging).
50
+
* Unit tests should clear their temporary directory **before** the tests start, but leave everything on disk after finishing. This allows you to diagnose
51
+
any problems with a test by running it and inspecting its temporary directory.
52
+
53
+
Debugging
54
+
---------
55
+
56
+
For debugging use the scripts in [dans-dev-scripts]{:target=_blank}. Start the environment with `start-env.sh`. This sets up configuration files under
57
+
`<project-dir>/etc/` for use during debugging and create directory to store input and output files under `<project-dir>/data/`. Start the program with the
58
+
`start-*debug.sh` helper scripts and then attach IntelliJ to the VM.
59
+
60
+
Documentation
61
+
-------------
62
+
Each module has its associated documentation site, which is published at `dans-knaw.github.io`. The archetype sets up the project with a skeleton site. Use
63
+
the `start-mkdocs.sh` script in [dans-dev-scripts]{:target=_blank} to start the site locally and see what it looks like after you have made your changes.
64
+
65
+
Each documentation site follows a common structure which depends on the type of module: library, microservice, or command-line application. See existing
66
+
documentation sites for examples.
67
+
68
+
### JavaDocs
69
+
70
+
If the project is a library it should include JavaDocs. Extensive code examples are best relegated to separated pages, outside
71
+
the JavaDocs, so that you can make full use of the extended Markdown support of mkdocs. You can then link to those from the JavaDocs.
0 commit comments