On Aug 22, 2011, at 4:53 PM, Pete Muir wrote: > > On 17 Aug 2011, at 21:59, Ove Ranheim wrote: > >> >> On Aug 17, 2011, at 10:21 PM, Clint Popetz wrote: >> >>> >>> >>> On Wed, Aug 17, 2011 at 3:17 PM, Ove Ranheim <[email protected]> wrote: >>> Clint, >>> >>> What is it specifically that you will benefit from taking this into Wicket? >>> What plans do you have and what would be to the better? >>> >>> Please enlighten me, but what's the problem for "the resource you're trying >>> to convince" of not contributing under the Seam umbrella. Why is it a >>> problem for the wicket team to stay in sync with releases? Isn't it approx >>> a year between every Wicket release? >>> >>> >>> The idea is that if wicket 1.x is released, wicket-cdi 1.x will be released >>> simultaneously. In addition, as wicket evolves, the person most familiar >>> with its evolution (Igor) will have responsibility for keeping the >>> integration current. Finally, wicket already supports other dependency >>> injection frameworks (spring, juice) as wicket modules, so it makes sense >>> for the cdi module to live alongside those, and will give cdi more exposure >>> for those looking to use dependency injection in wicket. >>> >> >> There's a danger with two many "currents" and no well architected umbrella. >> I'd rather see many more frameworks being integrated on top of Solder. It's >> a concern that reusability will suffer due different strategies of >> implementation. What Solder, Faces, Servlet and more, really does well. Is >> to make a unified glue layer to fully integrate with different technologies. >> >> I'm not too confident moving Wicket out in it's own Wicket CDI module. IMHO, >> it'll be an Igor vs a whole Seam Community empowerment where talking about >> here. Has Igor fully evaluated the Seam Solder eco-system? Will you make a >> new Wicket CDI Int, Servlet, Catch module too. Eventually, how well will a >> mixed platform play together in the future!? Is Wicket strategy to stay >> Wicket and no other than Wicket should get in. > > I think you are making a lot of (negative) assumptions about the way this > will work out. Clint is a long time contributor to Seam and Weld, and Igor > has previously contributed to Weld. So I think we can have complete faith > that the work they do will reuse what makes sense from Seam, and play nicely > with the Seam ecosystem. I don't think Wicket is proposing to create an > entire new set of CDI plugins, and I can't really read that into what Clint > says. >
First of all, my apologies to Clint and Igor and I see that my statement was to some extent negative. It was not my intention to be offensive though. So Clint and Igor, sorry about that. From my perspective I shared an opinion where further UI frameworks should become part of Seam over time, so moving the CDI extension out means one less extension in the Seam eco-system. I contributed the mock support in Seam Wicket and I hope in time I will have more time to contribute further. I really endorse CDI technologies and it's been a fantastic to follow Seam Solder (also Weld Extensions) the past year. I do recognize it's generally a good thing to see higher adaption of CDI and off course Wicket CDI module to be further developed and maintained, even if that means outside of Seam. > There are a lot of benefits to a relevant technology owning the CDI > integration. > > Firstly, expose. On the one hand, by placing it in Seam, we limit it's > perceived applicability to "Seam" projects, and we don't encourage the wider > Wicket community to try out CDI. OTOH if it lives in Wicket, we encourage > that whole community to try out CDI, and perhaps take a look at Seam. > > Secondly, release cycles. CDI is a backwards compatible, specified, API, > whilst Wicket in this case is more flexible. Therefore taking CDI as the > stable point makes a lot of sense. We tried the approach you suggest in Seam > 2.x and it quickly becomes unmanageable and limits the size of the ecosystem. > This was part of the motivation for developing CDI. > > Thirdly, expertise. CDI is well documented and specified (not to say Wicket > isn't, but if we generalize these arguments, this does often hold) and has a > growing community of people who are expert at integration techniques, and to > reaching out to third parties and helping them integrate with CDI. Having the > Wicket team own the integration makes a lot of sense here too. > > Finally, that there is actually nothing to stop the Wicket team making an > official CDI integration without the Seam communities involvment at all. Much > better to engage than build walls. > > There are the disadvantages you mention, however I believe they are small, > and can be mitigated almost entirely by Seam documenting third party > integrations. > > HTH understand the reasoning behind the Seam/JBoss philosophy here that it's > better that the integration with CDI lives outside Seam where possible. > I understand and it would be good to understand the demarcation between what should be a Seam project/module and what's outside scope, hence be a CDI extension, even outside Seam. I'm a bit confused by what's within the boundaries of Seam. But that might just be me. Nevertheless, I don't mean to be negative and my apologies for making my initial statement above. Br, Ove > Pete _______________________________________________ seam-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/seam-dev
