<div class="gmail_quote">On Tue, Jan 24, 2012 at 1:59 AM, Dan Allen <span dir="ltr"><<a href="mailto:dan.j.allen@gmail.com" target="_blank">dan.j.allen@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>On Tue, Jan 24, 2012 at 01:27, Jason Porter <span dir="ltr"><<a href="mailto:lightguard.jp@gmail.com" target="_blank">lightguard.jp@gmail.com</a>></span> wrote:<br></div><div class="gmail_quote"><div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
As for the non dep idea, I can certainly understand where Lincoln and Pete are coming from. </blockquote><div><br></div></div><div>I don't.</div></div></blockquote><div><br>This is a support-driven requirement. There was a good deal of concern as to what kind of libraries we wanted to "commit" to for a 5-7 year support plan. This is why Seam and the other libraries were removed.<br>
<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I do wonder though if that would preclude us from creating a CDI extension for rolling our own simple CRUD framework</blockquote><div><br></div></div><div>The one reasonable path I see here is working out the framework and then having Forge just spit it out into the project. (I know that will turn Richard's stomach). But then, it's easy to nuke that package and add the dep...likely update the imports to use the right package too. In fact, *that* could be a Forge plugin. It would be called</div>
</div></blockquote><div><br>There are always multiple paths, just like we can always have multiple scaffold providers. Open to extension - We can't, and I would argue that we shouldn't, drop the pure EE scaffold, but we can certainly add more, and enhance the way in which plugins can inter-operate with the generated scaffold. That's the area where I think we should be focusing, instead of thinking "straight up replacement." What we have is a good foundation. Let's build onto it, not bulldoze and rebuild it :)<br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote">
<div><br></div><div>forge> leave-javaee-purist-mode</div></div></blockquote><div><br>Also remember that what Richard has done with purist java EE is very impressive! The main thing that's missing is security, and that's something that's just not there in EE. (And wasn't a requirement for the scaffold.)<br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><div><br></div><div>:)</div><span><font color="#888888"><div><br></div>
<div>-Dan</div></font></span><br></div>
</blockquote></div><br><br clear="all"><br>-- <br>Lincoln Baxter, III<br><a href="http://ocpsoft.com" target="_blank">http://ocpsoft.com</a><br><a href="http://scrumshark.com" target="_blank">http://scrumshark.com</a><br>
"Keep it Simple"<br>