Home » Modeling » Epsilon » Setting IUserInput from Workflow(Adapting ant input management to EOL)
| Setting IUserInput from Workflow [message #1838942] |
Wed, 10 March 2021 00:12  |
|
In our project, we use Apache ant to drive Epsilon workflows. We want to run these workflows in a scripted manner for testing as well as interactively.
We are using Epsilon's context independent input facility in our eol scripts, but this facility does not allow a scripting interface.
We see that the intended response would be to subclass Epsilon's IUserInput.
However, we have the question of how we can call IEolContext.setUserInput(IUserInput userInput) from within ant, when we call eol. There does not seem to be and exposed reference to.
As an aside, Apache ant, as the driver for Epsilon workflow, also offers a means to obtain input, which includes PropertyFileInputHandler for automation.
Our eventual aim would be to write an adapter as a subclass to the ant's InputHandler to use Epsilon's IUserInput for input gathered from ant as well.
|
|
| | |
| Re: Setting IUserInput from Workflow [message #1838953 is a reply to message #1838951] |
Wed, 10 March 2021 10:50  |
|
Yes, that would work well. It also means that the control is in the right place, so the architecture seems sensible. Is there something we can contribute to this effort? Maybe write an article that describes the feature? I am not sure how easily we would be able to contribute a quality code patch at short notice, as we are not set up for Epsilon development yet.
Best wishes,
JG
|
|
| | |
| Re: Setting IUserInput from Workflow [message #1840167 is a reply to message #1838955] |
Thu, 08 April 2021 03:19 |
|
I have just started on the implementation of this and am surprised, as both Host and DefaultHost are not actually accessible through the plugin classloader, but bundled into the task library. Is the intended design? If so, how am I meant to shape the bundle that does this extension?
I see two ways to do this:
- Move the Host classes onto the plugin class path.
- Use some sort of extra-classpath directive to allow the build to proceed.
The second option sounds messy, the first is outside my control. Rock and a hard place. I could build a feature patch to patch Epsilon over, but Tycho is buggy with feature patches...
Seems I am stuck without greater effort. Any other ideas?
w.r.t. article, I am waiting on this.
|
|
| |
| Re: Setting IUserInput from Workflow [message #1840177 is a reply to message #1838942] |
Thu, 08 April 2021 06:29 |
|
I have now checked out the org.eclipse.epsilon.workflow plugin and split it such a way that the Host interface and its children are outside the task library and inside the plugin library, so other classes can be derived. This fails, because of the dependency on org.apache.tools.ant. This only concerns two methods, as shown below. Any advice on if/how this could be refactored to extend this?
public void addStopCapabilities(Project project, IEolModule module);
public IModel createModel(String type) throws BuildException;
Maybe we can instead use an extensionPoint with IUserInput that is called from the EclipseHost code? There can only ever be one for the workflow plugin, so a singleton should be fine.
/*******************************************************************************
* Copyright (c) 2012 The University of York.
* This program and the accompanying materials
* are made available under the terms of the Eclipse Public License 2.0
* which is available at https://www.eclipse.org/legal/epl-2.0/
*
* Contributors:
* Dimitrios Kolovos - initial API and implementation
******************************************************************************/
package org.eclipse.epsilon.workflow.tasks.hosts;
import java.io.File;
import java.util.List;
import org.apache.tools.ant.BuildException;
import org.apache.tools.ant.Project;
import org.eclipse.epsilon.eol.IEolModule;
import org.eclipse.epsilon.eol.models.IModel;
public interface Host {
public boolean isRunning();
public void initialise();
public void addNativeTypeDelegates(IEolModule module);
public void addStopCapabilities(Project project, IEolModule module);
public boolean supportsDebugging();
public Object debug(IEolModule module, File file) throws Exception;
public void configureUserInput(IEolModule module, boolean isGui);
public IModel createModel(String type) throws BuildException;
public <T> List<T> getExtensionsOfType(Class<T> klazz) throws Exception;
}[Updated on: Thu, 08 April 2021 06:33] Report message to a moderator |
|
|
| Re: Setting IUserInput from Workflow [message #1840186 is a reply to message #1840177] |
Thu, 08 April 2021 09:59 |
|
How about creating a custom ANT task that sets the desired host (HostManager.getInstance().getHost()) at the start of the workflow? e.g.
<project default="main">
<target name="main">
<customHostSettingTask/>
<epsilon.loadModel ...>
...
</target>
</project>
Best,
Dimitris
|
|
|
| Re: Setting IUserInput from Workflow [message #1840189 is a reply to message #1840186] |
Thu, 08 April 2021 11:23 |
|
I think there are a two obstacles to this approach:
1. This does not solve the problem that the Host interface is still on the classplath of the AntRunner and hence it is not possible to create an extension by depending on the bundle or plugin.
2. The implementations of Host would need to be exposed to the classloader of that task. This would require a callback and hence an extension point anyway.
Further it does not seem straightforward when the desired outcome is to set an IUserInput for a workflow. An extension point seems the adequate means to do that. It is the Eclipse way of allowing IoC. And the documentation mentions this feature, but it does not mention the Host concept. So to keep changes minimal, only documented features should be exposed.
I have been able to integrate the source of workflow @ tag 2.2 in my build and will see if I can get the extension point to build. I will let you know how I go.
Best,
JG
|
|
| |
| Re: Setting IUserInput from Workflow [message #1840588 is a reply to message #1840252] |
Tue, 20 April 2021 01:47 |
|
Hi!
I am a fair bit through working this change out and have found what seems an inconsistency.
The spec states:
"To abstract away from the different runtime environments and enable the user to specify user interaction statements uniformly and regardless of the runtime context, EOL provides the IUserInput interface that can be realized in different ways according to the execution environment and attached to the runtime context via the IEolContext.setUserInput(IUserInput userInput) method."
But the callgraph for JFaceUserInput shows that its constructor demands a PrettyPrinterManager, and in its current implementation that manager is stateful and preloaded with an EOL PrettyPrinter which in turn uses the context's 'toString()' methods to visualize.
All of this is only interesting because as part of the refactor, I would like to allow creation of IUserInputs in ant via types. The current design of JFaceUserInput would mean that they can only be created within an ExecutableModuleTask, because this is the only place where they have meaning.
Because it feels like the Implementation of JFaceUserInput is a mistake, I leave this part of the design out, but I would be happy for some advice on this. Alternatively, all IUserInputs should receive the context if it is assumed that communication will always happen on context.
[Updated on: Tue, 20 April 2021 01:48] Report message to a moderator |
|
| |
Goto Forum:
Current Time: Sat Apr 27 07:46:09 GMT 2024
Powered by FUDForum. Page generated in 0.04229 seconds |
] 
Search
Help
Register
Login
Home
