On Tue, Jan 24, 2012 at 18:15, Rafael Pestano <span dir="ltr">&lt;<a href="mailto:rmpestano@gmail.com">rmpestano@gmail.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Hi everyone,<div><br></div><div>its not just a matter of using different ScaffoldProviders in generateFromEntity plugin? </div><div><br></div><div>if you want vanilla javaEE code generation use FacesScaffold, if you want CDI Quey use CDIQueryBasedScafold and so on...</div>



<div><br></div><div>or its not that simple?  </div></blockquote><div><br></div><div>It&#39;s true. And from the conversation above, it looks like that&#39;s where we are headed.</div><div><br></div><div>I say that because:</div>

<div><br></div><div>(a) it appears the Java EE purist output is an immovable requirement</div><div>(b) we definitely want to offer output that *does* use a framework for those that want it (CDI Query likely)</div><div><br>

</div><div>Now, if at some point we decide that (b) isn&#39;t needed anymore, then (b) because the preferred recommendation. Yeah.</div><div><br></div><div>Granted, (a) and (b) won&#39;t be all that different, so we certainly aren&#39;t dumping work. (b) is simply introducing a dependency that effectively trims down what (a) produces.</div>

<div><br></div><div>I think Jason should proceed with what the (b) output will look like for the Open18 migration, then we can work it back into a (b) plugin.</div><div><br></div><div>-Dan</div><div> </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://google.com/profiles/dan.j.allen" target="_blank">http://google.com/profiles/dan.j.allen</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>