add ADRs, refactored config->cli

.gitignore

@@ -25,3 +25,4 @@ go-app/_pdfs
 pdfminion
 docs/website/_site
 docs/_site
+go-app/build

README.md

@@ -7,90 +7,21 @@ Helper (_minion_) for some mundane tasks with PDF documents, among others:
 * add header and/or footer text
 * concatenate (combine multiple PDF files into a single file)
 
-It shall have a (multi-platform) graphical user interface, at least for Mac-OS, Windows and maybe Linux.
 
 >  minion: a servile dependent, follower, or underling.<br> 
 > "He's one of the boss's minions."<br>
 > From: [Merriam-Webster Dictionary](https://www.merriam-webster.com/dictionary/minion)
 
 ## Status
-[![feature-linter](https://github.com/gernotstarke/PDFminion/actions/workflows/feature-linter.yml/badge.svg)](https://github.com/gernotstarke/PDFminion/actions/workflows/feature-linter.yml)
-[![go_test](https://github.com/gernotstarke/PDFminion/actions/workflows/go_test.yml/badge.svg)](https://github.com/gernotstarke/PDFminion/actions/workflows/go_test.yml)
 
 [![Go Report Card](https://goreportcard.com/badge/github.com/gernotstarke/PDFminion)](https://goreportcard.com/report/github.com/gernotstarke/PDFminion)
 [![Quality Gate Status](https://sonarcloud.io/api/project_badges/measure?project=gernotstarke_PDFminion&metric=alert_status)](https://sonarcloud.io/dashboard?id=gernotstarke_PDFminion)
 [![Maintainability](https://api.codeclimate.com/v1/badges/c481ef8142826f71ff65/maintainability)](https://codeclimate.com/github/gernotstarke/PDFminion/maintainability)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 
 I'm currently experimenting with an MVP version of PDFminion, therefore most of the information given here is **NOT** valid any longer.
-## Why PDFminion? 
 
+## Why PDFminion?
 
-## Development
-
-#### The following paragraphs are outdated!!
-
-We're using BDD (behavior driven development) with Cucumber to specify at least part of the requirements as _scenarios_.
-These scenarios can be executed, similar to automated unit tests.
-
-* [Godog](https://github.com/cucumber/godog), the official Cucumber tool
-* [Cucumber HTML Reporter](https://www.npmjs.com/package/cucumber-html-reporter)
-* [Cucumber Multi Reporter (more detailed)](https://github.com/wswebcreation/multiple-cucumber-html-reporter)
-
-Use `./create-detailed-cucumber-report.sh` to generate a detailed BDD Cucumber report.
-
-### Deviation from Standard golang practices
-As of June 2021, the `godog` bdd tool does not respect the standard golang layout practice
-of putting test files next to the tested-code.
-Instead, the step definitions need to be present in the root folder!
-
-To avoid confusion, I prefixed the step definitions with `stepdef_` - so they are easily recognizable.
-Other (non-bdd/cucumber) automated tests will reside within the appropriate package folders.
-
-See this [Cucumber/godog issue](https://github.com/cucumber/godog/issues/373).
-
-### Godog
-
-````shell
-go get github.com/cucumber/godog/cmd/[email protected]
-````
-### Cucumber HTML Reporter
-
-It's written in JavaScript and requires `npm` and `node` to be available on your machine.
-
-```shell
-npm install cucumber-html-reporter --save-dev
-```
-
-### Cucumber Multi Reporter
-
-Again, JavaScript, see above:
-
-```shell
-npm install multiple-cucumber-html-reporter --save-dev
-```
-
-
-## Usage of Development Tools
-
-I squeezed the required commands into the files `create-cucumber-report.sh`
-and `create-detailed-cucumber-report.sh`.
-
-### Godog
-
-```shell
-godog --format cucumber:test-results-results/cucumber-report.json
-```
-
-Notes: 
-
-* godog requires features and scenarios to be written in a `features` directory.
-* the `--format` switch can take a file and/or directory name
-
-
-### Cucumber Report
-
-```shell
-node ./assets/simple-cucumber-report.js
-```
-
+When creating PDF documents, you often need to add page numbers, headers, footers, or combine multiple PDF files into a single file.
+PDFminion can do that for you - from a terminal and the command line, on MacOS, Linux and Windows platforms.

changelog.md

@@ -1,5 +1,5 @@
 ## PDFminion version history
-
+0.3.1 Nov 16th 2024: refactored repository layout, fixed wrong output
 0.3.0 better structure, minimal main package, moved logic to process.go
 0.2.5 fixed nasty bug in numbering
 0.2.3 add --force flag to allow existing target directory

documentation/adr/.adr-dir

@@ -0,0 +1 @@
+.

documentation/adr/0001-use-adrs.md

@@ -0,0 +1,46 @@
+# 1. Use-ADRs
+# Architecture Decision Record: Using ADRs for Technical Documentation
+
+## Status
+Accepted
+
+## Date: 2024-11-18
+
+## Context
+We need a sustainable way to document technical decisions that:
+- Captures the context and reasoning at the time of decision
+- Is easy to maintain alongside code
+- Provides historical context for future maintainers
+- Supports clear communication within the team
+
+## Decision
+We will use Architecture Decision Records (ADRs) as our primary means of documenting significant technical decisions.
+
+## Format
+Each ADR will be:
+- Written in Markdown
+- Stored in `/documentation/adr` directory
+- Named using pattern: `NNNN-title-with-dashes.md`
+- Include sections: Status, Date, Context, Decision, Consequences
+
+## Reasons
+
+1. **Time-Stamped Context**
+- Captures why decisions were made at a specific point in time
+- Helps future maintainers understand historical choices
+
+2. **Version Control Integration**
+- ADRs live with the code
+- Changes tracked in git
+
+
+### Cons
+1. **Maintenance Required**
+- Must be kept up to date
+- Requires discipline to create consistently
+
+
+## Notes
+- ADRs are immutable once accepted
+- Superseded decisions should be marked as such
+- Not every decision needs an ADR - focus on significant architectural choices

documentation/adr/0002-use-make-as-build-tool.md

@@ -0,0 +1,107 @@
+# 2. Use-make-as-build-tool
+
+## Status
+Accepted
+
+## Date
+2024-11-18
+
+## Context
+We needed to choose a build tool for our Go application PDFminion that would handle:
+- Cross-platform compilation
+- Multiple build targets
+- Release packaging
+- Installation/uninstallation
+- Development workflows
+
+The main alternatives considered were:
+- Make
+- Shell scripts
+- Go's built-in build commands
+
+## Decision
+We decided to use Make as our primary build tool.
+
+## Reasons
+
+### Pros
+1. **Ubiquity**
+- Make is installed by default on most Unix-like systems
+- Well-understood by most developers
+- Extensive documentation available
+- Long history of reliability
+
+2. **Platform Independence**
+- Works on all major platforms (Linux, macOS, Windows via WSL)
+- Consistent behavior across environments
+
+3. **Dependency Management**
+- Built-in dependency tracking
+- Efficient rebuilds (only rebuilds what's necessary)
+- Clear visualization of build dependencies
+
+4. **Simplicity**
+- Declarative syntax
+- No additional dependencies needed
+- Easy to maintain and modify
+- Self-documenting through target names
+
+5. **Flexibility**
+- Can execute any shell command
+- Easy to add new targets
+- Supports both simple and complex build processes
+- Can integrate with other tools seamlessly
+
+
+### Cons
+1. **Windows Compatibility**
+- Requires WSL or MinGW on Windows
+- May create friction for Windows developers
+
+2. **Syntax**
+- Tab-based syntax can be error-prone
+- Learning curve for complex features
+- Limited string manipulation capabilities
+
+3. **Error Handling**
+- Basic error handling capabilities
+- Can be verbose for complex error scenarios
+
+4. **Debugging**
+- Limited built-in debugging facilities
+- Can be hard to troubleshoot complex makefiles
+
+## Consequences
+
+### Positive
+1. **Development Workflow**
+- Simple commands like `make mac` or `make release`
+- Easy to remember and use
+- Quick to execute
+- Consistent across team members
+
+2. **Maintenance**
+- Single file (Makefile) contains all build logic
+- Easy to add new targets and modify existing ones
+- Version control friendly
+- Self-documenting
+
+3. **Integration**
+- Easy integration with CI/CD pipelines
+- Works well with existing Go tools
+- Can be extended with shell scripts if needed
+
+### Negative
+1. **Team Requirements**
+- Team members need basic Make knowledge
+- Windows developers need additional setup
+- May need documentation for complex targets
+
+2. **Scaling**
+- Complex build processes may become hard to maintain
+- Limited modularity compared to modern build tools
+- May need to supplement with scripts for complex tasks
+
+## Notes
+- Maintain clear documentation of available make targets
+