I love this idea! Would it possible instead to make portable CDI support instead of binding to a specific implantation? The CDI api jar is in central. Sent from my iPhone On Aug 17, 2011, at 6:53, Clint Popetz <clint(a)42lines.net&gt; wrote: Hi, I have a proposal from one of the wicket committers (Igor Vaynberg, who is also one of my employees) to transition seam-wicket to become a wicket module that integrates wicket with weld, so that it's supported by the wicket team. This is a net win, in my opinion, because (a) the only code in seam wicket is really just code to configure wicket's request cycle to start/stop conversations and perform injection and has no other seam dependencies, (b) this allows the release to be correctly synced to the wicket releases, which we currently lag and are thus not compatible with, and (c) he has more time to maintain this than I do, and would do a better job of it. Is this acceptable to the seam team? The only thing I really need is for the weld 1.1.1 artifacts to be in the central m2 repo, because wicket is published there and the central repo doesn't let you have dependencies on non-central-repo artifacts. Is that reasonable/possible? Thanks, -Clint -- Clint Popetz <http://42lines.net>http://42lines.net Scalable Web Application Development _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

I know it's not greatly documented, but the seam conversation module works with all three known implementations Sent from my iPhone On Aug 17, 2011, at 11:23, Clint Popetz <clint(a)42lines.net&gt; wrote: My impression is that the conversation control API isn't part of CDI yet, so until it is it has to be weld-specific. -Clint On Wed, Aug 17, 2011 at 12:22 PM, Jason Porter < <lightguard.jp(a)gmail.com&gt; lightguard.jp(a)gmail.com&gt; wrote: > I love this idea! Would it possible instead to make portable CDI support > instead of binding to a specific implantation? The CDI api jar is in > central. > > Sent from my iPhone > > On Aug 17, 2011, at 6:53, Clint Popetz < <clint(a)42lines.net&gt; > clint(a)42lines.net&gt; wrote: > > Hi, > > I have a proposal from one of the wicket committers (Igor Vaynberg, who is > also one of my employees) to transition seam-wicket to become a wicket > module that integrates wicket with weld, so that it's supported by the > wicket team. This is a net win, in my opinion, because (a) the only code in > seam wicket is really just code to configure wicket's request cycle to > start/stop conversations and perform injection and has no other seam > dependencies, (b) this allows the release to be correctly synced to the > wicket releases, which we currently lag and are thus not compatible with, > and (c) he has more time to maintain this than I do, and would do a better > job of it. > > Is this acceptable to the seam team? The only thing I really need is for > the weld 1.1.1 artifacts to be in the central m2 repo, because wicket is > published there and the central repo doesn't let you have dependencies on > non-central-repo artifacts. Is that reasonable/possible? > > Thanks, > -Clint > > -- > Clint Popetz > <http://42lines.net> <http://42lines.net>http://42lines.net > Scalable Web Application Development > > _______________________________________________ > seam-dev mailing list > <seam-dev@lists.jboss.org&gt;seam-dev(a)lists.jboss.org > <https://lists.jboss.org/mailman/listinfo/seam-dev> > https://lists.jboss.org/mailman/listinfo/seam-dev > > -- Clint Popetz <http://42lines.net>http://42lines.net Scalable Web Application Development

On Wed, Aug 17, 2011 at 15:52, Clint Popetz <clint(a)42lines.net&gt; wrote: Ok, I'll suggest that to Igor, but the seam modules aren't in central either :) The Maven team at JBoss has been trying to tackle a sync of JBoss releases to central. They've had several false starts...not sure how close they are. But the goal, last I heard, was to make it happen. The reason for doing it this way is that we want to have an independent repository of JBoss Releases that is brought into central collectively rather than having individual publish credentials for every project (just gets too crazy). -Dan -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://www.google.com/profiles/dan.j.allen#about http://mojavelinux.com http://mojavelinux.com/seaminaction _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

On Wed, Aug 17, 2011 at 13:23, Clint Popetz <clint(a)42lines.net&gt; wrote: > My impression is that the conversation control API isn't part of CDI yet, > so until it is it has to be weld-specific. It's planned for CDI 1.1. There is a portable conversation module that is bridging this gap in the interim. As Jason mentioned, we need to make it more clear how to use it (and that it exists).

-Dan -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://www.google.com/profiles/dan.j.allen#about http://mojavelinux.com http://mojavelinux.com/seaminaction

On Wed, Aug 17, 2011 at 15:55, Clint Popetz <clint(a)42lines.net&gt; wrote: > > > On Wed, Aug 17, 2011 at 2:54 PM, Dan Allen <dan.j.allen(a)gmail.com&gt; wrote: > >> On Wed, Aug 17, 2011 at 13:23, Clint Popetz <clint(a)42lines.net&gt; wrote: >> >>> My impression is that the conversation control API isn't part of CDI >>> yet, so until it is it has to be weld-specific. >> >> >> It's planned for CDI 1.1. There is a portable conversation module that is >> bridging this gap in the interim. As Jason mentioned, we need to make it >> more clear how to use it (and that it exists). >> >> > And if you put it in m2 central, I think I can probably convince him to > use it. > Got it. I'll check on the status of the sync. If the sync isn't working, then we'll see if we can just publish using the Seam credentials...at least the parts of Seam that the Wicket CDI integration would need.

Hi, I have a proposal from one of the wicket committers (Igor Vaynberg, who is also one of my employees) to transition seam-wicket to become a wicket module that integrates wicket with weld, so that it's supported by the wicket team. This is a net win, in my opinion, because (a) the only code in seam wicket is really just code to configure wicket's request cycle to start/stop conversations and perform injection and has no other seam dependencies, (b) this allows the release to be correctly synced to the wicket releases, which we currently lag and are thus not compatible with, and (c) he has more time to maintain this than I do, and would do a better job of it. Is this acceptable to the seam team? The only thing I really need is for the weld 1.1.1 artifacts to be in the central m2 repo, because wicket is published there and the central repo doesn't let you have dependencies on non-central-repo artifacts. Is that reasonable/possible? Thanks, -Clint -- Clint Popetz http://42lines.net Scalable Web Application Development _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

On Wed, Aug 17, 2011 at 3:17 PM, Ove Ranheim <oranheim(a)gmail.com&gt; 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.

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&gt; 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.

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&gt; 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.