Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
#331 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
45/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
À l'abandon
Stack technique
java
Domaine
tooling

Piste de recherche

Commencez par python/rpdk/java/templates/init/guided_aws/ResourceModel.java, lié dans l’issue, et examinez comment les annotations de ResourceModel généré sont assemblées. Déterminez si toBuilder doit être activé par défaut ou exposé comme un indicateur de schéma, puis vérifiez que les modèles Java générés prennent en charge le workflow de copie via builder demandé.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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();
      //...
  }
}
Langage dominant
Java
Étoiles
30
Forks
48
Métriques de merge des PR
Aucune PR mergée en 30 j

Guide de contribution

Ouvrir le guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de aws-cloudformation/cloudformation-cli-java-plugin

Toutes les issues de aws-cloudformation/cloudformation-cli-java-plugin

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.