Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[Proposal] Enable Lombok.toBuilder annotation flag in ResourceModel template

Aperta
#331 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
45/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
java
Ambito
tooling

Direzione di ricerca

Iniziate da python/rpdk/java/templates/init/guided_aws/ResourceModel.java, collegato nell’issue, e analizzate come vengono assemblate le annotazioni di ResourceModel generato. Stabilite se toBuilder debba essere abilitato per impostazione predefinita o esposto come flag dello schema, quindi verificate che i modelli Java generati supportino il workflow di copia tramite builder richiesto.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Dear team,

I wonder if you folks would have any concerns about enabling toBuilder attribute for Lombok @Builder by default or with an additional schema flag?

At the moment, ResourceModel template generates non-parametrized @Builder: https://github.com/aws-cloudformation/cloudformation-cli-java-plugin/blob/master/python/rpdk/java/templates/init/guided_aws/ResourceModel.java#L20

One of the reasons I would like to see this flag enabled is a significant simplification of overriding massive resource model definitions in testing, especially in testing an UpdateHandler.

Here is an example:

public class AbstractTestBase {
  protected static final ResourceModel MODEL_BEFORE;
  protected static final ResourceModel MODEL_AFTER;

  static {
    MODEL_BEFORE = ResourceModel.builder()
      .foo("foo-before")
      .bar("bar-before")
      .baz("baz-before")
      .build();
    MODEL_AFTER = ResourceModel.builder()
      .foo("foo-before")
      .bar("bar-before")
      .baz("totally-different-baz")
      .build();
  }
}

Assume I'm using these models in UpdateHandler test suite. If the update flow has a broad branching based on model attribute invariants, one has to initiate separate model instances for each branch case. It's completely fine for a 5-10 attribute models, but the burden of carrying things around grows once one has to deal with a 30-50 attribute model.

Having toBuilder = true enabled in ResourceModel definition would let one define models like

public class AbstractTestBase {
  protected static final ResourceModel MODEL_BEFORE;
  protected static final ResourceModel MODEL_AFTER;

  static {
    MODEL_BEFORE = ResourceModel.builder()
      .foo("foo-before")
      .bar("bar-before")
      .baz("baz-before")
      .build();
    MODEL_AFTER = MODEL_BEFORE.toBuilder()
      .baz("totally-different-baz")
      .build();
  }
}

In fact, being able to override a static model locally within the current test case scope is even better, it could look like:

public class UpdateHandlerTest extends AbstractTestBase {
  //...
  public void handleRequest_SimpleSuccess() {
    final ResourceModel modelWithUpdatedBaz = MODEL_BEFORE.toBuilder()
      .baz("totally-different-baz")
      .build();
      //...
  }
}
Lingua principale
Java
Stelle
30
Fork
48
Metriche di merge delle PR
Nessuna PR unita negli ultimi 30g

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di aws-cloudformation/cloudformation-cli-java-plugin

Tutte le issue di aws-cloudformation/cloudformation-cli-java-plugin

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.