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
> <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
_______________________________________________
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

Reply via email to