Hi,
I have managed to solve my use-case but it is a bit tricky and it calls
internal API. Here is the solution:
@SuppressWarnings("restriction")
public static IMavenExecutionContext createExecutionContext(final
IMavenProjectFacade facade,
final IProgressMonitor monitor) throws CoreException {
return MavenPluginActivator.getDefault().getMavenProjectManagerImpl()
.createExecutionContext(facade.getPom(),
facade.getResolverConfiguration());
}
public static <V> V executeInContext(final IMavenProjectFacade facade,
final Consumer<MavenExecutionRequest> executionRequestModifier,
final ICallable<V> callable, final IProgressMonitor monitor) throws
CoreException {
IMavenExecutionContext executionContext =
createExecutionContext(facade, monitor);
MavenExecutionRequest executionRequest =
executionContext.getExecutionRequest();
return executionContext.execute((context, monitor1) -> {
if (executionRequestModifier != null) {
executionRequestModifier.accept(executionRequest);
}
return MavenPlugin.getMaven().createExecutionContext()
.execute(facade.getMavenProject(monitor), callable, monitor);
}, monitor);
}
You can execute an M2E ICallable by calling the function *executeInContext*.
You can modify the state of the executionRequest in the
*executionRequestModifier* parameter (functional interface).
I made the solution by analyzing the source code of M2E a lot (I mean
days). I noticed that it can be tricked in the following way:
- I create an executionContext by calling internal API of M2E but I do
not call execute on it
- I get the executionRequest from the newly created context
- I call execute on the context and inside the execute, I modify the
executionRequest (that I got before calling execute)
- I create an embedded execution context and call execute on it. The
embedded context will use the executionRequest of the parent (that is
modified).
I have a couple of issues with this solution:
- It uses internal API to create pre-configured execution context that
has a non-readonly executionRequest. I do not know how long this will work
- The trick with the embedded executionContext works. However, I got
that solution by knowing what is inside the source code. I do not know if
this trick will work in the next versions of M2E
I would be really happy if there was a standard and tested API that gives
us this functionality. At the moment it is impossible to execute any mojo
goal from a plugin with any overridden attribute (e.g.: user properties).
Regards,
*Balázs **Zsoldos*
On Sun, Aug 14, 2016 at 2:44 AM, Balázs Zsoldos <balazs.zsol...@everit.biz>
wrote:
> Hi,
>
> I would like to have the following steps in my Eclipse plugin:
>
>
> - Get the dependency tree of a project (done)
> - Flatten the dependency tree to a list that can be used to find out
> build order (done)
> - Iterate through the flattened dependency list and call every "mvn
> package" on each project that is in the Eclipse workspace without tests
> (done)
> - Use the result JAR file of calling "mvn package" for the next
> project (how?)
>
>
> When I call *execute(MavenProject, MojoExecution, IProgressMonitor)*
> function, how can I override the artifact resolution in the way that I use
> a JAR file that was the result of a previous build (mvn package).
>
> I checked every function of IMavenExecutionContext interface (and the
> interfaces it uses) but I could not find a way. Is there a possibility to
> override the *RepositorySystemSession *or the *WorkspaceReader* that
> belongs to the execution context?
>
> Thanks and regards,
> *Balázs **Zsoldos*
>
>
_______________________________________________
m2e-users mailing list
m2e-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/m2e-users
