There are no plans to expose internal workings of workspace
dependencies resolution to m2e extensions at this point. I suggest you
use m2e internal classes, but retest your code still work each time you
upgrade m2e.
--
Regards,
Igor
On Thu, Aug 25, 2016, at 04:34 AM, Balázs Zsoldos wrote:
> 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
> <[email protected]> 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
> [email protected]
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/m2e-users
_______________________________________________
m2e-users mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/m2e-users
