I'm really sorry. I never checked building with an empty maven repo.
Thanks for fixing it.
2009/7/20 Derek Chen-Becker dchenbec...@gmail.com:
FYI, it looks like the Hibernate dependency you had in your pom was pulling
in the javax.transactions:jta lib, which isn't available in maven repos. I
2009/7/20 Derek Chen-Becker dchenbec...@gmail.com:
... hit the enter key too quickly! Kudos on the work in this library. I
really like how this is coming together.
Thanks Derek.
Derek
On Sun, Jul 19, 2009 at 11:52 PM, Derek Chen-Becker dchenbec...@gmail.com
wrote:
FYI, it looks like
Thanks Tim and David.
2009/7/19 David Pollak feeder.of.the.be...@gmail.com:
On Sat, Jul 18, 2009 at 11:20 AM, Timothy Perrett timo...@getintheloop.eu
wrote:
Awesome - kudos Jonas.
+1
And more generally, it's great to have such a diverse and talented group of
people contributing to
FYI, it looks like the Hibernate dependency you had in your pom was pulling
in the javax.transactions:jta lib, which isn't available in maven repos. I
added an exclusion to prevent that from breaking the build.
Derek
On Sun, Jul 19, 2009 at 3:08 AM, Jonas Bonér jbo...@gmail.com wrote:
Thanks
... hit the enter key too quickly! Kudos on the work in this library. I
really like how this is coming together.
Derek
On Sun, Jul 19, 2009 at 11:52 PM, Derek Chen-Becker
dchenbec...@gmail.comwrote:
FYI, it looks like the Hibernate dependency you had in your pom was pulling
in the
JTA stuff is in github master branch now.
http://github.com/dpp/liftweb/tree/4d8405a3dcf93570da8142c078784f9dc127933c/lift-jta
Have fun.
/Jonas
2009/7/17 David Pollak feeder.of.the.be...@gmail.com:
On Fri, Jul 17, 2009 at 1:02 AM, Jonas Bonér jbo...@gmail.com wrote:
Hi Greg.
Have you had
Awesome - kudos Jonas.
Cheers, Tim
On Jul 18, 11:53 am, Jonas Bonér jbo...@gmail.com wrote:
JTA stuff is in github master branch
now.http://github.com/dpp/liftweb/tree/4d8405a3dcf93570da8142c078784f9dc1...
Have fun.
/Jonas
--~--~-~--~~~---~--~~
You
Hi Greg.
Have you had time to look at the JTA stuff?
Should I merge in master?
/Jonas
2009/7/7 Jonas Bonér jbo...@gmail.com:
Thanks Tim. Thanks for staying on top of it. Derek has already looked
at it and seemed to like it. But I'll wait until I get Greg's
feedback.
2009/7/7 Timothy
No I haven't. Should I? Is everyone happy with it?
Have anyone tried it? Is anyone using it?
2009/6/30 Timothy Perrett timo...@getintheloop.eu:
Jonas,
Did you roll this into master? What's its status?
Cheers, Tim
On Jun 10, 4:46 pm, James Strachan james.strac...@gmail.com wrote:
Jonas,
i'm going to begin playing with it after i've finished the conversion of the
DSL stuff to scala-query. The JTA monad should just fit with scala-query.
Best wishes,
--greg
On Tue, Jul 7, 2009 at 10:18 AM, Jonas Bonér jbo...@gmail.com wrote:
No I haven't. Should I? Is everyone happy
Hey Jonas,
I have no real use case to test it out - I was just interested in its status
as conceptually it was very very clever and wondered where you were too with
it. I think Greg or Derek are most likely to be able to give you valuable
feedback as I believe they are using JTA already.
Thanks Greg. I would love to get your feedback on it.
2009/7/7 Meredith Gregory lgreg.mered...@gmail.com:
Jonas,
i'm going to begin playing with it after i've finished the conversion of the
DSL stuff to scala-query. The JTA monad should just fit with scala-query.
Best wishes,
--greg
On
Thanks Tim. Thanks for staying on top of it. Derek has already looked
at it and seemed to like it. But I'll wait until I get Greg's
feedback.
2009/7/7 Timothy Perrett timo...@getintheloop.eu:
Hey Jonas,
I have no real use case to test it out - I was just interested in its status
as
Jonas,
Did you roll this into master? What's its status?
Cheers, Tim
On Jun 10, 4:46 pm, James Strachan james.strac...@gmail.com wrote:
2009/6/9 Jonas Bonér jbo...@gmail.com:
2009/6/9 David Pollak feeder.of.the.be...@gmail.com:
Jonas,
We always use Maven to load dependencies. We
Lifted,
i gotta say this thread of activity is just so cool. It's what i always
dreamed open source would be like. The community essentially gets to access
and think with each others' best minds and act with each others' best
talents to arrive on a path to a better concrete realization of
2009/6/9 Jonas Bonér jbo...@gmail.com:
2009/6/9 David Pollak feeder.of.the.be...@gmail.com:
Jonas,
We always use Maven to load dependencies. We never use GPL dependencies.
If you have a question about the license of a dependency and its use in
Lift, please ping me privately.
I am using
Thanks James.
But I have already found them in a public repo.
/Jonas
2009/6/10 James Strachan james.strac...@gmail.com:
2009/6/9 Jonas Bonér jbo...@gmail.com:
2009/6/9 David Pollak feeder.of.the.be...@gmail.com:
Jonas,
We always use Maven to load dependencies. We never use GPL
Sweet looking stuff!
On Tue, Jun 9, 2009 at 6:18 AM, Jonas Bonér jbo...@gmail.com wrote:
Hey guys.
I have hacked together an early draft of the JTA transaction stuff.
I have wrapped it up in a monad. Here are some examples of usage:
for {
ctx - TransactionContext.Required
entity
2009/6/9 David Pollak feeder.of.the.be...@gmail.com:
Sweet looking stuff!
Thanks.
On Tue, Jun 9, 2009 at 6:18 AM, Jonas Bonér jbo...@gmail.com wrote:
Hey guys.
I have hacked together an early draft of the JTA transaction stuff.
I have wrapped it up in a monad. Here are some examples
Starkt jobbat Jonas!
I'll have a look at it asap :)
On Tue, Jun 9, 2009 at 4:27 PM, Jonas Bonér jbo...@gmail.com wrote:
2009/6/9 David Pollak feeder.of.the.be...@gmail.com:
Sweet looking stuff!
Thanks.
On Tue, Jun 9, 2009 at 6:18 AM, Jonas Bonér jbo...@gmail.com wrote:
Hey guys.
Wow, this is very nice! Kudos Jonas!
Cheers, Tim
On 09/06/2009 14:18, Jonas Bonér jbo...@gmail.com wrote:
Hey guys.
I have hacked together an early draft of the JTA transaction stuff.
I have wrapped it up in a monad. Here are some examples of usage:
for {
ctx -
Awesome! I'll take a look at the code. If you're basing this on ScalaJPA,
would it be preferable to add the functionality there, or is there anything
Lift-specific?
Derek
On Tue, Jun 9, 2009 at 7:18 AM, Jonas Bonér jbo...@gmail.com wrote:
Hey guys.
I have hacked together an early draft of
OK, one quick comment before I dive in: we generally want to depend on Maven
to grab dependencies. Right now you have a lib folder checked into git that
appears to hold the JTA libs and Atomikos. If that's the Sun JTA libs then
we can't distribute them. We generally use the geronimo JTA API, so
I added the lib folder only since I have not been able to find the
atomikos and deps in any maven repo.
Now the user can install them in their private repo.
If they exist in a public repo then I will remove the lib folder.
Will switch to the apache libs.
Thanks, Jonas.
2009/6/9 Derek Chen-Becker
Isnt LiftLogger extensible? Perhaps there would be some way to integrate it
with LiftLogger so it was an optional logger just like Log4J, SL4J etc
Disclaimer: I know nothing about Configgy!
Cheers, Tim
On 09/06/2009 17:34, Jonas Bonér jbo...@gmail.com wrote:
I am only depending on Lift
Jonas,
We always use Maven to load dependencies. We never use GPL dependencies.
If you have a question about the license of a dependency and its use in
Lift, please ping me privately.
What does Configgy have that Lift's Props and Logger doesn't? I'm all for
enhancing Lift to be as good as
2009/6/9 David Pollak feeder.of.the.be...@gmail.com:
Jonas,
We always use Maven to load dependencies. We never use GPL dependencies.
If you have a question about the license of a dependency and its use in
Lift, please ping me privately.
I am using Maven. But as I said I could not find the
On Tue, Jun 9, 2009 at 10:13 AM, Jonas Bonér jbo...@gmail.com wrote:
2009/6/9 David Pollak feeder.of.the.be...@gmail.com:
Jonas,
We always use Maven to load dependencies. We never use GPL dependencies.
If you have a question about the license of a dependency and its use in
Lift,
First I like the printf-style logging API, similar to slf4j. Nice to
use plus better performance.
We can add that to Lift's logger (which can sit on top of slf4j)
That would be great.
Also, note that all of Lift's logger parameters are call-by-name so there's
no evaluation unless the log
Re configgy.
I think it is a great balance between properties and xml, like pragmatic xml.
Simple as properties but with nesting, hierarchies, type conversions,
good override and defaults system (inheritance).
It also has notification of changes and a JMX API for management
(which I have not
Jonas,
Awesome! i look forward to digging into this stuff!
Best wishes,
--greg
On Tue, Jun 9, 2009 at 6:18 AM, Jonas Bonér jbo...@gmail.com wrote:
Hey guys.
I have hacked together an early draft of the JTA transaction stuff.
I have wrapped it up in a monad. Here are some examples of
In my email above I have the link to the Maven artifacts for Atomikos:
http://mvnrepository.com/artifact/com.atomikos
I think that the dependency you want is:
dependency
groupIdcom.atomikos/groupId
artifactIdtransactions-jta/artifactId
version3.2.3/version
/dependency
Derek
On
Thanks Derek. I missed that. I will fix the pom.xml.
2009/6/9 Derek Chen-Becker dchenbec...@gmail.com:
In my email above I have the link to the Maven artifacts for Atomikos:
http://mvnrepository.com/artifact/com.atomikos
I think that the dependency you want is:
dependency
Thanks Greg. And thanks for the suggestion to see transactions as monadic.
All feedback is more than welcome.
/Jonas
2009/6/9 Meredith Gregory lgreg.mered...@gmail.com:
Jonas,
Awesome! i look forward to digging into this stuff!
Best wishes,
--greg
On Tue, Jun 9, 2009 at 6:18 AM, Jonas
Thanks Derek. Thanks for taking time to do a code review.
I'll add that to the README.
/Jonas
2009/6/9 Derek Chen-Becker dchenbec...@gmail.com:
Jonas, the code looks great! I don't see any issues with how ScalaJPA is
used. It's nice to see that this fits what you're doing well and I really
Now I have deleted the lib dir with all jars and fixed the POM.
2009/6/9 Derek Chen-Becker dchenbec...@gmail.com:
In my email above I have the link to the Maven artifacts for Atomikos:
http://mvnrepository.com/artifact/com.atomikos
I think that the dependency you want is:
dependency
On Tue, Jun 9, 2009 at 1:08 PM, Jonas Bonér jbo...@gmail.com wrote:
Now I have deleted the lib dir with all jars and fixed the POM.
Thanks!
2009/6/9 Derek Chen-Becker dchenbec...@gmail.com:
In my email above I have the link to the Maven artifacts for Atomikos:
Jonas,
i just got back from a week of Guitar on Raft Island. So, i just saw this
message. If you want any help, design review, code review, peanuts from the
peanut gallery, just give me a shout. Also, i wanted to reiterate that i
think you can also provide an annotation-style solution over the
Unfortunately, I'm still living in EJB land, and therefore would prefer
something to bridge the gap (between legacy and new code). Goatrodeo looks
very exciting, but something for our next new component.
I actually had a layer I was using between our EJB beans + LIft that perhaps
with some time
Thanks a lot Greg.
That's sounds like a great idea. I'll see what I can come up with.
/Jonas
2009/5/30 Meredith Gregory lgreg.mered...@gmail.com:
Jonas,
i applaud the effort. i agree with DPP sentiments regarding annotations.
That said, i feel pretty comfortable that transactions fit
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
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,
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.
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
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
Create a branch (see Oliver's recent thread) and push that. We cna look at
the branch before merging into master. Branching is preferred over forking
because it keeps things in the same stream.
Derek
On Fri, May 29, 2009 at 7:54 AM, Jonas Bonér jbo...@gmail.com wrote:
I'll go for closures.
Thanks Tim and Derek.
I'll work in a branch. Simpler for me as well.
/Jonas
2009/5/29 Timothy Perrett timo...@getintheloop.eu:
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
I agree.
Derek Chen-Becker wrote:
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
Wow, that I would very much like to see... using for comprehensions
for transactions!
Cheers, Tim
Sent from my iPhone
On 29 May 2009, at 23:54, Meredith Gregory lgreg.mered...@gmail.com
wrote:
Jonas,
i applaud the effort. i agree with DPP sentiments regarding
annotations. That said,
I, too, would like to see Transactions be monadic.
--j
On Fri, May 29, 2009 at 3:54 PM, Meredith Gregory
lgreg.mered...@gmail.comwrote:
Jonas,
i applaud the effort. i agree with DPP sentiments regarding annotations.
That said, i feel pretty comfortable that transactions fit entirely in a
+30
So many pluses in fact, that we are already experimenting with this concept
at work. Unfortunately, the source may not be openable. I'd be more than
willing to contribute to an open-source JTA monadic library.
for( tx - context) {
//Do stuff
if(somethingBad)
Otherwise you can enable it in the logging:
log4j.logger.org.hibernate.SQL=DEBUG
On Tue, Feb 10, 2009 at 7:50 AM, Derek Chen-Becker dchenbec...@gmail.comwrote:
Interesting idea. I'll look into adding something like this (configurable
at boot and/or runtime) into scalajpa.
Derek
On
Yes, but that only works for Hibernate. I use Hibernate from everything, but
I'm trying to keep the library usable for any JPA provider.
Derek
On 2/10/09, Viktor Klang viktor.kl...@gmail.com wrote:
Otherwise you can enable it in the logging:
log4j.logger.org.hibernate.SQL=DEBUG
On Tue, Feb
Is there a JPA defined way to turn loggin of DML on?
On Tue, Feb 10, 2009 at 3:45 PM, Derek Chen-Becker dchenbec...@gmail.comwrote:
Yes, but that only works for Hibernate. I use Hibernate from everything,
but I'm trying to keep the library usable for any JPA provider.
Derek
On 2/10/09,
Everything I've ever seen has been provider-specific.
On 2/10/09, Viktor Klang viktor.kl...@gmail.com wrote:
Is there a JPA defined way to turn loggin of DML on?
On Tue, Feb 10, 2009 at 3:45 PM, Derek Chen-Becker
dchenbec...@gmail.comwrote:
Yes, but that only works for Hibernate. I use
Interesting idea. I'll look into adding something like this (configurable at
boot and/or runtime) into scalajpa.
Derek
On 2/9/09, Oliver ola...@gmail.com wrote:
Hi Derek and interested parties
I know there is a showSQL option that can be enabled with
JTA/Hibernate but I find the output
56 matches
Mail list logo
