Wonderful! Wow, kernel committer. That's gotta be an entirely different
story, I guess :-)
If we have a working example (similar to the ones here:
https://github.com/jOOQ/jOOQ/tree/master/jOOQ-examples), we can take over
future maintenance as far as changes in jOOQ are concerned.

Looking forward to hearing from you again,
Lukas

2014-09-22 12:54 GMT+02:00 Sbham <[email protected]>:

> TY Lukas!
>
> I will definitely carve some time out for it then. I love OSS and always
> gave back -kernel ex-committer here -, so I will work something out.
>
> Cheers!
> -S
>
> On Monday, September 22, 2014 1:48:27 AM UTC-5, Lukas Eder wrote:
>>
>> Hi there,
>>
>> 2014-09-20 20:53 GMT+02:00 Sbham <[email protected]>:
>>
>> Yes it is me. I posted on both boards to get at least one answer. TY!
>>>
>>> I posted on the DW board, here is a copy:
>>> Thanks Lukas!
>>>
>>> I am not sure I am breaking any grounds, I am rather just curious as to
>>> why there haven't been any either community or vendor supported DW bundle
>>> for jooq. A bundle would make the adoption more natural, than fighting at
>>> integrating another library...
>>>
>>
>> From our (vendor) perspective, it is very hard to assess what UI we want
>> to "officially" support integrating with. Maintaining examples is far from
>> trivial, so we generally rely on the community moving forward with this -
>> possibly contributing examples. So, this could be you, in that case :-)
>>
>>
>>> From the look of jooq, it seems very very appealing on a few dimensions
>>> compared to JDBI (still not sure how one would implement transactions
>>> -intrinsic to jooq or outside?...-). I can see how it can speed up dev
>>> workflow though.
>>>
>>
>> I'm not really acquainted with how dropwizard would like you to manage
>> transactions. From a jOOQ perspective, transactions are definitively
>> managed by third-party APIs, e.g. JDBC directly, Spring, JavaEE. While jOOQ
>> does offer a transaction API (http://www.jooq.org/doc/
>> latestmanual/sql-execution/transaction-management/), that API also
>> relies on third-party transaction configuration - defaulting to a
>> JDBC-based implementation.
>>
>> If you have more concrete questions about dropwizard / transactions /
>> jOOQ, I'm sure I can help...
>>
>> I wish I had time to dive in the jooq world and implement some type of DW
>>> integration.I think somebody more fluent than me in framework dev (DW &
>>> JOOQ) should do it.
>>>
>> For now, JDBI is working for us, however I am thinking a well documented
>>> framework like jooq -especially with a commercial company behind it- would
>>> benefit from developing more natural setups in more frameworks. For
>>> example, majority of DW adopters are either going to lean toward JDBI or
>>> Hibernate just because how natural either libraries are setup in the
>>> framework (similar in SpringMVC: JPA or SpringJDBC ?). If there were native
>>> integrations with JOOQ, there would certainly be more adopters.
>>>
>>
>> Yes, we are aware of that. But as I said, there is a huge amount of
>> frameworks to possibly support. It's much worse to have stale, non-working
>> examples than no examples at all.
>>
>>
>>> I will definitely keep an eye on JOOQ! As as architect, I definitely
>>> would benefit from using it on next projects. I selfishly -lazily- will
>>> wait till I see more adopters/integrations :)
>>>
>>
>> Please do give an integration a try. *YOU* can make this difference that
>> you ask from the community / from vendors. You're getting all this great
>> software (dropwizard, jdbi, jOOQ, etc.) for free. Now would be an
>> opportunity to contribute back!
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "jOOQ User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "jOOQ 
User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to