Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
#331 0 comentários 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
3/5
Tempo estimado
1-2 dias
Facilidade para iniciantes
45/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Estagnada
Stack de tecnologia
java
Domínio
tooling

Direção de pesquisa

Comece por python/rpdk/java/templates/init/guided_aws/ResourceModel.java, vinculado na issue, e examine como as anotações de ResourceModel gerado são montadas. Determine se toBuilder deve ser habilitado por padrão ou exposto como uma flag de schema e, em seguida, verifique se os modelos Java gerados oferecem suporte ao workflow de cópia com builder solicitado.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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();
      //...
  }
}
Linguagem predominante
Java
Estrelas
30
Forks
48
Métricas de merge de PRs
Nenhum PR com merge em 30d

Guia de contribuição

Abrir o guia de contribuição

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de aws-cloudformation/cloudformation-cli-java-plugin

Todas as issues de aws-cloudformation/cloudformation-cli-java-plugin

Issues semelhantes

Mais issues de Java

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.