[
https://issues.apache.org/jira/browse/OPENNLP-1924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18112909#comment-18112909
]
ASF GitHub Bot commented on OPENNLP-1924:
-----------------------------------------
krickert opened a new pull request, #182:
URL: https://github.com/apache/opennlp-addons/pull/182
The add-ons work so far, presented for review with `main` as the base.
Earlier pull requests (#177, #179) used `OPENNLP-1924-canary-addon` as the
base, so `main` has not yet seen the full picture in one diff.
## What is here
**Coordinates.** Modules publish under `org.apache.opennlp.addons`. Core
dependencies remain `org.apache.opennlp`. Before this change the canary build
resolved all modules to `org.apache.opennlp`.
**Naming.** Module and artifact names drop the `-addon` suffix. Java package
names describe the feature, not the repository hosting it, so a component that
later moves into core needs no package rename.
**Modules removed.** Morfologik, because core provides the same classes,
including the OPENNLP-1905 correction. Also JWNL.
**Manual.** A new `opennlp-addons-docs` module, DocBook in the same format
as the main repository, with chapters for usage, the module catalog, building
from source, and contributing an add-on.
**Build.** OpenNLP Checkstyle rules, forbidden API checks, a RAT license
header check, and a dependency license report. Artifact deployment and release
SCM pushes remain disabled.
**README.** Aligned with the main repository: matching heading style, a
license badge, `Useful Links`, an `Overview` module list in the format the core
README uses, `Getting Started` with Maven and Gradle, `Building`, and
`Contributing`. The transitional notes about this branch were removed.
## dev-TEMP
The proposal text behind this work used to be a chapter of the manual,
titled "OpenNLP Add-ons Proposal", opening with a status line and closing with
a "Consensus requested" section. A position under discussion does not belong in
a user manual, so the durable rules moved into the "Contributing an Add-on"
chapter and the remainder moved to `dev-TEMP/`. That directory is working
material for the dev list and gets deleted before a release.
## Open for the dev list
- **Review threshold.** This repository's `.asf.yaml` sets no
`required_approving_review_count`, while `apache/opennlp` requires one approval
plus the `asf-allowlist-check` status check. Matching core would be a single
`.asf.yaml` edit, plus porting that workflow if the status check is wanted here
too.
- **Security.** This repository has no `SECURITY.md`. Core publishes one
with an explicit trust model. Add-ons need to say how they relate to it, since
an add-on may bundle data, download user-selected resources, or delegate to
native code.
Background for both is in `dev-TEMP/addons-proposal.md`.
## Verification
```
mvn clean verify -Dopennlp.forkCount=1
```
Checkstyle, forbidden API checks, RAT, the dependency license report, and
the DocBook HTML and PDF build all pass. Tests are 23 in `japanese`, 0 failures
and 0 errors, the full set the reactor currently contains.
> ADDONs - refactor + publish setup
> ---------------------------------
>
> Key: OPENNLP-1924
> URL: https://issues.apache.org/jira/browse/OPENNLP-1924
> Project: OpenNLP
> Issue Type: Epic
> Reporter: Kristian Rickert
> Assignee: Kristian Rickert
> Priority: Major
>
> After a discussion in the mailing list, we are expanding the addons repo
> more formally:
> [https://github.com/apache/opennlp-addons]
> This will keep it's original intent but push artifacts to m2. As part of
> this ticket we will come up with an formalize:
> # Boundaries of what belongs in addons vs core vs sandbox
> ** sandbox - unpublished, experiemental
> ** addons - published + maintained
> ** core - core interfaces and some reference implementations of those
> interfaces
> # Release train for addons
> # Versioning scheme
> # Compatibility rules (we pretty much said that if you build it here it
> should be compatible with the latest core)
> # Retirement rules (given it should have a higher cadence of features than
> core, decide some basic guidelines and rules of retiring defunct code /
> outdated)
> # "Graduation" rules (a highly downloaded / popular / dependent jar that
> should become part of core)
> # API addition rules - should a new feature go into add-ons, when to discuss
> bringing the API into core but leave the functionality/instance in addons.
> .. and anything else we can have on the discussions
> Please note: this has been spec'ed over email so far- we expect the
> requirements to change based on the team's full review.
> We'll keep this ticket open until all tasks related to it are completed.
> Here are some of the good examples of what we have went over so far:
> * Model-required features
> * a new provider for already existing functionality (tokenizer, embeddings,
> chunking, etc)
> * components that are in development but highly experiemental. (i.e. the
> java implementation of model2vec, turboquant)
> Finally - dependencies would only be bought in very rare instances. Even in
> those cases, if one is added, it may never go into core.
> There are a lot more points to add, and we'll comment/edit this story to
> represent those changing reqirements.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
