Committers can work on branches. The general solution is that if you are
working on something that is "new" or "dangerous" use a branch with the
following naming convention:
wip-<name>-<feature>
E.g. wip-tim-localization
Checkout the thread oliver started "git ouch" - I just posted instructions
there for creating branches on the lift repo for committers.
Good luck.
Cheers, Tim
On 29/05/2009 14:54, "Jonas Bonér" <jbo...@gmail.com> wrote:
>
> I'll go for closures. Much simpler and less intrusive into Lift.
> The current impl is based on Atomikos and Hibernate, I'll start with
> pushing that in and we can make it pluggable later.
> For example for Hibernate one need to add a line to the hibernate
> config to register the
> org.hibernate.transaction.TransactionManagerLookup class in order to
> make Hibernate aware of our TX manager.
>
> Should I fork the github repo and submit patches or how do you guys work?
>
> /Jonas
>
>
> 2009/5/29 Derek Chen-Becker <dchenbec...@gmail.com>:
>> I'd vote for closures. We use annotations for JPA because we have to, but
>> IMHO closures provide a nicer semantic approach because they syntactically
>> enclose the block where the action is occurring.
>>
>> Derek
>>
>> On Fri, May 29, 2009 at 7:44 AM, Jonas Bonér <jbo...@gmail.com> wrote:
>>>
>>> No perf difference. The annotations are turned into the same exact
>>> closures.
>>>
>>> 2009/5/29 Timothy Perrett <timo...@getintheloop.eu>:
>>>>
>>>>
>>>> Are there any performance implications considering closures vs
>>>> annotations?
>>>> Agreed that closures are more "lift like" however.
>>>>
>>>> Cheers, Tim
>>>>
>>>> On 29/05/2009 10:21, "marius d." <marius.dan...@gmail.com> wrote:
>>>>
>>>>>
>>>>> I think that would be really good. But I'd rather not use annotations.
>>>>> Personally I find closures approach a much better fit here.
>>>>>
>>>>> withTxRequired {
>>>>> ... // do transational stuff
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>> Br's,
>>>>> Marius
>>>>>
>>>>> On May 29, 11:55 am, Jonas Bonér <jbo...@gmail.com> wrote:
>>>>>> Hi guys.
>>>>>>
>>>>>> I have been talking with David Pollak the rest of the lift team about
>>>>>> adding JTA to Lift. I have implemented that for a product written in
>>>>>> Scala some time ago. Now some of that code is OSS
>>>>>> at:http://github.com/jboner/skalman/tree
>>>>>>
>>>>>> We used using two different APIs.
>>>>>> 1. Annotations (would require Lift to support proxied objects, e.g.
>>>>>> grab them from a factory):
>>>>>>
>>>>>> @TransactionAttribute(REQUIRED)
>>>>>> def transactionalMethod = { ... }
>>>>>>
>>>>>> 2. Call-by-name:
>>>>>>
>>>>>> withTxRequired {
>>>>>> ... // do transational stuff
>>>>>>
>>>>>> }
>>>>>>
>>>>>> But I don't know what fits Lift and would like to know how you guys
>>>>>> would like to have JTA integrated.
>>>>>> At which level? Which APIs? Etc.
>>>>>>
>>>>>> --
>>>>>> Jonas Bonér
>>>>>>
>>>>>> twitter: @jboner
>>>>>> blog: http://jonasboner.com
>>>>>> work: http://crisp.se
>>>>>> work: http://scalablesolutions.se
>>>>>> code: http://github.com/jboner
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Jonas Bonér
>>>
>>> twitter: @jboner
>>> blog: http://jonasboner.com
>>> work: http://crisp.se
>>> work: http://scalablesolutions.se
>>> code: http://github.com/jboner
>>>
>>>
>>
>>
>>>
>>
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---
