{"id":22515319,"url":"https://github.com/scijava/pom-scijava-base","last_synced_at":"2025-10-16T04:41:07.919Z","repository":{"id":44659825,"uuid":"72131582","full_name":"scijava/pom-scijava-base","owner":"scijava","description":"Low-level base POM for all SciJava-based software","archived":false,"fork":false,"pushed_at":"2025-02-13T15:19:27.000Z","size":729,"stargazers_count":3,"open_issues_count":3,"forks_count":4,"subscribers_count":8,"default_branch":"main","last_synced_at":"2025-03-28T02:18:50.981Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"unlicense","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/scijava.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2016-10-27T17:25:46.000Z","updated_at":"2025-02-13T15:19:31.000Z","dependencies_parsed_at":"2024-05-02T21:46:38.827Z","dependency_job_id":"1214f666-a748-4a85-a2f1-1bd6eee381a8","html_url":"https://github.com/scijava/pom-scijava-base","commit_stats":null,"previous_names":[],"tags_count":54,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/scijava%2Fpom-scijava-base","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/scijava%2Fpom-scijava-base/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/scijava%2Fpom-scijava-base/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/scijava%2Fpom-scijava-base/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/scijava","download_url":"https://codeload.github.com/scijava/pom-scijava-base/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":248886324,"owners_count":21177643,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-12-07T03:29:42.042Z","updated_at":"2025-10-16T04:41:02.859Z","avatar_url":"https://github.com/scijava.png","language":null,"readme":"[![](https://img.shields.io/maven-central/v/org.scijava/pom-scijava-base.svg)](https://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.scijava%22%20AND%20a%3A%22pom-scijava-base%22)\n[![](https://github.com/scijava/pom-scijava-base/actions/workflows/build-main.yml/badge.svg)](https://github.com/scijava/pom-scijava-base/actions/workflows/build-main.yml)\n\nThe pom-scijava-base project is a Maven POM that serves as the base for all\nMaven-based SciJava software, including:\n\n| Fiji | ImageJ2 | ImgLib2 | KNIME | LOCI | SCIFIO | SciJava | FLIMLib | Virtual Cell |\n|:----:|:-------:|:-------:|:-----:|:----:|:------:|:-------:|:----------:|:------------:|\n| [![Fiji](https://scijava.org/icons/fiji-icon-64.png)](https://github.com/fiji) | [![ImageJ2](https://scijava.org/icons/imagej2-icon-64.png)](https://github.com/imagej) | [![ImgLib2](https://scijava.org/icons/imglib2-icon-64.png)](https://github.com/imglib) | [![KNIME](https://scijava.org/icons/knime-icon-64.png)](https://knime.org) | [![LOCI](https://scijava.org/icons/loci-icon-64.png)](https://github.com/uw-loci) | [![SCIFIO](https://scijava.org/icons/scifio-icon-64.png)](https://github.com/scifio) | [![SciJava](https://scijava.org/icons/scijava-icon-64.png)](https://github.com/scijava) | [![FLIMLib](https://scijava.org/icons/flimlib-icon-64.png)](https://github.com/flimlib) | [![Virtual Cell](https://scijava.org/icons/vcell-icon-64.png)](https://github.com/virtualcell) |\n\n## pom-scijava-base vs. pom-scijava\n\nIt is encouraged that you _not_ extend this POM directly, and instead\nuse [pom-scijava](https://github.com/scijava/pom-scijava) as parent.\n\n| pom-scijava-base | pom-scijava |\n|:----------------:|:-----------:|\n| \"Low level\" base POM, _without_ dependency version management. Extend pom-scijava-base only if you are a Maven expert, and have good reasons for doing so. | _Friendly_ base POM for SciJava software, _including_ dependency version management. Extend pom-scijava to inherit the unified SciJava [Bill of Materials](https://imagej.net/BOM): component versions which have been tested to work together. |\n\nSee these examples for guidance:\n\n* [ImageJ2 command template](https://github.com/imagej/example-imagej-command)\n* [ImageJ 1.x plugin template](https://github.com/imagej/example-legacy-plugin)\n* [ImageJ2 tutorials](https://github.com/imagej/tutorials)\n\n## Enforcer rules declared in this parent\n\nThe `pom-scijava-base` parent POM declares several\n[enforcer](https://maven.apache.org/enforcer/maven-enforcer-plugin/) rules which\nwe believe make SciJava-based projects more reproducible and more consistent:\n\n* __Plugin versions.__ Out of the box, Maven does not require plugins used to\n  declare a version. But plugin versions must be declared to ensure\n  reproducible builds. Otherwise, the version of Maven core you use at build\n  time will determine which plugin versions are used, and the behavior might\n  differ between builds.\n\n* __No duplicate classes.__ If two dependencies define the same class, then\n  it introduces the possibility of serious class-loading issues. Which version\n  of the class should be chosen? In some scenarios, classes from one part of a\n  certain library may be loaded from dependency `foo`, but classes from a\n  different part of that same library at a _different version_ may be loaded\n  from dependency `bar`. When this happens, difficult-to-understand compiler\n  errors, or even runtime errors, may occur. Best practice is to ensure that\n  all classes come onto the classpath from exactly _one_ source.\n\n* __No too-new dependencies.__ When a project is compiled for Java version X,\n  then it may not use any dependencies which require a version newer than X.\n  Otherwise, your project is lying about needing only version X.\n\n* __No circular dependencies.__ Actually, this is a central rule of Maven. But\n  we configure the Enforcer to explicitly check for it, just to be safe. It is\n  always possible to avoid circular dependencies; if you feel like you need\n  one, you should instead solve it in one of the following ways, depending on\n  how much code is co-dependent:\n    1. Combine the co-dependent artifacts into a single artifact.\n    2. Introduce a third artifact to house the co-dependent code, which depends\n       on the other two artifacts.\n    3. If all else fails, write to the\n       [SciJava list](https://groups.google.com/group/scijava) for help.\n\n* __Reproducible builds.__ This rule means no `SNAPSHOT` dependencies, no\n  `SNAPSHOT` parents, and no `SNAPSHOT` plugin versions. A snapshot version is\n  not immutable, which means that code which depends on a snapshot may build\n  today, but not build tomorrow, if the snapshot is later changed. The best way\n  to avoid this conundrum is to _never depend on `SNAPSHOT` versions_. Snapshot\n  are best used for testing only; they can be used transiently, but their use\n  should never make it onto the main integration branch\n  (e.g., `main` or `master`) of a project. See also\n  [Using snapshot couplings during development](https://imagej.net/develop/architecture#using-snapshot-couplings-during-development).\n\n* __Developer roles.__ SciJava-based projects define developers and\n  contributors with roles matching the\n  [SciJava team roles](https://imagej.net/Team). Doing this is vital for\n  consistency, and for communicating expectations to the community. By being\n  careful about which developers are pledging which sorts of responsibility,\n  the social status of each project becomes much clearer, and which social\n  actions to take in various circumstances becomes a more tractable problem.\n  We have\n  [automated tooling](https://github.com/imagej/imagej.github.io/blob/main/assets/js/maven.js)\n  which can populates a statbox sidebar for any component built on SciJava,\n  including all components of the\n  [ImageJ2 software stack](https://imagej.net/develop/architecture#definitions);\n  this tooling requires SciJava developer roles to be present for sensible\n  results.\n\n* __Required metadata.__ Every SciJava-based project must override key pieces\n  of metadata, including the `name`, `description`, `url`, `inceptionYear`,\n  `organization`, `licenses`, `developers`, `contributors`, `mailingLists`,\n  `scm`, `issueManagement` and `ciManagement` elements, as well as the\n  `license.licenseName` and `license.copyrightOwners` properties.\n  There are several reasons for requiring these overrides:\n    * __Avoid inadvertent inheritance.__ The `pom-scijava-base` POM itself\n      declares all of this metadata for itself (e.g., its `\u003cscm\u003e` block defines\n      where the `pom-scijava-base` source code is managed, and this information\n      is necessary for the tooling which cuts releases of the\n      `pom-scijava-base` POM itself). For better and worse, when extending\n      `pom-scijava-base`, the child POM inherits all of these elements (except\n      for `\u003cname\u003e`, but that is the sole exception in the above list). If the\n      child POM does not override each and every one of these elements, then it\n      will inadvertently inherit the incorrect values from the\n      `pom-scijava-base` parent. Furthermore, due to a quirk/limitation in\n      Maven, if you specify an empty block (e.g., `\u003ccontributors /\u003e`), then the\n      non-empty value from the ancestor will take precedence in the\n      interpolated POM. Hence, we enforce that all of these fields are\n      overridden with _non-empty_ values. See below for advice on how to best\n      override specific metadata fields.\n    * __Present the project's metadata simply and clearly.__ For humans, being\n      able to look at a project POM and clearly see the metadata is very\n      helpful for understanding the project. Whereas when inheritance is\n      involved, the human must be patient enough to dig through the ancestor\n      POMs manually looking for the information, or else knowledgeable enough\n      to know that they should actually use `mvn help:effective-pom` and check\n      the metadata there instead, to know the actual values.\n    * __Make the metadata easier for tooling to consume.__ Maven-based tooling\n      which uses the interpolated POM will be able to extract the correct\n      inherited metadata from a POM, sure. But in many cases, it is much\n      simpler and more natural, especially for Maven non-experts, to code\n      tooling using shell scripts and similar approaches. In those cases, it is\n      much easier if the tooling can simply extract the metadata from the child\n      POM itself and be guaranteed that the values there are the correct ones,\n      without needing to recurse into parent POMs whose contents may be less\n      trivial to inspect.\n    * __Make it easier to maintain license headers in the sources.__ Putting a\n      license blurb at the top of each source file is legal best practice, but\n      it is undeniably a hassle, which is one reason many projects do not\n      bother. But with the `license-maven-plugin`, generating and maintaining\n      these license headers becomes very easy—as long as the `inceptionYear`,\n      `license.projectLicense` and `license.copyrightOwners` values are\n      provided in the POM. At that point, you can just invoke `mvn\n      license:update-file-header license:update-project-license` and your work\n      is done.\n    * __Encourage responsible metadata curation.__ As a project maintainer,\n      _you_ are responsible for your project's metadata. Yes, it is a hassle to\n      specify it. But regardless, you need to understand where (if anywhere)\n      your project lives in SCM, which (if any) system is being used to\n      automatically build it, and so on. You have legal and social obligations\n      to clearly communicate the project license, to clearly document community\n      expectations, to give credit where credit is due, etc.\n\nThe full set of Enforcer rules as of `pom-scijava-base` version 14.0.0 can be\n[seen here](https://github.com/scijava/pom-scijava-base/blob/pom-scijava-base-14.0.0/pom.xml#L831-L926).\n\n### How to override a field with an \"empty\" value\n\nFor some projects, you may have \"empty\" metadata fields, and you may be unsure\nhow best to override those values accordingly. The most common scenarios are:\n\n*   If your project has no contributors, write:\n    ```xml\n    \u003ccontributors\u003e\n      \u003c!--\n      NB: Need at least one element to override the parent.\n      See: https://issues.apache.org/jira/browse/MNG-5220\n      --\u003e\n      \u003ccontributor\u003e\n        \u003cname\u003eNone\u003c/name\u003e\n      \u003c/contributor\u003e\n    \u003c/contributors\u003e\n    ```\n*   If your project has no discussion forum or mailing list, write:\n    ```xml\n    \u003cmailingLists\u003e\n      \u003cmailingList\u003e\n        \u003cname\u003eNone\u003c/name\u003e\n      \u003c/mailingList\u003e\n    \u003c/mailingLists\u003e\n    ```\n    But you are warmly welcome to use the\n    [Image.sc Forum](https://forum.image.sc/) for discussing your project,\n    so instead it is better to write:\n    ```xml\n    \u003cmailingLists\u003e\n      \u003cmailingList\u003e\n        \u003cname\u003eImage.sc Forum\u003c/name\u003e\n        \u003carchive\u003ehttps://forum.image.sc/tag/your-tag\u003c/archive\u003e\n      \u003c/mailingList\u003e\n    \u003c/mailingLists\u003e\n    ```\n    Where `your-tag` is the tag you want to\n    be used when discussing your project.\n*   If your project has no CI, write:\n    ```xml\n    \u003cciManagement\u003e\n      \u003csystem\u003eNone\u003c/system\u003e\n    \u003c/ciManagement\u003e\n    ```\n*   If your project has no issue tracker, write:\n    ```xml\n    \u003cissueManagement\u003e\n      \u003csystem\u003eNone\u003c/system\u003e\n    \u003c/issueManagement\u003e\n    ```\n*   If your project does not live in SCM, then write:\n    ```xml\n    \u003cscm\u003e\n      \u003csystem\u003eNone\u003c/system\u003e\n      \u003curl\u003eNone\u003c/url\u003e\n    \u003c/scm\u003e\n    ```\n    But as an aside, in this case, we strongly encourage you to adopt an SCM;\n    [check yourself before you wreck yourself](https://imagej.net/contribute/distributing).\n\n## Getting help with Maven\n\nFor more information about Maven, see:\n\n* [ImageJ Maven overview](https://imagej.net/develop/maven)\n* [ImageJ Maven FAQ](https://imagej.net/develop/maven-faq)\n","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fscijava%2Fpom-scijava-base","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fscijava%2Fpom-scijava-base","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fscijava%2Fpom-scijava-base/lists"}