On 22 Aug 2011, at 17:18, Ove Ranheim wrote:
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 <oranheim(a)gmail.com>
>>> 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.
IMO the key is to look at the CDI and Java EE ecosystem, of which Seam is a part...
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
> 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
> 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
> 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.
In general the goal of the Seam project is to work with the Java EE platform to make it
the best place to build applications. Sometimes this comes in the form of code (the Seam
modules), sometimes in the form of education (the Seam docs and examples) and sometimes in
the form of supporting others.
So, if you take the overall goal, then you can see why it makes most sense for Wicket to
host the CDI integration - it's providing the best way to use Wicket with Java EE!
Sometimes of course a project isn't interested in doing this, so in that case it can
make sense to incubate the support within the Seam codebase (as we did with Wicket), build
support for it, and then see if the project is interested in taking it.