Le 09/03/2010 18:35, David Pollak a écrit :
On Tue, Mar 9, 2010 at 9:25 AM, Timothy Perrett mailto:timo...@getintheloop.eu>> wrote:
Wow, I wish I had 5 machines ;-) lol.
Thats an interesting outlook and an explanatory rationale. Can you
explain the implementation? Perhaps I can be
I see almost any difference with JRebel
On Mar 9, 6:13 pm, David Pollak wrote:
> My development cycle has never worked well with JRebel.
>
> First, I've got so many machines I do development on (5, 3 of which get
> wiped each time Ubuntu releases a new version), getting all of those
> machines se
On Tue, Mar 9, 2010 at 9:25 AM, Timothy Perrett wrote:
> Wow, I wish I had 5 machines ;-) lol.
>
> Thats an interesting outlook and an explanatory rationale. Can you explain
> the implementation? Perhaps I can be persuaded. Right now, i'm not convinced
> about hampering development mode in this wa
Why is compilation running with JRebel?
Also, how critical is JRebel to people getting their feet wet? When I was new
to Lift, I used the default setting in the POM that caused a jetty hot redeploy
when class files were updated. (Possibly earlier on I restarted jetty
manually.) While that meant
Wow, I wish I had 5 machines ;-) lol.
Thats an interesting outlook and an explanatory rationale. Can you explain the
implementation? Perhaps I can be persuaded. Right now, i'm not convinced about
hampering development mode in this way.
Cheers, Tim
On 9 Mar 2010, at 17:13, David Pollak wrote:
My development cycle has never worked well with JRebel.
First, I've got so many machines I do development on (5, 3 of which get
wiped each time Ubuntu releases a new version), getting all of those
machines set up with JRebel is something of a pain. Further, having JRebel
run in some cases is *ver
If the sitemap could be specified as a function JRebel could reload it.
One approach is along the lines that setSiteMap could be passed a function e.g.
()=>List[Menu]. In production mode the return value may or may not be cached.
Another approach is to have an optional method in Boot called say bu
No it doesn't work for sitemap... as thats loaded at boot only ;-) My point was
that it can still be a good experience without JR for our users.
Interesting what you were saying about your dev style... i'm usually the other
way around and implement sitemap last as I see it as a concrete setting
On Mar 9, 1:08 pm, Timothy Perrett wrote:
> BTW, with SBT, don't forget you can do:
>
> jetty-run
> (make changes to your code)
> prepare-webapp
>
> That will redeploy chnaged files / classses to the running jetty
> instance so development with SBT can still be slick without
> javarebel :-)
But on the other hand it happens not too often. I'm personally very
very happy with current productiveness using Lift + Jetty + JRebel.
But what happens when Zeroturnaround will turn back to Scala ? It is
quite possible that Scala will go mainstream. It might be viable
solution then.
Simple soluti
On Tue, Mar 9, 2010 at 12:08 PM, Timothy Perrett
wrote:
> BTW, with SBT, don't forget you can do:
>
> jetty-run
> (make changes to your code)
> prepare-webapp
>
> That will redeploy chnaged files / classses to the running jetty instance so
> development with SBT can still be slick without javarebe
BTW, with SBT, don't forget you can do:
jetty-run
(make changes to your code)
prepare-webapp
That will redeploy chnaged files / classses to the running jetty
instance so development with SBT can still be slick without
javarebel :-)
Lift is really elegant - some how, this approach feels pre
On Tue, Mar 9, 2010 at 9:33 AM, Timothy Perrett wrote:
> I'm afraid I agree with Marius... I'm just not sure on the benefit here over
> JRebel?
My main pain point was changes to Sitemap. JRebel doesn't help you
here as it's fixed once Lift is booted...
/Jeppe
--
You received this message becau
I'm afraid I agree with Marius... I'm just not sure on the benefit
here over JRebel?
Cheers, Tim
Sent from my iPhone
On 9 Mar 2010, at 08:05, Marius wrote:
I'm having seconds thoughts about this. Development mode can mean
slightly different things depending on the nature of the application
I'm having seconds thoughts about this. Development mode can mean
slightly different things depending on the nature of the application.
The things you enlisted are for me only PROS for not including this
feature.
Sorry but personally I don't see much value in this approach ... but
this doesn't mea
On Tue, Mar 9, 2010 at 2:42 AM, harryh wrote:
> What's the advantage of this sort of setup over using JavaRebel?
Sitemap and other things set in boot doesn't really change even if the
class is reloaded by JRebel
/Jeppe
--
You received this message because you are subscribed to the Google Group
It's less sensitive to inner class name changes and supports changing
interfaces.
Connected by MOTOBLUR™ on T-Mobile
-Original message-
From: harryh
To: Lift
Sent: Tue, Mar 9, 2010 01:42:10 GMT+00:00
Subject: [Lift] Re: More dynamic Lift
What's the advantage of this sor
What's the advantage of this sort of setup over using JavaRebel?
-harryh
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@g
18 matches
Mail list logo
