Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

intent: optional uses: - a module dependency whose relations, checks and reports degrade when the owner model is absent from the application

Abierto
  • ¿Algo no está bien?
#7,979 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
java
Área
backend, build-system

Línea de trabajo

Start with the engine-intent uses: and cross-model section in intent-dsl-features.md, then trace how base-expenses resolves projects in expenses/expenses.intent. Map the generated relations, checks, reports and dependency packaging that the issue names. Done when the acceptance cases pass with and without projects, and the optional owner is absent from the using jar's hard dependencies.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Problem

A uses: entry is all-or-nothing. When a model declares uses: - { model: projects }, the relation becomes a cross-model projection resolved against the owner's .model, and the AOT module jar depends on the owner's jar. So every application that ships the using module must also ship the owner module and the owner's whole transitive closure, even when the application never needs the feature the relation exists for.

There is no way to say "use this model if it is in the application, and degrade cleanly when it is not". The current engine-intent docs (master 1692135a, the uses: / cross-model section of intent-dsl-features.md) describe none.

Concrete case (BusinessIntents)

  • base-expenses (expenses/expenses.intent) declares uses: - { model: projects } for one feature: billable expense lines. It uses that dependency in three places:
    • ExpenseClaimItem.Project (cross-model manyToOne)
    • requiredWhen Project when "billable == true"
    • the ExpensesByProject report (dimensions [Project, billable])
  • The HR application (solution-hr: employees, vacations, payroll, expenses) does not use projects at all. Because of this one relation, it must still ship projects, which in turn uses sales-invoices, customers, customer-payments, products and uoms.
  • The module closure goes from 10 modules to 16. The image's module-assembly guard enforces the full closure: the application build failed until the six jars were added (hr 22/16).

Ask

An optional uses: entry, e.g. uses: - { model: projects, optional: true }, with defined behaviour when the owner model is absent from the application.

When the owner model is present, it behaves exactly like today.

When the owner model is absent:

  1. Generation and AOT packaging of the using module do not require the owner's .model or jar. The owner is a provided, optional dependency, not a compile/runtime one, so the application assembly guard does not demand it.
  2. Relations to the optional model are not emitted, or are emitted inert:
    • no projection entity;
    • no picker;
    • the FK column may still exist, so data survives moving between applications.
  3. Constructs that name such a relation are dropped, not failed: checks/requiredWhen on it, report dimensions/columns, roll-ups and generates from or to it. The generator reports them as warnings.
  4. Generated UI hides the fields and reports that depend on the absent model.

The parser must refuse an optional uses: whose relations are required: true, or that are part of the entity's identity (unique keys, numbering per:). Such a relation cannot be absent.

Acceptance

The same base-expenses intent is used in two applications:

  • in an application without projects, it generates, packages and boots, the expense-claim flow works, and there is no Project field and no ExpensesByProject report;
  • in an application with projects, it behaves as today.

The using module's jar no longer lists the optional owner as a hard dependency.

Lenguaje dominante
Java
Estrellas
278
Forks
97
Merge medio
19 h 30 min
PR fusionados (30 d)
242

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de eclipse-dirigible/dirigible

Todos los issues de eclipse-dirigible/dirigible

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.