You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Maven Mojos (and maybe components) can create / fork processes, common
examples would include:
- ant-run plugin
- maven-exec-plugin
- maven-surefire
currently the IDE has no effective way to know about forked processes,
so there is no way to visualize them (e.g. in a process manager) nor to
take special actions on them (e.g. automatically request to open a debug
port). For executions of tests, the IDE even may want to be notified
about individual test runs while the process is running.
This now adds a new build-process API that mitigates the problem by
allowing a mojo or component to make the IDE aware of subprocesses but
is completely disabled if running outside an IDE. An integration can
range from very basic, that is only notify that a process is running
over to specialized callbacks that allows the IDE to intercept process
creation in a generic way. An example implementation is provided for
either resuse, extension or own implementation of such callbacks.
To reflect this new opportunity, the minor version is increase to 1.3
even though neither consumers nor providers of the API need to take
immediate actions here.
Copy file name to clipboardExpand all lines: README.md
+58-1
Original file line number
Diff line number
Diff line change
@@ -7,19 +7,76 @@ Plexus Build API
7
7
8
8
This API allows IDEs to integrate with Maven deeper than it would be possible by just using regular Maven/Mojo API.
9
9
10
+
## Marker and File Delta support
10
11
It supports
11
12
12
13
- incremental builds e.g. allows to query which files have been touched since last build
13
14
- fine-grained error/info markers (referring to specific files in particular line numbers)
14
15
- notifications about updated files
15
16
17
+
## Process support
18
+
19
+
This API is located in the package `org.codehaus.plexus.build.process` and allows the IDE to interact with a mojo that starts new processes and has the following purposes:
20
+
21
+
- allow representation of processes in the UI e.g with a name and its current state together with a way to optionally terminate a running process
22
+
- optionally decorate the process dependeing on the use case e.g. add additional environment variables, supply classpath entries or provide listeners
23
+
24
+
The main entry point for this is the `ProcessContext` that can be injected in a mojo in the follwoing way:
25
+
26
+
```
27
+
public MyMojo extends AbstractMojo {
28
+
29
+
@Component
30
+
private ProcessManager processContext;
31
+
32
+
public void execute() {
33
+
34
+
ProcessContext context = ...
35
+
36
+
BuildProcess process = processContext.newProcess(context);
37
+
}
38
+
}
39
+
```
40
+
41
+
As one can see we have a `ProcessManager` that is capable of creating a Process for the user to see it in the IDE and the `BuildProcess` can be used to notify the IDE about process changes, e.g. if it is terminated.
42
+
There is also a `ProcessContext` passed to the call that allow the mojo to supply basic information like the name or if it can be terminated but also can implements different callbacks that might (or might not) be called to furhter decorate the process.
43
+
The follwoing callbacks are currently supported:
44
+
45
+
### ProcessCallback
46
+
47
+
`ProcessCallback` are quite bare callback that allow to request for adding (or replacing) an environment variable with `ProcessCallback#setEnvironmentVariable`,
48
+
any context that support should implement the interface. Even though a request is made it could be reqjected, e.g because the context don't allow this because
49
+
it uses a variable with the same name already and don'T want to replace it.
50
+
51
+
A basic implementation of this is provided with `ProcessBuilderContext` what implements this using a ProcessBuilder, so if processes are currently implemented that way it can be reused.
52
+
53
+
### JavaCallback
54
+
55
+
`JavaCallback` offers specialized way to add options to a launch that is running in a JVM (either directly or forked). The possible callbacks are
56
+
57
+
- setSystemProperty for requesting to add (or replace) a system property
58
+
- setVMOption for requesting to add (or replace) a VM option
59
+
- addClasspathEntry for requesting to add a new jar on the classpath
60
+
61
+
There is currently no implementation added here but one can reuse `ProcessBuilderContext` for performin neccesary actions.
62
+
63
+
### JUnitCallback
64
+
65
+
`JUnitCallback` offer specialized option to a launch that is executing test using JUnit framework. The possible callbacks are
66
+
67
+
- addTestClasspathEntry for requesting to add a new jar on the test classpath
68
+
- addTestExecutionListener for reuqest to add a new listener that is notified about test events
69
+
- getJUnitVersion allows to query for the used JUnit version
16
70
17
71
Current Implementations
18
72
-----
19
73
20
74
### Default Implementation
21
75
22
-
The default implementation shipping with this artifact is supposed to impose minimal overhead. It doesn't support incremental build and acts directly on the file system. Errors and warning are just logged through SLF4J.
76
+
- Marker and File Delta support is supposed to impose minimal overhead. It doesn't support incremental build and acts directly on the file system. Errors and warning are just logged through SLF4J.
77
+
- Process support is simply a no-op, it never will call any callbacks and just discards the name, all calls on the listener will simply do nothing
0 commit comments