<!-- you don't need to keep this, but it's cool for stats! -->
<meta name="generator" content="nanoc 4.11.18">
</head>
<body>
<divid="main">
<h1id="running-the-evaluation">Running the evaluation</h1>
<h2id="bash-scripts">Bash scripts</h2>
<p>We wrote <i>bash</i> scripts to simplify the run of the evaluation. They are available in the folder <code>evaluation-scripts</code> of the <ahref="../../tools/evaluation">tool suite</a>.</p>
<ul>
<li><code>generate-all</code> generates 10 OSGi bundles each with the java code for 10 generated metamodels</li>
<li><code>run-all</code> takes generated OSGi bundle as arguments, and run the evaluation for both 1 clone and 1000 clones</li>
<li><code>plot-all</code> takes generated CSV files as arguments, and created many plots to visualize the results</li>
</ul>
<p>They can be easily run in a linux environement, but also in a Windows environment using <ahref="http://win-bash.sourceforge.net/">win-bash</a>.</p>
<h2id="running">Running</h2>
<pre><code>cd /path/to/evaluation-scripts
./generate-all
</code></pre>
<p>A folder <code>benchmarktool-workingdir</code> is created, in which will be created 10 OSGi bundles named bundle1.jar, bundle2.jar, etc.</p>
<!-- you don't need to keep this, but it's cool for stats! -->
<metaname="generator"content="nanoc 4.11.18">
</head>
<body>
<divid="main">
<h1id="running-the-evaluation">Running the evaluation</h1>
<h2id="bash-scripts">Bash scripts</h2>
<p>We wrote <i>bash</i> scripts to simplify the run of the evaluation. They are available in the folder <code>evaluation-scripts</code> of the <ahref="../../tools/evaluation">tool suite</a>.</p>
<ul>
<li><code>generate-all</code> generates 10 OSGi bundles each with the java code for 10 generated metamodels</li>
<li><code>run-all</code> takes generated OSGi bundle as arguments, and run the evaluation for both 1 clone and 1000 clones</li>
<li><code>plot-all</code> takes generated CSV files as arguments, and created many plots to visualize the results</li>
</ul>
<p>They can be easily run in a linux environement, but also in a Windows environment using <ahref="http://win-bash.sourceforge.net/">win-bash</a>.</p>
<h2id="running">Running</h2>
<pre><code>cd /path/to/evaluation-scripts
./generate-all
</code></pre>
<p>A folder <code>benchmarktool-workingdir</code> is created, in which will be created 10 OSGi bundles named bundle1.jar, bundle2.jar, etc.</p>
<!-- you don't need to keep this, but it's cool for stats! -->
<meta name="generator" content="nanoc 4.11.18">
</head>
<body>
<divid="main">
<h1id="getting-started">Getting started</h1>
<p>What you need:</p>
<ul>
<li>Some existing Eclipse installation with Moclodash plugins installed using our update site, <ahref="../../tools/plugin/">as given here</a>.</li>
<li>An eclipse workspace with a plug-in or EMF project containing an ecore model serialized in one or multiple xmi files. Note that:
<ul>
<li>These ecore files must all be in the same folder.</li>
<li>For our approach to be interesting, the mutable properties of the metamodel must be tagged by adding a suffix <code>_m</code> to their names.</li>
</ul>
</li>
</ul>
<p>In this guide, we consider an empty EMF project called “MyProject” containing a folder “model”, in which the ecore files are stored. More preceisely, our starting point is the following:</p>
<p><imgsrc="1.png"alt="Starting point: a single project with a single ecore file."/></p>
<p>In this first part we generate all the java code required to created runtime representations of models of a given metamodel, including those of memory efficient clones.</p>
<ol>
<li>From a Java perspective, go to <em>Run → Run configurations</em>. Right click on <em>CloningMaterialGeneration</em>, and select <em>New</em>.</li>
<li>There are three fields to fill and a checkbox:
<ul>
<li>the folder that contains all the ecore files,</li>
<li>the project in which the Java code must be generated,</li>
<li>the name of the metamodel (which is mostly useful when the metamodel contains multiple packages or files).</li>
<li>if you also want to make a call to the EMF model code generator without handling a genmodel file yourself, tick the checkbox
<imgsrc="2.png"alt="Creating a cloning material generation run configuration."/></li>
</ul>
</li>
<li>Press “Run”. If you enabled the console view, then you can observe the progress. In the end, four packages are created (one per cloning strategy) each containing:
<ul>
<li>A <code>Copier</code> class, used by the cloner to instantiate java proxy classes when a class is partially shareable,</li>
<li>A <code>Tags</code> class, which can tell if a class is shareable or not for this strategy,</li>
<li>Proxy java classes for all classes of the metamodel that are partially shareable.
<imgsrc="3.png"alt="Getting a blink at the results."/></li>
</ul>
</li>
</ol>
<h2id="using-the-cloning-strategies">Using the cloning strategies</h2>
<p>In this second part we use the provided API to clone models using the different strategies. Here is a sample of code that creates a model using the same metamodel as previsously, and then clones it using the four cloning strategies:</p>
<!-- you don't need to keep this, but it's cool for stats! -->
<metaname="generator"content="nanoc 4.11.18">
</head>
<body>
<divid="main">
<h1id="getting-started">Getting started</h1>
<p>What you need:</p>
<ul>
<li>Some existing Eclipse installation with Moclodash plugins installed using our update site, <ahref="../../tools/plugin/">as given here</a>.</li>
<li>An eclipse workspace with a plug-in or EMF project containing an ecore model serialized in one or multiple xmi files. Note that:
<ul>
<li>These ecore files must all be in the same folder.</li>
<li>For our approach to be interesting, the mutable properties of the metamodel must be tagged by adding a suffix <code>_m</code> to their names.</li>
</ul>
</li>
</ul>
<p>In this guide, we consider an empty EMF project called “MyProject” containing a folder “model”, in which the ecore files are stored. More preceisely, our starting point is the following:</p>
<p><imgsrc="1.png"alt="Starting point: a single project with a single ecore file."/></p>
<p>In this first part we generate all the java code required to created runtime representations of models of a given metamodel, including those of memory efficient clones.</p>
<ol>
<li>From a Java perspective, go to <em>Run → Run configurations</em>. Right click on <em>CloningMaterialGeneration</em>, and select <em>New</em>.</li>
<li>There are three fields to fill and a checkbox:
<ul>
<li>the folder that contains all the ecore files,</li>
<li>the project in which the Java code must be generated,</li>
<li>the name of the metamodel (which is mostly useful when the metamodel contains multiple packages or files).</li>
<li>if you also want to make a call to the EMF model code generator without handling a genmodel file yourself, tick the checkbox
<imgsrc="2.png"alt="Creating a cloning material generation run configuration."/></li>
</ul>
</li>
<li>Press “Run”. If you enabled the console view, then you can observe the progress. In the end, four packages are created (one per cloning strategy) each containing:
<ul>
<li>A <code>Copier</code> class, used by the cloner to instantiate java proxy classes when a class is partially shareable,</li>
<li>A <code>Tags</code> class, which can tell if a class is shareable or not for this strategy,</li>
<li>Proxy java classes for all classes of the metamodel that are partially shareable.
<imgsrc="3.png"alt="Getting a blink at the results."/></li>
</ul>
</li>
</ol>
<h2id="using-the-cloning-strategies">Using the cloning strategies</h2>
<p>In this second part we use the provided API to clone models using the different strategies. Here is a sample of code that creates a model using the same metamodel as previsously, and then clones it using the four cloning strategies:</p>
