Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Have a way to pass the plugin/id and an error code #57

Open
laeubi opened this issue Dec 3, 2022 · 6 comments
Open

Have a way to pass the plugin/id and an error code #57

laeubi opened this issue Dec 3, 2022 · 6 comments
Labels
enhancement New feature or request

Comments

@laeubi
Copy link
Collaborator

laeubi commented Dec 3, 2022

Currently one can pass a message but then it is not possible to identify the message in the IDE.

For that purpose it would be good if a caller cann pass the pligin/id and an error code, that way an IDE could map error messages to quick-fix actions. To complement this, a plugin might also want to pass additional context. So a generic way would be to have a context-map of <String, Object> that can be passed along.

@kwin
Copy link
Contributor

kwin commented Mar 3, 2024

This would be also useful to extend the error message with a plugin id prefix. Currently all messages from BuildContext appear out of context (if not logged with SLF4J), i.e. the mojo which has emitted the message cannot be identified.

@kwin
Copy link
Contributor

kwin commented Mar 3, 2024

@laeubi WDYT about a new component BuildContextFactory which creates build contexts per plugin coordinate? That way the context would be part of the BuildContext object (which is then no longer a singleton obviously).

@laeubi
Copy link
Collaborator Author

laeubi commented Mar 3, 2024

@kwin I'm not sure if we are having the same in min,d but the mojo /execution is already tracked, so if this is useful it should already be possible to do so.

My plan would be to have a dedicated MarkerContext in a new package that is only dedicated to marker support, this then should also include for example:

@kwin
Copy link
Contributor

kwin commented Mar 3, 2024

but the mojo /execution is already tracked

How does this work if currently the context is a singleton and there is multithreading going on (i.e. multiple modules are built in parallel) or are you only talking about the m2e implementation?

Update: In m2e this is achieved with https://github.com/eclipse-m2e/m2e-core/blob/112488c013ba85ea43ad104296e391e68bd9fb50/org.eclipse.m2e.core/src/org/eclipse/m2e/core/internal/builder/MavenBuilderImpl.java#L145, which only works in a single-threaded build.

@laeubi
Copy link
Collaborator Author

laeubi commented Mar 3, 2024

In general you need to register a MojoExecutionListener (or similar) then there you just have a ThreadLocal where you put the current execution for example.

The in your BuildContext implementation you reference that mojo and can get the current active execution for the thread and extract whatever information you need.

One example can be seen at Tycho here:
https://github.com/eclipse-tycho/tycho/blob/main/tycho-spi/src/main/java/org/eclipse/tycho/helper/MojoExecutionHelper.java

@laeubi
Copy link
Collaborator Author

laeubi commented Mar 3, 2024

Another option would be to make implementation @MojoExecutionScoped.

@slachiewicz slachiewicz added the enhancement New feature or request label Jan 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants