On Tue, Jan 24, 2012 at 1:59 AM, Dan Allen
<dan.j.allen@gmail.com> wrote:
As for the non dep idea, I can certainly understand where Lincoln and Pete are coming from.
I don't.
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.
I do wonder though if that would preclude us from creating a CDI extension for rolling our own simple CRUD framework
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
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 :)
forge> leave-javaee-purist-mode
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.)