<div class="gmail_quote">On Wed, Mar 30, 2011 at 05:49, Paul Bakker <span dir="ltr"><<a href="http://paul.bakker.nl">paul.bakker.nl</a>@<a href="http://gmail.com">gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div>For the plugin I now just generate a new class with a main method to the project's test-source folder. After that I use an mvn exec:java to run the class. It's less ideal because the plugin now adds a user visible utility class to the project, but it's not really a problem I believe. The exporter class is also runnable outside of Forge, so that's good too.</div>
</blockquote><div><br></div><div>You read my mind (or perhaps I read yours) :) That's precisely what I was going to suggest. After all, the @Deployment method is a public static method. Since forge makes it easy to generate code, even temporary code, you can just lay down some tracks, execute it and clean up.</div>
<div><br></div><div>Great thinking!</div><div><br></div><div>-Dan</div><div><br></div></div>-- <br><div>Dan Allen</div>Principal Software Engineer, Red Hat | Author of Seam in Action<br>Registered Linux User #231597<br><br>
<div><a href="http://www.google.com/profiles/dan.j.allen#about" target="_blank">http://www.google.com/profiles/dan.j.allen#about</a><br><a href="http://mojavelinux.com" target="_blank">http://mojavelinux.com</a><br><a href="http://mojavelinux.com/seaminaction" target="_blank">http://mojavelinux.com/seaminaction</a><br>
</div><br>