>
> On Tue, Jan 24, 2012 at 01:27, Jason Porter <
lightguard.jp@gmail.com <mailto:
lightguard.jp@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.
>
>
> Again, I can stand see the point being made standing in those shoes.
>
> You do have to admit that it looks a bit bipolar that we are working hard to grow a CDI ecosystem with one face, then telling developers they don't need
> it (and we don't want to support it) with another face.
>
> When did we become so fearful of supporting open source software, whether it's invented "here" or not. I'm not saying your wrong, I'm just encouraging
> you to take another look.
>
>
> 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.
>
>
> Agreed. We want to avoid the paradox of choice, but 2 - 3 strong options is fair.
>
> 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.
>
>
> Can we agree to at least try to move some of the boilerplate into an embedded framework rather than have the common logic duplicated in each view bean?
> Does that fit within the requirements. After all, we want to make sure the code is as maintainable as possible given these constraints.
>
> 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 :)
>
>
> I'm not suggesting bulldoze. Simply refactor a small portion.
>
>
> forge> leave-javaee-purist-mode
>
>
> Also remember that what Richard has done with purist java EE is very impressive!
>
>
> +100
>
> Perhaps I should have started with "I was noticeably impressed during my demo last week at the JBUG when I first saw the sophistication of the UI forms
> and use of conversations." It's looking great.
>
> 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.)
>
>
> <sarcasm> Yeah, because security one of those nice to have extras. </sarcasm>
>
> Sarcasm aside, I understand that this is just a general problem. Being reminded of that, Jason and I recognized we should raise this as an early task in
> DeltaSpike, perhaps integrating with another Apache library to start, Shiro. Anyway, OT.
>
> -Dan
>
> --
> Dan Allen
> Principal Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
>
http://google.com/profiles/dan.j.allen
>
http://mojavelinux.com
>
http://mojavelinux.com/seaminaction
>
>
>