Hi Igor, thanks for the answer!
There are no plans to expose internal workings of workspace dependencies > resolution to m2e extensions at this point. I understand and agree. This is a special functionality that is rarely necessary. The solution I proposed in my second mail is a bit more generic: - Allow M2E extension developers to run Mojo executions (possible) - Allow M2E extension developers to run Mojo Executions in the way that they modify the ExecutionRequest (not possible, but it would be easy to add) At the moment, no system property, user property, WorkspaceReader or anything can be changed if we want to run a Mojo goal on a project. I can imagine that others wanted to set at least a user property sometimes. Kind regards, *Zsoldos Balázs* Rendszertervező | Software architect +36 70 594 9234 | balazs.zsol...@everit.biz *EverIT Kft.* 1137 Budapest, Katona József utca 17. III. em. 2. http://www.everit.biz I i...@everit.biz Ezen üzenet és annak bármely csatolt anyaga bizalmas, jogi védelem alatt áll, a nyilvános közléstől védett. Az üzenetet kizárólag a címzett, illetve az általa meghatalmazottak használhatják fel. Ha Ön nem az üzenet címzettje, úgy kérjük, hogy telefonon, vagy e-mail-ben értesítse erről az üzenet küldőjét és törölje az üzenetet, valamint annak összes csatolt mellékletét a rendszeréből. Ha Ön nem az üzenet címzettje, abban az esetben tilos az üzenetet vagy annak bármely csatolt mellékletét lemásolnia, elmentenie, az üzenet tartalmát bárkivel közölnie vagy azzal visszaélnie. This message and any attachment are confidential and are legally privileged. It is intended solely for the use of the individual or entity to whom it is addressed and others authorised to receive it. If you are not the intended recipient, please telephone or email the sender and delete this message and any attachment from your system. Please note that any dissemination, distribution, copying or use of or reliance upon the information contained in and transmitted with this e-mail by or to anyone other than the recipient designated above by the sender is unauthorised and strictly prohibited. On Thu, Aug 25, 2016 at 4:27 PM, Igor Fedorenko <i...@ifedorenko.com> wrote: > 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 >
_______________________________________________ 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
