Thank you for your interest in contributing to jdiskwipe! This document provides guidelines and instructions for contributing to this project.
- Code of Conduct
- Getting Started
- Development Setup
- Coding Standards
- Testing Requirements
- Submitting Changes
- Pull Request Process
- Reporting Bugs
This project adheres to professional and respectful collaboration. Please:
- Be respectful and constructive in discussions
- Focus on the technical merits of contributions
- Help maintain a welcoming environment for all contributors
Before contributing, ensure you have:
- Java Development Kit (JDK) 11 or higher - Required for compilation
- Apache Maven 3.6+ - Required for building and testing
- Git - For version control
- A Java IDE (recommended: IntelliJ IDEA, Eclipse, or VS Code with Java extensions)
- Fork the repository on GitHub
- Clone your fork locally:
git clone https://github.com/YOUR-USERNAME/jdiskwipe.git cd jdiskwipe - Add the upstream repository:
git remote add upstream https://github.com/FlossWare/jdiskwipe.git
Build the project to ensure your environment is set up correctly:
mvn clean packageThis will:
- Compile all source code
- Run the full test suite
- Generate the executable JAR at
target/jdiskwipe-1.0.jar
Run the test suite:
mvn testRun tests with coverage report:
mvn clean test jacoco:reportView coverage at target/site/jacoco/index.html
Generate JavaDoc:
mvn javadoc:javadocView docs at target/site/apidocs/index.html
Follow these conventions consistently throughout the codebase:
- Indentation: 4 spaces (no tabs)
- Line Length: Max 120 characters (prefer 100)
- Encoding: UTF-8
- File Format: Unix line endings (LF)
-
Naming:
- Classes:
PascalCase(e.g.,FileWorker,CleanDisk) - Methods/Variables:
camelCase(e.g.,formatBytes,bufferSize) - Constants:
UPPER_SNAKE_CASE(e.g.,DEFAULT_BUFFER_SIZE,PREFIX) - Package: lowercase (e.g.,
org.flossware.jdiskwipe.disk)
- Classes:
-
Visibility:
- Use package-private (no modifier) for internal classes
- Use
privatefor implementation details - Only expose
publicAPIs when necessary - Document all public APIs with JavaDoc
-
Braces:
- Always use braces for
if,for,while, even for single statements - Opening brace on same line as statement
- Closing brace on new line
- Always use braces for
/**
* Performs an important operation.
*
* @param input the input value
* @return the result
* @throws IllegalArgumentException if input is null
*/
public int doSomething(final String input) {
if (input == null) {
throw new IllegalArgumentException("Input cannot be null");
}
final int result = process(input);
return result;
}- All public classes and methods must have JavaDoc
- Include:
- Summary sentence (first sentence is critical)
@paramtags for all parameters@returntag for non-void methods@throwstags for declared exceptions
- Keep JavaDoc concise but complete
- Focus on what and why, not how (code shows the how)
All Java files must include the GPL copyright header:
/*
* Copyright (C) 2017-2026 Scot P. Floess
*
* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation, either version 3 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/All contributions must include appropriate tests:
- New features: Require comprehensive test coverage (aim for 80%+ line coverage)
- Bug fixes: Add a test that reproduces the bug, then fix it
- Refactoring: Ensure existing tests pass; add new tests for changed behavior
- Use JUnit Jupiter (JUnit 5) for all tests
- Place tests in
src/test/javamirroring the source structure - Test class naming:
[ClassUnderTest]Test.java - Test method naming:
test[MethodName][Condition](e.g.,testConstructorWithNullDirectory)
- Isolation: Each test should be independent and not rely on other tests
- Cleanup: Use
@TempDirfor file operations to ensure automatic cleanup - Assertions: Use clear assertion messages
- Edge Cases: Test null inputs, empty values, boundary conditions, and invalid states
- Thread Safety: Test concurrent operations where applicable
@Test
void testConstructorWithNullDirectory() {
assertThrows(IllegalArgumentException.class,
() -> new FileWorker(null, 1024),
"Constructor should reject null directory");
}
@Test
void testFileCreation(@TempDir final Path tempDir) {
final FileWorker worker = new FileWorker(tempDir.toFile(), 512);
assertNotNull(worker, "Worker should be created successfully");
}Before submitting a PR, ensure:
# All tests pass
mvn clean test
# No JavaDoc warnings
mvn javadoc:javadoc
# Project builds successfully
mvn clean package-
Create a feature branch from
main:git checkout -b feature/your-feature-name
-
Use descriptive branch names:
feature/add-multi-pass-wipe- New featuresfix/thread-cleanup-issue- Bug fixesdocs/improve-usage-guide- Documentation updatesrefactor/simplify-validation- Code refactoring
Write clear, descriptive commit messages:
Format:
Short summary (50 chars or less)
Detailed explanation of what changed and why, if necessary.
Include relevant context, references to issues, etc.
Fixes #123
Good commit messages:
Add support for custom wipe patternsFix thread interrupt handling in FileWorkerUpdate README with Windows-specific instructions
Bad commit messages:
fix bugchangeswip
Checklist before creating a PR:
- All tests pass (
mvn test) - Code follows project style guidelines
- New code has appropriate test coverage
- JavaDoc is complete for public APIs
- No compiler warnings
- CHANGELOG.md updated (if applicable)
- README.md updated (if user-facing changes)
- Commits are clean and well-organized
-
Update your fork with the latest upstream changes:
git fetch upstream git rebase upstream/main
-
Push your branch to your fork:
git push origin feature/your-feature-name
-
Create a Pull Request on GitHub with:
- Clear title describing the change
- Detailed description of what changed and why
- Link to related issues (e.g., "Fixes #42")
- Screenshots/examples if relevant
-
Address review feedback promptly:
- Make requested changes in new commits
- Push to your branch (PR will update automatically)
- Respond to reviewer comments
-
After approval, maintainers will merge your PR
Your PR will be reviewed for:
- Correctness: Does the code work as intended?
- Testing: Are there adequate tests? Do they pass?
- Code Quality: Does it follow project conventions?
- Documentation: Is it properly documented?
- Safety: Are there potential security issues?
- Performance: Are there obvious performance problems?
- Check if the issue already exists in GitHub Issues
- Verify it's reproducible with the latest version
- Gather relevant information (OS, Java version, command used)
Create a new issue with:
Title: Short, descriptive summary
Description:
**Environment:**
- OS: [e.g., Ubuntu 22.04, Windows 11, macOS 13]
- Java Version: [e.g., OpenJDK 11.0.16]
- jdiskwipe Version: [e.g., 1.0]
**Steps to Reproduce:**
1. Run command: `java -jar jdiskwipe-1.0.jar -t 4 /tmp/test`
2. Observe behavior...
**Expected Behavior:**
Should...
**Actual Behavior:**
Instead...
**Error Messages/Logs:**
[paste relevant logs here]
**Additional Context:**
Any other relevant information...
If you have questions:
- Open an issue with the
questionlabel - Check existing issues for similar questions
- Review the README and USAGE documentation
By contributing to jdiskwipe, you agree that your contributions will be licensed under the GNU General Public License v3.0 or later. See LICENSE for details.
Thank you for contributing to jdiskwipe! Your efforts help make secure disk wiping accessible to everyone.