from:"Indrajit Raychaudhuri"

ExtCore is MIT Licensed and a candidate for JSArtifacts impl [1].
I started dabbling with an implementation of ExtCoreArtifacts sometime
back, but didn't have enough bandwidth to carry it forward.

In case somebody is willing to run with this, there is a ticket for
this already [2]

Non ExtCore are GPLed and doesn't mix conveniently. Although there are
some exceptions, I am not sure how practically that works license wise
[3].

Cheers, Indrajit

[1] http://www.extjs.com/products/extcore/
[2] http://www.assembla.com/spaces/liftweb/tickets/132
[3] http://www.extjs.com/products/floss-exception.php

On Wed, Mar 10, 2010 at 1:55 PM, Marius marius.dan...@gmail.com wrote:

Please see here
http://groups.google.com/group/liftweb/browse_thread/thread/5e4f5e424d33db40/32cfb6752954?lnk=gstq=ExtJs#32cfb6752954

I'd strongly encourage you to integrate ExtJs with Lift and
potentially other frameworks. Depending on JS library licence we'd be
happy to have integrations with other JS frameworks.

JsArtifacts should provide you the necessary abstractions for such
integrations but if you run into problems, please let us know.

On Mar 10, 8:27 am, Jim Barrows jim.barr...@gmail.com wrote:
On Tue, Mar 9, 2010 at 8:45 PM, aw anth...@whitford.com wrote:
It is time for me to add some serious widgets to my lift app.

So far, I am most enamored by ExtJS.
Another alternative could possibly be ZK.

Does anybody have any experience with these frameworks? Can you
comment on why integrating them with Scala/Lift would be a bad idea
(or not work)?

I searched for some historical posts on ExtJS and discovered some
threads about it's license and how it impacts inclusion in the lift
framework. Would a commercial license prohibit it from being a lift-
widget submodule candidate?

Does anybody have a better suggestion that you think can compete with
ExtJS?

I'm using ExtJS in anger at 0rk. 3.1.1 is nice. 3.0.0 is weird. Some odd
bugs being reported. We're also getting some weird interactions with some
other js libraries ( I won't mention it, it's not available anymore, and if
it was it just leave you scarred) and CSS. However, that's the other
libraries fault more then ExtJS's.

If you want something that looks and feels as close to a desktop app as you
can get.. ExtJS can do the job well. With Lift providing the JSON, it would
be hard to go wrong. That said.. ExtJS is not an easy beast to learn. It's
even worse to try and L10N it easily. I would not try and use just pieces
of it, it's really not designed to do that. It seems to me to be an all or
nothing approach. That's not say you can't use it piecemeal, I think you
lose a lot of flexibility (especially in layout) that way.

I wouldn't use it if left to my own devices though, unless I had a
requirement for a desktop app on the web. It's serious overkill.

--
James A Barrows

--
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...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Serious widget action

Most certainly, yes! Quite like what Anthony is looking for. But (a)
this is different from JSArtifacts implementation for ExtCore that we
talked about couple of times and (b) Cappuccino isn't license
compatible either (for the purpose of integration within Lift).

Anthony, fwiw, David did some stuff on this last year that could be of
some interest to you :) [1]

Cheers, Indrajit

[1] http://github.com/dpp/Frothy

On Wed, Mar 10, 2010 at 2:45 PM, Timothy Perrett
timo...@getintheloop.eu wrote:
 Personally, I would say forget ExtJS, compared to Cappuccino its streets 
 behind:

 http://cappuccino.org/

 Easily the most exciting UI framework out there right now

 Cheers, Tim

 On 10 Mar 2010, at 03:45, aw wrote:

 It is time for me to add some serious widgets to my lift app.

 So far, I am most enamored by ExtJS.
 Another alternative could possibly be ZK.

 Does anybody have any experience with these frameworks?  Can you
 comment on why integrating them with Scala/Lift would be a bad idea
 (or not work)?

 I searched for some historical posts on ExtJS and discovered some
 threads about it's license and how it impacts inclusion in the lift
 framework.  Would a commercial license prohibit it from being a lift-
 widget submodule candidate?

 Does anybody have a better suggestion that you think can compete with
 ExtJS?

 --
 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...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/liftweb?hl=en.



 --
 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...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/liftweb?hl=en.



-- 
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Re: Serious widget action

On 10/03/10 3:21 PM, Timothy Perrett wrote:

The only possible thing that one could do would need two aspects:

1. The lift side to produce particular JSON
2. The capp side to consume said JSON

Without a full package, there aren't really any integration points as we have
already got comet working with capp so the only thing remaining is overall user
implementation experience.

+1 And some docs, may be.

The previous discussion thread on this:
http://groups.google.com/group/liftweb/browse_thread/thread/41839eee55ab8e2b/de6ed5b83242ab16

Cheers, Indrajit

Cheers, Tim

On 10 Mar 2010, at 09:40, Mads Hartmann Jensen wrote:

+1 for cappuccino

Played around with it a while back - it's pretty amazing.

What kind of intergration are we talking about? I wouldn't mind taking a look
at intergrating cappuccino.

On 10/03/2010, at 10.37, Indrajit Raychaudhuri wrote:

ExtCore is MIT Licensed and a candidate for JSArtifacts impl [1].
I started dabbling with an implementation of ExtCoreArtifacts sometime
back, but didn't have enough bandwidth to carry it forward.

In case somebody is willing to run with this, there is a ticket for
this already [2]

Non ExtCore are GPLed and doesn't mix conveniently. Although there are
some exceptions, I am not sure how practically that works license wise
[3].

Cheers, Indrajit

[1] http://www.extjs.com/products/extcore/
[2] http://www.assembla.com/spaces/liftweb/tickets/132
[3] http://www.extjs.com/products/floss-exception.php

On Wed, Mar 10, 2010 at 1:55 PM, Mariusmarius.dan...@gmail.com wrote:

Please see here
http://groups.google.com/group/liftweb/browse_thread/thread/5e4f5e424d33db40/32cfb6752954?lnk=gstq=ExtJs#32cfb6752954

I'd strongly encourage you to integrate ExtJs with Lift and
potentially other frameworks. Depending on JS library licence we'd be
happy to have integrations with other JS frameworks.

JsArtifacts should provide you the necessary abstractions for such
integrations but if you run into problems, please let us know.

On Mar 10, 8:27 am, Jim Barrowsjim.barr...@gmail.com wrote:

On Tue, Mar 9, 2010 at 8:45 PM, awanth...@whitford.com wrote:

It is time for me to add some serious widgets to my lift app.

So far, I am most enamored by ExtJS.
Another alternative could possibly be ZK.

Does anybody have any experience with these frameworks? Can you
comment on why integrating them with Scala/Lift would be a bad idea
(or not work)?

Does anybody have a better suggestion that you think can compete with
ExtJS?

I wouldn't use it if left to my own devices though, unless I had a
requirement for a desktop app on the web. It's serious overkill.

--
James A Barrows

[Lift] lift-core would be removed from repository shortly


Folks,

As discussed earlier, lift-core would be removed from repository 
sometime soon. For the deprecation notice and the rationale, please take 
a look at the announcement posted earlier [1].


If your application is still using lift-core, make the changes NOW! Soon 
it would stop working with 2.0-SNAPSHOT. The upcoming 2.0-M4 would not 
have it either.


Cheers, Indrajit

[1] 
http://groups.google.com/group/lift-announce/browse_thread/thread/28e9149425d8e6f3


--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Enable -Xcheckinit in 2.8 port?




On 08/03/10 11:48 PM, David Pollak wrote:



On Mon, Mar 8, 2010 at 10:01 AM, Jeppe Nejsum Madsen je...@ingolfs.dk
mailto:je...@ingolfs.dk wrote:

Hi,

Just found out why the Logging stuff doesn't work on the 2.8 branch.
Details here:
http://permalink.gmane.org/gmane.comp.lang.scala.user/24469

Is it somehow possible to enable the -Xcheckinit flag for the 2.8
branch? Don't know how common that issue is, but it may help trap some
subtle errors.  Don't know what the performance penalty is though.


Let's enable the flag for the 2.8 branch along with the deprecation flag
(Indrajit, can you do this?)


Use the profile -Dlift-debug for the purpose. It has the deprecation 
flag, I'll add the checkinit flag.


- Indrajit




/Jeppe

--
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
mailto:liftweb@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
mailto:liftweb%2bunsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.




--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--
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...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.


--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Potential breaking change

2010-03-05 Thread Indrajit Raychaudhuri


Mads/Ross,

You have the requisite rights now. Feel free to post to lift-announce :)

Cheers, Indrajit


On 05/03/10 2:08 PM, Mads Hartmann Jensen wrote:

Tried to post this to lift-announce but I don't have permission - I did join 
the group though so not sure why. How do i optain permission? I think that Ross 
Mellgren is having the same issue

Thanks
Mads Hartmann Jensen

On 04/03/2010, at 22.37, Mads Hartmann wrote:


If 'blob' is not a keyword in your DB and you're currently using blob
as a column name you should change it to blob_c

This is a cause of fixing issue 402

Thanks,
Mads Hartmann Jensen

--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.





--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] non snapshot version of lift for scala 2.8


Lukasz,

We don't have non-SNAPSHOT version of Lift for scala 2.8 branch yet.
You are encouraged to use 2.0-scala280-SNAPSHOT and report any issue 
that you encounter.


Cheers, Indrajit

On 04/03/10 2:41 PM, Lukasz Kuczera wrote:

Hi Folks.
I'm working on lift 2.0-scala280-SNAPSHOT. What is current recommended
stable version for scala 2.8 ?



--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] non snapshot version of lift for scala 2.8



On 04/03/10 3:26 PM, Jeppe Nejsum Madsen wrote:

On Thu, Mar 4, 2010 at 10:39 AM, Indrajit Raychaudhuri
indraj...@gmail.com  wrote:

Lukasz,

We don't have non-SNAPSHOT version of Lift for scala 2.8 branch yet.
You are encouraged to use 2.0-scala280-SNAPSHOT and report any issue that
you encounter.


Is there a status of the 2.8 branch somewhere on what works and what
doesn't? (Ie. are some modules missing, known things that don't work)
Or is everything ported and stuff that doesn't work is a defect?


The only module missing at the moment is lift-osgi and related ones 
because it is dependent on 2.8 port of scalamodules. Heiko said one is 
on its way as an Eclipse project (www.eclipse.org/proposals/scalamodules).


The rest are either of:
- defects
- non-functional because of API change
- sub-optimal design
- combination of the above

(look for the comment FIXME: 280 in the code-base)



I would love to get to the 2.8 Eclipse plugin and I've just started a
new Lift project where I can accept some bumps along the road, but
I've held off until now because I wasn't really sure of the status


If you can accept the bumps, you are welcome to give scala 2.8 port a 
shot. This would be great in fact.




/Jeppe



--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Re: New logging code is in master




On 04/03/10 10:42 PM, Stuart Roebuck wrote:

Trying this on 2.8 with the 2.8 Lift Snapshot.

The Logger trait seems to work fine though looking at the code I can't
see how setup gets called.

The Loggable trait is throwing a null pointer exception.


Yes, this is a known one. We encountered this in LoggingSpec too. 
Jeppe/myself would look into it.




I'm using Log4J.

Stuart.

P.S.  I don't want to mess with other people's wiki pages, but I
wonder whether it is worth consolidating the pages: How To: Configure
Logging and Logging in Lift.


On Mar 2, 12:49 am, awanth...@whitford.com  wrote:

Very nice!  I am looking forward to this.

On Feb 28, 8:14 am, Jeppe Nejsum Madsenje...@ingolfs.dk  wrote:




The newloggingcode is now in master and should be fully usable.
Therefore, the existingloggingcode has been deprecated.



I've added a Wiki article 
here:http://wiki.github.com/dpp/liftweb/logging-in-lift



/Jeppe




--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] conflicting slf4j versions when using M3 with smile


You can modify smile dependency declaration to exclude slf4j-jdk14 as thus:

dependency
  groupIdnet.lag/groupId
  artifactIdsmile/artifactId
  exclusions
exclusion
  groupIdorg.slf4j/groupId
  artifactIdslf4j-jdk14/artifactId
/exclusion
  /exclusions
/dependency

Or alternately, apply the exclusion of slf4j-log4j12 in the lift-util 
dependency section if you prefer to use slf4j-jdk14 instead.


Cheers, Indrajit

On 05/03/10 12:51 AM, harryh wrote:

Smile (a scala memcached client) is pulling in slf4j-jdk14-1.5.2.jar,
and lift-util is pulling in slf4j-log4j12-1.5.11.jar.

What is the best way to deal with this conflict?

-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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Re: conflicting slf4j versions when using M3 with smile




On 05/03/10 1:05 AM, harryh wrote:

OK, did that (like so in sbt):

override def ivyXML =
 dependencies
   dependency org=net.lag name=smile rev=0.8.12
 exclude module=slf4j-jdk14/
   /dependency
 /dependencies

I'm also getting this error when running my app from within sbt just
javarebel (possibly this isn't a big issue, but the error is
disconcerting):


Hmm, slf4j-log4j12-1.5.11.jar ends up being in the classpath twice (from 
/Users/harryh/foursquare.web/lib_managed/compile and 
/Users/harryh/foursquare.web/target/webapp/WEB-INF/lib).


A quick fix would be to apply exclusion of slf4j-log4j12 in lift-util 
declaration. This will prevent having slf4j-log4j12-1.5.11.jar under 
target/webapp/WEB-INF/lib.


- Indrajit



SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/Users/harryh/foursquare.web/
lib_managed/compile/slf4j-log4j12-1.5.11.jar!/org/slf4j/impl/
StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/Users/harryh/foursquare.web/target/
webapp/WEB-INF/lib/slf4j-log4j12-1.5.11.jar!/org/slf4j/impl/
StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an
explanation.

On Mar 4, 2:33 pm, Indrajit Raychaudhuriindraj...@gmail.com  wrote:

You can modify smile dependency declaration to exclude slf4j-jdk14 as thus:

  dependency
groupIdnet.lag/groupId
artifactIdsmile/artifactId
exclusions
  exclusion
groupIdorg.slf4j/groupId
artifactIdslf4j-jdk14/artifactId
  /exclusion
/exclusions
  /dependency

Or alternately, apply the exclusion of slf4j-log4j12 in the lift-util
dependency section if you prefer to use slf4j-jdk14 instead.

Cheers, Indrajit

On 05/03/10 12:51 AM, harryh wrote:




Smile (a scala memcached client) is pulling in slf4j-jdk14-1.5.2.jar,
and lift-util is pulling in slf4j-log4j12-1.5.11.jar.



What is the best way to deal with this conflict?



-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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] minified js artifacts (was Re: Re-opened #363)


A quick followup on this minified js concern...

The initial reason why I reopened still holds [1]

Marius and I had a quick chat on this point over IM where we agreed to 
take it up separate from this particular ticket and see if we can arrive 
at a consensus.


Conventionally, Lift keeps the un-minified js artifacts in the git 
repository and yuicompressor minifies them at build time. The templates 
still keep on referring to the un-minfied form (json2.js, jquery.js 
etc.) but ResourceServer/JSArtifact does the magic of rewriting the 
request path to serve the minified js created at build time.


While JQuery13Artifacts follows this convention (references 
jquery-1.3.2-min.js generated at build time), JQuery14Artifacts doesn't 
(reference jquery-1.4.2.min.js as distributed from jQuery.com). 
Consequently, src/main/resources/toserve contains jquery-1.3.2.js (the 
un-minified form) but jquery-1.4.2.min.js (the minified form) [2].


This is clearly inconsistent and confusing unless one is aware of the 
build-time trick.


So the question is, should we:

1. Continue using yuicompressor (to compress js files at build time) and 
apply the strategy universally to all toserve/**/*.js

OR
2. Include the minified version of the js artifacts and get rid of the 
build time compression trick


While #1 has the clear advantage of having human-readable js files in 
the repository, it is critically dependent on build time compression. 
Exact opposite set of argument holds for #2.


And since we are debating on this, the other option could be:

3. Keep both the form (un-minified and minified) available in 
resources/toserve and serve the un-minified form via gzip filter if 
user-agent has support for it (most does nowadays) or resort to minified 
form if user-agent doesn't. The behavior could be controlled via 
LiftRules even. Of course, this assumes that most production sites would 
be behind reverse proxies with proper cache control etc. and the 
overhead of gzip-ing is marginal. Bringing the decision (of minifying) 
in the framework realm also opens up the possibility of lazily creating 
one big js (synthetic or cached) and serving the entire stuff as one 
single response minified or otherwise depending on run.mode.


Thoughts?

- Indrajit

[1] http://www.assembla.com/spaces/liftweb/tickets/363?page=1#comment%3A2
[2] It still contains the vestigial jquery-1.4.1.js which needs to be 
removed after today's release



On 01/03/10 3:00 AM, Indrajit Raychaudhuri wrote:

I reopened #363 because according to Lift convention, JQuery14Artifacts
should actually refer to the compressed version of jquery-1.4.2 min that
is generated by yuicompressor-maven-plugin (and not minified version
available for download).

Marius, let me know if you agree to this, if not we should actually go
the other way round for the other bundled js (like jquery 1.3) as well
to be consistent.

Cheers, Indrajit


--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] minified js artifacts (was Re: Re-opened #363)




On 03/03/10 9:21 PM, Jeppe Nejsum Madsen wrote:

Indrajit Raychaudhuriindraj...@gmail.com  writes:


A quick followup on this minified js concern...


[...]


So the question is, should we:

1. Continue using yuicompressor (to compress js files at build time)
and apply the strategy universally to all toserve/**/*.js
OR
2. Include the minified version of the js artifacts and get rid of the
build time compression trick

While #1 has the clear advantage of having human-readable js files in
the repository, it is critically dependent on build time
compression. Exact opposite set of argument holds for #2.


Or 2.5: use 1. for the js artifacts included with Lift and let the user
decide how to handle their own js files. I would hate to be forced into
using the yui compressor for my own files that I put in toserve (not
that it isn't a good idea :-)


Yep, just disable yui compressor in your application pom.xml and this 
would be quite the case (because lift-webkit-version.jar has already 
being created by now with the minified js either using #1 or #2).


My interest in the current context, is to have consistent behavior in 
the js artifacts bundled with Lift.


To me (and Marius) #2 is also worth consideration. True that you'd have 
a compressed (IDE unfriendly) js in the codebase but you'd also be able 
to remove build-time dependency on yui compressor. (one less dependency, 
one less step etc.)






And since we are debating on this, the other option could be:

3. Keep both the form (un-minified and minified) available in
resources/toserve and serve the un-minified form via gzip filter if
user-agent has support for it (most does nowadays) or resort to
minified form if user-agent doesn't.


But gzip doesn't remove the need for minify. Gzipped minified jQuery is
40% smaller than gzipped jQuery:

http://stackoverflow.com/questions/807119/gzip-versus-minify


I learned this today, thank you!





The behavior could be controlled via LiftRules even. Of course, this
assumes that most production sites would be behind reverse proxies
with proper cache control etc. and the overhead of gzip-ing is
marginal. Bringing the decision (of minifying) in the framework realm
also opens up the possibility of lazily creating one big js (synthetic
or cached) and serving the entire stuff as one single response
minified or otherwise depending on run.mode.


Yes this would be the ideal and has been discussed on the list
recently.


I realize I have to catch up with the recent discussions, am way out of 
sync :(




/Jeppe



--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Transactions with Mapper




On 03/03/10 9:58 PM, David Pollak wrote:



On Tue, Mar 2, 2010 at 5:53 AM, Timothy Perrett timo...@getintheloop.eu
mailto:timo...@getintheloop.eu wrote:

Probally worth sticking this on the wiki

Cheers, Tim

Sent from my iPhone


Wait... you've got a broken hand and you can still type on your
iPhone?!?! :-)


Guess Tim types one handed and he is not a lefty :-)





On 2 Mar 2010, at 14:37, Jeppe Nejsum Madsen je...@ingolfs.dk
mailto:je...@ingolfs.dk wrote:

ced docpom...@googlemail.com mailto:docpom...@googlemail.com
writes:

When I use Mapper outside a request, say in an actor, how do
I wrap it
in a transaction? I know that I do a
S.addAround(DB.buildLoanWrapper)
to have transactions within a request.
Can anyone provide a simple code snippet?


You can use use :-)

DB.use(DefaultConnectionIdenfifier) {connection =
  User.findAll 
}

/Jeppe

--
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
mailto:liftweb@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
mailto:liftweb%2bunsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.



--
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
mailto:liftweb@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
mailto:liftweb%2bunsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.




--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--
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...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.


--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] minified js artifacts (was Re: Re-opened #363)




On 03/03/10 10:21 PM, Jeppe Nejsum Madsen wrote:

Indrajit Raychaudhuriindraj...@gmail.com  writes:

[...]


My interest in the current context, is to have consistent behavior in
the js artifacts bundled with Lift.

To me (and Marius) #2 is also worth consideration. True that you'd
have a compressed (IDE unfriendly) js in the codebase but you'd also
be able to remove build-time dependency on yui compressor. (one less
dependency, one less step etc.)


But why is it a problem with the build-time dependency on yui compressor
if it only concerns the building of the lift-*.jar? Or am I missing
something?


No question with the worthiness of yui-compressor as such, it does the 
job perfectly and great for the purpose :) It about when to use it.


If we are using it to minify the set of third party js files (jquery, 
json etc.) repeatedly which never change we might as well consider 
keeping the minified form directly. Hence the worthiness behind 
consideration. Note that Lift's internal js files (e.g., jlift.js) are 
fine going the yui-compressor route.


But more than anything, we need to be consistently following either of 
these (particularly for the 3rd party js artifacts).




Ideally the lift jars should contain both, and the non-minified used in
development.


Yes, better. Which actually led to the other thought (#3). But git 
should contain only one form in that case (the un-minified one).




/Jeppe



--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] Lift Web Framework 2.0 Milestone 3 released

The Lift Web Framework team is pleased to announce the framework-2.0-
M3 release!

Lift is an expressive and elegant framework for writing web
applications. Lift stresses the importance of security,
maintainability, scalability and performance while allowing for high
levels of developer productivity. Lift is a Scala web framework.

NOTE: The potential *breaking changes* have been specifically marked
for your reference. Please take a look at the specific issue at
http://www.assembla.com/spaces/liftweb/tickets and the Lift
announcement list for further details.

Changes in this version include:

New features:
o A flag for disabling the onblur stuff for ajax calls  Issue: 117.
o Added toHtml method to Mapper/MetaMapper  Issue: 350.
o Added support for area tags  Issue: 70.
o Added NOT IN to Mapper query builder  Issue: 353.
o Enhancements to LiftActors and LRU to support Goat Rodeo  Issue:
335.
o ByList is uniqued before the query is built  Issue: 298.
o Added linkToSelf option to Menu.build snippet  Issue: 343.
o xxxMenuLoc methods now delegate to protected xxxMenuLocParams
methods in order to get their LocParams.  Issue: 251.
o Extend Comet (ListenerManager) to selectively update subscribers
Issue: 326.
o Add DataBinding types and traits to lift-webkit  Issue: 212.
o Add CouchDB support (lift-couchdb)  Issue: 306.
o Integrate Image manipulation code to lift  Issue: 285.
o Add support to extract primitive values from JSON  Issue: 360.
o ItemsListEditor (and thus TableEditor) should warn when leaving page
with unsaved changes  Issue: 339.
o ItemsListEditor should display items pending removal, albeit in
strikeout font  Issue: 302.
o ItemsList.save unremoves removed unsaved items  Issue: 300.
o ItemsList should be have refresh method to clear added/removed
without requerying database  Issue: 299.
o ItemsListEditor should allow custom columns  Issue: 301.
o ItemsListEditor should catch SQLException in ItemsList.save  Issue:
340.

Fixed Bugs:
o Fixed a stack overflow on non-tail recursive method  Issue: 393.
o Allow Foreign Key support to be optional in PostgreSQL driver
Issue: 387.
o Scope attributes duplicated in certain cases. Fixed those cases.
Issue: 373.
o Better support for exceptions in DB Logging  Issue: 369.
o Further work to make sure control characters don't show up in XML
output.  Issue: 319.
o Fix runtime errors in a couple of example programs  Issue: 342.
o Issues with template cache updating incorrectly  Issue: 367.
o Fixed a comparison bug in ReplaceOption (wishing for type-safety in
==)  Issue: 296.
o Support for Scala 2.8 deltas in the way Nodes are compared  Issue:
357.
o 304 responses should not include Content-Type headers  Issue: 239.
o Fixed misspelled keys for resource bundles: *pasword* and
reset.password.confirmarion  Issue: 112.
o Optional fields in JSONRecord do not work without setting
needAllJSONFields to false  Issue: 359.
o JSON deserialization fails for null value  Issue: 358.
o Type hints are needed in JSON serialization for non-polymorphic Map
Issue: 341.
o Do not serialize the internal state of a case class (JSON)  Issue:
352.
o Forcing Authentication not working  Issue: 337.
o Autocomplete never submit value  Issue: 27.
o Javascript DSL inconsistencies  Issue: 287.
o Solve CSS/JS unwanted caching  Issue: 346.

Changes:
o Support for enhancing foreign key references in PostgreSQL 8.3+
Issue: 224.
o Have minimal support for archetype:create telling user to use
archetype:generate instead  Issue: 238.
o Internationalizing missing strings in ProtoUser  Issue: 320. Thanks
to Adam Warski.
o Enforce Maven version 2.2.1 or higher, but lower than 3.0.  Issue:
344.
o lift-flot has been updated to Flot 0.6  Issue: 322.
o Make OpenID support more extensible  Issue: 329.
o [BREAKING CHANGE] Lift Mapper (Record) camelCase to snake_case for
case insensitive databases  Issue: 155.
o [BREAKING CHANGE] Improved logging facilities  Issue: 309.
o Deprecate old logging code  Issue: 374.
o Enhance Facebook Connect utilities and example code  Issue: 336.
o Add ability to use doc result of query, not just value  Issue: 356.
o [BREAKING CHANGE] Add Optional variants of the basic record fields
Issue: 305.
o Update lift-couchdb to use dispatch 0.7.1 once released  Issue:
351.
o [BREAKING CHANGE] LiftRules.jQueryVersion should not be there.
Issue: 363.


Have fun!
-Lift Web Framework team

-- 
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Happy 3rd Anniversary to Lift


+1 Huge honor to be a part of the community.
Thank you David, thank you early committers, thank you early adopters.

- Indrajit

On 27/02/10 7:16 PM, Heiko Seeberger wrote:

I am proud to be on board and looking forward to the next three years

Heiko

On Saturday, February 27, 2010, David Pollak
feeder.of.the.be...@gmail.com  wrote:

Folks,

Today is Lift's 3rd Anniversary/Birthday!

Before I go offline for the weekend, I wanted to give a hearty thanks for the 
Scala team, the Scala community, the Lift committers, and most importantly the 
Lift community members new and old for making Lift possible, fun, and 
challenging.

Thank you all very, very much for everything each and everyone one of you has 
done.

David
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics


--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.





--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] New logging code is in master


Finally! Great job, Jeppe.

- IRC

On 28/02/10 9:44 PM, Jeppe Nejsum Madsen wrote:

The new logging code is now in master and should be fully usable.
Therefore, the existing logging code has been deprecated.

I've added a Wiki article here:
http://wiki.github.com/dpp/liftweb/logging-in-lift

/Jeppe



--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Re: [lift] scalajpa for 2.8

You are using scalajpa-1.2-SNAPSHOT which is built with Scala 2.7.x and 
thus binary incompatible with Scala 2.8.


To use 2.8 port of scalajpa, you should be using the version 
scalajpa-1.2-scala280-SNAPSHOT.


Your best bet would be to start with a lift-jpa archetype from 2.8 
branch. You could create a project from lift-archetype-jpa-basic as thus:


mvn archetype:generate \
  -DarchetypeRepository=http://scala-tools.org/repo-snapshots \
  -DremoteRepositories=http://scala-tools.org/repo-snapshots \
  -DarchetypeGroupId=net.liftweb \
  -DarchetypeArtifactId=lift-archetype-jpa-basic \
  -DarchetypeVersion=2.0-scala280-SNAPSHOT \
  -DgroupId=com.mypackage \
  -DartifactId=myproject \
  -Dversion=1.0-SNAPSHOT

The project thus created would be using the right version of scalajpa 
(built on Scala 2.8).


Cheers, Indrajit

On 28/02/10 6:34 PM, sjcarroll6 wrote:


I've downloaded the scalajpa-1.2SNAPSHOT. I am now getting the following
error: Error while loading ScalaEntityManager, Scala signature entity
manager has wrong version, expecting 5 found 4.1 in scalajpa-1.2-SNAPSHOT.
Any help in resolving this issue would be helpful.


sjcarroll6 wrote:


I was able to locate the 1.2 snapshot. From this I was able to find out
that this was initial port for 2.8. I'm trying to read Proj JPA and
converting the java code to scala. Since  I don't know much about scala or
JPA this is proving to be a challenge. If anyone could point me to a
simple LocalEMF CRUD example that would be great. Also, if anyone could
indicate if scalajpa 1.2 has any known issues with JPA 2.0 eclipselink
that would be helpful.

Thank you


sjcarroll6 wrote:


Are there any known issues with using scalajpa with 2.8? I read one post
which indicated scalajpa will need to be updated for 2.8 but it wasn't
clear if the existing version was still usable.

Thanks,








--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] Re-opened #363

I reopened #363 because according to Lift convention, JQuery14Artifacts 
should actually refer to the compressed version of jquery-1.4.2 min that 
is generated by yuicompressor-maven-plugin (and not minified version 
available for download).


Marius, let me know if you agree to this, if not we should actually go 
the other way round for the other bundled js (like jquery 1.3) as well 
to be consistent.


Cheers, Indrajit

--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Re: Master is fundamentally broken!!!!!!

2010-02-24 Thread Indrajit Raychaudhuri


Done in master. Wait for Hudson to respin.
Committers, sorry for direct commit to master and breaking the rule but 
Tim's need was urgent.


Have done quick smoke test locally.

- Indrajit

On 24/02/10 6:56 PM, Timothy Perrett wrote:

I can verify that the issue causing this is:
703a728af05fddda0f8c5e302cce21a9dc065b54

Can we please back this change out as this is affecting ALL lift
applications

Cheers, Tim

On Feb 24, 1:09 pm, Timothy Perretttimo...@getintheloop.eu  wrote:

Scratch that, it just does this all the time - irrelevant of the mime
type.

Reproduce this by making a blank lift app and looking at the source.

Cheers, Tim

On Feb 24, 11:14 am, Timothy Perretttimo...@getintheloop.eu  wrote:




Guys,



I see DPP made a bunch of commits last night. Something in there has
fundamentally broken the markup parser. Yesterday I deploy an
application to production and today I go to update a small bit of copy
that marketing want changed and i'm finding that my application is
broken



With LiftRules.useXhtmlMimeType = false in Boot, I see the following:



script type=text/javascript
//lt;![CDATA[
jQuery(document).ready(function()
{liftAjax.lift_successRegisterGC();});
var lift_page =quot;F1075228527421HHAquot;;
// ]]gt;
/script



This is obviously problematic and all my javascript in my application
is now doing this. Sorry to be grizzly about this, but its totally
untenable for me to be building apps that work one day and are broken
the next... I tried reverting to 2.0-M2, but that was giving me errors
about not being able to boot SessionMaster. If we are changing stuff
in the core of Lift, we need a good number of eyes (that is, people
who are ACTIVE committers) on the changes in review board otherwise
stuff like this happens (certainly, I don't remember getting review
requests for any of these changes that are now causing me
problems...)



I have to get this fixed today otherwise im going to be seriously
flamed.



A very unhappy Tim.




--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Re: Setting run mode for Lift applications

Given that setting initParams is the usual webapp idiom, should we not 
consider that at all? That would have served the purpose for Petr.


So the calcRunMode could roughly have something like:

customRunMode or context.initParam(run.mode) or 
Box.!!(System.getProperty(run.mode))


with provision for having customRunMode customized heartily.

Cheers, Indrajit


On 22/02/10 1:50 PM, Jeppe Nejsum Madsen wrote:

On Mon, Feb 22, 2010 at 8:48 AM, Heiko Seeberger
heiko.seeber...@googlemail.com  wrote:

Folks,
I really do not understand the value of setting the run mode statically via
code in LiftRules. The run mode should be set externally, right? In order to
use the same artifact (WAR) on a dev or a prod server.
Heiko


Agreed. This was more so that people could change how externally is
defined, ie in a hosted env you can't change system properties.

The default would still be the current lookup in system properties,
but you could change this to look at servlet params, hostname, day of
month etc :-)

/Jeppe



--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Re: Comet issue for Lift-2.0-scala280-SNAPSHOT


Understood, just wanted to ensure.

Cheers, Indrajit

On 22/02/10 4:25 PM, tbje wrote:

Hi Indrajit,
I was a little bit lazy and updated an old pom by hand.

Just pushed a new pom.xml using the following mvn
archetype:generate :

mvn archetype:generate -U -DarchetypeGroupId=net.liftweb -
DarchetypeArtifactId=lift-archetype-blank -DarchetypeVersion=2.0-
scala280-SNAPSHOT -DarchetypeRepository=http://scala-tools.org/repo-
snapshots -DremoteRepositories=http://scala-tools.org/repo-snapshots

Didn't solve the problem :(

Best regards
Trond





On 19 Feb, 16:32, Indrajit Raychaudhuriindraj...@gmail.com  wrote:

Trond,

  From cursory glance it appears that some old form of archetype (pre
Lift 2.0) had been used to generate the project. What command line
option did you use in mvn archetype:generate to create the project?

This is just a request for qualification.

Cheers, Indrajit

On 19/02/10 8:22 PM, tbje wrote:




Thank you for rapid replies and a great framework. I opened ticket
#357 for this issue.



Best regards
Trond



On 19 Feb, 15:22, Mariusmarius.dan...@gmail.comwrote:

Yeah AFAIK Scala 2.8 integration is not 100% done and fully tested.



Br's,
Marius



On Feb 19, 3:52 pm, tbjetrond.bjerkestr...@gmail.comwrote:



Hi Marius,
I discovered the issue while porting a working application from 2.7.7
to lift 2.0-scala280-SNAPSHOT and scala 2.8.0.Beta1.



In the example application I provided it's possible to change the
pom.xml by replacing
scala.version2.8.0.Beta1/scala.version
lift.version2.0-scala280-SNAPSHOT/lift.version
with
scala.version2.7.7/scala.version
lift.version2.0-SNAPSHOT/lift.version
and the application is working as I'd like it to :)



I therefor believe it's a lift 2.0-scala280 issue.



Best regards
Trond



On 19 Feb, 14:12, Mariusmarius.dan...@gmail.comwrote:



Can you also try with Scala 2.7.7 ?



On Feb 19, 2:26 pm, tbjetrond.bjerkestr...@gmail.comwrote:



Hi,
I've been testing out the Lift-2.0-scala280-SNAPSHOT a little bit and
found a issue with Comet actor, setHtml and ajaxInvoke.



When trying to invoke the following partial update nothing seems to
happen:
partialUpdate(SetHtml(field,input type=button
onclick={ajaxInvoke(() =JsRaw(alert('hi')))._2} value=Say hi /



))



This works as expected however:
partialUpdate(SetHtml(field, a(() =JsRaw(alert('hi')),
spanLink/span)))



I've created a example app to illustrate the problem if someone is
interested:



git://github.com/tbje/Lift-2.0-scala280-SNAPSHOT-issue.git



Best regards
Trond




--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Textmate bundle with codecompletion (beta)


Heavens! Need to give this a shot.

On 22/02/10 4:55 PM, Mads Hartmann wrote:

Hello everyone,
I've been working a bit on a TextMate bundle for Lift projects that
has codecompletion. It's still very beta but I'm sure someone would
find it helpfull :)

If you're interested you can read a bit more about it here:
http://www.sidewayscoding.com/2010/02/lift-textmate-bundle-now-with-primitive.html

NB: It's nowhere near as good as what I've seen in intelliJ (haven't
tried netbeans or eclipse) but that doesn't mean it isn't helpful :)

If you want to help out, please fork me on github http://github.com/mads379



--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] Re: ProtoUser i18n

On RB: http://reviewboard.liftweb.net/r/223/

Cheers, Indrajit

On Feb 3, 9:36 pm, Indrajit Raychaudhuri indraj...@gmail.com wrote:
 Thanks Adam, I'll take this one up :)

 - Indrajit

 On 03/02/10 12:48 PM, Adam Warski wrote:



  Sure:

  (a)http://github.com/dpp/liftweb/issues/issue/320
  (b)http://gist.github.com/293435

  I've also updated the wiki.

  On Feb 2, 2010, at 8:10 PM, Indrajit Raychaudhuri wrote:

  Adam, can you please (a) open a ticket and (b) create a gist 
  (http://gist.github.com/) of the patch and refer to it from the ticket? 
  We'll take it up from there.

  Tim, +1 on not having spaces in properties.

  Cheers, Indrajit

  On 02/02/10 10:41 PM, Timothy Perrett wrote:
  Sure - one of us will take this up... its minor.

  I propose we agree a policy, and use that going forward... should keys 
  have spaces? no would be my default response... (i tend to separate 
  with full stops) if thats so, lets just clear that out now, and do a 
  breaking changes ann.

  Cheers, Tim

  On 2 Feb 2010, at 17:06, David Pollak wrote:

  I'm okay with breakage here.  Jeppe, Indrajit, or Tim, can you guys 
  handle this issue going forward (making sure the patch is good, putting 
  it on a branch, opening a ticket, putting it on review board, and 
  sending out any breaking changes email)?

  --
  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...@googlegroups.com.
  For more options, visit this group 
  athttp://groups.google.com/group/liftweb?hl=en.

-- 
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] IMPORTANT White space separator is discontinued for resource keys

Folks,

If you are an i18n type, read it!

Going forward we are making two policy changes in the naming
convention for i18n resource keys; viz., Discontinuing the usage of
white space to separate keys and preferring all.lower.case for the
keys.

So in you locale properties file, instead of:
Current\ Mood=What ya up to?
you would be writing:
current.mood=What ya up to?

While the former is perfectly valid in in Java (and thus in Scala),
the usage is awkward and confusing. It also throws the IDE code
inspectors off the track :) Further, it's good convention to have the
keys in lower case character.

All the built-in resources in lift-core.properties (and the other
existing locale variant) have been updated. ProtoUser has also been
updated to to reflect the same.

Please reply back to this post if you see something missing.

Cheers, Indrajit

[1] 
http://groups.google.com/group/liftweb/browse_thread/thread/7c31bc68e33bf0e0/731da62cfc406821
[2] http://www.assembla.com/spaces/liftweb/tickets/320
[3] 
http://github.com/dpp/liftweb/commit/8d012190168574279369af19dd29f0b5d4086796

-- 
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Re: Setting run mode for Lift applications



On 22/02/10 3:22 PM, Indrajit Raychaudhuri wrote:

Given that setting initParams is the usual webapp idiom, should we not
consider that at all? That would have served the purpose for Petr.

So the calcRunMode could roughly have something like:

customRunMode or context.initParam(run.mode) or
Box.!!(System.getProperty(run.mode))

with provision for having customRunMode customized heartily.


On second thought, the order probably should be other way round.

Box.!!(System.getProperty(run.mode)) or context.initParam(run.mode) 
or customRunMode


-Drun.mode=... is more transient (and suitable for fast mode switching 
during development) than static definition in the code and thus to be 
tried first.




Cheers, Indrajit


On 22/02/10 1:50 PM, Jeppe Nejsum Madsen wrote:

On Mon, Feb 22, 2010 at 8:48 AM, Heiko Seeberger
heiko.seeber...@googlemail.com wrote:

Folks,
I really do not understand the value of setting the run mode
statically via
code in LiftRules. The run mode should be set externally, right? In
order to
use the same artifact (WAR) on a dev or a prod server.
Heiko


Agreed. This was more so that people could change how externally is
defined, ie in a hosted env you can't change system properties.

The default would still be the current lookup in system properties,
but you could change this to look at servlet params, hostname, day of
month etc :-)

/Jeppe



--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Re: Comet issue for Lift-2.0-scala280-SNAPSHOT

2010-02-19 Thread Indrajit Raychaudhuri


Trond,

From cursory glance it appears that some old form of archetype (pre 
Lift 2.0) had been used to generate the project. What command line 
option did you use in mvn archetype:generate to create the project?


This is just a request for qualification.

Cheers, Indrajit

On 19/02/10 8:22 PM, tbje wrote:

Thank you for rapid replies and a great framework. I opened ticket
#357 for this issue.

Best regards
Trond




On 19 Feb, 15:22, Mariusmarius.dan...@gmail.com  wrote:

Yeah AFAIK Scala 2.8 integration is not 100% done and fully tested.

Br's,
Marius

On Feb 19, 3:52 pm, tbjetrond.bjerkestr...@gmail.com  wrote:




Hi Marius,
I discovered the issue while porting a working application from 2.7.7
to lift 2.0-scala280-SNAPSHOT and scala 2.8.0.Beta1.



In the example application I provided it's possible to change the
pom.xml by replacing
   scala.version2.8.0.Beta1/scala.version
   lift.version2.0-scala280-SNAPSHOT/lift.version
with
   scala.version2.7.7/scala.version
   lift.version2.0-SNAPSHOT/lift.version
and the application is working as I'd like it to :)



I therefor believe it's a lift 2.0-scala280 issue.



Best regards
Trond



On 19 Feb, 14:12, Mariusmarius.dan...@gmail.com  wrote:



Can you also try with Scala 2.7.7 ?



On Feb 19, 2:26 pm, tbjetrond.bjerkestr...@gmail.com  wrote:



Hi,
I've been testing out the Lift-2.0-scala280-SNAPSHOT a little bit and
found a issue with Comet actor, setHtml and ajaxInvoke.



When trying to invoke the following partial update nothing seems to
happen:
partialUpdate(SetHtml(field,input type=button
onclick={ajaxInvoke(() =  JsRaw(alert('hi')))._2} value=Say hi /



))



This works as expected however:
partialUpdate(SetHtml(field, a(() =  JsRaw(alert('hi')),
spanLink/span)))



I've created a example app to illustrate the problem if someone is
interested:



git://github.com/tbje/Lift-2.0-scala280-SNAPSHOT-issue.git



Best regards
Trond




--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Re: Potential breaking change: MappedField.name, affects Mapper JSON

2010-02-18 Thread Indrajit Raychaudhuri




On 18/02/10 6:26 PM, harryh wrote:

If this does happen please take care to include this information in
the release notes for M3 (or whatever milestone first has this change)
as people using json serialization for caching purposes will need to
invalidate their caches.

Putting the note in BIG CAPITAL LETTERS might be a good idea.


Indeed! Note to Jeppe/Chas/IRC we need to add this in the release notes 
email that goes to lift-announce and liftweb.


- Indrajit



-harryh

On Feb 18, 6:22 am, Jeppe Nejsum Madsenje...@ingolfs.dk  wrote:

Hi,

As part of 
fixinghttps://www.assembla.com/spaces/liftweb/tickets/155-lift-mapper-%28re...
, I would like to change the semantics of MappedField.name slightly:

Currently, the name is always lowercased, ie:

class SampleModel extends KeyedMapper[Long, SampleModel] {
   object id extends MappedLongIndex(this)
   object firstName extends MappedString(this, 32)
   object moose extends MappedNullableLong(this)
   object notNull extends MappedString(this, 32)

}

firstName.name == firstname  notNull.name == notnull  id.name==id

I would like to have name preserve the case of the field such that:

firstName.name == firstName  notNull.name == notNull  id.name==id

Reasons:

1) More consistent. css styles, default column headers etc based on name now 
follows the actual
field name
2) Easier to implement #155 :-)

name is used when serializing a Mapped object as JSON. So the JSON
representation will be changed (unless we lowercase the name only when
creating JSON, but this goes against 1)

Now:
{
   $persisted:true,
   id:1,
   firstname:Elwood,
   moose:null,
   notnull:

}

After proposed change:
{
   $persisted:true,
   id:1,
   firstName:Elwood,
   moose:null,
   notNull:

}

I would like to get a feel for the pain this will cause people

/Jeppe




--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] autocrlf issue?

2010-02-17 Thread Indrajit Raychaudhuri


No it wasn't. Would do over the weekend.

- Indrajit

On 17/02/10 8:31 PM, Ross Mellgren wrote:

Did the repo ever get converted for autocrlf? I don't remember seeing the 
email. I have my autocrlf left alone and I don't have this issue.

-Ross

On Feb 17, 2010, at 9:46 AM, Heiko Seeberger wrote:


Sorry, forgot the subject ...

On Wednesday, February 17, 2010, Heiko Seeberger
heiko.seeber...@googlemail.com  wrote:

Hi,

Since a week or so I get modified files even when I create a fresh
clone of the repo. These are some js and css files from lift-widgets
and stuff from installer and references. Anyone else experiencing the
same? I guess it could be related to the core.autocrlf configuration
for Git. Mine is set to input and I am working on a Mac.

Any ideas?

Heiko

--
Heiko Seeberger

Work: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net



--
Heiko Seeberger

Work: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.





--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift]

2010-02-17 Thread Indrajit Raychaudhuri




On 17/02/10 8:21 PM, Jeppe Nejsum Madsen wrote:

On Wed, Feb 17, 2010 at 3:45 PM, Heiko Seeberger
heiko.seeber...@googlemail.com  wrote:

Hi,

Since a week or so I get modified files even when I create a fresh
clone of the repo. These are some js and css files from lift-widgets
and stuff from installer and references. Anyone else experiencing the
same? I guess it could be related to the core.autocrlf configuration
for Git. Mine is set to input and I am working on a Mac.


I had the same setup and experiences the same thing. I removed the
autocrlf setting.

 From what I understand from the committers list, this should only be
added when the repo is in a consistent state, ie. when Indrajit says
go :-)


Yep! The go would happen this weekend.



/Jeppe



--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] Re: New logging code

2010-02-15 Thread Indrajit Raychaudhuri



On Feb 15, 1:52 pm, Heiko Seeberger heiko.seeber...@googlemail.com
wrote:
 On 15 February 2010 09:45, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:

   Even if (probably) not needed, we should try to name it the best possible
   way. Changing now causes no pain at all, but later ... you know.

  Agreed. Suggestions?

 I already made mine, just to make sure everyone has a chance to see them:
 Like *Iterable* and *Iterator* lets call the trait that offers the logging
 methods (info, warn, etc.) *Logger* and the trait that gives access to a *
 Logger* should be called *Loggable*.

+1


 Heiko

 Work: weiglewilczek.com
 Blog: heikoseeberger.name
 Follow me: twitter.com/hseeberger
 OSGi on Scala: scalamodules.org
 Lift, the simply functional web framework: liftweb.net

-- 
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] New logging code

2010-02-15 Thread Indrajit Raychaudhuri

On 15/02/10 7:46 PM, Jeppe Nejsum Madsen wrote:

On Mon, Feb 15, 2010 at 9:52 AM, Heiko Seeberger
heiko.seeber...@googlemail.com wrote:

On 15 February 2010 09:45, Jeppe Nejsum Madsenje...@ingolfs.dk wrote:

Even if (probably) not needed, we should try to name it the best
possible
way. Changing now causes no pain at all, but later ... you know.

Agreed. Suggestions?

I already made mine, just to make sure everyone has a chance to see them:
Like Iterable and Iterator lets call the trait that offers the logging
methods (info, warn, etc.) Logger and the trait that gives access to a
Logger should be called Loggable.

I know, but before there was an extra (abstract) trait Logger which
was what I asked about :-). But this is a moot point now, it has been
eliminated and naming is now as you proposed above

For convenience:
http://github.com/dpp/liftweb/blob/add01980aa81875617f38260d710e0558c7ae1b1/framework/lift-base/lift-common/src/main/scala/net/liftweb/common/Logging.scala

One issue remains, which I don't know how to handle (if possible at
all): The current mixins use the dynamic type of an instance to
determine the logger name. This may not always be the preferred way.
E.g:

trait PaymentSystem extends Logger
trait FullfillmentSystem extends Logger

object MyStore extends PaymentSystem with FullfillmentSystem with Logger

Now everything in the subsystems will be logged with the MyStore
logger which is not how I would like to see it. The only solution I've
found so far is to not use the mixins and create private loggers in
the subsystem, where the static type is known. E.g. val logger =
Logger(classOf[PaymentSystem])

But this kind of restricts the usage of the mixins. Any thoughts on
this issue is appreciated

The restriction might be worthwhile in this case for the sake of
predictability. Having class/object specific logger is to be able to
filter in/out the logs (via configuration) at deployment time. It should
not be too sensitive to minor rearrangement of mixins in the code.

Would it be overcomplicated to make the Logger trait typed?

/Jeppe

[Lift] Re: lift-couchdb pushed to master

2010-02-12 Thread Indrajit Raychaudhuri

Nice, very nice!

On Feb 12, 2:26 pm, Timothy Perrett timo...@getintheloop.eu wrote:
 Congratulations Ross.

 Cheers, Tim

 On Feb 12, 5:07 am, Ross Mellgren dri...@gmail.com wrote:



  I've just pushed the CouchDB integration using Lift-JSON and Dispatch that 
  I've talked about on the list a couple times before.

  It has a couple pieces:
    - A straight JSON integration to CouchDB implemented by providing a 
  family of extended Request subclasses that model CouchDB operations such as 
  queries, revisions, storing and so on.
    - A Lift-JSON Record implementation, JSONRecord.
    - An extended JSONRecord that integrates with the JSON-oriented 
  integration, CouchRecord.

  The best examples of how to use it are currently the unit tests:

 http://github.com/dpp/liftweb/tree/master/framework/lift-persistence/...

  They cover most of the API. I plan to write some simple documentation at 
  some point.

  Share and Enjoy,
  -Ross

-- 
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Logging changes

2010-02-12 Thread Indrajit Raychaudhuri




On 12/02/10 2:36 PM, Jeppe Nejsum Madsen wrote:

David Pollakfeeder.of.the.be...@gmail.com  writes:


Jeppe  Co.,

I've been thinking about the logging changes.


(would have been nice with this before I went and updated all the
archetypes  examples...oh well :-)


How about a different approach?  How about a new logging system in common
that takes the best of the existing logging system plus a bunch of
enhancements?


+1 for me for sure.



A few points to consider:

1) How will the end result be better (ie. when everything deprecated is
gone, what are the improvements). What are the enhancements you have in
mind? Can they be made to the existing code?


The reason for me is to remove dependency on lift-util for using 
logging. Also, pulling up logging in lift-common allows all other 
modules in Lift to freely use logging. I was even tempted to consider 
suggesting lift-logging sometime back but that appeared too marginal to 
be considered a full fledged module.




2) The amount of work involved. I think we'll have to go through Lift
and change all logging references to the new code in order not to
include two logging systems for people using the new code. But this
could be made as part of #310 I guess.


We can possibly take the same approach as LRU. +1 on making it part of #310.



3) Transition. I think the transition phase will be more difficult: We can't
remove the log4j dependency from Lift, so people wanting something else
will have to use exclusions in their poms.


Ouch!




We can deprecate the stuff in util, but not phase it out for a while.

What do you think?


I prefer a clean cut, but understand if this is too much.


Let's deprecate instead. Can be removed post 2.0 :)



Just to summarize the changes that has been made in

http://github.com/dpp/liftweb/tree/jnm_issue_309

1) People will need to modify their code: 1 line in Boot, 1 dependency
in pom. See examples in the branch for details.

2) Lift will refuse to boot if 1) has not been done.

I've got some time this weekend (wife and kids out of town :-) and would
love to finish this, but this requires a decision soon. I'll be hacking
Lift later today (8pm CET), so we can discuss further.

/Jeppe



--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] Lift Web Framework 2.0 Milestone 2 released

2010-02-11 Thread Indrajit Raychaudhuri

The Lift Web Framework team is pleased to announce the framework-2.0-
M2 release!

Lift is an expressive and elegant framework for writing web
applications. Lift stresses the importance of security,
maintainability, scalability and performance while allowing for high
levels of developer productivity. Lift is a Scala web framework.

Changes in this version include:

New features:
o Multidimensional arrays supported in JSON serialization and
extraction  Issue: 279.
o Enable jQuery version switching in LiftRules  Issue: 311.
o New LRU Map that works better than Apache LRU map  Issue: 293.
o Allow thread-local Connection Identerifer resolution  Issue: 314.

Fixed Bugs:
o lift-Json doesn't appear to be correctly handling attributes  Issue:
323.
o net.liftweb.json.JsonParser.extract fails with List[List[Int]]
Issue: 279.
o Streamline JDBC library dependencies  Issue: 307.
o autocomplete widget - make options settable  Issue: 46.
o Ajax form submission with multiple submit buttons  Issue: 280.
o Ajax change from () = Any to () = JsCmd  Issue: 295.
o Add field-by-field error notifications to CRUDified fields  Issue:
254.
o MappedLongForeignKey::asJsonValue should generate JNull  Issue:
282.
o Additional tag support for TextileParser  Issue: 284.
o TextileParser molests divs  Issue: 290.
o The order of fields is random in Mapper  Issue: 308.
o How overriding of _showAllTemplate to show a limited number of
columns  Issue: 315.
o Control characters in input can lead to Denial of Service attacks
Issue: 319.

Changes:
o JSON object can be extracted into scala.Map (and scala.Map can be
serialized as JSON object). Recursive types can be serialized.  Issue:
303.
o JSON pull parser API  Issue: 333.
o Make Lift both Scala 2.7 and 2.8 friendly  Issue: 292.
o Upgrade jQuery to 1.4.1  Issue: 304.


Have fun!
-Lift Web Framework team

-- 
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Re: Parsed JSON values do not match with class constructor

2010-02-11 Thread Indrajit Raychaudhuri



On 11/02/10 10:37 PM, David Pollak wrote:



On Thu, Feb 11, 2010 at 9:05 AM, GA my_li...@me.com
mailto:my_li...@me.com wrote:

Thanks I am gonna try and test it.

When is 2.0-M2 going to be released?


Yesterday... trying to figure out why it didn't happen.  Likely today.


The announcement got delayed. The release was spun out yesterday :)



Cheers, GA



On Feb 11, 2010, at 6:00 PM, Joni Freeman wrote:

  Yes, it is fixed in 2.0-M2.
 
  Cheers Joni
 
  On Feb 11, 6:54 pm, GA my_li...@me.com mailto:my_li...@me.com
wrote:
  That's exactly what I've just found out. :-)
 
  As a workaround I am forcing the client app to send 0.0.
 
  are you saying that the bug is fixed in Lift 2.0-M2?
 
  Thanks for the answer,
 
  cheers,
 
  GA
 
  On Feb 11, 2010, at 5:42 PM, Joni Freeman wrote:
 
  Hi,
 
  I believe this bug is already fixed in trunk. If I'm right, the
  problem was missing conversion from JInt to float. You could
fix it by
  changing these values passMarkApplied:0,thresholdApplied:0 to
  passMarkApplied:0.0,thresholdApplied:0.0
 
  But it would be great if you have time to test with latest
snapshot.
  It worked for me at least.
 
  Cheers Joni
 
  On Feb 11, 6:11 pm, GA my_li...@me.com
mailto:my_li...@me.com wrote:
  Hello guys,
 
  I am having a very strange error parsing JSON messages.
Everything was working perfect until I introduce a new array in the
message. It supposed to be a very small change, but the system seems
to be parsing java data types instead of scala data types.
 
  This is the error message:
 
  net.liftweb.json.MappingException: Parsed JSON values do not
match with class constructor
  args=129567,248,1,1,0,0, String
  arg

types=java.lang.Long,java.lang.Long,java.lang.Long,java.lang.Long,scala.BigInt,scala.BigInt,java.lang.String
  constructor=public

com.tribes.ga.api.FeedAPI$FilterLogging$2(long,long,long,long,float,float,java.lang.String)
 
  I do not know how to solve this. There is another array in the
same structure that works just fine.
 
  This is the JSON message coming into the API:
 
  {lastSync:Thursday, February11,2010,
  tribeId:1,
 

filterLogging:[{passMarkApplied:0,thresholdApplied:0,entryId:129567,evaluationDescription:String,objectFiltered:1,filterApplied:1,sourceId:248}],
  history:7,
  deviceId:1036,
  source:248,
  showNews:true,
  userId:1049,
  syncFlag:false,
  showNewsChanged:false,
  updatedFeeds:[]}
 
  The error is with the array filter. I am parsing it with the
following code (this is an extraction of the entire definition):
 
  case class FilterLogging(entryId: Long,
   sourceId: Long,
   objectFiltered: Long,
   filterApplied: Long,
   passMarkApplied: Float,
   thresholdApplied: Float,
   evaluationDescription: String
  )
 
  case class UpdatedSource(userId: Long,
   deviceId: Long,
   tribeId: Long,
   syncFlag: Boolean,
   lastSync: String,
   history: Int,
   source: Long,
   updatedFeeds:
List[UpdatedFeeds],
   filterLogging:
List[FilterLogging]
  )
 
  val json = parse(req.body.map(bytes = new
String(bytes, UTF-8)) openOr )
  val request: UpdatedSource =
json.extract[UpdatedSource]
 
  Any ideas?
 
  Thanks in advance,
 
  GA
 
  --
  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
mailto:liftweb@googlegroups.com.
  To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
mailto:liftweb%2bunsubscr...@googlegroups.com.
  For more options, visit this group
athttp://groups.google.com/group/liftweb?hl=en
http://groups.google.com/group/liftweb?hl=en.
 
 
 
  --
  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
mailto:liftweb@googlegroups.com.
  To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com

Re: [Lift] Logging error when building lift

On 10/02/10 2:20 PM, Jeppe Nejsum Madsen wrote:

Naftoli Gugenheimnaftoli...@gmail.com writes:

Does this mean I'm not up to date? Or were the tests not updated with the
change to logging?

No change has been made to logging yet (unless I did some git mistake,
not impossible :-)

I don't think either :)

But I think this is caused by the fact that lift-webkit includes
slf4j-simple as test dependency as well as jwebunit-htmlunit-plugin
which in turn includes slf4j-log4j12 causing two slf4j logging backends
to be included. This seems like bad packaging of jwebunit (the mistake
we'll try to avoid in #309 :-)

Yes, just figured. We have to do some dependency exclusion circus to
clean things. Naftoli, feel free to open a ticket and assign it to me.

In general I think some of the dependencies need cleanup (ie lift-openid
includes Spring!) and once #309 is done (after M2) we can cleanup the
logging dependencies (ie remove commons-logging)

Very good point! Post M2, we need to put some effort in cleaning up
things. Yes, the project descriptors would end up being uglier. But
that's less important than shoving in a world of redundant dependencies
during the build (of both Lift proper and the dependent applications).

/Jeppe

When building Lift I get

---
T E S T S
---
Running net.liftweb.webapptest.ToHeadUsagesTest
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in
[jar:file:/C:/Users/Naftoli/.m2/repository/org/slf4j/slf4j-simple/1.5.10/slf4j-simple-1.5.10.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/C:/Users/Naftoli/.m2/repository/org/slf4j/slf4j-log4j12/1.5.0/slf4j-log4j12-1.5.0.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an
explanation.
0 [main] INFO org.mortbay.log - Logging to
org.slf4j.impl.SimpleLogger(org.mortbay.log) via org.mortbay.log.Slf4jLog
94 [main] INFO org.mortbay.log - jetty-6.1.22
468 [main] INFO org.mortbay.log - NO JSP Support for /, did not find
org.apache.jasper.servlet.JspServlet
151189 [main] INFO org.mortbay.log - Started socketconnec...@0.0.0.0:8989
log4j:WARN No appenders could be found for logger
(com.gargoylesoftware.htmlunit.WebClient).
log4j:WARN Please initialize the log4j system properly.

Re: [Lift] Re: Lift 2.0 on Scala 2.8 update


scalacheck_2.8.0.Beta1 used in the branch 280_port_refresh now.

Tim, see if your build works on this branch now.

Cheers, Indrajit

On 04/02/10 12:12 PM, Indrajit Raychaudhuri wrote:

Sure, I will. This would go in as regular 280_port_refresh update activity.

Cheers, Indrajit

On 04/02/10 3:13 AM, Timothy Perrett wrote:

Awesome stuff :-)

IRC, will you take the lead on this?

Cheers, Tim

Sent from my iPhone

On 3 Feb 2010, at 20:33, Rickard Nilsson rickyn...@gmail.com wrote:


I have now built ScalaCheck for Scala 2.8.0 Beta 1:

http://groups.google.com/group/scalacheck/browse_thread/thread/5a1e216fa82ed91



Regards,
Rickard

Den 2010-01-31 21:57:07 skrev David Pollak
feeder.of.the.be...@gmail.com:


The problem is that there's no ScalaCheck version for Scala 2.8.0
Beta1.
The Beta1-RC5 compilation of ScalaCheck was causing the wrong Scala
libraries to be loaded.

This is seriously suboptimal.

On Sun, Jan 31, 2010 at 12:44 PM, Timothy Perrett
timo...@getintheloop.euwrote:


Im just doing a fresh clone and checkout to see if something was
screwed in my local build.

Cheers, Tim

On Jan 31, 7:44 pm, Indrajit Raychaudhuri indraj...@gmail.com wrote:
 I was suspecting Java 1.5 (if you were on 10.5). That's not the
case. So
 I am completely stumped now.

 See if you can compare with the Hudson copy

(http://hudson.scala-tools.org/view/Lift/job/lift-framework-scala280/)

 - IRC

 On 01/02/10 12:55 AM, Timothy Perrett wrote:



  macbookpro:lift-framework timperrett$ java -version




--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Mixing up 2.7 and 2.8 codes inline (was Re: [Lift] Why not SHtml?)


Hey Naftoli,

Man, it would be great *not to* mix up 2.7 and 2.8 codes inline.

Keeping it in sync with master would get very confusing and error prone 
(personally I don't find that aesthetically pleasing either).


In fact, with some adjustment, it's possible to have parts of code 
friendly with both 2.7 and 2.8. That way, we'll have smaller delta to 
manage between the branches. If necessary, feel free to reopen #313 and 
backport as much as possible.


Cheers, Indrajit

On 10/02/10 9:59 AM, Naftoli Gugenheim wrote:

Never mind, apparently I wasn't up to date.

On Tue, Feb 9, 2010 at 11:20 PM, Naftoli Gugenheim naftoli...@gmail.com
mailto:naftoli...@gmail.com wrote:

I got OneToMany to compile (not in a way that would work on 2.7 though).
Then I tried to push it:
naft...@naftoli-pc /c/dev/gitrepo/liftweb (280_port_refresh)
$ git rebase origin/280_port_refresh
Current branch 280_port_refresh is up to date.

naft...@naftoli-pc /c/dev/gitrepo/liftweb (280_port_refresh)
$ git push origin 280_port_refresh
To g...@github.com:dpp/liftweb.git
  ! [rejected]280_port_refresh - 280_port_refresh (non-fast
forward)
error: failed to push some refs to 'g...@github.com:dpp/liftweb.git'

naft...@naftoli-pc /c/dev/gitrepo/liftweb (280_port_refresh)
$

Actually I only did the rebase to be sure, after I had already
gotten the 'non-fast forward' error. What am I doing wrong?

As far as ManyToMany, I can't work on it because the compiler seems
to just freeze (using up CPU though). I assume that means there's a
compiler bug involved.

Thanks.


On Tue, Feb 9, 2010 at 5:46 PM, David Pollak
feeder.of.the.be...@gmail.com
mailto:feeder.of.the.be...@gmail.com wrote:



On Tue, Feb 9, 2010 at 2:28 PM, Naftoli Gugenheim
naftoli...@gmail.com mailto:naftoli...@gmail.com wrote:

Could you give me exact instructions what to do to test my
code on 2.8?


git checkout -b 280_port_refresh origin/280_port_refresh
cd framework/lift-persistence/lift-mapper
emacs $(grep -l FIXME: 280 $(find . -name *.scala))

remove the comments around your code.  Make it compile and pass
the existing tests.

Thanks.

2010/2/7 David Pollak feeder.of.the.be...@gmail.com
mailto:feeder.of.the.be...@gmail.com



On Sun, Feb 7, 2010 at 1:01 PM, Naftoli Gugenheim
naftoli...@gmail.com mailto:naftoli...@gmail.com wrote:

So if I get around to it would it indeed be
preferable to point it to SHtml?


Changing the code is one of the lowest priorities I
could imagine.  I would say that closing the stuff
you've had on review board for  1 months would be much
higher priority.  Adding copyright notices and other
headers to the code you've written in Lift is a higher
priority.  Helping to port your code to 2.8 would be a
higher priority.


-
David Pollakfeeder.of.the.be...@gmail.com
mailto:feeder.of.the.be...@gmail.com wrote:

On Sun, Feb 7, 2010 at 12:47 PM, Naftoli Gugenheim
naftoli...@gmail.com
mailto:naftoli...@gmail.comwrote:

  Hello. Why do Mapper's toForm implementations use
S.fmapFunc directly
  rather than using SHtml? Is it not duplicate code?
 

Because the Mapper code was the earliest Lift
code... written long before
SHtml.


  Thanks.
 
  --
  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
mailto:liftweb@googlegroups.com.
  To unsubscribe from this group, send email to
  liftweb+unsubscr...@googlegroups.com

mailto:liftweb%2bunsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
mailto:liftweb%252bunsubscr...@googlegroups.com
  .
  For more options, visit this group at
  http://groups.google.com/group/liftweb?hl=en.
 
 


--
Lift, the simply functional web framework
http://liftweb.net
Beginning Scala
http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp

Re: [Lift] Features in Lift 2.0


Hi Murtaza,

Everything since Lift 1.0 is new on Lift 2.0 [1].

There is a good chance that you'll find most as part of the changelog 
that we maintain.


See the static version in project docs [2] or milestone-wise details in 
Assembla [3] (we have them since 1.1-M6 here).


Cheers, Indrajit

[1] Lift 1.1 has been renamed Lift 2.0, there are same stuff
[2] http://scala-tools.org/mvnsites-snapshots/liftweb/changes-report.html
[3] 
https://liftweb.assembla.com/spaces/milestones/completed/liftweb?milestone_sort_id=ASC



On 10/02/10 6:27 PM, Murtaza Rampurawala wrote:

Hi,

I have been exploring lift and was interested in what new features are
in/planned for lift 2.0. I havent been able to find any documentation
regarding it. Can anyone guide me to it. Also what is the planned
release for 2.0?

Also appreciate for maintaining such a responsive mailing list.

Thanks,
Murtaza



--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] IMPORTANT BREAKING CHANGES lift-core is deprecated


Folks,

If your project has dependency on lift-core, this is important for you!

lift-core stands deprecated and Lift 2.0-M2 would be the penultimate 
milestone with support for lift-core. Subsequently (after the milestone 
2.0-M3) it would be unsupported.


lift-core is a 'meta' module that can be added as a dependency to a Lift 
based application to pull in all the Lift modules. The initial purpose 
of having single dependency on this 'meta' module in the application was 
to conveniently serve as a singular configuration point in a Lift based 
application.


However, this comes for a cost. Since lift-core downloads and enforces 
bundling all the Lift modules (irrespective of whether the project needs 
it), adding this as the dependency slows down things for a standard Lift 
application that doesn't need all the additional modules. Further, this 
makes the generated application war much larger than necessary.


Going forward, just discontinue using lift-core in your project and for 
alternative(s), follow these general guidelines:


1. If you are using any of the persistence modules (lift-mapper, 
lift-jpa, lift-record), just have the respective persistence module as 
dependency. You *do not* need to add any of the other base modules 
(lift-common, lift-actor, lift-json, lift-util, lift-webkit) as dependency.


2. If you are not using the persistence module (possibly because your 
app doesn't need such support), just including lift-webkit should suffice.


3. Additionally, if you are using any of the special purpose modules 
(from lift-modules), add that to the list of dependencies in addition to 
the ones added in #1 or #2 above.


In all the above cases, the additional dependencies necessary (and just 
the necessary ones) for the respective modules would be pulled 
transitively in your project automatically.


This would make your application lighter by having more precise 
dependency map. And that's a good thing!


Cheers,
Indrajit

--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Comet shutdown?




On 10/02/10 9:49 PM, David Pollak wrote:



On Wed, Feb 10, 2010 at 8:13 AM, Adam Warski a...@warski.org
mailto:a...@warski.org wrote:

Hello,

  Yes, in fact there is a timespan method in CometActor.  You
should be using Lift 2.0-M1 or 2.0-SNAPSHOT.

I'm using 2.0-SNAPSHOT:

class Test extends CometActor {
  def render = NodeSeq.Empty
  override def timespan = 0
}

error: method timespan overrides nothing
  override def timespan = 0
   ^
one error found

same for timeSpan.


Yep, override def timespan: Int does if fact override nothing...  please
look at my mail.  The method to override is def timespan:
Box[Helpers.TimeSpan]


You probably mean
def lifespan: Box[TimeSpan]




--
Adam Warski
http://www.warski.org
http://www.softwaremill.eu




--
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
mailto:liftweb@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
mailto:liftweb%2bunsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.




--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--
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...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.


--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Comet shutdown?


Adam,

As mentioned earlier, please try *lifespan* instead.

def lifespan: Box[TimeSpan] is what you probably want.

- Indrajit

On 10/02/10 10:58 PM, Adam Warski wrote:

Hello,

to be extra sure I pulled the latest sources from git and recompiled.
And I still get an error:

error: method timespan overrides nothing
   override def timespan: Box[TimeSpan] = Full(0 seconds)


Yep, override def timespan: Int does if fact override nothing...  please look 
at my mail.  The method to override is def timespan: Box[Helpers.TimeSpan]


if I was trying to override a method with another method with an incompatible return 
type, I would get another error (like error overriding method x in class A of 
type =  Int;
  method x has incompatible type =  String)

Searching for timespan method in the current source:
http://github.com/dpp/liftweb/blob/master/framework/lift-base/lift-webkit/src/main/scala/net/liftweb/http/CometActor.scala

also doesn't return anything.



--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Welcome javier Goday to the Lift committers

2010-02-09 Thread Indrajit Raychaudhuri


Welcome Javier!

- a wild crowd member

On 09/02/10 9:39 PM, David Pollak wrote:

Folks,

Please join me in welcoming Javier Goday to the Lift committers.  Javier
wrote the Lift LDAP module and now that he's a committer, he can make
the LDAP module part of the official Lift distribution (and the crowd
goes wild).

Welcome Javier!!

Thanks,

David

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--
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...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.


--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] IMPORTANT HOLD OFF CREATING TICKETS ON ASSEMBLA




On 08/02/10 12:17 AM, Naftoli Gugenheim wrote:

Thank you for a great web framework!
Thanks tons Indrajit for getting this done!


Thanks a ton Naftoli for coming up with an awesome script that helped 
getting it done!




-
David Pollakfeeder.of.the.be...@gmail.com  wrote:

On Sat, Feb 6, 2010 at 12:12 PM, Indrajit Raychaudhuri
indraj...@gmail.comwrote:


Go ahead! create tickets in Assembla.



Excellent job and a huge round of applause to Indrajit and Naftoli for
moving the tickets over the Assembla.  Thanks guys!




Cheers, Indrajit

On 05/02/10 10:49 AM, Naftoli Gugenheim wrote:


Indrajit and I are working on importing tickets into Assembla. The first
ticket on GitHub is #3 and there are now two on Assembla.
So please don't create any Assembla tickets until further notice.
Thanks!

--
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...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.



--
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...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.







--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Re: Forcing Authentication not working

You have to register yourself as Watcher of the space liftweb to see 
the New Ticket button :) We have this rule to avoid (Anonymous) spams 
in the ticket.


Cheers, Indrajit

On 08/02/10 2:48 PM, aw wrote:

On Feb 7, 11:31 pm, Mariusmarius.dan...@gmail.com  wrote:

Please open a defect herehttp://www.assembla.com/spaces/liftweb/tickets


Would love to, but the New Ticket button does not seem to exist...
Is this project configured correctly to accept non-teammate
submissions?



--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Closing in on Lift logging


+1

Need to send a **BREAKING CHANGE** notice to lift-announce and liftweb 
and update the Wiki possibly carrying the rationale behind.


Also clearly mentioning how the existing applications would behave 
without making these changes (and what needs to be done to get the 
existing behavior either for slf4j or log4j)


For archetypes, it would be great to offer a choice during 
archetype:generate (with some comment in the generated pom.xml as well).


Thank you very much for seeing through this issue and tying the loose 
end on the way!


Cheers, Indrajit

On 08/02/10 3:25 PM, Jeppe Nejsum Madsen wrote:

Hi,

Trying to tie the knots on #309 (Logging), I've committed my changes to
http://github.com/dpp/liftweb/commits/jnm_issue_309

Before updating all the examples and archetypes, I would like to get
consensus to the approach chosen now:

- Slf4j is the logging facade used internally by the LiftLogger
- No logging backends are included by default
- A logging backend must be included in a client app for Lift to boot 
successfully
- If current functionality is to be matched, two things should be changed in 
client code:
   1) Add slf4j-log4j12 dependency
   2) Add to boot: LogBoot.loggerSetup = Log4JLogBoot.setup

- Logback functionality can be included in client app:
   1) Add logback-classic dependency
   2) Optional:  LogBoot.loggerSetup = LogbackLogBoot.setup

If this sounds right, I'll go ahead and update the remaining parts.

/Jeppe



--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Re: JRebel not reloading with new snapshot archetype

Hmm, specs_2.8.0.Beta1 is the appropriate version aligned with Scala 
2.8.0Beta1.


If you really find the expected behavior with specs_2.8.0.Beta1-RC8 but 
not with specs_2.8.0.Beta1, we have an interesting behavior at hand.


Cheers, Indrajit

On 08/02/10 3:41 PM, Lukasz Kuczera wrote:

It seems like pom.xml had wrong version of specs. I'm not shure if it
is a bug but had to change artifact id from: specs_2.8.0.Beta1 to:
specs_2.8.0.Beta1-RC8



--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Re: IMPORTANT Lift ticketing system has moved to Assembla


I digg this :)

Assembla docs has this to say on email alerts:
http://www.assembla.com/wiki/show/breakoutdocs/FAQ#EmailsAlerts

FWIW, I couldn't find admin settings to set this as space level default.

Cheers, Indrajit

On 08/02/10 5:41 PM, Erkki Lindpere wrote:

I noticed that Assembla sends a lot of spam (seems I get an e-mail for
everything anyone does in there, including new users registering)

These alerts can be turned off under Stream -  Change alert settings
if anyone has trouble finding it.



--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] IMPORTANT Lift 2.0 Milestone 2 is coming and it's time to test the SNAPSHOT in master

Folks,

Lift 2.0 Milestone 2 release is coming soon!

This also means the master would get 'slushy' by end of day today
(PST) !

Committers please:
- merge all branches for outstanding ticket to master (subject to RB
approval)
- associate corresponding tickets in Assembla to appropriate milestone
(Lift 2.0-M2)
- post your code for RB approval if you haven't done so

Community, please do the usual drill:
git pull from master, do mvn -U clean install at the base of the
project and do intense test on SNAPSHOT as much as possible. And
report any defect [1] that you come across. This would help us close
them before now and the actual release of 2.0-M2.

All going well, we should be able to spin Lift 2.0 Milestone 2 on 10
February.

Cheers,
Indrajit

[1] https://www.assembla.com/spaces/liftweb/tickets

-- 
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Why don't milestone releases include the source archive in the Maven repository ?

Umm, the source jas are actually available in the repository along with 
the binary jars :) Looks for lift-module-2.0-M1-sources.jar in the 
same place as lift-module-2.0-M1.jar.


See any of the module location in 
http://scala-tools.org/repo-releases/net/liftweb/lift-module/2.0-M1 
for example.


Cheers, Indrajit

On 08/02/10 4:50 PM, Hugo Palma wrote:

They are very handy for debugging but it seems both the 1.1 and the
2.0 milestones don't include them.
Is there any particular reason why that is ?

Thanks



--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] Re: [Lift committers] A Groovy welcome to James Strachan who has joined the Lift committers


+1 Welcome James!

Cheers, Indrajit


On 08/02/10 11:22 PM, Timothy Perrett wrote:

Wow, that was a long time comming!!

Welcome to the team James... great to finally have another UK bod!

Cheers, Tim

On 8 Feb 2010, at 17:16, David Pollak wrote:


Folks,

I'm wicked pleased that James Strachan has joined the Lift committers.
I'm looking forward to the cool stuff that James will add to Lift.

Please join me in welcoming James!

Thanks,

David

--
Lift, the simply functional web framework http://liftweb.net
http://liftweb.net/
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--
You received this message because you are subscribed to the Google
Groups Lift-committers group.
To post to this group, send email to lift-committ...@googlegroups.com
mailto:lift-committ...@googlegroups.com.
To unsubscribe from this group, send email to
lift-committers+unsubscr...@googlegroups.com
mailto:lift-committers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/lift-committers?hl=en.


--
You received this message because you are subscribed to the Google
Groups Lift-committers group.
To post to this group, send email to lift-committ...@googlegroups.com.
To unsubscribe from this group, send email to
lift-committers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/lift-committers?hl=en.


--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] Re: [Lift committers] We're moving our ticketing system to Assembla


Migration complete!

Please DO NOT use GitHub Issue tracking facility anymore.
Use http://www.assembla.com/spaces/liftweb/tickets instead.

Cheers, Indrajit

On 04/02/10 2:05 AM, David Pollak wrote:

Folks,

On today's committer call, we made the final decision to move the Lift
ticketing system from GitHub to Assembla.  We made the decision to move
ticketing systems because the current GitHub ticket system, while
visually pretty, is slow, lacks support for ordinal ordering (bug
priority, milestone dates, etc.), is difficult to use for more than 40
open tickets, doesn't allow attachments, etc.

I personally would have preferred to move to a home-grown system built
on top of Derek's LiftTicket system.  Unfortunately, we did not find a
prime maintainer (owner) for enhancing LiftTicket code someone who
could evolve the code into something similar to Trac or other systems.
If Derek winds up having more time or if someone else shows long term
dedication to LiftTicket, the choice of moving to LiftTicket remains open.

I vetoed Trac because it's got a horrid UI.

Assembla has a nice ticketing system (it's used by the Akka and Clojure
teams and well regarded by both teams.)

Over the next week, we'll be migrating from the GitHub ticket system to
Assembla: https://liftweb.assembla.com/spaces/liftweb/tickets  Specifically:

* Indrajit will spearhead the migration of existing tickets to the
  new system
* For the committers, I will invite you to join the project via
  Assembla's invitation system
* For the community, please start opening tickets at Assembla.  Once
  we get our existing tickets moved over, we'll disable the GitHub
  ticketing system.

One of the side benefits of the new system is that we'll relax the
discuss the defect on the list first policy as the Assembla ticketing
system allows for a more robust mechanism for changing the state of tickets.

Thanks,

David

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--
You received this message because you are subscribed to the Google
Groups Lift-committers group.
To post to this group, send email to lift-committ...@googlegroups.com.
To unsubscribe from this group, send email to
lift-committers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/lift-committers?hl=en.


--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] IMPORTANT HOLD OFF CREATING TICKETS ON ASSEMBLA


Go ahead! create tickets in Assembla.

Cheers, Indrajit

On 05/02/10 10:49 AM, Naftoli Gugenheim wrote:

Indrajit and I are working on importing tickets into Assembla. The first
ticket on GitHub is #3 and there are now two on Assembla.
So please don't create any Assembla tickets until further notice.
Thanks!

--
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...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.


--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] IMPORTANT TOTALLY DO CREATE TICKETS ON ASSEMBLA


Ross, Thanks for updating the subject line and clarifying even.

- Indrajit

On 07/02/10 1:46 AM, Ross Mellgren wrote:

Also, please don't use GitHub for issues any more. Care of Indrajit,
here is the new URL to submit issues:

http://www.assembla.com/spaces/liftweb/tickets

-Ross


On Feb 6, 2010, at 3:12 PM, Indrajit Raychaudhuri wrote:


Go ahead! create tickets in Assembla.

Cheers, Indrajit

On 05/02/10 10:49 AM, Naftoli Gugenheim wrote:

Indrajit and I are working on importing tickets into Assembla. The first
ticket on GitHub is #3 and there are now two on Assembla.
So please don't create any Assembla tickets until further notice.
Thanks!

--
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
mailto:liftweb@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
mailto:liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.


--
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
mailto:liftweb@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
mailto:liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.



--
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...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.


--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] IMPORTANT Lift ticketing system has moved to Assembla

Folks,

Following David's announcement about moving our ticketing system to
Assembla [1], the migration is complete and we have now completely
moved from GitHub issues to Assembla tickets.

Please DO NOT use GitHub to create issues anymore (the GitHub URL
would be disabled), instead use this Assembla URL:
http://www.assembla.com/spaces/liftweb/tickets

Feel free to discuss, ask for clarification in the main list.

Cheers,
Indrajit

[1] http://groups.google.com/group/liftweb/browse_thread/thread/85c38d03790bc2eb

-- 
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Mapped(Date)(Time) formatter/parser

2010-02-05 Thread Indrajit Raychaudhuri




On 05/02/10 5:28 PM, Jeppe Nejsum Madsen wrote:

Naftoli Gugenheimnaftoli...@gmail.com  writes:


David and all,
QUESTION 1
I'm working on issue #258. Here are two options for an overridable parser 
(applies to formatting too):
1. def parse(s: String): Box[Date] = ConversionRules.parseDate()(s)
2. def parse: String=Box[Date] = ConversionRules.parseDate()

What are the pros and cons, and which should I use?


I prefer 1) I see no reason for parse to be a function


+1





QUESTION 2
MappedDate and MappedDateTime apparently were parsing via LiftRules in 
setFromAny, while buildSetStringValue etc. were using (Time)Helpers.toDate. Is 
there a reason not to change it? Or, should toDate use ConversionRules?


I think it would be natural for toDate to use ConversionRulesthen
ConversionRules becomes the only place where date formatting is handled.

/Jeppe



--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Github issue browser


Great stuff! Where did you get the github issue xml?

Cheers, Indrajit

On 03/02/10 10:14 AM, Naftoli Gugenheim wrote:

If anyone finds github's issue manager too limited, I made a teeny
little app that lets you list the issues in a more configurable way. All
comments welcome!

http://github-issues.naftoligug.staxapps.net/index

You do not need to log in or register. Right now it only browses issues
for dpp/liftweb. Use the check boxes on top to filter tickets, click
column headers to sort, and click 'more' or 'less' on a ticket to view
its description.

Enjoy!

--
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...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.


--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Lift security vulnerability


1. Fix in head/master (2.0-SNAPSHOT) and prepone 2.0-M2.

2. Backport in 1.0.x branch and spin 1.0.4. We haven't marked 1.0.x 
'unsupported' yet. Forcing apps to move to 2.0-M2 just for this 
vulnerability fix isn't fun.


Cheers, Indrajit

On 03/02/10 3:34 PM, Timothy Perrett wrote:

+1

Fix it in head, no need to back-port; M2 is only around the corner.

Cheers, Tim

On 3 Feb 2010, at 09:49, Jeppe Nejsum Madsen wrote:


David Pollakfeeder.of.the.be...@gmail.com  writes:


I'd like to get a sense of how important the community views this defect.
Is it a backport the fix to every milestone and release yesterday or is it
a fix it in 2.0-M2 or someplace in between.


For me, it's fix it in 2.0-SNAPSHOT

/Jeppe

--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.






--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Github issue browser


Naftoli,

Yes, looked at your source. I was curious about the source of the 
downloaded xml you have in there.


http://develop.github.com/p/issues.html seems to have them all. Thanks!

Cheers, Indrajit

On 03/02/10 7:57 PM, Naftoli Gugenheim wrote:

They have an API. I think the site is develop.github.com, or something like 
that.
The source code is on github.com/nafg, although I think there it references an 
xml file I downloaded rather than the live urls, as it does locally (ironically 
:) ). I took the basic archetype (actually I couldn't maven install the 
archetypes because I was offline so I copied the archetype resources and 
changed the placeholders etc. :) ) and wrote the code and xhtml in the 
HelloWorld.howdy snippet!
If anyone has any suggestions and/or constructive criticism please pile it on!


-
Indrajit Raychaudhuriindraj...@gmail.com  wrote:

Great stuff! Where did you get the github issue xml?

Cheers, Indrajit

On 03/02/10 10:14 AM, Naftoli Gugenheim wrote:

If anyone finds github's issue manager too limited, I made a teeny
little app that lets you list the issues in a more configurable way. All
comments welcome!

http://github-issues.naftoligug.staxapps.net/index

You do not need to log in or register. Right now it only browses issues
for dpp/liftweb. Use the check boxes on top to filter tickets, click
column headers to sort, and click 'more' or 'less' on a ticket to view
its description.

Enjoy!

--
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...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.




--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] ProtoUser i18n


Thanks Adam, I'll take this one up :)

- Indrajit

On 03/02/10 12:48 PM, Adam Warski wrote:

Sure:

(a) http://github.com/dpp/liftweb/issues/issue/320
(b) http://gist.github.com/293435

I've also updated the wiki.

On Feb 2, 2010, at 8:10 PM, Indrajit Raychaudhuri wrote:


Adam, can you please (a) open a ticket and (b) create a gist 
(http://gist.github.com/) of the patch and refer to it from the ticket? We'll 
take it up from there.

Tim, +1 on not having spaces in properties.

Cheers, Indrajit

On 02/02/10 10:41 PM, Timothy Perrett wrote:

Sure - one of us will take this up... its minor.

I propose we agree a policy, and use that going forward... should keys have spaces? 
no would be my default response... (i tend to separate with full stops) if 
thats so, lets just clear that out now, and do a breaking changes ann.

Cheers, Tim

On 2 Feb 2010, at 17:06, David Pollak wrote:


I'm okay with breakage here.  Jeppe, Indrajit, or Tim, can you guys handle this 
issue going forward (making sure the patch is good, putting it on a branch, 
opening a ticket, putting it on review board, and sending out any breaking 
changes email)?




--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.





--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Re: Lift 2.0 on Scala 2.8 update


Sure, I will. This would go in as regular 280_port_refresh update activity.

Cheers, Indrajit

On 04/02/10 3:13 AM, Timothy Perrett wrote:

Awesome stuff :-)

IRC, will you take the lead on this?

Cheers, Tim

Sent from my iPhone

On 3 Feb 2010, at 20:33, Rickard Nilsson rickyn...@gmail.com wrote:


I have now built ScalaCheck for Scala 2.8.0 Beta 1:

http://groups.google.com/group/scalacheck/browse_thread/thread/5a1e216fa82ed91


Regards,
Rickard

Den 2010-01-31 21:57:07 skrev David Pollak
feeder.of.the.be...@gmail.com:


The problem is that there's no ScalaCheck version for Scala 2.8.0 Beta1.
The Beta1-RC5 compilation of ScalaCheck was causing the wrong Scala
libraries to be loaded.

This is seriously suboptimal.

On Sun, Jan 31, 2010 at 12:44 PM, Timothy Perrett
timo...@getintheloop.euwrote:


Im just doing a fresh clone and checkout to see if something was
screwed in my local build.

Cheers, Tim

On Jan 31, 7:44 pm, Indrajit Raychaudhuri indraj...@gmail.com wrote:
 I was suspecting Java 1.5 (if you were on 10.5). That's not the
case. So
 I am completely stumped now.

 See if you can compare with the Hudson copy

(http://hudson.scala-tools.org/view/Lift/job/lift-framework-scala280/)

 - IRC

 On 01/02/10 12:55 AM, Timothy Perrett wrote:



  macbookpro:lift-framework timperrett$ java -version




--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Is there any way to set default source encoding in Lift2.0-scala280 ?


Takeuchi-san,

Can you please set project.build.sourceEncoding=UTF-8 in your pom.xml 
and check if it works?


You can set project.build.sourceEncoding in pom.xml the following way:

properties
  project.build.sourceEncodingUTF-8/project.build.sourceEncoding
  ...
  ...
/properties

Cheers, Indrajit

On 04/02/10 1:01 AM, David Pollak wrote:



On Wed, Feb 3, 2010 at 1:54 AM, Timothy Perrett timo...@getintheloop.eu
mailto:timo...@getintheloop.eu wrote:

Do not use the 2.8 port of Lift yet... its mostly broken. Please use
2.7.7 until the official 2.8 release is out.


Although this is the kind of bug we want to find.

For production sites, I would strongly recommend sicking with 2.7.7

If you are skilled with Scala and want to try Lift and 2.8, I encourage
you to do so.  This is the kind of corner-case that we want to find
during testing.


Cheers, Tim

On 3 Feb 2010, at 02:00, pomu0325 wrote:

  Hi, I'm quite a newbie to Lift. I'm now trying to port my first Lift
  application from Lift1.0.2 to latest Lift2.0-scala280, and faced a
  problem relating to source encoding.
 
  I managed to merge pom.xml and some codes on Boot.scala, and
succeeded
  to build my application, but when I access to it from browser, it
  displays:
 
  Message: java.nio.charset.UnmappableCharacterException: Input
length =
  2
 
java.nio.charset.CoderResult.throwException(CoderResult.java:261)
sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:319)
sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158)
java.io.InputStreamReader.read(InputStreamReader.java:167)
java.io.BufferedReader.fill(BufferedReader.java:136)
java.io.BufferedReader.read(BufferedReader.java:157)
scala.io.BufferedSource$$anonfun$1$$anonfun$apply$1.apply
  (BufferedSource.scala:29)
scala.io.BufferedSource$$anonfun$1$$anonfun$apply$1.apply
  (BufferedSource.scala:29)
scala.io.Codec.wrap(Codec.scala:65)
 
scala.io.BufferedSource$$anonfun$1.apply(BufferedSource.scala:29)
 
scala.io.BufferedSource$$anonfun$1.apply(BufferedSource.scala:29)
scala.collection.Iterator$$anon$13.next(Iterator.scala:145)
scala.collection.Iterator$$anon$24.hasNext(Iterator.scala:435)
scala.collection.Iterator$$anon$19.hasNext(Iterator.scala:326)
scala.io.Source.hasNext(Source.scala:209)
 
net.liftweb.util.PCDataXmlParser$$anonfun$apply$2$$anonfun$apply
  $4.apply(PCDataMarkupParser.scala:184)
 
  ... and more
 
   I traced Lift source and found out that Codec argument is not
  passed to Source.fromInputStream(in) at PCDataMarkupParser.scala(l.
  182). Codec api seems to be introduced newly in Scala 2.8, and
  Source.fromInputStream() uses Codec.default as a implicit argument.
 
   My problem here, is I'm using utf-8 for write *.html templates, but
  my Codec.default is MS932(Japanese characterset in Windows), so
  failing to decode my template files. I looked through Scala lib
  source, and found out Codec.default it is actually an alias to
  java.lang.Charset.getDefault(), so I just set
-Djava.encoding=utf-8 to
  MVN_OPTS and solved the problem, but considering deployment, I don't
  think it's a smart way.
 
   BTW, I confirmed this does not occur on Lift2.0-scala2.7.7. I think
  default source encoding should be somehow configurable in Lift to
  achieve portability.
 
  Kind regards,
 
  Pomu TAKEUCHI
 
  --
  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
mailto:liftweb@googlegroups.com.
  To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
mailto:liftweb%2bunsubscr...@googlegroups.com.
  For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
 
 

--
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
mailto:liftweb@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
mailto:liftweb%2bunsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.




--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--
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...@googlegroups.com.
For more options, visit this group at

Re: [Lift] MYSQL TEXT field

Look for MappedText. That maps to DriverType.clobColumnType (LONGTEXT 
for MySQL).


Cheers, Indrajit

On 02/02/10 11:27 AM, XiaomingZheng wrote:

hi guys:
my app needs to use one field of mysql text type, but in Lift mapper
package, and i don't find any MappedField is suitable. any ideas?
thanks



--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Since when did Record depend on Derby and H2??

Thanks for spotting this. Yes, DB drivers should be either in runtime 
scope with optional=true or in test scope.


I missed out the optional=true declaration during recent DB dependency 
refactoring (#307). But test scope is more appropriate in this case 
(instead of runtime scope with optional=true). Would fix it in master.


Cheers, Indrajit


On 02/02/10 9:24 PM, David Pollak wrote:

Record should only depend on H2 and Derby in test mode.

On Tue, Feb 2, 2010 at 7:50 AM, Timothy Perrett timo...@getintheloop.eu
mailto:timo...@getintheloop.eu wrote:

Guys,

Just found this in my deps tree:

[INFO] |  |  \- net.liftweb:lift-record:jar:2.0-SNAPSHOT:compile
[INFO] |  | +- net.liftweb:lift-mapper:jar:2.0-SNAPSHOT:compile
[INFO] |  | +- com.h2database:h2:jar:1.2.127:runtime
[INFO] |  | \- org.apache.derby:derby:jar:10.5.3.0_1:runtime

Certainly, this should not be the case. Thoughts?

Cheers, Tim

--
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
mailto:liftweb@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
mailto:liftweb%2bunsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.




--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--
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...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.


--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Prevent leaving page if unsaved

How about setting some global variable on a field change 
(http://jqapi.com/#p=change) and then checking for the variable when you 
navigate out (probably onunload or something)?


Cheers, Indrajit

On 03/02/10 12:01 AM, Naftoli Gugenheim wrote:

Hi, in Lift how would one implement functionality similar to in Gmail, that 
when you try to navigate away from an unsaved email you get a dialog box asking 
to confirm?



--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] ProtoUser i18n

Adam, can you please (a) open a ticket and (b) create a gist 
(http://gist.github.com/) of the patch and refer to it from the ticket? 
We'll take it up from there.


Tim, +1 on not having spaces in properties.

Cheers, Indrajit

On 02/02/10 10:41 PM, Timothy Perrett wrote:

Sure - one of us will take this up... its minor.

I propose we agree a policy, and use that going forward... should keys have spaces? 
no would be my default response... (i tend to separate with full stops) if 
thats so, lets just clear that out now, and do a breaking changes ann.

Cheers, Tim

On 2 Feb 2010, at 17:06, David Pollak wrote:


I'm okay with breakage here.  Jeppe, Indrajit, or Tim, can you guys handle this 
issue going forward (making sure the patch is good, putting it on a branch, 
opening a ticket, putting it on review board, and sending out any breaking 
changes email)?




--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] ProtoUser i18n


Yep, I did ;)

Cheers, Indrajit

On 03/02/10 1:21 AM, Timothy Perrett wrote:

Indrajit, I think you just volunteered to take this on good chap ;-)

Cheers, Tim

On 2 Feb 2010, at 19:10, Indrajit Raychaudhuri wrote:


Adam, can you please (a) open a ticket and (b) create a gist 
(http://gist.github.com/) of the patch and refer to it from the ticket? We'll 
take it up from there.

Tim, +1 on not having spaces in properties.

Cheers, Indrajit

On 02/02/10 10:41 PM, Timothy Perrett wrote:

Sure - one of us will take this up... its minor.

I propose we agree a policy, and use that going forward... should keys have spaces? 
no would be my default response... (i tend to separate with full stops) if 
thats so, lets just clear that out now, and do a breaking changes ann.

Cheers, Tim

On 2 Feb 2010, at 17:06, David Pollak wrote:


I'm okay with breakage here.  Jeppe, Indrajit, or Tim, can you guys handle this 
issue going forward (making sure the patch is good, putting it on a branch, 
opening a ticket, putting it on review board, and sending out any breaking 
changes email)?




--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.






--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Re: Lift 2.0 on Scala 2.8 update


Welcome back, Tim!

I am suspecting that an incorrect spec version is sneaking in.
Just to confirm - the maintained 2.8 port branch is 280_port_refresh.

Cheers, Indrajit

On 31/01/10 11:02 PM, Timothy Perrett wrote:

I just attempted to build the branch and got the following:

Running net.liftweb.common.BoxSpecTest
org.apache.maven.surefire.booter.SurefireExecutionException: org/specs/
matcher/AnyBaseMatchers$$anon$4; nested exception is
java.lang.NoClassDefFoundError: org/specs/matcher/AnyBaseMatchers$$anon
$4
java.lang.NoClassDefFoundError: org/specs/matcher/AnyBaseMatchers$$anon
$4
 at org.specs.Specification.init(Specification.scala:43)
 at net.liftweb.common.BoxSpec$.init(BoxSpec.scala:26)
 at net.liftweb.common.BoxSpec$.clinit(BoxSpec.scala)
 at net.liftweb.common.BoxSpecTest.init(BoxSpec.scala:25)
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0
(Native Method)
 at sun.reflect.NativeConstructorAccessorImpl.newInstance
(NativeConstructorAccessorImpl.java:39)
 at sun.reflect.DelegatingConstructorAccessorImpl.newInstance
(DelegatingConstructorAccessorImpl.java:27)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:
513)
 at java.lang.Class.newInstance0(Class.java:355)
 at java.lang.Class.newInstance(Class.java:308)
 at org.specs.runner.JUnitSuiteRunner.testSuite
(JUnitSuiteRunner.scala:37)
 at org.specs.runner.JUnitSuiteRunner.run
(JUnitSuiteRunner.scala:45)
 at org.apache.maven.surefire.junit4.JUnit4TestSet.execute
(JUnit4TestSet.java:59)
 at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet
(AbstractDirectoryTestSuite.java:115)
 at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute
(AbstractDirectoryTestSuite.java:102)
 at org.apache.maven.surefire.Surefire.run(Surefire.java:180)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess
(SurefireBooter.java:350)
 at org.apache.maven.surefire.booter.SurefireBooter.main
(SurefireBooter.java:1021)
Caused by: java.lang.ClassNotFoundException:
org.specs.matcher.AnyBaseMatchers$$anon$4
 at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
 at java.security.AccessController.doPrivileged(Native Method)
 at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:315)
 at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:
330)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:250)
 at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:
398)
 ... 22 more
Caused by: java.util.zip.ZipException: invalid bit length repeat
 at java.util.zip.InflaterInputStream.read
(InflaterInputStream.java:147)
 at sun.misc.Resource.getBytes(Resource.java:108)
 at java.net.URLClassLoader.defineClass(URLClassLoader.java:
256)
 at java.net.URLClassLoader.access$000(URLClassLoader.java:56)
 at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
 ... 28 more

Obviously an issue with specs, but just thought id report it to
hopefully add some clarity.

Cheers, Tim

On Jan 27, 8:15 pm, David Pollakfeeder.of.the.be...@gmail.com
wrote:

On Wed, Jan 27, 2010 at 11:58 AM, Jeppe Nejsum Madsenje...@ingolfs.dkwrote:


Indrajit Raychaudhuriindraj...@gmail.com  writes:



Some more awesomeness - 280_port_refresh of Lift has moved to
Scala-2.8.0.Beta1.



Cheers, Indrajit



Awesome. How much is supported?


Right now, nothing... I'm working on fixing some issues and working around
compiler problems.






  Someone running anything substantial on
2.8 yet? I really (really!) want to ditch the 2.7 Eclipse plugin for
2.8



/Jeppe



--
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...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.


--
Lift, the simply functional web frameworkhttp://liftweb.net
Beginning Scalahttp://www.apress.com/book/view/1430219890
Follow me:http://twitter.com/dpp
Surf the harmonics




--
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...@googlegroups.com.
For more options, visit this group at

Re: [Lift] Re: Lift 2.0 on Scala 2.8 update


The output is fine. Curious to know what puzzled you in the output.

Can you please send me the output of mvn help:effective-pom for 
lift-common?


Cheers, Indrajit

On 31/01/10 11:47 PM, Timothy Perrett wrote:

However, the dependency tree looks like:

[INFO] 
[INFO] Building Lift Common
[INFO]task-segment: [dependency:tree]
[INFO] 
[INFO] [dependency:tree {execution: default-cli}]
[INFO] net.liftweb:lift-common:jar:2.0-scala280-SNAPSHOT
[INFO] +- org.scala-lang:scala-library:jar:2.8.0.Beta1:compile
[INFO] +- org.scala-tools.testing:specs_2.8.0.Beta1:jar:1.6.2:test
[INFO] +- 
org.scala-tools.testing:scalacheck_2.8.0.Beta1-RC5:jar:1.7-SNAPSHOT:test
[INFO] |  \- org.scala-tools.testing:test-interface:jar:0.2:test
[INFO] \- junit:junit:jar:4.7:test

Which is somewhat puzzling...

Cheers, Tim

On 31 Jan 2010, at 18:07, Indrajit Raychaudhuri wrote:


Welcome back, Tim!

I am suspecting that an incorrect spec version is sneaking in.
Just to confirm - the maintained 2.8 port branch is 280_port_refresh.

Cheers, Indrajit

On 31/01/10 11:02 PM, Timothy Perrett wrote:

I just attempted to build the branch and got the following:

Running net.liftweb.common.BoxSpecTest
org.apache.maven.surefire.booter.SurefireExecutionException: org/specs/
matcher/AnyBaseMatchers$$anon$4; nested exception is
java.lang.NoClassDefFoundError: org/specs/matcher/AnyBaseMatchers$$anon
$4
java.lang.NoClassDefFoundError: org/specs/matcher/AnyBaseMatchers$$anon
$4
 at org.specs.Specification.init(Specification.scala:43)
 at net.liftweb.common.BoxSpec$.init(BoxSpec.scala:26)
 at net.liftweb.common.BoxSpec$.clinit(BoxSpec.scala)
 at net.liftweb.common.BoxSpecTest.init(BoxSpec.scala:25)
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0
(Native Method)
 at sun.reflect.NativeConstructorAccessorImpl.newInstance
(NativeConstructorAccessorImpl.java:39)
 at sun.reflect.DelegatingConstructorAccessorImpl.newInstance
(DelegatingConstructorAccessorImpl.java:27)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:
513)
 at java.lang.Class.newInstance0(Class.java:355)
 at java.lang.Class.newInstance(Class.java:308)
 at org.specs.runner.JUnitSuiteRunner.testSuite
(JUnitSuiteRunner.scala:37)
 at org.specs.runner.JUnitSuiteRunner.run
(JUnitSuiteRunner.scala:45)
 at org.apache.maven.surefire.junit4.JUnit4TestSet.execute
(JUnit4TestSet.java:59)
 at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet
(AbstractDirectoryTestSuite.java:115)
 at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute
(AbstractDirectoryTestSuite.java:102)
 at org.apache.maven.surefire.Surefire.run(Surefire.java:180)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess
(SurefireBooter.java:350)
 at org.apache.maven.surefire.booter.SurefireBooter.main
(SurefireBooter.java:1021)
Caused by: java.lang.ClassNotFoundException:
org.specs.matcher.AnyBaseMatchers$$anon$4
 at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
 at java.security.AccessController.doPrivileged(Native Method)
 at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:315)
 at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:
330)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:250)
 at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:
398)
 ... 22 more
Caused by: java.util.zip.ZipException: invalid bit length repeat
 at java.util.zip.InflaterInputStream.read
(InflaterInputStream.java:147)
 at sun.misc.Resource.getBytes(Resource.java:108)
 at java.net.URLClassLoader.defineClass(URLClassLoader.java:
256)
 at java.net.URLClassLoader.access$000(URLClassLoader.java:56)
 at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
 ... 28 more

Obviously an issue with specs, but just thought id report it to
hopefully add some clarity.

Cheers, Tim

On Jan 27, 8:15 pm, David Pollakfeeder.of.the.be...@gmail.com
wrote:

On Wed, Jan 27, 2010 at 11:58 AM, Jeppe Nejsum Madsenje...@ingolfs.dkwrote:


Indrajit Raychaudhuriindraj...@gmail.com   writes:



Some more awesomeness - 280_port_refresh of Lift has moved to
Scala-2.8.0.Beta1.



Cheers, Indrajit



Awesome. How much is supported?


Right now, nothing... I'm working on fixing some issues and working around

Re: [Lift] Re: Lift 2.0 on Scala 2.8 update

 artifactIdslf4j-simple/artifactId
 version[1.5.6,)/version
 scopetest/scope
   /dependency
   dependency
 groupIdorg.mortbay.jetty/groupId
 artifactIdjetty/artifactId
 version[6.1.6,7.0)/version
 scopetest/scope
   /dependency
   dependency
 groupIdnet.sourceforge.jwebunit/groupId
 artifactIdjwebunit-htmlunit-plugin/artifactId
 version2.2/version
 scopetest/scope
 exclusions
   exclusion
 artifactIdservlet-api/artifactId
 groupIdjavax.servlet/groupId
   /exclusion
 /exclusions
   /dependency
 /dependencies
   /dependencyManagement
   properties
 maven.compiler.source1.5/maven.compiler.source
 maven.compiler.target1.5/maven.compiler.target
 maven.scaladoc.vscaladocVersion1.2-SNAPSHOT/
maven.scaladoc.vscaladocVersion
 project.build.sourceEncodingUTF-8/project.build.sourceEncoding
 project.reporting.outputEncodingUTF-8/
project.reporting.outputEncoding
 scala.version2.8.0.Beta1/scala.version
 slf4j.version[1.5.6,)/slf4j.version
 vscaladoc.links.liftweb.baseurl/Users/timperrett/repositories/
lift/lift-framework/framework/lift-base/lift-common/../../
vscaladoc.links.liftweb.baseurl
 vscaladoc.links.liftweb.pathsufixtarget/site/scaladocs//
vscaladoc.links.liftweb.pathsufix
   /properties
/project

Cheers, Tim


On Jan 31, 6:35 pm, Indrajit Raychaudhuriindraj...@gmail.com  wrote:

The output is fine. Curious to know what puzzled you in the output.

Can you please send me the output of mvn help:effective-pom for
lift-common?

Cheers, Indrajit

On 31/01/10 11:47 PM, Timothy Perrett wrote:




However, the dependency tree looks like:



[INFO] 
[INFO] Building Lift Common
[INFO]task-segment: [dependency:tree]
[INFO] 
[INFO] [dependency:tree {execution: default-cli}]
[INFO] net.liftweb:lift-common:jar:2.0-scala280-SNAPSHOT
[INFO] +- org.scala-lang:scala-library:jar:2.8.0.Beta1:compile
[INFO] +- org.scala-tools.testing:specs_2.8.0.Beta1:jar:1.6.2:test
[INFO] +- 
org.scala-tools.testing:scalacheck_2.8.0.Beta1-RC5:jar:1.7-SNAPSHOT:test
[INFO] |  \- org.scala-tools.testing:test-interface:jar:0.2:test
[INFO] \- junit:junit:jar:4.7:test



Which is somewhat puzzling...



Cheers, Tim



On 31 Jan 2010, at 18:07, Indrajit Raychaudhuri wrote:



Welcome back, Tim!



I am suspecting that an incorrect spec version is sneaking in.
Just to confirm - the maintained 2.8 port branch is 280_port_refresh.



Cheers, Indrajit



On 31/01/10 11:02 PM, Timothy Perrett wrote:

I just attempted to build the branch and got the following:



Running net.liftweb.common.BoxSpecTest
org.apache.maven.surefire.booter.SurefireExecutionException: org/specs/
matcher/AnyBaseMatchers$$anon$4; nested exception is
java.lang.NoClassDefFoundError: org/specs/matcher/AnyBaseMatchers$$anon
$4
java.lang.NoClassDefFoundError: org/specs/matcher/AnyBaseMatchers$$anon
$4
  at org.specs.Specification.init(Specification.scala:43)
  at net.liftweb.common.BoxSpec$.init(BoxSpec.scala:26)
  at net.liftweb.common.BoxSpec$.clinit(BoxSpec.scala)
  at net.liftweb.common.BoxSpecTest.init(BoxSpec.scala:25)
  at sun.reflect.NativeConstructorAccessorImpl.newInstance0
(Native Method)
  at sun.reflect.NativeConstructorAccessorImpl.newInstance
(NativeConstructorAccessorImpl.java:39)
  at sun.reflect.DelegatingConstructorAccessorImpl.newInstance
(DelegatingConstructorAccessorImpl.java:27)
  at java.lang.reflect.Constructor.newInstance(Constructor.java:
513)
  at java.lang.Class.newInstance0(Class.java:355)
  at java.lang.Class.newInstance(Class.java:308)
  at org.specs.runner.JUnitSuiteRunner.testSuite
(JUnitSuiteRunner.scala:37)
  at org.specs.runner.JUnitSuiteRunner.run
(JUnitSuiteRunner.scala:45)
  at org.apache.maven.surefire.junit4.JUnit4TestSet.execute
(JUnit4TestSet.java:59)
  at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet
(AbstractDirectoryTestSuite.java:115)
  at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute
(AbstractDirectoryTestSuite.java:102)
  at org.apache.maven.surefire.Surefire.run(Surefire.java:180)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
  at java.lang.reflect.Method.invoke(Method.java:597)
  at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess
(SurefireBooter.java:350)
  at org.apache.maven.surefire.booter.SurefireBooter.main
(SurefireBooter.java:1021)
Caused

Re: [Lift] Re: Lift 2.0 on Scala 2.8 update

I was suspecting Java 1.5 (if you were on 10.5). That's not the case. So 
I am completely stumped now.


See if you can compare with the Hudson copy 
(http://hudson.scala-tools.org/view/Lift/job/lift-framework-scala280/)


- IRC

On 01/02/10 12:55 AM, Timothy Perrett wrote:

macbookpro:lift-framework timperrett$ java -version
java version 1.6.0_17
Java(TM) SE Runtime Environment (build 1.6.0_17-b04-248-10M3025)
Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01-101, mixed mode)

macbookpro:lift-framework timperrett$ mvn -version
Apache Maven 2.2.1 (r801777; 2009-08-06 20:16:01+0100)
Java version: 1.6.0_17
Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/
Home
Default locale: en_US, platform encoding: MacRoman
OS name: mac os x version: 10.6.2 arch: x86_64 Family: mac

Cheers, Tim

On Jan 31, 6:59 pm, Indrajit Raychaudhuriindraj...@gmail.com  wrote:

Hmm, the effective pom is perfect! Something else somewhere.
Are you on OSX 10.5 or 10.6?

- IRC

On 01/02/10 12:11 AM, Timothy Perrett wrote:




I was puzzled because the deps looked fine ;)



Here's the effective pom:



?xml version=1.0 encoding=UTF-8?
!--
==
--
!--
--
!-- Generated by Maven Help Plugin on 1/31/10 6:40
PM  --
!-- See:http://maven.apache.org/plugins/maven-help-plugin/
--
!--
--
!--
==
--



!--
==
--
!--
--
!-- Effective POM for
project  --
!-- 'net.liftweb:lift-common:jar:2.0-scala280-
SNAPSHOT'--
!--
--
!--
==
--



project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://
www.w3.org/2001/XMLSchema-instance xsi:schemaLocation=http://
maven.apache.org/POM/4.0.0http://maven.apache.org/xsd/maven-4.0.0.xsd;
modelVersion4.0.0/modelVersion
parent
  artifactIdlift-base/artifactId
  groupIdnet.liftweb/groupId
  version2.0-scala280-SNAPSHOT/version
/parent
groupIdnet.liftweb/groupId
artifactIdlift-common/artifactId
version2.0-scala280-SNAPSHOT/version
nameLift Common/name
descriptionCommon Interfaces for Lift and perhaps other
frameworks/description
urlhttp://dev.liftweb.net/framework/lift-base/lift-common/url
inceptionYear2006/inceptionYear
organization
  nameWorldWide Conferencing, LLC/name
  urlhttp://www.liftweb.net/url
/organization
licenses
  license
nameApache License, Version 2.0/name
urlhttp://www.apache.org/licenses/LICENSE-2.0.txt/url
distributionrepo/distribution
commentsLift open source software is licensed under an Apache
2.0 license./comments
  /license
/licenses
mailingLists
  mailingList
nameUser and Developer Discussion List/name
subscribeliftweb+subscr...@googlegroups.com/subscribe
unsubscribeliftweb+unsubscr...@googlegroups.com/unsubscribe
postliftweb@googlegroups.com/post
archivehttp://groups.google.com/group/liftweb/archive
  /mailingList
  mailingList
nameCommitter Discussion List/name
archivehttp://groups.google.com/group/lift-committers/
archive
  /mailingList
  mailingList
nameAnnouncement List/name
subscribelift-announce+subscr...@googlegroups.com/subscribe
unsubscribelift-announce+unsubscr...@googlegroups.com/
unsubscribe
archivehttp://groups.google.com/group/lift-announce/archive
  /mailingList
/mailingLists
developers
  developer
iddpp/id
nameDavid Pollak/name
emaildpp [at] liftweb.net/email
roles
  roleBDFL/role
  roleFeeder of the Bears/role
/roles
timezone-8/timezone
  /developer
  developer
idBurak.Emir/id
nameBurak Emir/name
  /developer
  developer
idphilipp.schmidt/id
namephilipp.schmidt/name
  /developer
  developer
idcwilkes/id
namecwilkes/name
  /developer
  developer
idjulien.wetterwald/id
namejulien.wetterwald/name
  /developer
  developer
idleppoc/id
nameleppoc/name
  /developer
  developer
idstepan.koltsov/id
namestepan.koltsov/name
  /developer
  developer
idjorge.ortiz/id
nameJorge Ortiz/name
emailjorge [at] liftweb.net/email
timezone-8/timezone
  /developer
  developer
idstevej/id
nameSteve Jenson/name
  /developer
  developer
idalex.boisvert/id
nameAlex Boisvert/name
  /developer
  developer
nameOctoberDan/name
  /developer
  developer
idviktor.klang/id
nameViktor Klang a.k.a. Sevikkla/name
roles
  roleEnhancement specialist/role

Re: [Lift] Re: Upgrade to Flot 0.6

Let's keep the unpacked excanvas for the sake of consistency. Using YUI 
compressor at build time is what lift-webkit does at the moment.


How about injecting the excanvas JS conditionally (via ieMode)? This is 
mostly cosmetic though.


Cheers, Indrajit

On 30/01/10 6:14 AM, Peter Robinett wrote:

Aaron, thanks so much for taking the initiative to upgrade Flot, it's
something that I've been meaning to do. Just skimming over your
changes, everything looks good. As for not using the packed excanvas
file, that should be ok since Lift runs the YUI compressor by default
on all Javascript files (correct, David?). Of course, broken URLs need
to be fixed.

David, how do we go about merging these changes?

Peter

On Jan 29, 3:32 pm, Aaron Valadea...@alum.mit.edu  wrote:

There is one break that my commit made which I just realized after I
had sent this email in that I deleted the excanvas.pack.js file and
dropped in the excanvas.js that was included with the Flot 0.6
distribution but didn't rename it to be excanvas.pack.js and didn't
change the path in the Flot.scala file.

I can make an additional commit that fixes this, if it pleases the court. :-)

- A

On Fri, Jan 29, 2010 at 6:15 PM, David Pollak



feeder.of.the.be...@gmail.com  wrote:

Peter,



What do you think of the upgrade (given that you're the most Flot-ish Lift
committer)?



Thanks,



David



On Fri, Jan 29, 2010 at 12:32 PM, Aaron Valadea...@alum.mit.edu  wrote:



Hello all,
I needed to use some of the recent functionality in the Flot jQuery
plugin which is version 0.6.  The Flot lift-widget is currently at
0.4.  So I upgraded it to use the new version and I've posted the
commit on github:



http://github.com/avalade/liftweb/commit/fa3d76fb72a7f74d13265e4039f0...



Version 0.6 of Flot does make one breaking change which requires some
of the options which were previously described as a top level
attributes on the FlotOptions object to be pushed inside of a new
attribute called FlotSeriesOptions.  I've made the appropriate changes
to the various example Flot charts which were included in the flotDemo
module.



Would it be possible to get this change upstream?



- Aaron



--
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...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.



--
Lift, the simply functional web frameworkhttp://liftweb.net
Beginning Scalahttp://www.apress.com/book/view/1430219890
Follow me:http://twitter.com/dpp
Surf the harmonics



--
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...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.




--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Always log through Slf4j?




On 30/01/10 3:23 AM, Jeppe Nejsum Madsen wrote:

David Pollakfeeder.of.the.be...@gmail.com  writes:


On Fri, Jan 29, 2010 at 2:40 AM, Jeppe Nejsum Madsenje...@ingolfs.dkwrote:


Indrajit Raychaudhuriindraj...@gmail.com  writes:


I am not sure you need to add yet another adapter on top of slf4j for
MDC support. Enhancing the existing slf4j wrapper for the purpsoe
might be worth an attempt instead.


Yes but if we introduce a Lift MDC it would need to delegate to either
Log4j or Slf4j (which already has MDC wrapped for logback  log4j)



Looking at the way the Java frameworks do MDC, I'm not keen on it.

I'd much rather see some kind of doWith mechanism:

Log.doWith(name -  value, otherName -  otherValue) {

}


Exactly. I was about to implement something along these lines. But if we
would still support native log4j as well as slf4j, it would mean that
I'd have to implement two different MDC implementations (ala Log4jLogger
and Slf4jLogger). And this is exactly the problem Slf4j solves, hence
the original mail :-)

[...]


I'd like to apply Scala and Lift constructs to Logging rather than just
borrow existing paradigms.


I agree on the interface part. I think there's good value in leveraging
existing logging frameworks for the actual logging as long as there's
not too big of an impedance mismatch.


In terms of slf4j, I have a generic allergic reaction to it.


Fair enough :-) It is also non-trivial to get these things right in all
scenarios with different containers etc (Seems like Slf4j has succeeded
where commons-logging has failed though. Just look at the
commons-logging classloader problems).


The other problem slf4j solves is providing unified access to underlying 
logging framework used by the dependencies. Thankfully, that's not much 
to be bothered about in Lift space as yet. So this doesn't count much.


The other issue I see is the author of log4j moving on to concentrate on 
logback.


Given how reliable and ubiquitous log4j bas been, the inclination 
towards slf4j isn't being driven on the basis of pure merit - I agree.





There was a thread 2 years ago on Slf4j that seemed to me to be a
bunch of zealots demanding it as the default without giving any
reasons other than it's better (think emacs vs vi.)


But clearly emacs is better :-)


If there are real reasons to insert it into the mix, I'll listen to
them, but I'd rather start at a design that's Scala and Lift-like and
move down the implementation stack to see why it's a win to insert
slf4j.


The real benefit, as I see it, is that the Lift code can concentrate on
providing a Scala/Lift interface to logging, programmed against a single
well defined (imho) API while still giving the user full flexibility on
the actual logging backend (log4j, JDK, logback etc)

But we've already spent quite some time back and forth on this (minor)
issue, so I'll just implement MDC in the same way as the current
loggers. If we keep a sane interface, we can always change the
implementation later if deemed necessary.


Okay, hope you would consider the Loggable trait stuff too!



/Jeppe



--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Always log through Slf4j?




On 30/01/10 2:47 PM, Jeppe Nejsum Madsen wrote:

David Pollakfeeder.of.the.be...@gmail.com  writes:

[...]


If you're 100% sure that nothing will break, go for the slf4j-based
approach.


100% certainty is difficult :-)

How about this:

1) Implement new MDC functionality only for Slf4j

+0


2) Switch the default logging to go through Slf4j (with log4j backend), but keep
existing Log4j functionality

+1


3) After a while, cleanup and remove the log4j native logging
-1 deprecate first and then remove later. Given my recent Scala 2.7 to 
2.8 porting experience, I now appreciate the significance of 
@deprecated() even more :)




Depending on the time frame, we could postpone 2)+3) to sometime after M2

/Jeppe



--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] Re: beginner help

Hi Lachlan,

In the mvn goal, you have to use -DarchetypeVersion=2.0-scala280-
SNAPSHOT instead :)

The full command should be:

mvn archetype:generate -U -DarchetypeGroupId=net.liftweb -
DarchetypeArtifactId=lift-archetype-basic -DarchetypeVersion=2.0-
scala280-SNAPSHOT -DarchetypeRepository=http://scala-tools.org/repo-
snapshots -DremoteRepositories=http://scala-tools.org/repo-snapshots -
DgroupId=ldeck.liftweb -DartifactId=hellolift

You can skip -DscalaVersion (since that is the default for
archetypeVersion 2.0-scala280-SNAPSHOT).

This should give you a *proper* project on scala 2.8. Let us know how
this goes.

Cheers, Indrajit

On Jan 30, 11:53 am, Lachlan Deck lachlan.d...@gmail.com wrote:
 Woops - forgot to mention I'm using Eclipse 3.5.1 Cocoa/64 on Mac OS X 
 10.6.2...

 On 30/01/2010, at 5:22 PM, Lachlan Deck wrote:





  Hi all,

  I'm just getting started with both scala and lift (or attempting to) and as 
  a first step I've installed the scala eclipse plugin from nightlies 
  (version 2.8.0.r20723-b20100129045351) and attempted to just create a basic 
  maven-based lift project via m2eclipse.

  I've got some initial build errors that I can't quite figure out.

  The params I used were equivalent to these:
  mvn archetype:generate -DarchetypeGroupId=net.liftweb 
  -DarchetypeArtifactId=lift-archetype-blank -DarchetypeVersion=2.0-SNAPSHOT 
  -DremoteRepositories=http://scala-tools.org/repo-snapshots-DgroupId=ldeck.liftweb
   -DartifactId=hellolift -DscalaVersion=2.8.0.Beta1

  This, however, doesn't appear to automatically pick up the scala nature and 
  thus initially fails to build after creation. Easily fixed, of course, but 
  it also seems to reference jdk 1.4 so I changed that to 1.6. I assume 1.5 
  would be a minimum for scala 2.8?

  Anyway, after doing so all the class files compile but there's the 
  following build errors on the project itself:
  - error while loading Full, Scala signature Full has wrong version
  - error while loading Helpers, Scala signature Helpers has wrong version
  - error while loading LiftRules, Scala signature LiftRules has wrong version
  - error while loading Loc, Scala signature Loc has wrong version
  - error while loading Menu, Scala signature Menu has wrong version
  - error while loading PCDataXmlParser, Scala signature PCDataXmlParser has 
  wrong version

  Any pointers on what I've missed would be great. Thanks!

  with regards,
  --

  Lachlan Deck

 with regards,
 --

 Lachlan Deck

-- 
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Always log through Slf4j?




On 30/01/10 3:06 PM, Jeppe Nejsum Madsen wrote:

Indrajit Raychaudhuriindraj...@gmail.com  writes:


On 30/01/10 2:47 PM, Jeppe Nejsum Madsen wrote:

David Pollakfeeder.of.the.be...@gmail.com   writes:

[...]


If you're 100% sure that nothing will break, go for the slf4j-based
approach.


100% certainty is difficult :-)

How about this:

1) Implement new MDC functionality only for Slf4j

+0


2) Switch the default logging to go through Slf4j (with log4j backend), but keep
existing Log4j functionality

+1


3) After a while, cleanup and remove the log4j native logging

-1 deprecate first and then remove later. Given my recent Scala 2.7 to
2.8 porting experience, I now appreciate the significance of
@deprecated() even more :)


You're right of course, but I don't think anybody will ever see the
deprecated warnings since this is Lift internals only (ie users never used
the Log4jLogging trait). But we could deprecate it in step 2)


Quite so. I am possibly going through this paranoia after falling over 
couple of times in the past few days.




/Jeppe



--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Re: [Lift Announce] Lift 1.0.3 released


David,

It's an honor. You are welcome!

- Indrajit


On 30/01/10 11:21 PM, David Pollak wrote:

Indrajit,

Thanks for yet again spinning a build and moving Lift forward!

Rock on!

David

On Fri, Jan 29, 2010 at 10:33 PM, Indrajit Raychaudhuri
indraj...@gmail.com mailto:indraj...@gmail.com wrote:

The Lift team is pleased to announce the lift-1.0.3 release!

Lift is an expressive and elegant framework for writing web
applications.
Lift stresses the importance of security, maintainability, scalability
and performance while allowing for high levels of developer
productivity.
Lift is a scala web framework.

Changes in this version include:

Fixed Bugs:
o Upgrade to Scala 2.7.7
o Add user presence heartbeat support

Have fun!
-Lift team




--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--
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...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.


--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] Re: beginner help

Hi Lachlan,

On Jan 30, 5:50 pm, Lachlan Deck lachlan.d...@gmail.com wrote:
 Hi Indrajit,

 On 30/01/2010, at 8:43 PM, Indrajit Raychaudhuri wrote:

  Hi Lachlan,

  In the mvn goal, you have to use -DarchetypeVersion=2.0-scala280-
  SNAPSHOT instead :)

 Ah. That makes all the difference. Thanks.

 Now for a couple of follow-up questions:
 1) I noticed the jpa based archetypes are not as yet available for 2.8. It'll 
 be a little while yet before I'd be up to speed enough with lift to worry 
 about that, but is there info somewhere about eta's for such things?

This has dependency on lift-jpa which in turn depends on scalajpa
(http://github.com/dchenbecker/scalajpa). We would attempt to have a
scalajpa build for scala 2.8 available soon and then lift-jpa enabled
in Lift. We haven't planned any concrete eta for this yet.


 2) (might be slightly OT) sometimes eclipse forgets that the scala class 
 files are scala files and not java files. Is this a known issue? Do you know 
 what triggers this and how to remedy it? I tried cleaning the project, 
 closing/opening the project, restarting eclipse .. but only recreating the 
 project worked. Perhaps some eclipse meta-data was out of order...

I don't use Eclipse :( Any Eclipse ninja to help Lachlan?


 Thanks.

 with regards,
 --

 Lachlan Deck

Cheers, Indrajit

-- 
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Always log through Slf4j?

I am not sure you need to add yet another adapter on top of slf4j for 
MDC support. Enhancing the existing slf4j wrapper for the purpsoe might 
be worth an attempt instead.


Slf4j supports MDC (org.slf4j.MDC) and automatically delegates MDC 
functionality to the underlying logging framework if it has support for 
such. It's a facade after all.


That said, I think there is room (and opportunity) for defaulting to 
lightweight wrapper over slf4j and letting users choose any underlying 
framework (simple, log4j, logback, jul) at build/deploy time. I am 
optimistic this would be doable without any code change on existing Lift 
applications. And keep OSGi happiness in the way.


As such, I thing we should be careful and avoid duplicating (very 
similar impl of) MDC enhancement to both Log4JLogger and Slf4JLogger.


I would be inclined to consider:

- Zero code change in application for switching log implementations 
(nothing should be necessary to be put in Boot.scala)


- Tuck in everything behind the helper object(s) - Log for the root 
logger or other objects introduced because of the Loggable trait


- Have MDC and other enhancements aligned to slf4j. Per design slf4j-api 
expects a real logging framework behind it (bundled or otherwise).


- In Lift, for guaranteed compatibility, default to log4j (by using 
log4j wrapper of slf4j) - but still allow using logback, jul etc. just 
by flipping the dependency during build. Bonus, slf4j would fallback to 
simple logger if none of the dependencies are available.


- Existing applications can just add log4j bridge for the existing behavior.

- New applications (generated from archetype) mark slf4j-api as compile 
scope dependency and have one of the implementations 
(simple,log4j,logback etc.) added as either compile scope or provided 
scope (to cover for log4j in container classpath). This can even be 
offered as choice during archetype:generate!


Thoughts?

Cheers, Indrajit


On 29/01/10 4:04 AM, David Pollak wrote:



On Thu, Jan 28, 2010 at 2:11 PM, Jeppe Nejsum Madsen je...@ingolfs.dk
mailto:je...@ingolfs.dk wrote:

Last logging question, I promise!

I'm about to implement MDC in Lift's logging, but it seems more and more
layers are introduced.

So before adding another adapter on top of e.g. Slf4j which is already
an adapter on top of e.g. logback I thought I would see if there are any
objections to making Lift always log through Slf4j?


Yes.  I object.  There is a way to log through slf4j right now.  It's a
one-line addition to boot.scala.  I have a very strong preference for
not changing any APIs or defaults.  If you want to add or enhance the
mechanics, cool.

There wouldn't be any API changes and Log4j could still be the default
backend, with the config settings as we currently have, only there
wouldn't be any Log4JLogger.

On the positive side, Lift's logging is simpler: only interface to Slf4j
(we would keep the log4j config stuff)

Downside is two more jars if you're using log4j: slf4j-api 
slf4j-log4j12

Thoughts?

/Jeppe

--
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
mailto:liftweb@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
mailto:liftweb%2bunsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.




--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--
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...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.


--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Re: [lift] Issue with my first Lift project


Most certainly, the groupId for maven-jetty-plugin is missing.

The minimal configuration for jetty plugin would be:

  plugin
groupIdorg.mortbay.jetty/groupId
artifactIdmaven-jetty-plugin/artifactId
version6.1.22/version
  /plugin

Cheers, Indrajit


On 29/01/10 3:18 PM, tomLee wrote:


I tried,but nothing change.

mvn jetty:run -U
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'jetty'.
[INFO] org.apache.maven.plugins: checking for updates from central
[INFO] org.codehaus.mojo: checking for updates from central
[INFO] artifact org.apache.maven.plugins:maven-jetty-plugin: checking for
updates from central
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] The plugin 'org.apache.maven.plugins:maven-jetty-plugin' does not
exist or no valid version could be found
[INFO]

[INFO] For more information, run Maven with the -e switch
[INFO]

[INFO] Total time: 3 seconds
[INFO] Finished at: Fri Jan 29 17:47:33 CST 2010
[INFO] Final Memory: 1M/4M
[INFO]






David Bernard-3 wrote:


I suppose it's your first run of mvn jetty:run.
try : mvn jetty:run -U to force download of jetty.

see http://wiki.github.com/dpp/liftweb/about-maven-mini-guide

/davidB

On Fri, Jan 29, 2010 at 04:04, tomLeetomcatl...@gmail.com  wrote:


Got error when I run it:

D:\MySource\oterh\myliftmvn jetty:run
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'jetty'.
[INFO] artifact org.apache.maven.plugins:maven-jetty-plugin: checking for
updates from central
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] The plugin 'org.apache.maven.plugins:maven-jetty-plugin' does not
exist or no valid version could be found
[INFO]

[INFO] For more information, run Maven with the -e switch
[INFO]

[INFO] Total time: 1 second
[INFO] Finished at: Fri Jan 29 10:53:33 CST 2010
[INFO] Final Memory: 1M/4M
[INFO]



thanks
--
View this message in context:
http://old.nabble.com/Issue-with-my-first-Lift-project-tp27366670p27366670.html
Sent from the liftweb mailing list archive at Nabble.com.

--
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...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.




--
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...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.







--
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...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Lift and Scala 2.8 Beta1

] artifact org.scala-tools:maven-scala-plugin: checking for
updates from scala-tools.org http://scala-tools.org
[INFO] artifact org.scala-tools:maven-scala-plugin: checking for
updates from central
[INFO] artifact org.mortbay.jetty:maven-jetty-plugin: checking for
updates from scala-tools.org http://scala-tools.org
[INFO] artifact org.mortbay.jetty:maven-jetty-plugin: checking for
updates from central
[INFO] artifact net.sf.alchim:yuicompressor-maven-plugin: checking
for updates from scala-tools.org http://scala-tools.org
[INFO] artifact net.sf.alchim:yuicompressor-maven-plugin: checking
for updates from central
[INFO] artifact org.apache.maven.plugins:maven-eclipse-plugin:
checking for updates from scala-tools.org http://scala-tools.org
[INFO] artifact org.apache.maven.plugins:maven-eclipse-plugin:
checking for updates from central
[INFO] [clean:clean]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [yuicompressor:compress {execution: default}]
[INFO] nb warnings: 0, nb errors: 0
[INFO] snapshot net.liftweb:lift-core:2.0-scala280-SNAPSHOT:
checking for updates from scala-tools.org http://scala-tools.org
Downloading:

http://scala-tools.org/repo-releases/net/liftweb/lift-core/2.0-scala280-SNAPSHOT/lift-core-2.0-scala280-SNAPSHOT.pom
[INFO] artifact org.mortbay.jetty:jetty: checking for updates from
scala-tools.org http://scala-tools.org
[INFO] artifact org.mortbay.jetty:jetty: checking for updates from
central
Downloading:

http://scala-tools.org/repo-releases/net/liftweb/lift-core/2.0-scala280-SNAPSHOT/lift-core-2.0-scala280-SNAPSHOT.jar
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Failed to resolve artifact.

Missing:
--
1) net.liftweb:lift-core:jar:2.0-scala280-SNAPSHOT

   Try downloading the file manually from the project website.

   Then, install it using the command:
   mvn install:install-file -DgroupId=net.liftweb
-DartifactId=lift-core -Dversion=2.0-scala280-SNAPSHOT
-Dpackaging=jar -Dfile=/path/to/file

   Alternatively, if you host your own repository you can deploy the
file there:
   mvn deploy:deploy-file -DgroupId=net.liftweb
-DartifactId=lift-core -Dversion=2.0-scala280-SNAPSHOT
-Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

   Path to dependency:
1) com.biosimilarity.identity:testLift280:war:1.0-SNAPSHOT
2) net.liftweb:lift-core:jar:2.0-scala280-SNAPSHOT

--
1 required artifact is missing.

for artifact:
   com.biosimilarity.identity:testLift280:war:1.0-SNAPSHOT

from the specified remote repositories:
   central (http://repo1.maven.org/maven2),
scala-tools.org http://scala-tools.org
(http://scala-tools.org/repo-releases)


[INFO]

[INFO] For more information, run Maven with the -e switch
[INFO]

[INFO] Total time: 9 seconds
[INFO] Finished at: Fri Jan 29 10:30:24 PST 2010
[INFO] Final Memory: 8M/15M
[INFO]

bash-3.2$


On Thu, Jan 28, 2010 at 9:04 PM, Indrajit Raychaudhuri
indraj...@gmail.com mailto:indraj...@gmail.com wrote:

The Lift 2.0 snapshot jars for Scala 2.8 are now available on
scala-tools Maven repository. Feel free to try your Lift application
against 2.0-scala280-SNAPSHOT jars.

You can change Lift artifact dependencies version to
2.0-scala280-SNAPSHOT in you application pom and proceed to build as
usual.

Cheers, Indrajit


On 28/01/10 2:31 AM, David Pollak wrote:

Folks,

Lift is currently building against Scala 2.8 Beta1 and currently
runs
the examples/example app (the app that's at
http://demo.liftweb.net).
We have disabled many of the tests during the automated build
because as
of last night, not all the test frameworks (ScalaTest, Specs, and
ScalaCheck) were compiled against 2.8 Beta1.

We are doing continuous builds of Lift against the 280_port_refresh
branch at http://hudson.scala-tools.org/job/lift-scala280/  And
will be
publishing to the scala-tools.org http://scala-tools.org
http://scala-tools.org Maven

repository very soon now (today or tomorrow).

Once we get the JAR files publishing to the Scala-tools.org Maven
repository, we will open up the Lift list to report of problems
running
Lift apps against 2.8 Beta 1.  Please do not file tickets until
there's

Re: [Lift] Lift and Scala 2.8 Beta1

 at: Fri Jan 29 10:28:16 PST 2010
[INFO] Final Memory: 8M/15M
[INFO]

bash-3.2$ cd testLift280/
bash-3.2$ mvn -U clean compile
[INFO] Scanning for projects...
[INFO]

[INFO] Building testLift280
[INFO]task-segment: [clean, compile]
[INFO]

[INFO] artifact org.scala-tools:maven-scala-plugin: checking for
updates from scala-tools.org http://scala-tools.org
[INFO] artifact org.scala-tools:maven-scala-plugin: checking for
updates from central
[INFO] artifact org.mortbay.jetty:maven-jetty-plugin: checking
for updates from scala-tools.org http://scala-tools.org
[INFO] artifact org.mortbay.jetty:maven-jetty-plugin: checking
for updates from central
[INFO] artifact net.sf.alchim:yuicompressor-maven-plugin:
checking for updates from scala-tools.org http://scala-tools.org
[INFO] artifact net.sf.alchim:yuicompressor-maven-plugin:
checking for updates from central
[INFO] artifact org.apache.maven.plugins:maven-eclipse-plugin:
checking for updates from scala-tools.org http://scala-tools.org
[INFO] artifact org.apache.maven.plugins:maven-eclipse-plugin:
checking for updates from central
[INFO] [clean:clean]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [yuicompressor:compress {execution: default}]
[INFO] nb warnings: 0, nb errors: 0
[INFO] snapshot net.liftweb:lift-core:2.0-scala280-SNAPSHOT:
checking for updates from scala-tools.org http://scala-tools.org
Downloading:

http://scala-tools.org/repo-releases/net/liftweb/lift-core/2.0-scala280-SNAPSHOT/lift-core-2.0-scala280-SNAPSHOT.pom
[INFO] artifact org.mortbay.jetty:jetty: checking for updates
from scala-tools.org http://scala-tools.org
[INFO] artifact org.mortbay.jetty:jetty: checking for updates
from central
Downloading:

http://scala-tools.org/repo-releases/net/liftweb/lift-core/2.0-scala280-SNAPSHOT/lift-core-2.0-scala280-SNAPSHOT.jar
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Failed to resolve artifact.

Missing:
--
1) net.liftweb:lift-core:jar:2.0-scala280-SNAPSHOT

   Try downloading the file manually from the project website.

   Then, install it using the command:
   mvn install:install-file -DgroupId=net.liftweb
-DartifactId=lift-core -Dversion=2.0-scala280-SNAPSHOT
-Dpackaging=jar -Dfile=/path/to/file

   Alternatively, if you host your own repository you can deploy
the file there:
   mvn deploy:deploy-file -DgroupId=net.liftweb
-DartifactId=lift-core -Dversion=2.0-scala280-SNAPSHOT
-Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

   Path to dependency:
1) com.biosimilarity.identity:testLift280:war:1.0-SNAPSHOT
2) net.liftweb:lift-core:jar:2.0-scala280-SNAPSHOT

--
1 required artifact is missing.

for artifact:
   com.biosimilarity.identity:testLift280:war:1.0-SNAPSHOT

from the specified remote repositories:
   central (http://repo1.maven.org/maven2),
scala-tools.org http://scala-tools.org
(http://scala-tools.org/repo-releases)


[INFO]

[INFO] For more information, run Maven with the -e switch
[INFO]

[INFO] Total time: 9 seconds
[INFO] Finished at: Fri Jan 29 10:30:24 PST 2010
[INFO] Final Memory: 8M/15M
[INFO]

bash-3.2$


On Thu, Jan 28, 2010 at 9:04 PM, Indrajit Raychaudhuri
indraj...@gmail.com mailto:indraj...@gmail.com wrote:

The Lift 2.0 snapshot jars for Scala 2.8 are now available on
scala-tools Maven repository. Feel free to try your Lift
application against 2.0-scala280-SNAPSHOT jars.

You can change Lift artifact dependencies version to
2.0-scala280-SNAPSHOT in you application pom and proceed to
build as usual.

Cheers, Indrajit


On 28/01/10 2:31 AM, David Pollak wrote:

Folks,

Lift is currently building against Scala 2.8 Beta1

Re: [Lift Announce] Re: [Lift] Lift and Scala 2.8 Beta1


For SNAPSHOTs, you need to add the SNAPSHOT repo explicitly.

Try this command:

mvn archetype:generate -U \
   -DarchetypeGroupId=net.liftweb \
   -DarchetypeArtifactId=lift-archetype-basic \
   -DarchetypeVersion=2.0-scala280-SNAPSHOT \
   -DarchetypeRepository=http://scala-tools.org/repo-snapshots \
   -DremoteRepositories=http://scala-tools.org/repo-snapshots \
   -DgroupId=$1 -DartifactId=$2

NB: My previous reply was a supplement of this one:
http://groups.google.com/group/liftweb/msg/0734a3a1b7d0424d

Cheers, Indrajit

On 30/01/10 12:50 AM, Meredith Gregory wrote:

Dear Indrajit,

See the trace below with the archetypeVersion set as you suggest.

Best wishes,

--greg

bash-3.2$ bin/mklift.sh com.biosimilarity.identity WhiteRabbit
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'archetype'.
[INFO] org.apache.maven.plugins: checking for updates from central
[INFO] org.codehaus.mojo: checking for updates from central
[INFO] artifact org.apache.maven.plugins:maven-archetype-plugin:
checking for updates from central
[INFO]

[INFO] Building Maven Default Project
[INFO]task-segment: [archetype:generate] (aggregator-style)
[INFO]

[INFO] Preparing archetype:generate
[INFO] No goals needed for project - skipping
[INFO] Setting property: classpath.resource.loader.class =
'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
[INFO] Setting property: velocimacro.messages.on = 'false'.
[INFO] Setting property: resource.loader = 'classpath'.
[INFO] Setting property: resource.manager.logwhenfound = 'false'.
[INFO] [archetype:generate]
[INFO] Generating project in Interactive mode
[INFO] Archetype repository missing. Using the one from
[net.liftweb:lift-archetype-basic:RELEASE -
http://scala-tools.org/repo-releases] found in catalog internal
[INFO] snapshot net.liftweb:lift-archetype-basic:2.0-scala280-SNAPSHOT:
checking for updates from lift-archetype-basic-repo
Downloading:
http://scala-tools.org/repo-releases/net/liftweb/lift-archetype-basic/2.0-scala280-SNAPSHOT/lift-archetype-basic-2.0-scala280-SNAPSHOT.jar
[INFO]

[ERROR] BUILD FAILURE
[INFO]

[INFO] The desired archetype does not exist
(net.liftweb:lift-archetype-basic:2.0-scala280-SNAPSHOT)
[INFO]

[INFO] For more information, run Maven with the -e switch
[INFO]

[INFO] Total time: 5 seconds
[INFO] Finished at: Fri Jan 29 11:19:16 PST 2010
[INFO] Final Memory: 8M/15M
[INFO]

bash-3.2$

On Fri, Jan 29, 2010 at 11:16 AM, Meredith Gregory
lgreg.mered...@gmail.com mailto:lgreg.mered...@gmail.com wrote:

Dear Indrajit,

-DarchetypeVersion=2.0-scala280-SNAPSHOT

was the first thing i tried and that failed. ;-(

Best wishes,

--greg


On Fri, Jan 29, 2010 at 11:15 AM, David Pollak
feeder.of.the.be...@gmail.com
mailto:feeder.of.the.be...@gmail.com wrote:



On Thu, Jan 28, 2010 at 9:04 PM, Indrajit Raychaudhuri
indraj...@gmail.com mailto:indraj...@gmail.com wrote:

The Lift 2.0 snapshot jars for Scala 2.8 are now available
on scala-tools Maven repository. Feel free to try your Lift
application against 2.0-scala280-SNAPSHOT jars.

You can change Lift artifact dependencies version to
2.0-scala280-SNAPSHOT in you application pom and proceed to
build as usual.


Awesome!  Let the Lift on Scala 2.8 Beta1 testing and feedback
commence.


Cheers, Indrajit


On 28/01/10 2:31 AM, David Pollak wrote:

Folks,

Lift is currently building against Scala 2.8 Beta1 and
currently runs
the examples/example app (the app that's at
http://demo.liftweb.net).
We have disabled many of the tests during the automated
build because as
of last night, not all the test frameworks (ScalaTest,
Specs, and
ScalaCheck) were compiled against 2.8 Beta1.

We are doing continuous builds of Lift against the
280_port_refresh
branch at
http://hudson.scala-tools.org/job/lift-scala280/  And
will be
publishing to the scala-tools.org
http://scala-tools.org http://scala-tools.org Maven

repository very soon now (today or tomorrow).

Once we get the JAR files publishing to the
Scala-tools.org

[Lift] Lift 1.0.3 released