Nenjim Journals
+Implementation status: Journal format version 1, the immutable Java model,
+ internal strict parser, read-only JournalService, and explicitly refreshed lifecycle
+ JournalServiceManager are implemented. Contexts, resolution, classloading, downloading, publishing,
+ synchronization, watching, signatures, and license filtering remain future work.
2. Versioning and Dependencies
-Nenjim uses a method where packages are named with the version number directly in the package name. However, - this is managed in so-called journals outside of the actual code, so that the Java code itself does not depend - on Nenjim.
-This ensures that developers do not have to worry about version conflicts, as each dependency refers precisely - to the version it needs. The system ensures that all necessary modules are available and kept up to date in - the background.
+One Journal per artifact
+A Journal describes exactly one artifact. API, test, and implementation artifacts therefore have independent
+ Journals and chains. Roles such as API or implementation are not stored as a TYPE.
<GROUP>-<MODULE>-<ARTIFACT>
+com_r35157_nenjim-hubd-api
+com_r35157_nenjim-hubd-api:1.0.3The three metadata components identify the chain; there is no separate JOURNAL_ID.
3. Updates and Security
-Nenjim automatically monitors for updates through what are called journals. If a security vulnerability is - discovered in a particular version, the developers update the journal, and all NenjimHubs will automatically - fetch the new secure version, or downgrade to a previous version until an update is ready. In this way, - updates are distributed quickly and efficiently throughout the entire network.
+Complete immutable snapshots and history
+Every Journal revision is a complete worldview of the artifact and all releases known in that revision. It is + not a delta and inherits nothing implicitly. A later snapshot may change metadata, add or remove releases, + correct release knowledge, alter dependencies or policy, or be a semantic no-op.
+The genesis omits PREVIOUS_JOURNAL_DIGEST. Each successor names the SHA-256 digest of the
+ predecessor's exact UTF-8 text, including whitespace and line endings. A chain has one genesis and one head;
+ missing predecessors, forks, cross-artifact links, and non-increasing Journal versions are invalid.
JOURNAL_VERSION is when the worldview was published. PUBLISHED_AT is when an artifact
+ release was published. Both use uuuuMMddHHmmssSSS'Z', but historical knowledge is selected from
+ the Journal chain rather than by filtering the newest snapshot on release publication time.
4. Payment System and Integration with AssetAZ
-To support payment for software packages, Nenjim integrates with AssetAZ. This means that developers can choose - to receive payment for their packages either as a one-time fee, as a subscription, or per use. All transactions - are handled via cryptocurrency.
+Metadata and release content
+DESCRIPTION is mandatory single-quoted text. INFORMATION_URI is optional single-quoted
+ metadata and must decode to a non-empty absolute URI. Format 1 does not restrict schemes: HTTPS, FTP, IPFS,
+ and other syntactically valid schemes are accepted without opening or interpreting their content.
Every exact major.minor.patch release has a mandatory single-quoted LICENSE, a
+ publication timestamp, non-negative byte size, and one or both supported content identities:
+ sha256 and CIDv1 (cid1). License text is preserved as free text; no vocabulary,
+ compatibility decision, or filtering is applied.
5. Backing Store and Flexibility
-Nenjim provides complete flexibility regarding where data is stored. This can be via IPFS, in a local folder, - or even in a database. The system is designed to be so flexible that developers can choose the solution that - best fits their needs.
+Version expressions
+| Expression | Meaning |
|---|---|
1.0.3, [1.0.3] | The same exact release. |
[1.0] | Every stable 1.0.x release; not exact 1.0.0. |
[1.0.3-->1.0.7] | A closed range including both exact endpoints. |
[1.0-->1.2) | Includes 1.0.x and 1.1.x, excluding the complete 1.2.x series. |
[1.0--> | Starts at 1.0.0 and stops before 2.0.0. |
Comma-separated expressions form a union. Boundaries require at least major and minor. Mathematical + comparison syntax, incomplete bare exact versions, prereleases, build metadata, empty elements, and reversed + or empty ranges are rejected.
-6. Standardized and Automated Package Management
-One of the major advantages of Nenjim is that users no longer have to manually search for dependencies on the - Internet. Nenjim uses a standardized method to automatically find and download packages, for example via IPFS. - This means that all packages are easily accessible and can be retrieved in a consistent manner, which saves - time and ensures a more streamlined experience for both developers and users.
+Dependencies
+Dependencies belong to individual releases and always have an explicit scheme. Format 1 implements only the
+ nenjim: scheme; Maven resolution and unknown schemes are not silently accepted.
DEPENDS_ON=nenjim:com_r35157_nenjim-hubd-api=[1.0-->
+EXCLUDES=nenjim:com_r35157_nenjim-hubd-api=1.0.5:'Known incompatibility'
+PREFERRED=nenjim:com_r35157_nenjim-hubd-api=1.0.3:'Built together'DEPENDS_ON is the hard base set. EXCLUDES removes hard-invalid combinations for that
+ relationship. PREFERRED is a hint and must remain a subset of
+ DEPENDS_ON - EXCLUDES. Repeated rules form unions while each line and description remains
+ inspectable. The Journal layer represents these rules but does not resolve a graph.
7. Importance of Semantic Versioning
-For Nenjim to function optimally, it is essential that all packages follow the principles of semantic versioning. - This means that each version of a package clearly indicates whether it is a minor update, a bug fix, or a major, - potentially incompatible change. By adhering to these versioning rules, Nenjim can easily and safely handle - updates and ensure that the system is always stable and fully functional.
+Artifact policy
+-
+
BLACKLISTis a hard global prohibition.
+ DISCOURAGEDis a negative hint; a matching release remains selectable.
+ RECOMMENDEDis a positive hint naming one exact release in the same snapshot.
+
Overlaps are valid and hard rules win over hints. A future resolver should seek a valid graph containing as + many compatible recommendations as possible. The highest valid version is a fallback, not an unconditional + rule, so future convergence may move from a higher local version to a lower recommended version.
-8. Integration of Plugins and Central Registry
-One of the unique advantages of using Nenjim is that applications can communicate directly with the NenjimHub to - find and integrate new plugins. Through a global registry, applications can search for plugins that implement - specific interfaces of certain versions, making it easy to extend their functionality. This flexibility allows - users to add new features or improvements, such as codecs for a video player, while also being able to see the - cost of different plugins.
+Strict parsing and immutable model
+FORMAT_VERSION=1 must be the first actual entry. Blank lines and comments beginning with
+ # are accepted, while a hash inside single quotes is data. Quoted values support escaped quotes
+ (\') and backslashes (\\). Unknown, malformed, duplicate, misplaced, empty, or
+ semantically inconsistent content fails with source name, one-based line number, and a reason. Validation is
+ complete before service state changes. Returned objects and collections are immutable and defensively copied.
9. Integration with AssetAZ and Economic Activity
-Nenjim is designed to be an open and free tool for managing dependencies, versioning, and the execution of - software packages. The system can be used without any form of payment, and all basic features—such as local - injection, dependency analysis, and dynamic classloading—are available without any economic interaction - required.
-However, in cases where the user wants to make their software publicly available to others—for example, by - propagating packages to a registry or selling their software—a small economic cost will be associated with - these actions.
-To support this kind of activity, Nenjim uses the digital AssetAZ crypto token. This token is part of the - broader AssetAZ platform and enables micropayments in connection with software distribution.
-By using a dedicated token, a decentralized and transparent settlement mechanism is achieved, while also - creating a natural connection to AssetAZ, where the entire economic infrastructure is anchored.
-It is important to note that this integration does not limit the use of Nenjim in regular, non-commercial - contexts, but as soon as you wish to publish and distribute software for commercial purposes—and thus also - participate in registration and transaction logic—it requires the use of AssetAZ and its token.
-In this way, a sustainable ecosystem is created where it is free to use and experiment, but there is a small - cost for commercial activity.
+Service, ServiceManager, packages, and disk layout
+A Service is the public domain API used by applications and other services during ordinary
+ operation. JournalService is therefore filesystem-independent and read-only: it exposes current
+ and historical Journal queries without lifecycle, paths, refresh, parser, or mutation operations.
A ServiceManager is the lifecycle and administrative API owned by a composition/lifecycle owner.
+ JournalServiceManager starts and stops the Journal service, reports its normalized data root,
+ performs explicit refresh, and exposes JournalService only after complete successful initial
+ loading. Its reference implementation reads UTF-8 runtime files chronologically and validates directory and
+ filename placement. It creates, overwrites, and deletes nothing.
JournalServiceImpl keeps exact-text SHA-256 identity, chain state, idempotency, conflicts, forks,
+ and atomic ingestion internal. The public package contains only the two central interfaces; composed models,
+ value types, and exceptions live under .model, .valuetypes, and
+ .exception, while parser, ingestion, chain state, and filesystem loading live under
+ .impl.ref without leaking through public signatures.
data/nenjim/journals/
+└── <artifact-coordinate>/
+ ├── <journal-version>.journal
+ └── <journal-version>.journal.exampleOnly .journal files are runtime input. Version-controlled .journal.example files are
+ documentation and are ignored by the service.