Create dedicated Messages API

[Copilot]

• Create new package org.codehaus.plexus.build.messages
• Create MessageType enum for message severity levels (INFO, WARNING, ERROR)
• Create Message class to hold message parameters
• Create MessageBuilder class with builder pattern implementation
• Create Messages interface with clearAll, clear, and build methods
• Create DefaultMessages implementation using BuildContext
• Update README.md to document the new Messages API
• Build and verify the implementation
• Address code review feedback (improve log formatting, clarify INFO to WARNING mapping)
• Address review comments:
  • Make Message constructor package-private
  • Rename methods to shorter names (error, warning, info)
  • Change create() to require message parameter
  • Map INFO to severity 0 (undocumented BuildContext feature)
  • Remove copyright lines per ASF guidelines
  • Add deprecation warnings to BuildContext methods
• Address additional review feedback:
  • Add @deprecated annotations to addMessage and removeMessages
  • Move formatLogMessage logic to Message.toString() for better reusability
  • Keep message.trim().isEmpty() for blank check (Java 8 compatible)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Creaze a dedicated Messages API</issue_title>
<issue_description>Currently we have the BuildContext that it mixing two concerns:

1. Resource Operations (see Provide a new Resources API #76)
2. Creating Messages/Markers that inform the user in an IDE about issues on their files

For the Messages/Markers we even have some outstanding issues:

• Have a way to pass the plugin/id and an error code #57
• Messages must be clearable by an (plugin) id or properties #58
• Rethink deprecation of addError / addWarning and maybe even add addInfo and default implement those #44
• Make SEVERITY a enum? #40
• Please output INFO messages in DefaultBuildContext.addMessage #20
• UsePath instead of File in the API #47
• Due to a lot of parameters that needs to be passed it is always hard to use

due to backward-compatibility we can hardly change them or make any useful evolution.

Because of this we want a new API that is implemented in the following way:

• Create a new package org.codehaus.plexus.build.messages where we have a Messages interface
• Document it in the https://github.com/codehaus-plexus/plexus-build-api/blob/master/README.md#provided-apis section of the readme
• The Messages interface should have a method "clearAll" that clears all messages and a clear method that takes a path
• Beside that we want to have a builder pattern to construct a message in a more convenient, flexible and extensible ways: buildError, buildWarning, buildInfo that all delegate to a generic build that takes an enum for the type of message to build. Beside that each method must accept a Path for wich a message should be build
• There should be a DefaultMessages component that gets the BuildContext it injected in the contructor to proof the API is implementable
• The builder should be implemented in a class MessageBuilder that takes the type enum, the path and a Consumer of a constructed "Message" class that holds all collected parameter in one object, that way implementers of the API do not need to reimplement the builder, but the javadoc should state that this is usually nothing client code will call
• For all other current parameters the builder needs to have a appropriate method (e.g. line(int), column(int), message(String), cause(Exception)) that return the builder for chaining
• the MessageBuilder#create() method will the create a message object and inform the consumer, where the DefaultMessages implementation should log the message and call the old message API in the BuildContext, clearAll will be a noop here

</issue_description>

<agent_instructions>Implement like described in the issue, a test is not yet needed to be implemented yet.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

Fixes #102

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[laeubi]

@copilot see my review comments here for some changes, additionally we should mark the corresponding method in BuildContext as deprecated with a note to the new API to use.

[Copilot]

@copilot see my review comments here for some changes, additionally we should mark the corresponding method in BuildContext as deprecated with a note to the new API to use.

Added @deprecated annotations to addMessage and removeMessages methods in BuildContext in commit 6a17a42.

[laeubi]

@copilot just some smaller remarks

[laeubi]

Looks good to me, anyone else likes to review?
Otherwise I would Squash+Merge this the next days.