Is there an existing issue for this?

• I have searched the existing issues

Is there a StackOverflow question about this issue?

• I have searched StackOverflow

What happened?

Problem:

An error occurs when configuring the mavenPublishing extension for a plugin project using the winds plugin. The error message states that the value for the groupId property with the key "groupId$plugin" is final and cannot be modified.

Affected Code:

@Suppress("UnstableApiUsage")
pom { mavenPom ->
  metadata.artifactDescriptor?.let { dependencySpec ->
    coordinates(
      groupId = dependencySpec.group,
      artifactId = dependencySpec.artifactId,
      version = dependencySpec.version.toString(),
    )
  }

  metadata toPom mavenPom
}

Expected Behavior:

The groupId property for the plugin project's mavenPublishing configuration should be set dynamically based on the dependencySpec.group value. This allows plugins to inherit the group ID from their parent project, leading to consistent group identification across the project structure.

Actual Behavior:

The code attempts to modify the groupId property with the key "groupId$plugin", which is likely a final property within some framework or library. This modification is not allowed, resulting in the configuration failure.

Steps to Reproduce:

1. Create a project structure using the winds plugin with a plugin project.
2. Attempt to configure the mavenPublishing block in the plugin project as shown in the provided code snippet.
3. Observe the build error during project configuration.

Environment:

• Kotlin version: 1.9.22
• Gradle version: 8.2
• Winds plugin version: 1.0.0-beta03

Relevant logcat output

* Exception is:
org.gradle.api.ProjectConfigurationException: A problem occurred configuring project ':examples:plugin'.
	at org.gradle.configuration.project.LifecycleProjectEvaluator.wrapException(LifecycleProjectEvaluator.java:84)
	at org.gradle.configuration.project.LifecycleProjectEvaluator.addConfigurationFailure(LifecycleProjectEvaluator.java:77)
	at org.gradle.configuration.project.LifecycleProjectEvaluator.access$400(LifecycleProjectEvaluator.java:55)
	at org.gradle.configuration.project.LifecycleProjectEvaluator$NotifyAfterEvaluate.run(LifecycleProjectEvaluator.java:255)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:29)
       ...
	at com.vanniktech.maven.publish.MavenPublishBaseExtension.groupId(MavenPublishBaseExtension.kt:191)
	at com.vanniktech.maven.publish.MavenPublishBaseExtension.coordinates(MavenPublishBaseExtension.kt:185)
	at dev.teogor.winds.common.maven.MavenPublishUtilsKt$configureMavenPublishing$2$1.invoke(MavenPublishUtils.kt:42)
	at dev.teogor.winds.common.maven.MavenPublishUtilsKt$configureMavenPublishing$2$1.invoke(MavenPublishUtils.kt:40)
	at dev.teogor.winds.common.maven.MavenPublishUtilsKt.configureMavenPublishing$lambda$1$lambda$0(MavenPublishUtils.kt:40)
	at org.gradle.api.publish.maven.internal.publication.DefaultMavenPublication.pom(DefaultMavenPublication.java:272)
	at com.vanniktech.maven.publish.MavenPublishBaseExtension$pom$1$1.invoke(MavenPublishBaseExtension.kt:251)
	at com.vanniktech.maven.publish.MavenPublishBaseExtension$pom$1$1.invoke(MavenPublishBaseExtension.kt:250)

Code of Conduct

• I agree to follow this project's Code of Conduct

Is there an existing issue for this?

• I have searched the existing issues

Describe the problem

This issue aims to improve the naming convention for the setBomOptions function within the codebase.

Describe the solution

The function is designed to configure options related to the Bill of Materials (BoM) module, but the current naming might not accurately reflect its purpose. The goal is to find a more descriptive and intuitive name that clearly indicates its role in setting configurations specific to BoM modules. This improvement will enhance code readability and maintainability, ensuring a more intuitive and clear function name for developers working with BoM configurations.

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Is there an existing issue for this?

• I have searched the existing issues

Is there a StackOverflow question about this issue?

• I have searched StackOverflow

What happened?

Some modules applying the kotlin-dsl in the project are misconfigured, leading to issues with proper functionality and performance.

Details:
Certain modules utilizing the kotlin-dsl within the project exhibit misconfiguration, causing operational discrepancies and potentially affecting the overall performance and behavior. The misconfiguration details can include improper property settings, incorrect dependencies, or other misaligned configurations within the Kotlin DSL structure. As a result, this has led to unexpected errors and difficulties in module functioning.

Expected Behavior:
Modules utilizing kotlin-dsl should be correctly configured and aligned with the Kotlin DSL standards, ensuring they operate smoothly and harmoniously within the project structure.

Impact:
The misconfiguration of modules using kotlin-dsl could lead to runtime issues, build errors, or other undesired behavior, which may impact the project's functionality and performance.

Note:
This issue aims to address and rectify the misconfigured modules to ensure they align with proper Kotlin DSL configurations, thus optimizing the modules' performance and contributing to the overall efficiency of the project.

Relevant logcat output

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Is there an existing issue for this?

• I have searched the existing issues

Is there a StackOverflow question about this issue?

• I have searched StackOverflow

What happened?

The bomMd function in the project contains a conditional statement that checks for a boolean flag true and always writes default content to the file regardless of the flag's value. This flag appears to be redundant and can be removed for cleaner code.

Code Snippet:

fun bomMd(
  inputDir: File,
  bomModule: ModuleDescriptor,
  modules: List<ModuleDescriptor>,
  includeOwner: Boolean,
  asModule: Boolean,
) {
  val file = File(inputDir, "index.md").also { file ->
    if (!file.exists() || true) { // Redundant flag `true`
      file.writeText(
        buildString {
          append(bomMdDefault)
        },
      )
    }
  }
}

Proposed Change:

Remove the true flag from the conditional statement and simplify it to:

if (!file.exists()) {
  // ... write default content ...
}

This change ensures the default content is only written if the file doesn't already exist.

Additional Notes:

• Consider mentioning the potential impact of removing the flag (if any).
• If there's a specific reason for the current behavior, it might be helpful to document it within the code or the issue description.

Relevant logcat output

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Is there an existing issue for this?

• I have searched the existing issues

Is there a StackOverflow question about this issue?

• I have searched StackOverflow

What happened?

When publishing a Gradle project to Maven Central, it is mandatory to include a license in the project's POM file. This ensures that users of the project are aware of the terms under which they can use the software.

The current implementation of the licenses block in the build.gradle file does not guarantee that a license will be included in the POM. The code checks if the mavenPublish.licenses property is not null, and if it is, it converts it to a LicenseSpec object and sets it as the mavenPomLicenseSpec. However, if the mavenPublish.licenses property is null, the code throws a RuntimeException without providing any guidance on how to fix the problem.

This behavior can lead to situations where the project is published to Maven Central without a license, which is a violation of the Maven Central guidelines.

Relevant logcat output

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Is there an existing issue for this?

• I have searched the existing issues

Is there a StackOverflow question about this issue?

• I have searched StackOverflow

What happened?

The following error has been encountered while utilizing afterEvaluate in the Gradle build scripts: "Cannot run Project.afterEvaluate(Action) when the project is already evaluated." This error typically occurs when the afterEvaluate method is applied to a project that has already been evaluated.

This issue arises from attempting to run afterEvaluate on an already evaluated project in Gradle, resulting in the mentioned error message. It's crucial to ensure the correct usage of the afterEvaluate block and understand the sequence of execution in the Gradle build lifecycle.

Relevant logcat output

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Is there an existing issue for this?

• I have searched the existing issues

Is there a StackOverflow question about this issue?

• I have searched StackOverflow

What happened?

This issue reports a bug in the displayName getter of the MavenPublish interface. When the getter calls the gets function with a selector that references displayName itself, it creates an infinite loop.

Steps to Reproduce:

1. Provide a minimal reproducible example demonstrating the infinite loop. Include relevant code snippets and dependencies.
2. Explain the expected behavior and how the current implementation deviates from it.

Expected Behavior:

• The displayName getter should return a human-readable name for the MavenPublish instance, potentially constructed from other properties like name, version, etc.
• Calling gets within the getter with appropriate selectors should retrieve individual elements contributing to the display name without causing recursion.

Actual Behavior:

• An infinite loop occurs when the displayName getter calls gets with a selector referencing itself.

Additional Information:

• Please mention the version of the library or codebase where this bug is identified.
• If possible, share any relevant logs, error messages, or stack traces encountered.
• Suggest potential workarounds or fixes if you have any insights.

Impact:

This bug can prevent the correct display name from being retrieved and potentially lead to issues downstream if the name is used in other parts of the application.

Relevant logcat output

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Is there an existing issue for this?

• I have searched the existing issues

Is there a StackOverflow question about this issue?

• I have searched StackOverflow

What happened?

Problem:

The PublishingOptions configured within the winds extension block aren't being propagated correctly to child subprojects. This prevents child projects from inheriting those publishing settings.

Affected Code:

winds {
  // ... other configurations

  publishingOptions {
    publish = false
    enablePublicationSigning = true
    optInForVanniktechPlugin = true
    cascadePublish = true
    sonatypeHost = SonatypeHost.S01
  }

  // ... other configurations
}


### Relevant logcat output

_No response_

### Code of Conduct

- [X] I agree to follow this project's Code of Conduct

Is there an existing issue for this?

• I have searched the existing issues

Is there a StackOverflow question about this issue?

• I have searched StackOverflow

What happened?

The Developer interface, which defines essential information about project contributors, should incorporate an email field to provide comprehensive developer details. This enhancement aims to augment the existing information with a developer's email.

Proposed Changes:

• Add an email field to the Developer interface.
• Update the DeveloperImpl data class to include the email field.
• Modify the existing implementations of the Developer interface to include the email information.

Context:
The Developer interface is utilized to gather information about contributors and key individuals involved in a project. The addition of the email field would be beneficial for comprehensive developer details, making it more informative and inclusive.

Acceptance Criteria:

• The Developer interface should contain an email field.
• The DeveloperImpl data class should be updated to reflect the changes.
• Any dependent classes or implementations should be updated to include the email field as well.

Adding the email field ensures the interface provides a complete profile of developers contributing to the project.

Relevant logcat output

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Is there an existing issue for this?

• I have searched the existing issues

Is there a StackOverflow question about this issue?

• I have searched StackOverflow

What happened?

Issue Summary

The project configuration contains empty or unspecified dependencies, leading to potential issues during compilation and runtime.

Problem Details

The specified dependencies section in the project configuration is incomplete. It contains entries with empty values for group, artifact, and version. These incomplete dependency entries might lead to compilation errors or runtime issues due to the missing or unspecified library information.

Impact

Empty dependencies can disrupt the build process, cause compilation failures, or result in runtime issues due to undefined or missing library references.

Proposed Solution

This issue should be addressed by ensuring that all dependencies are accurately specified and that no essential fields like group, artifact, or version are left empty or unspecified. Ideally, replace the placeholder or unspecified values with the correct information for each dependency.

It's important to review the project configuration to fill in the missing details for each dependency entry.

Affected Sections

• Dependencies section:
  • implementationType: api, compileOnly
  • group: ""
  • artifact: "unspecified"
  • version: ""

Relevant logcat output

No response

Code of Conduct

• I agree to follow this project's Code of Conduct