It's pretty much what I put together for JMS, which has supporting implementations for HornetQ, OpenMQ and ActiveMQ (or at least will shortly)<br><br><div class="gmail_quote">On Mon, Jul 25, 2011 at 6:10 PM, Jason Porter <span dir="ltr"><<a href="http://lightguard.jp">lightguard.jp</a>@<a href="http://gmail.com">gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I like that idea quite a bit actually. But it becomes very complicated once you get into Reports and Cron, and even Mail.<div>
<div></div><div class="h5"><br><br><div class="gmail_quote">On Mon, Jul 25, 2011 at 16:06, Shane Bryzak <span dir="ltr"><<a href="mailto:sbryzak@redhat.com" target="_blank">sbryzak@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
How about having one module that contains all of the API for all<br>
implementations, and then one implementation for each of the services?<br>
<div><div></div><div><br>
On 26/07/11 01:51, Antoine Sabot-Durand wrote:<br>
> Hi Shane,<br>
><br>
> Seam social is in alpha1, but API are now stable enough to enter in beta. This also necessary to add my OAuth contribution to Seam security.<br>
><br>
> Regarding packaging I'm still wondering if model and controller class for a given service (Twitter for instance) shouldn't be put in a sub module to separate core functions from specific implementations. It will facilitate different lifecycle for each social service support for instance and allow users to only include module they need for their development.<br>
><br>
> the only issue with that is it would create 2 submodule per service (API and IMPL) and I find it a bit heavy...<br>
><br>
> What is your opinion on that subject ?<br>
><br>
> regard,<br>
><br>
> Antoine SABOT-DURAND<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> Le 25 juil. 2011 à 01:33, Shane Bryzak a écrit :<br>
><br>
>> Just a heads up to everyone that we only have 3 weeks remaining until<br>
>> the beta 1 release for Seam 3.1. It would be appreciated if all module<br>
>> leads could reply to this with a status update for your module, and<br>
>> whether you foresee any issues with delivering a beta for your module<br>
>> within this timeframe.<br>
>><br>
>> I'd also like to remind everyone that we are getting rid of the shaded<br>
>> (combined) jars, so if you need assistance in doing this for your module<br>
>> please let me know and I can help out.<br>
>><br>
>> Shane<br>
>> _______________________________________________<br>
>> seam-dev mailing list<br>
>> <a href="mailto:seam-dev@lists.jboss.org" target="_blank">seam-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/seam-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/seam-dev</a><br>
<br>
_______________________________________________<br>
seam-dev mailing list<br>
<a href="mailto:seam-dev@lists.jboss.org" target="_blank">seam-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/seam-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/seam-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br></div></div>-- <br>Jason Porter<br><a href="http://lightguard-jp.blogspot.com" target="_blank">http://lightguard-jp.blogspot.com</a><br><a href="http://twitter.com/lightguardjp" target="_blank">http://twitter.com/lightguardjp</a><br>
<br>Software Engineer<br>Open Source Advocate<br>Author of Seam Catch - Next Generation Java Exception Handling<br><br>PGP key id: 926CCFF5<br>PGP key available at: <a href="http://keyserver.net" target="_blank">keyserver.net</a>, <a href="http://pgp.mit.edu" target="_blank">pgp.mit.edu</a><br>
<br>_______________________________________________<br>
seam-dev mailing list<br>
<a href="mailto:seam-dev@lists.jboss.org">seam-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/seam-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/seam-dev</a><br>
<br></blockquote></div><br>