Skip to content

Conversation

Copy link
Contributor

Copilot AI commented Oct 13, 2025

Overview

This PR modernizes the severity level API by converting the integer constants SEVERITY_WARNING and SEVERITY_ERROR to a type-safe enum, addressing issue #XX.

Problem

The current implementation uses primitive integer constants for severity levels:

int SEVERITY_WARNING = 1;
int SEVERITY_ERROR = 2;

void addMessage(File file, int line, int column, String message, int severity, Throwable cause);

This approach has several drawbacks:

  • No type safety: Any integer value can be passed (e.g., 999, -1, 42)
  • Poor readability: Magic numbers like 1 and 2 are less clear than named constants
  • Limited IDE support: No autocomplete for valid values
  • Harder to maintain: Adding new severity levels requires careful coordination

Solution

Introduced a new Severity enum with WARNING and ERROR values:

public enum Severity {
    WARNING(1),
    ERROR(2);
    
    public int getValue() { ... }
    public static Severity fromValue(int value) { ... }
}

Added a new type-safe method signature:

void addMessage(File file, int line, int column, String message, Severity severity, Throwable cause);

Benefits

  • Type-safe: Compiler enforces only valid severity values
  • Readable: Severity.WARNING is clearer than 1
  • IDE-friendly: Full autocomplete and refactoring support
  • Future-proof: Easy to add new levels (INFO, DEBUG) mentioned in Please output INFO messages in DefaultBuildContext.addMessage #20
  • Backward compatible: Existing code continues to work

Backward Compatibility

All existing code continues to work without modification:

  • Old SEVERITY_WARNING and SEVERITY_ERROR constants remain available (deprecated)
  • Old addMessage(int severity) method still works (deprecated)
  • Automatic conversion between int and enum values via getValue() and fromValue()

Migration Path

Old code (still works):

buildContext.addMessage(file, 1, 1, "message", BuildContext.SEVERITY_WARNING, null);

New code (recommended):

buildContext.addMessage(file, 1, 1, "message", Severity.WARNING, null);

Changes

  • New: src/main/java/org/codehaus/plexus/build/Severity.java - Type-safe enum
  • Modified: BuildContext.java - Added enum-based method, deprecated int-based API
  • Modified: DefaultBuildContext.java - Implements both enum and deprecated int-based methods

Fixes #XX

Original prompt

This section details on the original issue you should resolve

<issue_title>Make SEVERITY a enum?</issue_title>
<issue_description>Currently there are

 /** Constant <code>SEVERITY_WARNING=1</code> */
  int SEVERITY_WARNING = 1;

  /** Constant <code>SEVERITY_ERROR=2</code> */
  int SEVERITY_ERROR = 2;

it might be better to have these (together with INFO and probably DEBUG see #20 )as an Enum to make the code more type safe</issue_description>

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

@michael-o Yes, this is quite old style...

Fixes #40


✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

Copilot AI changed the title [WIP] Refactor severity constants to use enum Convert SEVERITY constants to type-safe enum Oct 13, 2025
Copilot AI requested a review from slachiewicz October 13, 2025 20:55
Copilot finished work on behalf of slachiewicz October 13, 2025 20:55
@laeubi
Copy link
Collaborator

laeubi commented Oct 14, 2025

@slachiewicz actually I won't do it here, instead we should define a new dedicated marker API (that by default delegates to the "old" Buildcontext. This then could then use all cool stuff and I think a builder pattern would be mor suitable given the large amount of parameters here that are hard to handle.

If you like I can describe it in an issue and ask copilote to work on this :-D

@slachiewicz slachiewicz deleted the copilot/make-severity-an-enum branch October 14, 2025 05:22
@slachiewicz
Copy link
Member

Feel free to propose a solution, I hope You can also ask the Copilot for a solution. I don't want to be a forwarder here :-)
I saw a few old tickets and thought that it may be easy to fix it this way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Make SEVERITY a enum?

3 participants