Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[epsilon-dev] Epsilon CLI v1.0

Hello everyone,

 

As some people have shown interest in running Epsilon without Eclipse (i.e. as a standalone  Java application from command-line), I have developed an infrastructure for doing this in the parallel-epsilon branch. The functionality so far supports the following features:

 

  • Multiple models and properties per script
  • Script parameters (i.e. variables to be put into the FrameStack as strings)
  • Time and memory profiling
  • Showing results (whatever is returned by execute() method of the module)
  • Writing results/profiling data to a file
  • Specifying a module implementation for execution (along with parameters to be passed to the constructor)
  • All EMC models which have a no-arguments constructor can be used

 

There are two main components to this infrastructure: the IEolRunConfiguration and EolConfigParser. The former is an object which encapsulates all the information and methods required for running an Epsilon program, such as the module, path to the Epsilon script, models, parameters etc. This is completely independent of the command-line functionality and can be used programmatically for convenience, which I found useful for creating run configurations when running tests. The latter is a command-line parser whose purpose is to build an IEolRunConfiguration from a String array. An example of an invocation for an EVL program via command-line would be as follows:

 

java -jar /path/to/script.evl -models emf.EmfModel:storeOnDisposal=true,fileBasedMetamodelUri=/path/to/metamodel.ecore,modelUri=/path/to/model1.xmi;plainxml.PlainXmlModel:name=emptyModel -profile -results -module evl.concurrent.EvlModuleParallelElements int=4 -parameters myVar1=foo,anotherVar=bar -outfile /path/to/logs.txt

 

It is intended that each Epsilon language have its own RunConfiguration and ConfigParser extension (e.g. EvlRunConfiguration and EvlConfigParser, as implemented already) however it is possible to use the generic EOL ones by providing the appropriate module with the -module option. For example, to run ETL one would add the option -module etl.EtlModule.

 

Finally to avoid unnecessary dependencies the EOL CLI plugin assumes that the necessary class files are included in the JAR, so if you’re working with EMF models the EMF plugin and its dependencies need to be on the classpath. Similarly if you are invoking something other than EOL without creating an extension of the EOL CLI plugin (such as in the ETL example above) then the appropriate plugins for the module and its dependencies need to be on the classpath.

 

Please let me know if you have any suggestions or comments.

 

Thanks,

Sina Madani


Back to the top