Re: [Lift] Maven help!
including something at compile-time and not test time is a rare thing for maven, which assumes tests also need dependencies used to compile. Of all the scopes you can specify for dependencies *all* of them end up on the testing classpath. (see http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html ) I would recommend droping one of your requirements, or giving us some more information on exactly the nature of the problem, so we can better assist your maven usage! - Josh Suereth ANyway, what you want to do is exclude the dependency On Fri, Feb 26, 2010 at 3:55 AM, Jeppe Nejsum Madsen je...@ingolfs.dkwrote: Hi, For the new logging code I need a setup that I can't really see how to achieve with Maven: 1) Both slf4j-log4j and logback-classic needs to be on the classpath when compiling 2) Only sf4j-log4j should be on the classpath when testing 3) None should be included in the generated pom dependencies Using scope=provided takes care of 1) 3) But both are still included in the classpath during test /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. -- 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
Congrats on a great framework!! On Fri, Feb 26, 2010 at 8:26 PM, 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.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.
[Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
I think staying in maven would require the least amount of typing, but the most amount of time as you'd have to publish local snapshots of Scala 2.8.0 to use them in the lift build. I remember how annoying this is ;). Also note that deploying maven requires a full scala build, but if needed I can make a short-cut that will just publish the quick libraries. This would help immensely in testing trunk against projects, but is not very helpful otherwise. Would this be desirable? What was already suggested (runing mvn dependency:copy-dependencies) is very viable. However, if lift-mapper relies on lift-util, you'll have to rebuild one before you rebuild the other if you're somehow changing the ABI. If you still wanted to use maven, I recommend using the reactor plugin. If you identify the project that is failing you can run: mvn reactor:make -Dmake.artifacts=net.liftweb:lift-mapper Where net.liftweb:lift-mapper is the groupId:artifactId containing the failing module. This will only build the lift-mapper module and other modules on which lift-mapper depends (i.e. if lift-mapper needs lift-util (and only lift-util) just those two will be built. I have a local VM where I was setting up a scala nightly build that would feed maven. Perhaps when I finish I'll make a write-up on how to do this, or have some kind of template/script you can use to do it by hand. - Josh On Tue, Dec 22, 2009 at 7:24 AM, David Pollak feeder.of.the.be...@gmail.com wrote: I'm cc'ing this to the Lift list. Perhaps Indrajit or another Maven guru can help out. On Tue, Dec 22, 2009 at 2:32 AM, martin odersky martin.oder...@epfl.chwrote: On Tue, Dec 22, 2009 at 11:11 AM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: 2009/12/22 martin odersky martin.oder...@epfl.ch Annoying... Just to explain what goes on here. Between RC3 and RC4 we tightened the erasure of compund types T with U where T and U are traits. These used to be all erased to Object and now are erased to the first trait in the sequence, i.e. T in the example above. Unfortunately it seems the previous behavior of erasing to Object hid a few bugs in prior transformation phases where one should have taken the self type of a class and one took instead the type of the class itself. These bugs are now crawling out, and it seems that lift is their primary crawling ground, probably because of its ubiquitous pattern of using self types that are compound types of traits. Making them creep out sooner than later is beneficial, even if it causes some pain right now ;-) Another problem is that lift by itself is hard to test for me because it requires maven (and I am no maven expert) and maven requires a full build, which takes time to do. So the turn around time is quite high, many hours to days instead of minutes. Any ideas what one can do to address these issues would be welcome. Meanwhile Lift is a large and highly modular framework. The RC4 error occurred while building lift-util which is a prerequisite module (built in the very beginning). The RC5 error occurred while building lift-mapper, which is already outside of the lift-base modules. Hence I am optimistic that we do not need many further rounds. Heiko Is there a way I can build lift from the command line, using simple invocations of scalac only? I don't mind to do it bit by bit. I could isolate the previous fault myself, but for this one it looks like I need help because the file causing the crash depends on too many other things. -- Martin -- 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.
[Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
For curiousities sake, if you're building using fsc, are you running scalac via an exploded classpath (i.e. not a JAR file?). If so, I'll try to come up with a longer-term solution for this. If we allowed you to do the following: mvn reactor:make -Dmake.artifacts=net.liftweb:lift-mapper -P local-scala -Dscala.local.classpath=classfiledir would that be sufficient? We could also have this do conditional computation in the future. - Josh On Tue, Dec 22, 2009 at 8:12 AM, martin odersky martin.oder...@epfl.chwrote: On Tue, Dec 22, 2009 at 2:01 PM, Josh Suereth joshua.suer...@gmail.com wrote: I think staying in maven would require the least amount of typing, but the most amount of time as you'd have to publish local snapshots of Scala 2.8.0 to use them in the lift build. I remember how annoying this is ;). Also note that deploying maven requires a full scala build, but if needed I can make a short-cut that will just publish the quick libraries. This would help immensely in testing trunk against projects, but is not very helpful otherwise. Would this be desirable? What was already suggested (runing mvn dependency:copy-dependencies) is very viable. However, if lift-mapper relies on lift-util, you'll have to rebuild one before you rebuild the other if you're somehow changing the ABI. If you still wanted to use maven, I recommend using the reactor plugin. If you identify the project that is failing you can run: mvn reactor:make -Dmake.artifacts=net.liftweb:lift-mapper Where net.liftweb:lift-mapper is the groupId:artifactId containing the failing module. This will only build the lift-mapper module and other modules on which lift-mapper depends (i.e. if lift-mapper needs lift-util (and only lift-util) just those two will be built. I have a local VM where I was setting up a scala nightly build that would feed maven. Perhaps when I finish I'll make a write-up on how to do this, or have some kind of template/script you can use to do it by hand. - Josh Hi Josh, The problem is not so much building individual maven modules, but building them with experimental compilers. I need to be able to put a println into scalac, rebuild that (takes 10sec with fsc) and then recompile the offending maven part with that compiler. That's why I need a version of lift that can be compiled without maven. It need not be perfect, for instance one can probably throw out all the tests. But I need to be able to use lift as a rapid experimentation tool for the scala compiler itself. Unfortunately, LAMP is pretty much shutting down for the holidays right now. So any outside help that you can give is appreciated. Ideally: I get the right lift version as a tarball, together with all jars that it needs. Then, instructions what to compile in what order (I can probably figure them out in a pinch, but if someone knows that already, it would help). Thanks -- Martin -- 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: Nexus/Hudson maitenance on scala-tools.org
The hudson upgrade has been completed, however the nexus upgrade ran into some issues. We've reverted to the previous version of nexus. There will be a continuing maintenance window (for nexus only) from 8pm - 11pm EST today (December 21st). Thanks for your patience! - Josh Suereth On Fri, Dec 18, 2009 at 3:38 PM, Josh Suereth joshua.suer...@gmail.comwrote: All, Nexus/Hudson will be temporarily disabled Saturday/Sunday from 8-11pm EST. These services are being upgraded. I'll post an email 15 minutes before the actual shutdown and immediately after things are back up and working. You should be able to make use of artifacts on the scala-tools.org server, however nightly builds and posting releases will be disabled. If anyone has a specific release/test they need performed during this period please send me an email and I can accomodate you. Thanks for your cooperation! - Josh Suereth -- 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: [maven-and-scala] Re: Nexus/Hudson maitenance on scala-tools.org
Deferred for now. I was trying to figure out how to set up build nodes which would handle building against various platforms (e.g. windows, mac, ubuntu, fedora, etc.). This is where we could better customize what's installed on our build farm. Might take a different approach short term, but this is where we'd like to take it long term. - Josh On Mon, Dec 21, 2009 at 9:38 AM, Indrajit Raychaudhuri indraj...@gmail.comwrote: Neato! Thank you very much for the upgrade and the update on that! Should we expect a java5 environment as well, or are you deferring this for now? Cheers, Indrajit On 21/12/09 7:44 PM, Josh Suereth wrote: The hudson upgrade has been completed, however the nexus upgrade ran into some issues. We've reverted to the previous version of nexus. There will be a continuing maintenance window (for nexus only) from 8pm - 11pm EST today (December 21st). Thanks for your patience! - Josh Suereth On Fri, Dec 18, 2009 at 3:38 PM, Josh Suereth joshua.suer...@gmail.com mailto:joshua.suer...@gmail.com wrote: All, Nexus/Hudson will be temporarily disabled Saturday/Sunday from 8-11pm EST. These services are being upgraded. I'll post an email 15 minutes before the actual shutdown and immediately after things are back up and working. You should be able to make use of artifacts on the scala-tools.org http://scala-tools.org server, however nightly builds and posting releases will be disabled. If anyone has a specific release/test they need performed during this period please send me an email and I can accomodate you. Thanks for your cooperation! - Josh Suereth -- 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.
[Lift] Re: Nexus/Hudson maitenance on scala-tools.org
The scala-tools.org maintenance/upgrade has been completed. Any further service interruptions should be reported to ad...@scala-tools.org Thanks! - Josh On Fri, Dec 18, 2009 at 3:38 PM, Josh Suereth joshua.suer...@gmail.comwrote: All, Nexus/Hudson will be temporarily disabled Saturday/Sunday from 8-11pm EST. These services are being upgraded. I'll post an email 15 minutes before the actual shutdown and immediately after things are back up and working. You should be able to make use of artifacts on the scala-tools.org server, however nightly builds and posting releases will be disabled. If anyone has a specific release/test they need performed during this period please send me an email and I can accomodate you. Thanks for your cooperation! - Josh Suereth -- 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] Nexus/Hudson maitenance on scala-tools.org
All, Nexus/Hudson will be temporarily disabled Saturday/Sunday from 8-11pm EST. These services are being upgraded. I'll post an email 15 minutes before the actual shutdown and immediately after things are back up and working. You should be able to make use of artifacts on the scala-tools.orgserver, however nightly builds and posting releases will be disabled. If anyone has a specific release/test they need performed during this period please send me an email and I can accomodate you. Thanks for your cooperation! - Josh Suereth -- 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] Next Lift version will be 2.0
Heiko, Just curious what the difference between Major and Minor truly is as both can break source/binary compatibility? My feeling here is that sticking to strick source-compatibility for minor releases is actually a bonus. The other question I have is about deprecations. What's your plan for handling these? When can deprecated features be removed, etc. That might feed into the source-compatibility issues in minor versions. I think this is great stuff! Whatever is decided here will help shape the future of the Scala community's versioning, so I hope you don't mind my pestering ;) - Josh On Mon, Dec 7, 2009 at 12:41 PM, Indrajit Raychaudhuri indraj...@gmail.comwrote: Heiko, Grand stuff! Indeed, I was wondering if we could sync this up with the Round 2 of Refactoring exercise ( http://groups.google.com/group/liftweb/browse_thread/thread/450a3e741999b5df ). New structure, new version. I am working on this refactoring in a private copy and am planning to publish the branch once M8 is out (assuming original schedule of 2 weeks from 27th Nov). Would this work with you? Cheers, Indrajit On 07/12/09 4:23 PM, Timothy Perrett wrote: Heiko, This is great - can you work with IRC to arrange a time to changes the poms to 2.0-SNAPSHOT? Cheers, Tim On 7 Dec 2009, at 08:32, Heiko Seeberger wrote: Lifters, Maybe you followed the discussion about the versioning policy for Lift. The committers finally decided to have a well defined versioning policy which you can take from here: http://wiki.github.com/dpp/liftweb/about-versioning-policy. Following this policy the next Lift version will be 2.0, not 1.1, because there are numerous changes and enhancements breaking the source compatibility. As soon as we change the version numbers in the Maven POMs, we will let you know via the lift-announce mailing list. Best regards, Heiko My job: weiglewilczek.com http://weiglewilczek.com/ My blog: heikoseeberger.name http://heikoseeberger.name/ Follow me: twitter.com/hseeberger http://twitter.com/hseeberger OSGi on Scala: scalamodules.org http://scalamodules.org/ Lift, the simply functional web framework: liftweb.net http://liftweb.net/ -- 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.comliftweb%2bunsubscr...@googlegroups.com mailto: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.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: Call it Lift 2.0
The real question is could you still keep source compatibility if you made use of some interesting implict and @deprecated annotations? I believe those are acceptable. - Josh On Mon, Nov 23, 2009 at 6:05 AM, Timothy Perrett timo...@getintheloop.euwrote: Interesting - this is something i've not actually thought about: If we were to compile a list of all the breaking changes in 1.1, perhaps that would give some focus to this discussion... as josh points out, there are most likely quite a few now and 1.0 - 1.1 is a fairly short jump. Loc and LocParam Actor - LiftActor Full,Box etc have moved packages JSON parsing alterations and changes in JsExp Im probably missing a number of others, but we are talking about some fairly significant breaks here, right? Cheers, Tim On 23 Nov 2009, at 07:09, Heiko Seeberger wrote: Josh, Thank you for your brilliant elaboration of compatibility issues! 2009/11/22 Josh Suereth joshua.suer...@gmail.com The real question is, with all these breaking changes in lift 1.1, has any attempt been made at source-compatability? If not, I would argue a bigger version jump than 1.1. The current Lift is not source compatible with 1.0.x, just consider Box moved from ...util to ...common. Hence you would go for 2.0, right? Also, there is the possibility of taking the version system and adding a functionality milestone version at the begginning. In this case, you can use that number for marketting purposes (e.g. Lift goes 1.0!). Your version number would then be Marketing.SourceCompatability.All but Trait BinaryCompatability.Binary Compatibility. I am all against using versioning policy for marketing! Heiko Seeberger My job: weiglewilczek.com My 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.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=. -- 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=. -- 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=.
Re: [Lift] Re: Call it Lift 2.0
On Mon, Nov 23, 2009 at 2:09 AM, Heiko Seeberger seeber...@weiglewilczek.com wrote: Josh, Thank you for your brilliant elaboration of compatibility issues! [snip/] Also, there is the possibility of taking the version system and adding a functionality milestone version at the begginning. In this case, you can use that number for marketting purposes (e.g. Lift goes 1.0!). Your version number would then be Marketing.SourceCompatability.All but Trait BinaryCompatability.Binary Compatibility. I am all against using versioning policy for marketing! Ah, but this is the real world. Providing a means for marketing to use the first version number and still letting engineering have some control seems a better world to me than what I currently have ;) - Josh -- 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=.
Re: [Lift] Re: Call it Lift 2.0
No argument there! My only point was that perhaps in scala a slightly different policy might make sense. Because certain features of scala are more backwards-compatable then others, and you are still forced to recompile your libraries/projects to all use the same scala version, I think whatever version system you use should focus on the following aspects: - Binary Comptability Issues - Internal changes on classes or object methods, no API changes. No need to recompile project - Minor API changes (additions of methods, internal method implementation changes not belonging to traits.). No Need to recompile project - Minor Trait implementation and API changes. Requires a recompile of anything extending from these traits. Binary incompatable as of how traits compile today. Source should still remain compatible. - Major changes - similar to above, requires rebuild of project. - Source Compatability Issues - A project on previous version could be compiled against current version but with potential deprecation warnings - This could even include method signature changes if, e.g. an implicit conversion from one type of argument to the new argument is provided. I beleive is this implicit is @deprecated, then it will issue a warning on conversion. I know Mark Harrah uses this to acheive source-compatability across the SBT scalac plugin. - A project on the previous version could not be compiled against this version, re-writing code is required. My opinion on a version system for scala is as follows (unfortunately 2.8.0 breaks some of these rules...) X - This X version implies source-incompatible changes from previous X versions X.Y - The Y version implies source-compatible, but binary incompatible changes from previous X versions. X.Y.Z - The Z version implies internal changes such that only classes/objects extending traits need to be recompiled. X.Y.Z.A - The A Version implies a completely internal change such that no recompilation is necessary (I don't see these happening all that often in real life.. Traits are far to useful!). This adds an additional layer from the normal OSGi versioning system. My reasoning is that we hope X.Y.Z.A version numbers disappear (in favor of X.Y.Z) as research into how to compile traits for the JVM improves. Notice as well that X.Y is only *source* compatible. Not binary-compatible. That's the other difference from an OSGi perspective. The real question is, with all these breaking changes in lift 1.1, has any attempt been made at source-compatability? If not, I would argue a bigger version jump than 1.1. Also, there is the possibility of taking the version system and adding a functionality milestone version at the begginning. In this case, you can use that number for marketting purposes (e.g. Lift goes 1.0!). Your version number would then be Marketing.SourceCompatability.All but Trait BinaryCompatability.Binary Compatibility. In this case, perhaps a 1.1 release makes sense vs. a 1.0 release. The question is, should it have been 1.0.2 or 1.0.0.2? Anyway, those are my thoughts, let me know what you think. - Josh On Sun, Nov 22, 2009 at 4:33 AM, Heiko Seeberger seeber...@weiglewilczek.com wrote: 2009/11/21 Josh Suereth joshua.suer...@gmail.com I think eclipse and maven might be two of the only projects following that convention (besides others in the eclipse ecosystem). I think that Spring also follows the recommended OSGi versioning policy, but to be sure I will check with some of the Spring folks. And what about Java EE? Just remember 2.0-2.1 (small refinements and additions) and then 3.0 (very very breaking stuff). The question in my mind is what is the popular version number convention in the Scala ecosystem. As far as I can tell, e.g. from the 2.8 or 3.0 discussion on scala-internals, not many folks from Scala world are interested or trustful in versioning policies. So why not make Lift the thought leader in this regard? Heiko -- 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=. -- 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=.
Re: [Lift] Re: Call it Lift 2.0
I think eclipse and maven might be two of the only projects following that convention (besides others in the eclipse ecosystem). The question in my mind is what is the popular version number convention in the Scala ecosystem. - Josh On Sat, Nov 21, 2009 at 9:59 AM, Heiko Seeberger seeber...@weiglewilczek.com wrote: Hi, Heiko, can you find the stated version number policies of 3 or 4 other well regarded open source projects? That will allow us to synthesize the best of what others have done into a coherent policy for Lift. Take a look at the recommended OSGi version policy: http://www.aqute.biz/Code/XBnd Then take a look at Eclipse (pretty well known, eh?): http://wiki.eclipse.org/index.php/Version_Numbering Both use a major increment (1.x - 2) to show breaking changes in API, a minor increment (1.1.x - 1.2) to show non-breaking changes in API and a micro increment to show internal (no class name changes, no method signature changes, ...) changes (e.g. bug fixes in the implementation). -- 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=. -- 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=.
Re: [Lift] Re: Lift Scaladocs for Maven?
No, you can raise an issue on github (davidB/maven-scala-plugin). You can also use the build-helper-plugin to attach the scaladocs in maven. We'll try to resolve this for the 2.13 or 2.14 release of the plugin. Please raise the issue so it stays on the radar ;) - Josh On Thu, Nov 19, 2009 at 12:48 AM, aw anth...@whitford.com wrote: Note that the Maven Javadoc Plugin has a specific goal defined for creating a jar of the javadocs: http://maven.apache.org/plugins/maven-javadoc-plugin/jar-mojo.html Then you need to add a goal to attach it when you create a package: http://maven.apache.org/plugin-developers/cookbook/attach-source-javadoc-artifacts.html Unfortunately, I don't see a corresponding goal for the Maven Scala Plugin: http://scala-tools.org/mvnsites/maven-scala-plugin/plugin-info.html -- 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=. -- 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=.
Re: [Lift] Lift Scaladocs for Maven?
Yes. http://www.scala-tools.org/. I think you need to look at the snapshot sites. Also, I'm not sure the scaladoc are being attached to the lift builds correctly. If one of the maven guru committers wants to attack that, otherwise I'll add it to my pile of TODOs. - Josh On Wed, Nov 18, 2009 at 3:46 PM, braver delivera...@gmail.com wrote: Perhaps I'm not looking in the right place, but I didn't find the scaladocs alongside the jars and source.jars for Lift in the usual maven repo. Are we supposed to use scaladoc manually, or IDEs, to generate the API docs? Also, I'm interested in liftweb-actor separately, and see its jar and source.jar in the maven repo. Is there a pre-cooked scaladoc somewhere? Thanks, Alexy -- 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=.
[Lift] Re: **Important** Migration guide Scala Actors - Lift Actors
You mean you didn't implement your own GC on top of the JVM's GC? Where's
your sense of adventure...
On Mon, Nov 16, 2009 at 1:35 AM, David Pollak feeder.of.the.be...@gmail.com
wrote:
On Sun, Nov 15, 2009 at 10:29 PM, braver delivera...@gmail.com wrote:
I have a simple question on migrating a typical PinS-desribed pattern:
def act() =
loop {
react {
case DoSomething = ...
case EXIT = exit()
}
}
-- now, without exit(), how does it terminate?
Like any other object in the JVM... when the last reference to the Lift
Actor is gone, the Lift Actor is garbage collected. Lift Actors (like JVM
objects) don't have a concept of running. They will always respond to
messages sent to them. They consume no system resources other than memory
except when they are processing a message, then they will consume a thread
out of the thread pool.
Cheers,
Alexy
--
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 liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Changes to scala-tools.org Hudson
The site portion has not changed yet. I'm working on that ;)
- Josh
On Fri, Nov 13, 2009 at 11:04 AM, Derek Chen-Becker
dchenbec...@gmail.comwrote:
Josh, ScalaJPA has the following distribution setup:
distributionManagement
repository
idscala-tools.org/id
urlhttp://nexus.scala-tools.org/content/repositories/releases/url
/repository
snapshotRepository
idscala-tools.org/id
urlhttp://nexus.scala-tools.org/content/repositories/snapshots
/url
uniqueVersiontrue/uniqueVersion
/snapshotRepository
site
idscala-tools.org/id
url
http://nexus.scala-tools.org/content/repositories/mvnsites/${project.artifactId}http://nexus.scala-tools.org/content/repositories/mvnsites/$%7Bproject.artifactId%7D
/url
/site
/distributionManagement
Does that look correct?
On Thu, Nov 5, 2009 at 5:58 PM, Josh Suereth joshua.suer...@gmail.comwrote:
Scala-tools.org's Hudson server will no longer allow local deployment to
the repository. You *must* submit all snapshot/release artifacts through
the nexus webapp. The hudson server will provide a server id (
nexus.scala-tools.org) that will have appropriate (and appropriately
hidden) credentials for nightly deployments of snapshots.
As such, the following changes should be made to lift's pom.xml (I'm
trying to update your hudson lift configuration to cause the least amount of
disruption):
I have a forked repo (jsuereth/liftweb) with the changes as well (if you
want to use github's fork queue feature):
--- a/pom.xml
+++ b/pom.xml
@@ -806,16 +806,16 @@
idhudson/id
distributionManagement
repository
- idhudson.scala-tools.org/id
- urlfile:///home/scala-tools.org/www/repo-snapshots/url
+ idnexus.scala-tools.org/id
+ url
http://nexus.scala-tools.org/content/repositories/releases/url
/repository
snapshotRepository
- idhudson.scala-tools.org/id
- urlfile:///home/scala-tools.org/www/repo-snapshots/url
+ idnexus.scala-tools.org/id
+ url
http://nexus.scala-tools.org/content/repositories/snapshots/url
uniqueVersionfalse/uniqueVersion
/snapshotRepository
site
- idhudson.scala-tools.org/id
+ idnexus.scala-tools.org/id
urlfile:///home/
scala-tools.org/www/mvnsites-snapshots/liftweb/url
/site
/distributionManagement
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Changes to scala-tools.org Hudson
Scala-tools.org's Hudson server will no longer allow local deployment to the repository. You *must* submit all snapshot/release artifacts through the nexus webapp. The hudson server will provide a server id ( nexus.scala-tools.org) that will have appropriate (and appropriately hidden) credentials for nightly deployments of snapshots. As such, the following changes should be made to lift's pom.xml (I'm trying to update your hudson lift configuration to cause the least amount of disruption): I have a forked repo (jsuereth/liftweb) with the changes as well (if you want to use github's fork queue feature): --- a/pom.xml +++ b/pom.xml @@ -806,16 +806,16 @@ idhudson/id distributionManagement repository - idhudson.scala-tools.org/id - urlfile:///home/scala-tools.org/www/repo-snapshots/url + idnexus.scala-tools.org/id + urlhttp://nexus.scala-tools.org/content/repositories/releases /url /repository snapshotRepository - idhudson.scala-tools.org/id - urlfile:///home/scala-tools.org/www/repo-snapshots/url + idnexus.scala-tools.org/id + urlhttp://nexus.scala-tools.org/content/repositories/snapshots /url uniqueVersionfalse/uniqueVersion /snapshotRepository site - idhudson.scala-tools.org/id + idnexus.scala-tools.org/id urlfile:///home/scala-tools.org/www/mvnsites-snapshots/liftweb /url /site /distributionManagement --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Error mvn install on lift-actor
huh, perhaps if I was in active development with you guys, I'd have a better
idea...
I know maven + -SNAPSHOT can cause fun for everyone ;)
Anyway, I wonder if maven has the ability to turn on checksuming now. I
know things like archiva and nexus can do that, but this might help you
avoid problems in the future...
- Josh
On Mon, Nov 2, 2009 at 3:52 AM, Timothy Perrett timo...@getintheloop.euwrote:
Sorry, but +1
Maven is a funny beast that needs some controlling but in my experience a
little manual repo pruneing usually yeilds results :-)
Cheers, Tim
Sent from my iPhone
On 2 Nov 2009, at 02:18, Josh Suereth joshua.suer...@gmail.com wrote:
There's something just wrong about this
On Sun, Nov 1, 2009 at 10:06 AM, David Pollak feeder.of.the.be...@gmail.com
feeder.of.the.be...@gmail.com wrote:
Yeah, I do rm -rf ~/.m2 about once a week. Usually on Monday mornings
just before I go make myself some tea.
On Sun, Nov 1, 2009 at 7:55 AM, Naftoli Gugenheim naftoli...@gmail.com
naftoli...@gmail.com wrote:
It can't be the POM -- it built it. It just couldn't install it. I wonder
if it's related to the new structure. I emptied .m2/repository/new/liftweb
and it seems to be working now.
Thanks.
-
Josh Suereth joshua.suer...@gmail.comjoshua.suer...@gmail.com wrote:
It looks like the pom is in a different encoding then maven expects.
That's
a fun issue! I would check maven's JIRA to see if someone else has
reported
this issue and has a workaround.
Who is deploying/configuring Lift's POM files? Are you using UTF-8 or
UTF-16 encoding? In either case, I would check the pom.xml for
lift-actors
in your local repo. Pull it up in a text editor that will show you all
characters and switch encodings.
- Josh
On Sat, Oct 31, 2009 at 10:54 PM, Naftoli Gugenheim naftoli...@gmail.com
naftoli...@gmail.comwrote:
What could be wrong?
C:\dev\gitrepo\liftweb\lift-base\lift-actormvn -e install
+ Error stacktraces are turned on.
[INFO] Scanning for projects...
WAGON_VERSION: 1.0-beta-2
[INFO]
[INFO] Building Lift Actor
[INFO]task-segment: [install]
[INFO]
[INFO] [resources:resources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
C:\dev\gitrepo\liftweb\lift-base\lift-actor\src\main\resources
[INFO] [scala:compile {execution: scala-compile}]
[INFO] Checking for multiple versions of scala
[INFO] includes = [**/*.scala,**/*.java,]
[INFO] excludes = []
[INFO] Compiling 0 source files to
C:\dev\gitrepo\liftweb\lift-base\lift-actor\target\classes
[INFO] Nothing to compile - all classes are up to date
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
C:\dev\gitrepo\liftweb\lift-base\lift-actor\src\test\resources
[INFO] [scala:testCompile {execution: scala-testCompile}]
[INFO] Checking for multiple versions of scala
[INFO] includes = [**/*.scala,**/*.java,]
[INFO] excludes = []
[WARNING] No source files found.
[INFO] [compiler:testCompile]
[INFO] No sources to compile
[INFO] [surefire:test]
[INFO] Surefire report directory:
C:\dev\gitrepo\liftweb\lift-base\lift-actor\target\surefire-reports
---
T E S T S
---
There are no tests to run.
Results :
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[INFO] [jar:jar]
[INFO] Building jar:
C:\dev\gitrepo\liftweb\lift-base\lift-actor\target\lift-actor-1.1-SNAPSHOT.jar
[INFO] [source:jar-no-fork {execution: default}]
[INFO] [bundle:bundle {execution: default-bundle}]
[INFO] [install:install]
[INFO] Installing
C:\dev\gitrepo\liftweb\lift-base\lift-actor\target\lift-actor-1.1-SNAPSHOT.jar
to
C:\Users\Naftoli\.m2\repository\net\liftweb\lift-actor\1.1-SNAPSHOT\lift-actor-1.1-SNAPSHOT.jar
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error installing artifact's metadata: Error installing metadata:
Error updating group repository metadata
only whitespace content allowed before start tag and not \u0 (position:
START_DOCUMENT seen \u0... @1:1)
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error
installing
artifact's metadata: Error installing metadata: Error updating group
repository metadata
[Lift] Re: Error mvn install on lift-actor
It looks like the pom is in a different encoding then maven expects. That's
a fun issue! I would check maven's JIRA to see if someone else has reported
this issue and has a workaround.
Who is deploying/configuring Lift's POM files? Are you using UTF-8 or
UTF-16 encoding? In either case, I would check the pom.xml for lift-actors
in your local repo. Pull it up in a text editor that will show you all
characters and switch encodings.
- Josh
On Sat, Oct 31, 2009 at 10:54 PM, Naftoli Gugenheim naftoli...@gmail.comwrote:
What could be wrong?
C:\dev\gitrepo\liftweb\lift-base\lift-actormvn -e install
+ Error stacktraces are turned on.
[INFO] Scanning for projects...
WAGON_VERSION: 1.0-beta-2
[INFO]
[INFO] Building Lift Actor
[INFO]task-segment: [install]
[INFO]
[INFO] [resources:resources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
C:\dev\gitrepo\liftweb\lift-base\lift-actor\src\main\resources
[INFO] [scala:compile {execution: scala-compile}]
[INFO] Checking for multiple versions of scala
[INFO] includes = [**/*.scala,**/*.java,]
[INFO] excludes = []
[INFO] Compiling 0 source files to
C:\dev\gitrepo\liftweb\lift-base\lift-actor\target\classes
[INFO] Nothing to compile - all classes are up to date
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
C:\dev\gitrepo\liftweb\lift-base\lift-actor\src\test\resources
[INFO] [scala:testCompile {execution: scala-testCompile}]
[INFO] Checking for multiple versions of scala
[INFO] includes = [**/*.scala,**/*.java,]
[INFO] excludes = []
[WARNING] No source files found.
[INFO] [compiler:testCompile]
[INFO] No sources to compile
[INFO] [surefire:test]
[INFO] Surefire report directory:
C:\dev\gitrepo\liftweb\lift-base\lift-actor\target\surefire-reports
---
T E S T S
---
There are no tests to run.
Results :
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[INFO] [jar:jar]
[INFO] Building jar:
C:\dev\gitrepo\liftweb\lift-base\lift-actor\target\lift-actor-1.1-SNAPSHOT.jar
[INFO] [source:jar-no-fork {execution: default}]
[INFO] [bundle:bundle {execution: default-bundle}]
[INFO] [install:install]
[INFO] Installing
C:\dev\gitrepo\liftweb\lift-base\lift-actor\target\lift-actor-1.1-SNAPSHOT.jar
to
C:\Users\Naftoli\.m2\repository\net\liftweb\lift-actor\1.1-SNAPSHOT\lift-actor-1.1-SNAPSHOT.jar
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error installing artifact's metadata: Error installing metadata:
Error updating group repository metadata
only whitespace content allowed before start tag and not \u0 (position:
START_DOCUMENT seen \u0... @1:1)
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error installing
artifact's metadata: Error installing metadata: Error updating group
repository metadata
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)
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.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at
[Lift] Re: Error mvn install on lift-actor
There's something just wrong about this
On Sun, Nov 1, 2009 at 10:06 AM, David Pollak feeder.of.the.be...@gmail.com
wrote:
Yeah, I do rm -rf ~/.m2 about once a week. Usually on Monday mornings just
before I go make myself some tea.
On Sun, Nov 1, 2009 at 7:55 AM, Naftoli Gugenheim naftoli...@gmail.comwrote:
It can't be the POM -- it built it. It just couldn't install it. I wonder
if it's related to the new structure. I emptied .m2/repository/new/liftweb
and it seems to be working now.
Thanks.
-
Josh Suerethjoshua.suer...@gmail.com wrote:
It looks like the pom is in a different encoding then maven expects.
That's
a fun issue! I would check maven's JIRA to see if someone else has
reported
this issue and has a workaround.
Who is deploying/configuring Lift's POM files? Are you using UTF-8 or
UTF-16 encoding? In either case, I would check the pom.xml for
lift-actors
in your local repo. Pull it up in a text editor that will show you all
characters and switch encodings.
- Josh
On Sat, Oct 31, 2009 at 10:54 PM, Naftoli Gugenheim naftoli...@gmail.com
wrote:
What could be wrong?
C:\dev\gitrepo\liftweb\lift-base\lift-actormvn -e install
+ Error stacktraces are turned on.
[INFO] Scanning for projects...
WAGON_VERSION: 1.0-beta-2
[INFO]
[INFO] Building Lift Actor
[INFO]task-segment: [install]
[INFO]
[INFO] [resources:resources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
C:\dev\gitrepo\liftweb\lift-base\lift-actor\src\main\resources
[INFO] [scala:compile {execution: scala-compile}]
[INFO] Checking for multiple versions of scala
[INFO] includes = [**/*.scala,**/*.java,]
[INFO] excludes = []
[INFO] Compiling 0 source files to
C:\dev\gitrepo\liftweb\lift-base\lift-actor\target\classes
[INFO] Nothing to compile - all classes are up to date
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
C:\dev\gitrepo\liftweb\lift-base\lift-actor\src\test\resources
[INFO] [scala:testCompile {execution: scala-testCompile}]
[INFO] Checking for multiple versions of scala
[INFO] includes = [**/*.scala,**/*.java,]
[INFO] excludes = []
[WARNING] No source files found.
[INFO] [compiler:testCompile]
[INFO] No sources to compile
[INFO] [surefire:test]
[INFO] Surefire report directory:
C:\dev\gitrepo\liftweb\lift-base\lift-actor\target\surefire-reports
---
T E S T S
---
There are no tests to run.
Results :
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[INFO] [jar:jar]
[INFO] Building jar:
C:\dev\gitrepo\liftweb\lift-base\lift-actor\target\lift-actor-1.1-SNAPSHOT.jar
[INFO] [source:jar-no-fork {execution: default}]
[INFO] [bundle:bundle {execution: default-bundle}]
[INFO] [install:install]
[INFO] Installing
C:\dev\gitrepo\liftweb\lift-base\lift-actor\target\lift-actor-1.1-SNAPSHOT.jar
to
C:\Users\Naftoli\.m2\repository\net\liftweb\lift-actor\1.1-SNAPSHOT\lift-actor-1.1-SNAPSHOT.jar
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error installing artifact's metadata: Error installing metadata:
Error updating group repository metadata
only whitespace content allowed before start tag and not \u0 (position:
START_DOCUMENT seen \u0... @1:1)
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error installing
artifact's metadata: Error installing metadata: Error updating group
repository metadata
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
at
[Lift] Re: Scala and Eclipse
I'm not supporting the mvn eclipse:eclipse plugin route right now. If anyone desires to support that, please contribute patches ;) On Sat, Oct 17, 2009 at 8:58 AM, Miles Sabin mi...@milessabin.com wrote: On Sat, Oct 17, 2009 at 11:07 AM, johncch john...@gmail.com wrote: I manage to import lift and lift-mapper projects fine, but earlier today when I tried importing in lift-hello lift I'm getting editor shutdowns and what nots. Let's look at a few. From the stacktrace my hunch is that you're trying to create projects outside of the Eclipse workspace. That's not fully supported in 2.7.x (it will be in 2.8). Cheers, Miles -- Miles Sabin tel: +44 (0)7813 944 528 skype: milessabin http://www.chuusai.com/ http://twitter.com/milessabin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Scala and Eclipse
It's gotten to the point where I can only support the configuration we're using at work (as it's critical to our success). At one point I thought I had written how on this wiki: http://lampsvn.epfl.ch/trac/scala/wiki/ScalaEclipseMaven, but it seems like I've missed that. Also, it seems some of the information on this wiki is confusing. Here's the original wiki I was putting together http://code.google.com/p/esmi/wiki/CreatingScalaMavenProjectsInEclipse. If I can grab enough time, I'll combine the two works. But in the meantime, here's the configuration I can guarantee support for: Maven 2.0.10 - 2.2 Eclipse 3.4 Eclipse IAM Plugin 0.10 Scala IDE For Eclipse 2.7.5/2.7.4 Remember to *NOT* use a different version of the Scala IDE for Eclipse from the version of Scala you're using on your projects. And remember to set up your projects in the following order: 1) Import your POMs with IAM's Maven Import Wizards 2) Right click on scala projects and select Add Scala Nature 3) Sometimes, when you change your pom classpath, you need to poke the resident scala compiler. Usually closing/opening the project fixes this. This happens rarely (~1/week) We have a large multi-module project that includes scala in a few key artifacts and things are going somewhat smoothly. However, I think most of the devs are bailing out of eclipse for intellij. Hope that helps! - Josh On Sat, Oct 17, 2009 at 9:36 AM, Miles Sabin mi...@milessabin.com wrote: On Sat, Oct 17, 2009 at 2:31 PM, Josh Suereth joshua.suer...@gmail.com wrote: I'm not supporting the mvn eclipse:eclipse plugin route right now. If anyone desires to support that, please contribute patches ;) So, for the archives, could you say what the currently recommended Maven+Eclipse configuration is? Cheers, Miles -- Miles Sabin tel: +44 (0)7813 944 528 skype: milessabin http://www.chuusai.com/ http://twitter.com/milessabin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Removing Scala Actors from Lift
As much as I agree with your decision, it just makes me sad. I know lots of people that learned scala for actors are the way of the future I think we need to push harder. Hopefully all major projects migrating off actors will give EPFL a wake up call? - Josh On Tue, Sep 29, 2009 at 1:41 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck stuart.roeb...@gmail.comwrote: Apologies if I've missed something obvious but my web search hasn't turned anything up... What are the Scala Actors instability issues? I'm in the process of doing some major Scala development work and this comment raises concerns that I'd like to understand. The issues (with the Scala Actors in general and Lift's use of them) are: - Scala Actors use a custom version of Doug Leah's Fork/Join library. This was necessary for JDK 1.4 support. With JDK 1.5, the java.util.concurrent stuff should have been used. I was led to understand that this change was made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still contains fork-join. The FJ library has a memory retention issue where it trades memory for non-locking performance and, with many threads in a thread-pool, this leads to out of memory issues. - The Scala Actor code is very brittle. See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html The code has not been materially refactored, which means that even in 2.8, there will be significant potential problems with the Actors. Those potential problems have manifest themselves as real problems in 2.7.x. I have spent in aggregate nearly 3 weeks of my time since November 2008 working around the defects in the Actor library. It's easier to have our own Actors (the current Actor library is about 2 days of work on my part and the refactoring of Lift to work with the existing Actor library is another 2 days of work.) - EPFL has been generally slow to respond to bug reports. I am very frustrated and quite frankly tired of having to cajole EPFL into responding to defects in one of the premier Scala libraries. I would strongly suggest that you look at Akka. It's got a better view and implementation of Actors than does the standard Scala distribution. Akka includes support for distributed actors, etc. Hope this helps. Best, Stuart On Sep 29, 3:30 am, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, Given the continued instability of Scala Actors, I've decided to remove them from Lift. Specifically, I'm migrating CometActors to sit on top of Lift's Actors. But, you'll also be able to use Akka Actors to power Lift's CometActors. Specifically, I'm working with Jonas to make sure that we share a common interface to Actors. I've gotten Lift nearly completely migrated over to Lift's Actors on the dpp_wip_actorize branch. Seehttp:// github.com/dpp/liftweb/tree/dpp_wip_actorize There will be some breaking changes to your applications. Specifically: - Box will be moved to a new package, net.liftweb.base (this is where the interface for Actors will live as well) - If you make any assumptions about your CometActors being Scala Actors (e.g., using linking), you will have to rewrite this code - Some methods in Lift that currently take Scala Actors as parameters will take Lift Actors (e.g., ActorPing) There will be a parallel Maven repository with the new Lift Actor stuff in it so you will be able to build you apps against the new code before the official switch-over. Milestone 6 (which should be out next week) will be based on the existing Actor model. After we get feedback from the community about the new Actor stuff, we will switch -SNAPSHOT over to the new Actor stuff. Questions, thoughts, or comments? Thanks, David -- 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 -- 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 liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Alternate Lift builds?
Profiles are nice, but I think just using -P should be ok here (instead of properties). Although I do like the properties approach, I usually use that to simplify builds in the case where I have a system with a guaranteed property. At work we usually use a profile to attach the hudosn build version to our version. I personally don't like classifiers as you'd have to make all your nested dependencies also use the same classifier to really test the system. - Josh On Sat, Sep 19, 2009 at 3:49 PM, Kevin Wright kev.lee.wri...@googlemail.com wrote: Quite right, it's classifier and not qualifier. It was a typo, honest! :-p Nice thinking about using profiles, lets you keep the pom in sync between trunk and the branch, should help nicely with those merges One change I would make though is to activate the profile by way of a property: http://maven.apache.org/guides/introduction/introduction-to-profiles.html It doesn't make a great deal of difference at this level, but I've found it can really make things a lot more flexible if you want to start mixing in configurations based on architecture or JVM version, or if you're working with multi-module builds. http://maven.apache.org/guides/introduction/introduction-to-profiles.html On Sat, Sep 19, 2009 at 6:28 PM, Indrajit Raychaudhuri indraj...@gmail.com wrote: Dependency classifier might be close to what you'd need. See the 'Classifier' section in http://maven.apache.org/pom.html#Dependencies So, you could create a build profile (disabled by default), say dppactor as so: profiles profile iddppactor/id activation activeByDefaultfalse/activeByDefault /activation dependencies dependency groupIdnet.liftweb/groupId artifactIdlift-actor/artifactId version1.1-SNAPSHOT/version classifierdpp/classifier /dependency /dependencies /profile /profiles See http://maven.apache.org/pom.html#Profiles for more. Now if you invoke mvn -Pdppactor compile, the dependency would be on lift-actor-1.1-SNAPSHOT-dpp.jar! To create lift-actor-1.1-SNAPSHOT-dpp.jar, you can follow the same technique (another profile). Just use the optional config parameter 'classifier' See: http://maven.apache.org/plugins/maven-jar-plugin/jar-mojo.html#classifier Now Hudson build would just need the extra param (-P) to do the needful. Hope this helps. Cheers, Indrajit On Sep 19, 4:38 am, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, Is there a clean and easy way that anyone knows of to have Hudson do alternate builds from different Git branches and put them in SNAPSHOTS with different versions (e.g., 1.1-SNAPSHOT_DPP_ACTOR)? I am making some wholesale changes to Lift's use of Actors (basically getting rid of all Scala Actors and creating some simple traits that Akka or other systems can implement so that Lift-based systems can choose different Actor implementations. Given that these changes are non-trivial, I'd like to run a parallel version of Lift for at least a few weeks and get feedback on the API changes and performance before committing the code to the main branch, but I want the code to available in Hudson. So... any ideas? Thanks, David -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Git some:http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Best way to write a wizard
All, I write to you (unfortunately still) as a lift n00b. I'm trying to modify a form such that it looks more wizard like. i.e. I want it to specifically state You've completed part 1, you're on step 2 of 5, etc. How should I accomplish this in view-first rendering? Normal MVC, I'd make one controll that redirects you to the appropriate wizard screen depending on what steps have already been accomplished (i.e. the controller figures out which step you're on and sends you to the appropraite view. In Lift, I'm thinking I have a few options: 1) Have my stateful snippet actually return the various pages in code. I'm not happy with this, as my view would reside in the controller, but I could git'r'done this way. 2) Attempt to learn the lift-wizard library (is this stable/released?) 3) Spend more time trying to be inventive. Anyone have any thoughts? - Josh --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Why isn't this a trait in lift-json?
Scala does support annotations, they're just anemic at this point.
I hadn't tried, but does extending ClassfileAnnotation allow runtime
visibility? That would give you a pure scala implementation. If not, I
think we need to rally for StaticAnnotation/ClassfileAnnotation to be joined
by their future brother RuntimeAnnotation.
- Josh
On Sun, Sep 13, 2009 at 6:31 PM, marius d. marius.dan...@gmail.com wrote:
On Sep 13, 3:15 pm, Joni Freeman freeman.j...@gmail.com wrote:
Hi,
That annotation is used to configure the json path when extracting
values. By default the extraction code assumes that case class
parameter names match with json field names. For instance these match:
case class Foo(bar: String, baz: Int)
{ bar: qwerty, baz: 10 }
But sometimes json field names can contain characters which are not
allowed in Scala identifiers. For example:
{ foo-bar: qwerty, baz: 10 }
Now, to able to extract this we have to somehow tell the extractor the
exact path explicitly. Currently @path annotation is used for that:
case class Foo(@path(foo-bar) bar: String, baz: Int)
I don't see how a trait can accomplish this, maybe I'm missing
something?
The reason why it is in Java is that Scala annotations are not
accessible at runtime.
Right but I'd also suggest removing Java code from Lift stack. The
above can be easily achieved by introducing a trait such as:
case class Foo(bar: String with Nominator, baz: Int)
Lift is a 100% Scala code with zero Java code. We also have strong
opinions in the team that we should stay away from annotations.
one option would be something like this:
Lift would have :
trait Nominator{
def name : String
}
In user's code:
case class Foo(bar: String with MyNominator, baz: Int)
trait MyNominator extends Nominator {
def name = foo-bar
}
Yes it is more verbose then the annotation but IMHO it is more Scala-
ish Lift-ish.
Cheers Joni
On Sep 13, 11:03 pm, Timothy Perrett timo...@getintheloop.eu wrote:
Just had a browse over the latest commit and found the following in
path.java:
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface path {
public String value();
}
Any reason were not using a trait etc to complete the same
functionality?
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
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: Getting Maven Offline Mode Working
Check your PATH variable, probably pointing to the wrong maven still. You really need to get off of maven 2.0.9. The offlline mode is broken. 2.0.10 should be the minimum version you need to fix that issue. On Sun, Sep 13, 2009 at 8:33 PM, Peter Robinett pe...@bubblefoundry.comwrote: Thanks, Kevin. Dropping in the latest version didn't seem to work (mvn --version kept saying I still had 2.0.9) but switching to 1.1-M5 did. Peter On Sep 13, 4:00 pm, Kevin Wright kev.lee.wri...@googlemail.com wrote: Maven is essentially a java application, so you *should* just be able to download and run. I'm afraid I can't really give better advice for OS-X though. One other idea is to work with 1.1-M5, which should let you go offline on the older maven version - assuming you have no other snapshot dependencies. On Sun, Sep 13, 2009 at 10:51 PM, Peter Robinett pe...@bubblefoundry.comwrote: Thanks. I have version 2.0.9, which was installed by the Lift OS X installer. What is the best way to upgrade to 2.2.1? Peter On Sep 13, 12:57 pm, Kevin Wright kev.lee.wri...@googlemail.com wrote: Try updating to the latest maven, older versions have known issues with offline behaviour for snapshots. On Sun, Sep 13, 2009 at 8:55 PM, Peter Robinett pe...@bubblefoundry.com wrote: Hi all, I'm having problems running mvn -o jetty:run with my version of Lift (1.1-SNAPSHOT) because Maven thinks that net.liftweb:lift-core:jar:1.1- SNAPSHOT is missing. How do I fix that? My pom.xml is here: http://gist.github.com/186293 I've got an international plane flight in 24 hours, so I'd love to have offline mode working for then. Thanks for the help! Peter --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Lift deal breakers
This is how we do JavaScript/ExtJS development at my work place, except with a twist. We actually have a javascript-only project for a our javascript library. We use the maven-javascript-tools plugins to create a javascript project that relies on others (in our case, things like Simile Timeline and ExtJS). We then compile/minify the javascript into an 'artifact' that gets used by our main webapp, where the alchim yui-compressor takes all the CSS/Javascript and bundles as much of it as possible into a single huge JS file. The library project can make use of JSUnit tests (slow-to-run, recommend for integration tests only), and has its own stubbed out controllers and jetty for testing. It's a very interesting setup, but I'm very happy with it. We have very modular JS code, and very very very very very very little JSP/HTML code (we didn't select lift at work). If I were to start using Lift for my backend to ExtJS I would need support for a similar setup (i.e. expect little or no HTML generated outside of the Javascript). Also, the ability to cache dynamically created pages works great for our product in production, however, we're only dynamically creating a javasript file containing very static resources (externalized string library for use when rendering in javascript. This ensures our Javascript and Java externalization works similarly.) I highly recommend the approach if using something like ExtJS, however for lift's templates I'd agree that a page-unique-id would be required for every synthetically created js file so that caching works appropriately. You can also force the browser to check if something's changed. We have a development hack that checks class-load time of the synthetic-js-generator and ensures the cached copy is up-to-date from that time. This means jetty-reloads will reload the class and ensure the next refresh pulls a new version. It's a bit tricky to get set up at first, but worked great! Hopefully this input is helpful! - Josh On Sun, Sep 13, 2009 at 8:48 PM, Charles F. Munat c...@munat.com wrote: I'm afraid I have to disagree. As a website developer, I've been putting all my JS into an external file (per page when necessary) for many years without any problems. Every good JS programmer I know does the same. It is considered *more* not less robust to put the JS in an external file and attach event handlers to the DOM from there. Page loading is in the eye of the beholder. Moving the JS to external scripts and the script tags to the bottom of the page actually makes the page appear more quickly, hence load faster in the mind of the user. Fragility is a non-issue. If the JS is all in the external file and the file does not load, then the page loads without JS. Put the event handlers in the HTML and the external file to which they refer doesn't load, same problem (except now you get a raft of JS errors). With best practices, the JS file can be cacheable, albeit per-page. Ideally, here's what I'd like. I add Lift tags to my page for each JS file I want included with the page. In each tag I designate whether that file is cacheable or dynamic and whether it is site-wide or specific to that page. Lift then takes all the site-wide cacheable pages, in the order I specified them, and gzips them up into a single file. Then it inserts a script tag for that file at the bottom of the page. Similarly, it takes all the page-specific cacheable pages, adds Lift's own page specific stuff at the end (the event handlers of which we speak), gzips it, gives it a name unique to that page, and adds another script tag for that file. Finally, it gzips up all dynamically-generated JS and gives it a timestamp for a filename so it won't be cached. This way I get jQuery, Ext JS, etc. all downloaded and cached in one big gzipped file. I get all page-specific but unchanging JS in another gzipped file for each page (cacheable, too). And I get my dynamically-generated, changing JS (if any) in a final gzipped file. My page is clean, all the scripts load in the proper order at the end, and everything is gzipped and, where applicable, cacheable for the best speed. We've just eliminated several points of failure, as I see it. Note also that since I use Ext JS, some of my JS files are very long and complex. I'm building a rich client, after all. I want to separate these scripts out into simple modules to make it easier to code them. But when they are served, I want them combined together in the proper order into one file. Another benefit of this system. On final option might be to indicate in the Lift tag whether the combined JS should be an external resource or inserted into the HTML page. Then you could insert the dynamic stuff into the page if you wanted to. (Of course, if nothing in the HTML changes, you've just prevented the caching of the HTML page, but it might be a useful option.) I wish I could offer to do this, but I'm desperately
[Lift] Re: Ext.Direct
I believe the core of ExtJS is now MIT licenesed (the widgets being GPL with Commercial licenses available). You could potentially build the Ajax calls on top of this (as long as you stay away from ui components). Then users who have bought an ExtJS subscription (like my company) would have a much easier time moving to lift! I believe the ExtJS core supports many of the same operations as jQuery's core. - Josh On Thu, Aug 27, 2009 at 5:53 PM, Charles F. Munat c...@munat.com wrote: I haven't used Ext.Direct yet, but I am currently building a site (three sites, really) that uses Ext JS 3.0 for the front end. One site is essentially a CRUD app. The back end is a PostgreSQL database. The middle layer is a Lift app that uses JPA/Hibernate to access the database. It provides a REST interface to the data that accepts and returns JSON. (I've hand written this but must learn more about Lift's JSON capabilities.) The front end is pure Ext JS. All connections to the database are via AJAX-like calls (AJAJ?). The REST interface is pretty pure, using only GET, PUT, and DELETE. (I like idempotency, so I don't use POST. The back end generates UUIDs and prepopulates the add forms with a UUID, then the create calls use the same URL as the update calls. If the object with that ID already exists, it is updated. If it doesn't, it is created. Thus all calls are idempotent. This also improves security, as you're, um, unlikely to guess a UUID.) I'd be happy to talk to you about this. It's still in the early stages, but I have to debut it in a couple weeks if not sooner (what's new?), so I'll be zooming through the front end stuff over the next few days. I plan for all future sites that I build in Lift to follow a similar pattern on the front end. Chas. Naftoli Gugenheim wrote: Has anyone used lift with Ext.JS forms/Ext.Direct? P.S. It would be neat if it could interact with Lift's JSON support. I wonder what it would take. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Hudson not building?
I'll take a shot at upgrading the git plugin and see what happens. There was some fuss on the hudson mailing lists about issues with git earlier, I'm wondering if we ran into the same issue. - Josh On Mon, Jul 20, 2009 at 10:56 AM, Derek Chen-Becker dchenbec...@gmail.comwrote: Yeah, I restarted it. I think Josh was talking about upgrading to the latest version of Hudson at some point. I don't know if that would fix it. Derek On Mon, Jul 20, 2009 at 8:37 AM, Timothy Perrett timo...@getintheloop.euwrote: Awesome - appears to have built again... what a strange error; guess we'll just have to keep an eye on it. http://hudson.scala-tools.org/job/Lift/lastSuccessfulBuild/ Cheers, Tim On Jul 20, 2:25 pm, Derek Chen-Becker dchenbec...@gmail.com wrote: I'm showing these errors in the log: Jul 20, 2009 5:31:30 AM hudson.model.AbstractProject checkout INFO: Lift #1045 aborted java.lang.InterruptedException at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireInterruptibl y(AbstractQueuedSynchronizer.java:813) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly( AbstractQueuedSynchronizer.java:1137) at java.util.concurrent.locks.ReentrantLock.lockInterruptibly(ReentrantLock.ja va:312) at hudson.model.AbstractProject.checkout(AbstractProject.java:800) at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:314) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:266) at hudson.model.Run.run(Run.java:923) at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:234) at hudson.model.ResourceController.execute(ResourceController.java:93) at hudson.model.Executor.run(Executor.java:119) Jul 20, 2009 5:31:30 AM hudson.model.Run run INFO: Lift #1045 main build action completed: FAILURE Jul 20, 2009 6:05:55 AM hudson.triggers.SCMTrigger$Runner runPolling SEVERE: Failed to record SCM polling hudson.plugins.git.GitException: Failed to fetch at hudson.plugins.git.GitAPI.fetch(GitAPI.java:92) at hudson.plugins.git.GitAPI.fetch(GitAPI.java:103) at hudson.plugins.git.GitSCM$1.invoke(GitSCM.java:143) at hudson.plugins.git.GitSCM$1.invoke(GitSCM.java:129) at hudson.FilePath.act(FilePath.java:552) at hudson.plugins.git.GitSCM.pollChanges(GitSCM.java:129) at hudson.model.AbstractProject.pollSCMChanges(AbstractProject.java:857) at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:382) at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:417) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.j ava:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java: 908) at java.lang.Thread.run(Thread.java:619) I'm going to restart hudson and see if that helps... Derek On Mon, Jul 20, 2009 at 6:09 AM, Timothy Perrett timo...@getintheloop.euwrote: Jeppe, There is something odd going on with hudson it seems - even the manual build does nothing... the modules say that didnt run even tho its taking nearly an hour to complete. Derek, is this perhaps related to the increase in open file handles you made previously? Cheers, Tim On Jul 20, 12:15 pm, Timothy Perrett timo...@getintheloop.eu wrote: Hey Jeppe, Thats strange, i've just kicked off a hudson build manually, so we'll see if it works or not - i'll report back shortly Derek / DPP can you look into this? Cheers, tim On Jul 20, 12:03 pm, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: Hi, It seems the latest Lift build onhttp:// hudson.scala-tools.org/job/Lift/is10 days old, same with the jars inhttp:// scala-tools.org/repo-snapshots/net/liftweb/lift-webkit/1.1-SNA... Yet, many changes have been committed to github which I assume is the master? I didn't notice until I tried making a release build since I'm building lift from source in the dev env. /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 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: FileUploadIOException with streaming upload
What web server are you using for testing? It's been a while, but I remember having to configure 3 different file-size limits in our appliance. We're using Apache-Tomcat forwarding though, so I'm not sure where things would be for you necessarily. Anyway, I remember the seeing the same issue, and tweaking a new-found parameter that did the trick. I'll try to find out from a coworker which one that was. - Josh On Tue, Jul 14, 2009 at 8:20 AM, Timothy Perrett timo...@getintheloop.euwrote: Guys, Im trying to test this new upload progress widget i've written and the obvious way to do that is use a big upload locally so it takes time and i can see it working. I configured my maxMimeSize to this: LiftRules.maxMimeSize = 30 * 1024 * 1024 And I get the following error message when I upload a file that is larger than 8mb (small uploads work fine) - see below for exception... Message: org.apache.commons.fileupload.FileUploadBase $FileUploadIOException org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl $FileItemStreamImpl$1.raiseError(FileUploadBase.java:753) org.apache.commons.fileupload.util.LimitedInputStream.checkLimit (LimitedInputStream.java:71) org.apache.commons.fileupload.util.LimitedInputStream.read (LimitedInputStream.java:128) java.io.FilterInputStream.read(FilterInputStream.java:90) net.liftweb.http.OnDiskFileParamHolder$.doUpload$1(Req.scala:74) net.liftweb.http.OnDiskFileParamHolder$.apply(Req.scala:82) eu.getintheloop.example.lib.UploadProgress$$anonfun$init$2.apply (UploadProgress.scala:19) eu.getintheloop.example.lib.UploadProgress$$anonfun$init$2.apply (UploadProgress.scala:18) net.liftweb.http.Req$$anonfun$3$$anon$1.next(Req.scala:157) net.liftweb.http.Req$$anonfun$3$$anon$1.next(Req.scala:144) scala.Iterator$class.toList(Iterator.scala:696) net.liftweb.http.Req$$anonfun$3$$anon$1.toList(Req.scala:144) net.liftweb.http.Req$$anonfun$3.apply(Req.scala:159) net.liftweb.http.Req$$anonfun$3.apply(Req.scala:139) net.liftweb.http.Req.x$16(Req.scala:328) net.liftweb.http.Req.uploadedFiles(Req.scala:327) net.liftweb.http.LiftSession.runParams(LiftSession.scala:330) net.liftweb.http.LiftSession.processRequest(LiftSession.scala:558) net.liftweb.http.LiftServlet.net$liftweb$http$LiftServlet$ $dispatchStatefulRequest(LiftServlet.scala:239) net.liftweb.http.LiftServlet$$anonfun$2.apply(LiftServlet.scala:155) net.liftweb.http.LiftServlet$$anonfun$2.apply(LiftServlet.scala:155) net.liftweb.http.S$.net$liftweb$http$S$$wrapQuery(S.scala:909) Caught and thrown by: Message: org.apache.commons.fileupload.FileUploadBase $FileSizeLimitExceededException: The field F1052029947622ETF exceeds its maximum permitted size of 7340032 characters. org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl $FileItemStreamImpl$1.raiseError(FileUploadBase.java:746) org.apache.commons.fileupload.util.LimitedInputStream.checkLimit (LimitedInputStream.java:71) org.apache.commons.fileupload.util.LimitedInputStream.read (LimitedInputStream.java:128) java.io.FilterInputStream.read(FilterInputStream.java:90) net.liftweb.http.OnDiskFileParamHolder$.doUpload$1(Req.scala:74) net.liftweb.http.OnDiskFileParamHolder$.apply(Req.scala:82) eu.getintheloop.example.lib.UploadProgress$$anonfun$init$2.apply (UploadProgress.scala:19) eu.getintheloop.example.lib.UploadProgress$$anonfun$init$2.apply (UploadProgress.scala:18) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] toForm on a MappedLongForeignKey
Hey all, This is my first venture into lift's ORM and I'm upgrading an existing codebase, so I'm not sure how all the pieces fit together, but I've figured out enough to patch in my features. I was wondering if someone can help me out with this issue: The code is using the toForm method on the objects inside a KeyedMetaMapper. What I want to see for the foriegn key relationship is a combo box with a drop-down of the possible values (perhaps with a user-specified toString on those foreign key objects). toForm simply displays: Can't change on the MappedLongForeignKey. What/where should I look to change this? Thanks!!! - Josh --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: toForm on a MappedLongForeignKey
Exactly! Thanks
On Sat, Jul 11, 2009 at 11:54 AM, TylerWeir tyler.w...@gmail.com wrote:
Something like this?
object reportsTo extends MappedLongForeignKey(this, User) {
override def displayName = Reports To
override def asHtml = {
span{User.find(By(User.id, this)).map(u =
(u.firstName + +
u.lastName)).openOr(Text(PM))}/span
}
override def validSelectValues: Box[List[(Long, String)]] =
Full(User.findAll(OrderBy(User.lastName, Ascending)).map(c =
(c.id.is, c.niceName)))
override def _toForm = {
Full(span{User.find(By(User.id, this)).map(u =
(u.firstName +
+ u.lastName)).openOr(Text(No Reports To))}/span)
}
}
On Jul 11, 11:20 am, Josh Suereth joshua.suer...@gmail.com wrote:
Hey all,
This is my first venture into lift's ORM and I'm upgrading an existing
codebase, so I'm not sure how all the pieces fit together, but I've
figured
out enough to patch in my features. I was wondering if someone can help
me
out with this issue:
The code is using the toForm method on the objects inside a
KeyedMetaMapper. What I want to see for the foriegn key relationship is
a
combo box with a drop-down of the possible values (perhaps with a
user-specified toString on those foreign key objects). toForm simply
displays: Can't change on the MappedLongForeignKey. What/where should
I
look to change this?
Thanks!!!
- Josh
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: toForm on a MappedLongForeignKey
actually, do you need the _toForm in there? If I remove it, it makes a nice
combo box. I think I was just missing the validSelectValues override.
Thanks again.
- Josh
On Sat, Jul 11, 2009 at 11:54 AM, TylerWeir tyler.w...@gmail.com wrote:
Something like this?
object reportsTo extends MappedLongForeignKey(this, User) {
override def displayName = Reports To
override def asHtml = {
span{User.find(By(User.id, this)).map(u =
(u.firstName + +
u.lastName)).openOr(Text(PM))}/span
}
override def validSelectValues: Box[List[(Long, String)]] =
Full(User.findAll(OrderBy(User.lastName, Ascending)).map(c =
(c.id.is, c.niceName)))
override def _toForm = {
Full(span{User.find(By(User.id, this)).map(u =
(u.firstName +
+ u.lastName)).openOr(Text(No Reports To))}/span)
}
}
On Jul 11, 11:20 am, Josh Suereth joshua.suer...@gmail.com wrote:
Hey all,
This is my first venture into lift's ORM and I'm upgrading an existing
codebase, so I'm not sure how all the pieces fit together, but I've
figured
out enough to patch in my features. I was wondering if someone can help
me
out with this issue:
The code is using the toForm method on the objects inside a
KeyedMetaMapper. What I want to see for the foriegn key relationship is
a
combo box with a drop-down of the possible values (perhaps with a
user-specified toString on those foreign key objects). toForm simply
displays: Can't change on the MappedLongForeignKey. What/where should
I
look to change this?
Thanks!!!
- Josh
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: liftweb.net down now, and maven refuses to compile
Hi, I forwarded the email to ad...@scala-tools.org, but I have not received it back (meaning is has not been sent). I also tried ssh'ing onto the box, and was unsuccessful. That's being my powers of admin for scala-tools.orguntil we can get it active again. David Pollak and Derek Chen-Becker are the other admins (for future reference). - Josh On Sat, Jun 27, 2009 at 5:28 AM, marius d. marius.dan...@gmail.com wrote: dunno who can help .. I sent an email on scala-list but nothing yet On Jun 27, 12:17 pm, Timothy Perrett timo...@getintheloop.eu wrote: @marius Is there anyone around to checkup on scala-tools? DavidB doesn't monitor the lift list much these days and I'm not sure if there are any other non-American guys (I.e people who are awake now!) to take a look at the server? Cheers, Tim Sent from my iPhone On 27 Jun 2009, at 10:06, marius d. marius.dan...@gmail.com wrote: try maven -o Marius On Jun 27, 11:46 am, Ellis ellis.whiteh...@gmail.com wrote: Maven is suddenly refusing to compile because scala-tools.org is down. Can the liftweb-snapshot-1.1 POM be changed in order to let maven work in offline mode? Here's an excerpt of the error message when trying to run in offline mode: $ mvn -o -npu compile [INFO] NOTE: Maven is executing in offline mode. Any artifacts not already in your local repository will be inaccessible. ... [ERROR] BUILD ERROR [INFO] --- - [INFO] Failed to resolve artifact. ... Missing: -- 1) net.liftweb:lift-util:jar:1.1-SNAPSHOT ... The files DO appear to be in my local repository, last updated via maven yesterday at 15:20 GMT: $ ls -1 /home/ellis/.m2/repository/net/liftweb/lift-util/1.1- SNAPSHOT/ lift-util-1.1-SNAPSHOT.jar lift-util-1.1-SNAPSHOT.jar.sha1 lift-util-1.1-SNAPSHOT-javadoc.jar.lastUpdated lift-util-1.1-SNAPSHOT.pom lift-util-1.1-SNAPSHOT.pom.sha1 lift-util-1.1-SNAPSHOT-sources.jar lift-util-1.1-SNAPSHOT-sources.jar.sha1 maven-metadata-scala-tools.org.snapshots.xml maven-metadata-scala-tools.org.snapshots.xml.sha1 maven-metadata-scala-tools.org.xml resolver-status.properties Any ideas how to force maven to use the files that it was content to use yesterday? Thanks, Ellis --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
Re: [scala] Re: [Lift] Programming in Scala #5, Lift Book #8, Beginning Scala #9
I must say, I have not met a build system (besides automake) that exceeded make in complexity. The amount of funny exceptions to rules is astounding. I had far less trouble learning maven (in all its complexity) Sent from my iPhone On Jun 9, 2009, at 4:56 PM, Alexy Khrabrov delivera...@gmail.com wrote: Since the topic seems to have morphed into learning Scala and Lift by immersion in a day, as a recent Scala convert, I can't begin to emphasize how important it is to have the build infrastructure all done in a simple way to let novices focus on Scala. Lift is a good example where you have no choice and just follow magic Maven incantations. Another is Processing in Scala, where you can just do small sketches. If the assumption is that it is the Java crowd which comes to JVM mostly, it doesn't bootstrap non-JVM folks like those coming from Ruby and Haskell/OCaml. So I'm glad David covers the build systems in his book; there should really be an easier way to begin without making choices between Maven, SBT, Buildr, Ant, etc.! Nothing more complex than a good old command line and a Makefile in the same directory... Ideally SBT becomes a part of Scala and you'll have a --make option, or something like that. Cheers, Alexy --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: JTA
Unfortunately, I'm still living in EJB land, and therefore would prefer
something to bridge the gap (between legacy and new code). Goatrodeo looks
very exciting, but something for our next new component.
I actually had a layer I was using between our EJB beans + LIft that perhaps
with some time I can re-write in a open-source setting. I make no promises
on time, but I do see interfacing with legacy systems as being a huge win
for promoting lift/scala use in the enterprise. Basically, my Lift-EJB
Layer looked like the following:
import EJBHelper._
def retreiveSomeValue = {
val result = withBean[BeanLocalInterface] { bean =
bean.someBusinessMethod()
}
result.openOrElse(SomeOtherValue)
}
What I'd like is to be able to migrate scala further down my EJB stack when
refactoring. For example:
@Stateless
class MyBean extends MyBeanLocal with ScalaEJBHelper {
def getMyData(id : Long) {
(for {
tx - transaction(JOIN_OR_NEW)
result - ejb_single_query(from MyDataBean where MyDataBean.id
= ?) % id
} yield result).first
}
}
At least until it becomes more acceptable/feasible to migrate to better
solutions than EJB.
- Josh
On Fri, May 29, 2009 at 11:36 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
On Fri, May 29, 2009 at 7:19 PM, Josh Suereth joshua.suer...@gmail.comwrote:
+30
See http://github.com/dpp/goatrodeo/tree/master
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: JTA
+30
So many pluses in fact, that we are already experimenting with this concept
at work. Unfortunately, the source may not be openable. I'd be more than
willing to contribute to an open-source JTA monadic library.
for( tx - context) {
//Do stuff
if(somethingBad) tx.rollback()
//Do more stuff
}
Just seems to fit the needs of my software *much* better than the magical
annotated method...errr... method seen in EJB and Spring.
-Josh
On Fri, May 29, 2009 at 9:16 PM, Jorge Ortiz jorge.or...@gmail.com wrote:
I, too, would like to see Transactions be monadic.
--j
On Fri, May 29, 2009 at 3:54 PM, Meredith Gregory
lgreg.mered...@gmail.com wrote:
Jonas,
i applaud the effort. i agree with DPP sentiments regarding annotations.
That said, i feel pretty comfortable that transactions fit entirely in a
monadic context. Since LINQ demonstrates that query fits into monadic
context, and there's already at least one Scala implementation of
LINQhttp://github.com/szeiger/scala-query/tree/master,
might i suggest that you come up with a monadic presentation first and then
map the sugar to that. My guess is that the sugar will be informed by the
monadic presentation.
To be suggestive... think of a context with a Tx object, TxCtxt, as like
an Option widget. Then you do stuff inside a transaction via
for ( myTransactedWidget - TxCtxt if someCondition ) yield {
someOperationsThatNeedToBeTransacted }
If you implement flatMap, yada, on TxCtxt you can have fun with nested
transaction semantics. The point is that this should just work with a
LINQ-like presentation of query.
Best wishes,
--greg
On Fri, May 29, 2009 at 6:54 AM, Jonas Bonér jbo...@gmail.com wrote:
I'll go for closures. Much simpler and less intrusive into Lift.
The current impl is based on Atomikos and Hibernate, I'll start with
pushing that in and we can make it pluggable later.
For example for Hibernate one need to add a line to the hibernate
config to register the
org.hibernate.transaction.TransactionManagerLookup class in order to
make Hibernate aware of our TX manager.
Should I fork the github repo and submit patches or how do you guys work?
/Jonas
2009/5/29 Derek Chen-Becker dchenbec...@gmail.com:
I'd vote for closures. We use annotations for JPA because we have to,
but
IMHO closures provide a nicer semantic approach because they
syntactically
enclose the block where the action is occurring.
Derek
On Fri, May 29, 2009 at 7:44 AM, Jonas Bonér jbo...@gmail.com wrote:
No perf difference. The annotations are turned into the same exact
closures.
2009/5/29 Timothy Perrett timo...@getintheloop.eu:
Are there any performance implications considering closures vs
annotations?
Agreed that closures are more lift like however.
Cheers, Tim
On 29/05/2009 10:21, marius d. marius.dan...@gmail.com wrote:
I think that would be really good. But I'd rather not use
annotations.
Personally I find closures approach a much better fit here.
withTxRequired {
... // do transational stuff
}
Br's,
Marius
On May 29, 11:55 am, Jonas Bonér jbo...@gmail.com wrote:
Hi guys.
I have been talking with David Pollak the rest of the lift team
about
adding JTA to Lift. I have implemented that for a product written
in
Scala some time ago. Now some of that code is OSS
at:http://github.com/jboner/skalman/tree
We used using two different APIs.
1. Annotations (would require Lift to support proxied objects,
e.g.
grab them from a factory):
@TransactionAttribute(REQUIRED)
def transactionalMethod = { ... }
2. Call-by-name:
withTxRequired {
... // do transational stuff
}
But I don't know what fits Lift and would like to know how you
guys
would like to have JTA integrated.
At which level? Which APIs? Etc.
--
Jonas Bonér
twitter: @jboner
blog:http://jonasboner.com
work: http://crisp.se
work: http://scalablesolutions.se
code: http://github.com/jboner
--
Jonas Bonér
twitter: @jboner
blog:http://jonasboner.com
work: http://crisp.se
work: http://scalablesolutions.se
code: http://github.com/jboner
--
Jonas Bonér
twitter: @jboner
blog:http://jonasboner.com
work: http://crisp.se
work: http://scalablesolutions.se
code: http://github.com/jboner
--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117
+1 206.650.3740
http://biosimilarity.blogspot.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
[Lift] Re: Using ExtJS
A question I've had is how hard would it be to support a ExtJS based application (i.e. the server side only needs to be a remote JSON framework). I assume this would be just-as-difficult as providing a REST-based API to your data. We use ExtJS extensively at work, and there are some pors/cons to having 90% of your UI code run inside the browser. In our situation, the server-side controllers are doing very little (our business tier is pretty robust and includes portions outside the scope of any web framework). Anyway, in my prototyping with lift, it was a very nice AJAXy framework, but I could never determine how to unify the ExtJS wants me to program like X and Lift wants me to program like Y bridge. Not that one excludes the other, but I was never sure if I was in the sweet spot. From what I could tell, 90% application would have lived in a bunch of rewrite rules. Can anyone fill me in on what I might have missed? -Josh On Sun, May 17, 2009 at 11:55 PM, David Pollak feeder.of.the.be...@gmail.com wrote: You can mix ExtJS into the project without any work at all. If you want to use ExtJS exclusively, then you'll need to do the adapter thing so Lift knows how to communicate with the server (Ajax, Comet, etc.) On Sun, May 17, 2009 at 4:15 PM, Charles F. Munat c...@munat.com wrote: Wait. Is that right, guys? Does the LGC need JQuery or YUI? If not, then you only need to use an adapter and one of those if you are going to use the built-in Lift Js helper methods. So I guess it's possible to use ExtJs 3.0 without any adapter if you're not going to use the helper methods. Sorry if I'm just confusing the issue. I am using ExtJs on a Lift site with no problems (other than that ExtJs is a PITA). Chas. Charles F. Munat wrote: You'll need to use an adapter for either JQuery or YUI because the Lift garbage collector depends on that. There are no Lift JS functions specific to ExtJs, but as you'll be using either JQuery or YUI for the GC, you can use Lift's JQuery/YUI helpers for non-ExtJs stuff. For things specific to ExtJs, you'll have to build your own helpers, but you can probably just copy, paste, and modify the others to get what you want. ExtJs probably can't be built into Lift because of licensing issues, so you'll have to do some work for yourself. Chas. Jesse Eichar wrote: Hi, I was wondering how plausible using ExtJS since Lift adds some Ajax libraries. ExtJS requires adapters to work nicely with others. I am not sure if the adapters need to be ran with the specific version of (say YUI or JQuery) the library that is shipped with Ext or if the adapters are enough by then selves. But really my question is: Is it possible to use advanced ExtJS in Lift? And what would the recommended way be? Thanks, Jesse -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Using ExtJS
Is there a way for me to *know* the potential stateful snippets I could call using the lift_page javascript variable? Most of my views are completely in JavaScript, and my server calls can take in any kind of data (JSON or raw parameters) and return JSON. IF you can point me at the right way to do this, I'll set up a demo sight showing the style of web development we do at work. -Josh On Mon, May 18, 2009 at 11:59 AM, David Pollak feeder.of.the.be...@gmail.com wrote: On Mon, May 18, 2009 at 6:02 AM, Josh Suereth joshua.suer...@gmail.comwrote: A question I've had is how hard would it be to support a ExtJS based application (i.e. the server side only needs to be a remote JSON framework). I assume this would be just-as-difficult as providing a REST-based API to your data. We use ExtJS extensively at work, and there are some pors/cons to having 90% of your UI code run inside the browser. In our situation, the server-side controllers are doing very little (our business tier is pretty robust and includes portions outside the scope of any web framework). Anyway, in my prototyping with lift, it was a very nice AJAXy framework, but I could never determine how to unify the ExtJS wants me to program like X and Lift wants me to program like Y bridge. Not that one excludes the other, but I was never sure if I was in the sweet spot. From what I could tell, 90% application would have lived in a bunch of rewrite rules. Can anyone fill me in on what I might have missed? Josh, It's actually brain-damaged simple to do JSON request handlers in Lift. See http://demo.liftweb.net/json You set up patterns to handle the incoming JSON requests. Combining this with extractors makes things type-safe, secure, and very concise. If you need more, please let me know. Thanks, David -Josh On Sun, May 17, 2009 at 11:55 PM, David Pollak feeder.of.the.be...@gmail.com wrote: You can mix ExtJS into the project without any work at all. If you want to use ExtJS exclusively, then you'll need to do the adapter thing so Lift knows how to communicate with the server (Ajax, Comet, etc.) On Sun, May 17, 2009 at 4:15 PM, Charles F. Munat c...@munat.comwrote: Wait. Is that right, guys? Does the LGC need JQuery or YUI? If not, then you only need to use an adapter and one of those if you are going to use the built-in Lift Js helper methods. So I guess it's possible to use ExtJs 3.0 without any adapter if you're not going to use the helper methods. Sorry if I'm just confusing the issue. I am using ExtJs on a Lift site with no problems (other than that ExtJs is a PITA). Chas. Charles F. Munat wrote: You'll need to use an adapter for either JQuery or YUI because the Lift garbage collector depends on that. There are no Lift JS functions specific to ExtJs, but as you'll be using either JQuery or YUI for the GC, you can use Lift's JQuery/YUI helpers for non-ExtJs stuff. For things specific to ExtJs, you'll have to build your own helpers, but you can probably just copy, paste, and modify the others to get what you want. ExtJs probably can't be built into Lift because of licensing issues, so you'll have to do some work for yourself. Chas. Jesse Eichar wrote: Hi, I was wondering how plausible using ExtJS since Lift adds some Ajax libraries. ExtJS requires adapters to work nicely with others. I am not sure if the adapters need to be ran with the specific version of (say YUI or JQuery) the library that is shipped with Ext or if the adapters are enough by then selves. But really my question is: Is it possible to use advanced ExtJS in Lift? And what would the recommended way be? Thanks, Jesse -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Using ExtJS
I'll let you know. Having a good ExtJS + LIft story would be very handy when I talk to the Grails fans in the office. -Josh On Mon, May 18, 2009 at 5:08 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Mon, May 18, 2009 at 9:28 AM, Josh Suereth joshua.suer...@gmail.comwrote: Is there a way for me to *know* the potential stateful snippets I could call using the lift_page javascript variable? Actually, you're not calling stateful snippets, you're calling a Json handler. Please take a look at http://demo.liftweb.net/json_more This is an example of sending data from the UI via JavaScript calls and getting a callback when the server has processed the results. Does this help? Most of my views are completely in JavaScript, and my server calls can take in any kind of data (JSON or raw parameters) and return JSON. IF you can point me at the right way to do this, I'll set up a demo sight showing the style of web development we do at work. -Josh On Mon, May 18, 2009 at 11:59 AM, David Pollak feeder.of.the.be...@gmail.com wrote: On Mon, May 18, 2009 at 6:02 AM, Josh Suereth joshua.suer...@gmail.comwrote: A question I've had is how hard would it be to support a ExtJS based application (i.e. the server side only needs to be a remote JSON framework). I assume this would be just-as-difficult as providing a REST-based API to your data. We use ExtJS extensively at work, and there are some pors/cons to having 90% of your UI code run inside the browser. In our situation, the server-side controllers are doing very little (our business tier is pretty robust and includes portions outside the scope of any web framework). Anyway, in my prototyping with lift, it was a very nice AJAXy framework, but I could never determine how to unify the ExtJS wants me to program like X and Lift wants me to program like Y bridge. Not that one excludes the other, but I was never sure if I was in the sweet spot. From what I could tell, 90% application would have lived in a bunch of rewrite rules. Can anyone fill me in on what I might have missed? Josh, It's actually brain-damaged simple to do JSON request handlers in Lift. See http://demo.liftweb.net/json You set up patterns to handle the incoming JSON requests. Combining this with extractors makes things type-safe, secure, and very concise. If you need more, please let me know. Thanks, David -Josh On Sun, May 17, 2009 at 11:55 PM, David Pollak feeder.of.the.be...@gmail.com wrote: You can mix ExtJS into the project without any work at all. If you want to use ExtJS exclusively, then you'll need to do the adapter thing so Lift knows how to communicate with the server (Ajax, Comet, etc.) On Sun, May 17, 2009 at 4:15 PM, Charles F. Munat c...@munat.comwrote: Wait. Is that right, guys? Does the LGC need JQuery or YUI? If not, then you only need to use an adapter and one of those if you are going to use the built-in Lift Js helper methods. So I guess it's possible to use ExtJs 3.0 without any adapter if you're not going to use the helper methods. Sorry if I'm just confusing the issue. I am using ExtJs on a Lift site with no problems (other than that ExtJs is a PITA). Chas. Charles F. Munat wrote: You'll need to use an adapter for either JQuery or YUI because the Lift garbage collector depends on that. There are no Lift JS functions specific to ExtJs, but as you'll be using either JQuery or YUI for the GC, you can use Lift's JQuery/YUI helpers for non-ExtJs stuff. For things specific to ExtJs, you'll have to build your own helpers, but you can probably just copy, paste, and modify the others to get what you want. ExtJs probably can't be built into Lift because of licensing issues, so you'll have to do some work for yourself. Chas. Jesse Eichar wrote: Hi, I was wondering how plausible using ExtJS since Lift adds some Ajax libraries. ExtJS requires adapters to work nicely with others. I am not sure if the adapters need to be ran with the specific version of (say YUI or JQuery) the library that is shipped with Ext or if the adapters are enough by then selves. But really my question is: Is it possible to use advanced ExtJS in Lift? And what would the recommended way be? Thanks, Jesse -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp
[Lift] Re: Builing Lift ... again
Do you have the scala-tools.org/repo-snapshots configured? Maven will look in all configured repositories for artifacts sequentially. If it is *only* looking in repo-releases, then you need to modify your pom so it will also look in repo-snapshots. -Josh On Wed, May 13, 2009 at 3:40 AM, Marius marius.dan...@gmail.com wrote: Hi, I tried again to build lift on Windows ... and it failed again. Yes I did clean um my repository folder. The problems I ran into so far: 1. The spec for sites/examples application in pom.xml it was pointing to 1.4.4-SNAPTHOT version but this version does not seem to exist on scala-tools. Replacing this version with 1.4.5-SNAPSHOT did the trick 2. I'm now having some problems building with Scala JPA. It seems that it looks for scalajpa at: http://scala-tools.org/repo-releases/org/scala-libs/scalajpa/1.1-SNAPSHOT/scalajpa-1.1-SNAPSHOT.pom The hing is that on http://scala-tools.org/repo-releases/org/scala-libs/scalajpa/1.1/ there is no 1.1-SNAPSHOT, just 1.1. Br's, Marius --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: [scala-user] Update to maven-scala-plugin 2.10.1 and add maven-compiler-plugin?
Ah, sorry, I saw this come out on the scala-user mailing list. I assume you mean the root pom of Lift? Well, maven-scala-plugin 2.10.1 is working now, and I have lift as one of my final integration tests before release. So you should be good to go :). - Josh On Thu, Apr 30, 2009 at 4:08 PM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: The root POM for what? Well, plugin settings are inherited by child projects = Hence you can import lift-webkit, lift-util, etc. into Eclipse and will find the correct compiler settings. Heiko 2009/4/30 Josh Suereth joshua.suer...@gmail.com I'm fine with these changes, but The root pom for what? Yes, the maven-scala-plugin 2.10.1 is the best currently. 2.11 should feature updates to take advantage of the new process-argument-limit workarounds in Scalac (which I think are in 2.7.4). -Josh On Thu, Apr 30, 2009 at 3:25 PM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: Hi, I would like to change the root POM: 1. Update to maven-scala-plugin - 2.10.1 This is just to use the latest (best?) version. 2. Add maven-compiler-plugin - Set source and target to 1.5 This is to ease eclipse integration: The Maven integration for Eclipse applies these settings to Eclipse projects which helps a *great* lot. Any concerns? Heiko -- www.heikoseeberger.name OSGi on Scala: www.scalamodules.org Lift, the simply functional web framework: http://liftweb.net -- www.heikoseeberger.name OSGi on Scala: www.scalamodules.org Lift, the simply functional web framework: http://liftweb.net --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: developing Scala/Lift using Eclipse
Good catch! Also if you just place your scala files in src/main/java (with your java files) you would be ok. On Wed, Apr 29, 2009 at 8:55 AM, David Bernard david.bernard...@gmail.comwrote: Quick note : * You need to use build-helper-maven-plugin (like Josh shown) only for mixed project. * if you set in your build sourceDirectorysrc/main/scala/sourceDirectory testSourceDirectorysrc/test/scala/testSourceDirectory then the maven-eclipse-plugin use the right directory (archetype use this setup) my 2c /davidB On Wed, Apr 29, 2009 at 14:46, Josh Suereth joshua.suer...@gmail.comwrote: It should be innocuous. (Assuming no typing errors). It will also fix some of your mvn eclipse:eclipse woes. Remember though, using mvn eclipse:eclipse does *not* give the Scala IDE for Eclipse any chance to fix/edit its configuration. Most eclipse plugins assume they have full control over *their* configuration and when doing things through eclipse APIs, they have a chance to respond and tweak the project settings appropriately. This means that any bugs you run into in eclispe should be reproduced without using mvn eclipse:eclipse. This is why you should prefer eclipse plugins, rather than maven plugins, to do integration between Scala + Maven + Eclipse. - Josh On Wed, Apr 29, 2009 at 5:29 AM, Channing Walton channingwal...@mac.comwrote: Can we fix our existing Lift project poms by adding the lump of xml you just posted, or will that break things? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: developing Scala/Lift using Eclipse
On Wed, Apr 22, 2009 at 8:05 AM, Miles Sabin mi...@milessabin.com wrote: On Wed, Apr 22, 2009 at 11:14 AM, Channing channingwal...@mac.com wrote: 4. went to the project properties and edited each of the source folders removing the 'Excluded items' which was preventing eclipse from compiling the scala code snip/ Whenever I change the pom, I use a terminal to run mvn commands from the project directory and refresh my workspace, I have to repeat step 4 whenever I do this. Umm ... this Maven behaviour is just completely broken, isn't it? Or am I missing something? Can someone explain the rational for it to me? The maven-eclipse-plugin is currently broken in the sense that it won't pay attention to the source directories configured by the maven-scala-plugin. The developers seem unwilling to try to integrate these two plugins, as they have a workaround. The workaround is to configure the build-helper-pluginhttp://mojo.codehaus.org/build-helper-maven-plugin/howto.htmlin your pom with the correct source directories, and then when running maven eclispe:eclipse you will see these show up. Very intuitive eh? Perhaps if enough people complain to the maven-eclipse-plugin guys, they'll think about changing how they determine source directories. -Josh --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: developing Scala/Lift using Eclipse
On Wed, Apr 22, 2009 at 8:53 AM, Miles Sabin mi...@milessabin.com wrote: On Wed, Apr 22, 2009 at 1:16 PM, Josh Suereth joshua.suer...@gmail.com wrote: The maven-eclipse-plugin is currently broken in the sense that it won't pay attention to the source directories configured by the maven-scala-plugin. The developers seem unwilling to try to integrate these two plugins, as they have a workaround. Which developers are these? Where should I be applying pressure? The maven-eclipse-plugin. We've recently attracted the attention of Jason van-zyl so hoepfully that will encourage more support for scala :) The workaround is to configure the build-helper-plugin in your pom with the correct source directories, and then when running maven eclispe:eclipse you will see these show up. Very intuitive eh? Can't that workaround be made the default behaviour for Maven Scala modules? At least then things would work out of the box with Eclipse (if I'm understanding the situation correctly). Perhaps lift should update it archetypes appropriately? I'll update the documentation for the maven-scala-plugin accordingly. I do not use the maven-eclipse-plugin personally, so it hasn't caused me pain directly. I also recommend using one of the plugins for eclipse that actively synchs your data internally rather than updating eclipse configuration files outside of eclipse. However, I'll try to make sure we provide better help in this area. Would one of the lift committers please add the following to your plugins section in the poms for your acrchetypes: plugin groupIdorg.codehaus.mojo/groupId artifactIdbuild-helper-maven-plugin/artifactId executions execution idadd-source/id phasegenerate-sources/phase goals goaladd-source/goal /goals configuration sources sourcesrc/main/scala/source /sources /configuration /execution execution idadd-test-source/id phasegenerate-sources/phase goals goaladd-test-source/goal /goals configuration sources sourcesrc/test/scala/source /sources /configuration /execution /executions /plugin TBH, I'm a little bit cheesed off to discover that lots of the alleged brokenness of the Scala IDE for Eclipse seem to boil down to Maven trampling all over internal Eclipse metadata. True, the broken-ness is actually with the maven-eclipse integrations (specifically, the maven-eclipse-plugin cheating when it comes to calculating source directories). I understand the gripe, however when integrating diverse plugins, I think misconceptions on who's to blame happen all the time. The big fail here is that Maven is still working on being friendlier for multi-language projects, and some of the downstream projects aren't up-to-date yet. I'm not aware of any maven aspects like feature that is flexible enoguh to allow me to monkey-patch fixes on plugins I have no control over, so I'm limited to trying to submit patches when applicable. I hope it's not terribly inconvenient, but feel free to send any Maven + Eclipse questions (as they relate to adding scala support) my way. I'm hoping to solve most of these issues with ESMi. -Josh --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Improving our eclipse experience (was: Why can eclipse never find: org.mortbay.jetty.webapp.WebAppContext)
On Sun, Apr 19, 2009 at 8:07 PM, Miles Sabin mi...@milessabin.com wrote: I think that all of this sounds generally positive, but I have to ask ... Why is this thread (now) titled Improving out Eclipse experience? What is Eclipse doing wrong here? Cheers, Miles TBH my biggest complaint when using lift with eclipse is my complaint every time I use multiple plugins with eclipse, and that is the cross-plugin integration (particularly maven + scala or maven + javascript). In general, things work, but there are a few large potholes you have to avoid. Being a regular driver, I sometimes forget these potholes exist (as I learned to instinctively avoid them.) Actually the Add Scala Nature feature (from so long ago) and the new aspects-for-working-around-the-jdt provides fixes for 90% of the integration problems I had. I don't really see any specific thing in the plugin to make this better, just as things show up, fixing minor issues and playing nicely. The second biggest complaint would be mismatched scala version issues. Lift may be compiled against scala 2.7.3, so i need to make sure that the eclipse compiled files do not mingle with the maven compiled files. This way, in production I have everything against scala 2.7.3 but inside eclipse it's using Scala 2.8.0-xxx or 2.74.-rc1. In general this is fine, but sometimes I cannot run/debug applications in eclipse due to the mismatch (very fun exceptions on startup). I've been working on making this reproducable (and therefore fixable), but have not yet done so. In general, on my work machine I run similar version (plugin == maven) so it's not an issue. However this means I'm usually behind at work for bug fixes and such. It would be nice if the plugin could use its own internal compiler for IDE features (auto-complete, refactoring, outlines, etc) but allow me to specify a version of scala to use when compiling .class files so we don't have this mismatch. I realize this is a huge feature request, but I don't mind helping contribute to make it happen ;) So far you've already taken the plugin from something only us bleeding edge folk would use, to something my coworkers are using without complaining. Kudos! and please keep up the good work. - Josh --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Liftweb without Maven?
Maven does not really use Jelly anymore (in Maven2). I agree a Maven1 was rather ridiculous. Maven2 takes the idea that the pom should just be configuration + declaration, not implementation details. It's a breath of fresh air from other build tools (even Maven1). The issue still becomes how do you implement plugins so as to keep the declare, don't implement rules. I would recommend just looking at the general idea, because it will change your opinion of build tools. It still has a long way to come, but the idea of it, I think, has a lot of potential, more so than task-based build utilities. -Josh --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Lift works on Google App Engine (within the confines of what's possible)
On Fri, Apr 17, 2009 at 5:57 PM, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, I've just committed a version of Lift (including the Lift Example) that runs on the Google App Engine. You can see the running demo at: http://liftdemo.appspot.com/ What's missing: - Mapper and Mapper-related stuff. You can use JPA. - Comet. GAE's lack of thread or message queue support is a huge limitation. - Actor-based session-shutdown notification is disabled on GAE. - There's no session affinity guarantee, so there may be problems with migrating sessions (I'll be working with the Google folks on this issue) Okay... so you can build apps on GAE... I have to wonder... who would want to? GAE gives you a highly scalable platform to build CRUD apps. Without a back-end messaging infrastructure, long running processes, threads, inter-session messaging, etc. there's not much in the way of exciting apps to build. Here are a list of apps that could not be built with GAE: - Twitter (requires a message bus and back-ground processing) - Facebook (has many of Twitter's requirements) - GoogleTalk - A travel site (the 30 second request duration means that looking stuff up on a back end service is not possible) - A multi-player game MySQL Game http://mysqlgame.appspot.com/ is actually pretty good multiplayer game on GAE. Here's the description if you never played: --- Are you tired of browser-based games that are thinly veiled interfaces for databases? Finally, there's a game that just *is* a database! THRILL as you insert your very own row in the rows table! With careful selection of SQL queries, you will soon have three or even four-digit numbers in some of the fields in your row! Other queries may allow you to use those numbers to subtract from rows entered by other players -- all while pushing the numbers in your own row even higher! As you master the game, you may find that you have inserted not just one row into the game, but several! --- Anyway, I wouldn't discount GAE. It's certainly not as cool as lift's comet support, but perhaps in the future you can make that happen. It does appear to have different goals than lift, but again, perhaps in the future they will be more aligned. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: [Lift committers] Re: Meeting
I am firmly against anything that re-writes byte-code after the
compilation
phase for production code. Once the Scala-Maven plugin supports
compiler
plugins, then there's a lot of stuff that can be done at compile-time.
The scala-maven plugin already supports compiler plugins. Feel free to
make use of it as I do.
(yes this is unrelated).
BTW - Most cases where aspects would have been useful in Java, I'd rather
see some kind of DSL.
E.g. Transactions -
def doSomeWork() {
transactional {
//My Trasnactional code
}
//Wow, I can even do stuff outside the transaction look at me go
}
The one use of annotations I see as being handy is how it's used in the
Eclipse plugin (i.e. fix a flaw the JDT Community is unwilling to fix).
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Liftweb without Maven?
Does the ant build file already exist? If not, it wouldn't be too hard to create a maven assembly that assembles all the various dependencies and such into a directory (or uses something like the maven-ant-tasks to materialize them for the project later), and includes an ant build script/starter project code. I can add this to my list of things todo, however if someone else is interested and has time, I'm more than willing to help answer questions / point you in the correct maven direction. I guess it would be ideal to make use of the current archetypes, but I don't even see this as necessary. An assembly for a zip/tgz file could be generated which includes a project-starter kit for ANT and could be deployed into the maven repository with all the other artifacts for a build. This could be downloaded from the maven repository then (and versioned, etc.). We actually use this at work for our ubiquituous install (we also have RPMs, etc. for installing our software). My question here, is why should the project be generated on the fly? Is that so you can have your desired package structure on startup? -Josh --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: How to use the new Record framework and Jackrabbit
Glenn, Given what I know of the existing Scala OSGi bundles, I don't see any issues with what you're attempting, but I have not tried that personally. As Tim mentioned, the stuff Heiko and I are working on will hopefully unify the existing OSGi solutions and provide a little bit easier integration for you. I'm hoping you'll see the early work show up in the scala nightlies by next week. In the meantime Heiko's bundlification of scala or the scala-library used by the eclipse plugin are both good alternatives for using scala in OSGi environments. I've only ever used the later personally (and I would only recommend it in equinox, as it uses eclipse specific manifest extensions). - Josh On Wed, Apr 8, 2009 at 7:34 PM, Timothy Perrett timo...@getintheloop.euwrote: Glenn, my understanding is that the OSGI stuff is *extremely* new... Check back on the recent conversations about it on list and that might answer some of your questions :-) Josh might also chime in with an appropriate answer as I think he's been working on the OSGI stuff. Cheers, Tim On 08/04/2009 22:27, glenn gl...@exmbly.com wrote: Has anyone tried to use the Scala OSGI bundle, say in Sling, to persist data to Jackrabbit? Any attempt at an implementation, at this stage, would be welcome. Glenn Silverman --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Rails - Lift
On Thu, Apr 9, 2009 at 9:42 AM, Clemens Oertel clemens.oer...@gmail.comwrote: I don't think it's necessary to make a final decision about your IDE at any time. AFAIK, all major IDEs work quite well with Maven's pom files, so it's very easy to switch IDEs at any time. WOAAAH I beg to differ. Actually some IDEs work much better with Maven pom's than others. It depends on how you like to arrange your projects and work on them. (At work, the IntelliJ users get a much different feel for multi-module projects than Eclipse users). As you said in the lower portion, choosing an IDE is more about what you're comfortable with. As I know Eclipse the best I am most productive in it (being a plugin contributor helps here ;) ). I have coded scala in a text editor (and sometimes resort to that at times), but in general I am more efficient in eclipse as I began to think in eclipse when I code. I'm positive this is different for different users. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: [scala-user] OSGi-fying Scala
Heiko, I've been working on OSGi support in scala, specifically 2 things: 1) OSGi-ifying scala standard libraries isn't too bad. I have project which does this: http://github.com/jsuereth/scala-jigsaw/tree/master I'd like to add this to the standard scala build so there is no more differentation between an OSGi version of scala and a non-OSGi version. Currently all this does is use BND to add a few entries to the manifests of each library. The issue here would be updating the eclipse plugin so that dogfooding is still possible (the current method breaks it). I haven't had the time to invest in fixing this yet. 2) A method of enforcing module visibility inside the compiler. I've started a scalac plugin: http://github.com/jsuereth/osgi-scalac-plugin/tree/master to make this happen. Currently it only pays attention to libraries that declare packge-export in their manifest and warns for all other import types. Help here would be appreciated if anyone is interested!!! Whatever is decided would be great! Recently I haven't had as much time as desired to hack on these and bring them up to production ready. So, if they are handy in whatever we decide to do, great! I would prefer not having different artifacts for OSGi scala vs. non-OSGi scala. ( *The main reason is that the same maven plugin could be used in both cases ;)* ) -Josh On Sun, Apr 5, 2009 at 11:37 AM, Heiko Seeberger fightgrav...@me.comwrote: Hi, I am currently working on different OSGi on Scala projects, e.g. ScalaModules http://www.scalamodules.org, Lift http://www.liftweb.net (OSGi-fying Lift) and BindForge http://www.bindforge.org. I do not know how well OSGi is known in the Scala space, but it will be a very serious thing for Java and in my opinion also very useful for Scala. To keep things simple: It is a dynamic module system which allows to develop and deploy modular Java/Scala systems. Basically there is some metadata specified in a JAR's manifest declaring things like module ID and version, public API, dependencies, etc. Hence all that is needed to OSGi-fy an existing library is adding the necessary manifest headers. For the above mentioned projects me and my mates have created OSGi-fied versions of the Scala libraries (scala-lang and scala-compiler so far). But that is redundant work! We would like to create these OSGi-fied Scala libraries in ONE common project and publish these to ONE central Maven repository. So far I have been talking to David Pollak and we decided to go for: org.scala-lang as group id and scala-library-osgi, scala-compiler-osgi, etc. as artifact ids. This naming resembles the original Scala libraries and makes clear that you will find OSGi inside. What do you think? Any other ideas? Heiko --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Menu widget
Don't know if anyone responded, but you may need to add the maven
snapshot repository to your pom as well.
Sent from my iPhone
On Apr 3, 2009, at 2:36 PM, DavidV david.v.villa...@gmail.com wrote:
I added the dependency to my pom.xml exactly as you suggested and I'm
getting this error:
Downloading:
http://scala-tools.org/repo-releases/net/liftweb/lift-widgets/1.1-S
NAPSHOT/lift-widgets-1.1-SNAPSHOT.jar
[INFO]
---
-
[ERROR] BUILD ERROR
[INFO]
---
-
[INFO] Failed to resolve artifact.
Missing:
--
1) net.liftweb:lift-widgets:jar:1.1-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-
widgets -
Dversion=1.1-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-
widgets -Dv
ersion=1.1-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -
Drepositor
yId=[id]
Path to dependency:
1) testLift:testLift:war:1.0
2) net.liftweb:lift-widgets:jar:1.1-SNAPSHOT
--
1 required artifact is missing.
for artifact:
testLift:testLift:war:1.0
from the specified remote repositories:
scala-tools.org (http://scala-tools.org/repo-releases),
central (http://repo1.maven.org/maven2)
I changed the dependency version to 1.0 because I followed the scala-
tools.org link (http://scala-tools.org/repo-releases) and noticed that
there wasn't a 1.1-SNAPSHOT version in net\liftweb\lift-widgets.
Maven then compiled the project, but my menu still isn't showing up as
I would like it to. I haven't changed my template.
On Apr 2, 11:07 pm, Derek Chen-Becker dchenbec...@gmail.com wrote:
Do you have lift-widgets module as a dependency in your pom.xml?
dependency
groupIdnet.liftweb/groupId
artifactIdlift-widgets/artifactId
version1.1-SNAPSHOT/version
/dependency
That's needed to get the dropdown widget code.
Derek
On Thu, Apr 2, 2009 at 3:13 PM, DavidV david.v.villa...@gmail.com
wrote:
I posted this yesterday but I haven't seen it appear yet...sorry
if it
is here twice.
I downloaded the scripts separately because I didn't know how to
update my repository/library to include the MenuWidget class and the
appropriate .js and .css files. I tried running mvn install on my
webapp, but it didn't download those new files.
I fixed the problem with my .css file so it compiles now, however
I'm
still not getting the nice stylish superfish navbar. Instead, I'm
getting a vertical bulleted list of links to my different pages. I
think it's a problem with my template. Here are the relevant
sections:
html xmlns=http://www.w3.org/1999/xhtml; xmlns:lift=http://
liftweb.net/
head
meta http-equiv=content-type content=text/html;
charset=UTF-8 /
meta name=description content= /
meta name=keywords content= /
titleMy WebApp lift:Menu.title / /title
lift:StyleSheet.entryForm /
lift:StyleSheet.fancyType /
script id=jquery src=/classpath/jquery.js type=text/
javascript/
script id=json src=/classpath/json.js type=text/
javascript/
/head
body
div class=container
div style=text-align: center
br/
h1 class=alt
Welcome to My WebApp /h1
/div
hr/
div
lift:MyMenu.render /
div
lift:Msgs/
hr class=space /
/div
/div
MyMenu is the snippet that contains the render method, which looks
like this:
def render(xhtml: NodeSeq): NodeSeq = {
MenuWidget(MenuStyle.NAVBAR)
}
Does anyone see what might be wrong here?
Thanks,
David
On Apr 1, 11:04 am, marius d. marius.dan...@gmail.com wrote:
Is there a reason why you downloaded he scripts separately? ... the
superfish dependencies are offered by the widget. Please see the
lift-
widgets project and the test applicaiton from there.
Br's,
Marius
On Mar 31, 11:48 pm, DavidV david.v.villa...@gmail.com wrote:
I would like to use this newMenuWidget, so I got the source code
from
GitHub and put it into my application as a snippet. I also
downloaded
all of the necessary superfish .css and .js files from the
superfish
website and put those in local sub-directories of the src/main/
webapp folder. When I try to compile the code in maven,
however, I
get the following error.
C:\Source\trunk\eclipse\testLiftmvn clean jetty:run
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'jetty'.
[INFO]
---
---
--
[INFO] Building testLift
[INFO]task-segment: [clean, jetty:run]
[INFO]
---
[Lift] Re: The Lift 1.1 list
My resources are pretty limited, but I'd love to at least contribute what I can to the OSGi support. I'd love to see a plugin system for lift apps that's sensible! Speaking of which, perhaps a plugin system that's sensible should be part of the list? I know grails does some neat stuff there with creating plugins (but their packaging/distribution model was less than desirable IMHO). Granted, a plugin in grails usually means nice library in scala, but being able to define extension points and plug in features would be handy (in certain circumstances. Hudson is my example of a good use of these features). -Josh On Wed, Apr 1, 2009 at 12:11 PM, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, I think we've got our Lift 1.1 list. If anyone has anything to add, please speak up now. - Improved documentation: better VScalaDoc coverage as well as better tutorial and cook-book documentation. - Improved J2EE support including JTA and Portlets. - Finish Record/Field code with backing store including JDBC, JPA and Goat Rodeo (what's Goat Rodeo? http://goatrodeo.org) - Improved client-side JavaScript support and better JavaScript abstractions. - Client/Server data synchronization (integrated with Record/Field) - Improved support for REST. - Improved performance including caching templates when running in production mode. - OSGi support. - Improved testing framework and better testing support when running in test mode. - Implement Servlet 3.0 support. - HTML 5 and Web Sockets support and integration with Kaazing's Web Sockets server. Also, sensing which browser is making the request and performing optimizations based on that browser's characteristics (specifically, Chrome and Firefox 3.1 support) We will have bug-fix releases of 1.0 along the way and we'll have a release off the 1.0 branch when Scala 2.8 is released. Feedback is welcome in the next 3 days. 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 Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: MappedDateTime - Do we have a Date? Or is it a timestamp?
Thanks Jorge! We just started using JodaTime and it's definitely everything we wanted from a Time API. Good Find!!! On Tue, Mar 31, 2009 at 8:31 PM, Kris Nuttycombe kris.nuttyco...@gmail.comwrote: I'm also using joda-time, and very pleased with it. In fact, I use it in my Lift project - via JPA with the provided Hibernate extensions for mapping of DateTime, Period, etc. Kris On Tue, Mar 31, 2009 at 1:54 PM, TylerWeir tyler.w...@gmail.com wrote: For an internal project I used JodaTime, twas a dream. I have switched to using MappedLong along with Unix time for dates now. ( hooray for ancedotes! ) On Mar 31, 3:21 pm, Jorge Ortiz jorge.or...@gmail.com wrote: I was on IRC trying to help Clemens with this. The name (MappedDateTime), targetSQLType (java.sql.Types.TIMESTAMP), and type (extends MappedField[java.util.Date, _]) of this class suggests millisecond precision (java.sql.Timestamp and java.util.Date have millisecond precision). However, methods jdbcFriendly and real_convertToJDBCFriendly use java.sql.Date, which has only day precision. If the intent is day precision, then calling the class DateTime is probably misleading. If the intent is millisecond precision, then we have a bug. rant Which brings up the larger issue of the brokennes of the Java Date/Time API. Java 7 will hopefully be getting a newer/better one, but for those of us stuck on Java 5/6, Joda Time is much preferable to the native Date/Time API. It more clearly represents foundational concepts like instants (March 31, 2009 at 12:15.000pm UTC), partials (March 3 or 7:15pm), intervals (the space between two instants), durations (1000 milliseconds), periods (1 month), and chronologies (calendar systems). It's also completely immutable (oh, you didn't know java.util.Calendar isn't thread-safe? you're lucky to have never had to track down that bug). /rant Sigh... it's probably too big of a breaking change to rip out Java Date/Time from Mapper and Helpers and replace it with Joda Time, but one can dream... --j On Tue, Mar 31, 2009 at 11:58 AM, Clemens Oertel clemens.oer...@gmail.comwrote: While trying to figure out why my MappedDateTime fields get stored in the DB with all the time info set to 0, I noticed the following: MappedDateTime (v. 1.0) claims to be a TimeStamp: def targetSQLType = Types.TIMESTAMP. However, it uses java.sql.Date for its JDBC- friendly converted version, not java.sql.TimeStamp. If I read the java.sql.Date documentation correctly, java.sql.Date does set all time information to 0, since the SQL DATE type only stores dates, by no times. Any comment whether this might have something to do with me losing my time would be appreciated. Best, Clemens --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Lift AJAX and IE6
I've only ever entered debug mode with Visual Studio installed. Unfortunately I'm only supporting IE7 on my work machine so I can't offer any other help :( - Josh On Wed, Apr 1, 2009 at 5:50 PM, Charles F. Munat c...@munat.com wrote: Hmm. Yeah, I thought it was used for GC. That's why I asked. When I get back to the Windows machine, I'll check. But IE6 doesn't make it easy. It gives me a line number and a character number, and then asks if I want to keep running scripts on the page. I'm not sure how to get into debug mode (or even if it's possible). I'm using Apache 2.0 to proxy to a single instance of Jetty 6 running the Lift app. (Multiple Lift apps in multiple Jetty instances.) More shortly... Chas. David Pollak wrote: On Wed, Apr 1, 2009 at 1:25 PM, Charles F. Munat c...@munat.com mailto:c...@munat.com wrote: I just got around to testing a couple of my Lift sites on IE6 and the results are depressing. One problem is that there is a recurrent JavaScript error. I presume this is coming from the Lift AJAX script since it pops up like clockwork. Does anyone know anything about this? Also, is the Lift AJAX script necessary for anything other than Comet? If I have a site that's using no AJAX or Comet, can I just turn this off? If so, how? No... it's also used for Garbage Collection. :-( What's the JS error? What is your server stack (e.g., Apache/Tomcat, NGinx/Jetty, etc.) Thanks! Chas. -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: scala:console and then boot call hangs
Are you on windows? I believe we haven't fixed mvn scala:console for windows yet. DavidB will be able to give you a better estimate of when this will be fixed, or what the exact cause may be. -Josh On Sun, Mar 29, 2009 at 4:30 PM, bradford fingerm...@gmail.com wrote: I feel like I'm spamming the mailing list with all of my questions. I apologize if they are too many. It would be nice to see more people in IRC since these messages are moderated and take a while to post. mvn scala:compile scala new net.liftweb.Boot().boot hangs until I kill it (but, mvn jetty:run always works) Any ideas why? Thanks, Bradford --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Welcome Jonas Bonér to the Lift committer s
I think AspectJ compiler currently pukes on scala classes anyway (or at least it did when Miles set up aspectj as a workaround the Eclipse JDT). So... no dice for AspectJ + Scala without using a Java glue class. On Mon, Mar 30, 2009 at 3:12 PM, Lee Mighdoll leemighd...@gmail.com wrote: Certainly, maintaining an aspect compiler in the project would be hassle. Probably not worth debating AOP unless there's a case that really calls for it. My guess is that most uses of aspects will eventually get rolled into scala compiler plugins, anyway, but that aspectJ could be an interim strategy if there's a use case. Lee On Mon, Mar 30, 2009 at 11:53 AM, David Pollak feeder.of.the.be...@gmail.com wrote: On Mon, Mar 30, 2009 at 11:26 AM, Lee Mighdoll leemighd...@gmail.comwrote: Welcome Jonas! I'd been thinking that some judicious use of aspectJ might be a nice fit for lift. Rumor has it you know something about aspects... AspectJ over my dead body. :-) I think AOP is a dangerous and generally very bad thing to do (sorry Jonas). I have not found an application for it in Scala and would need a lot of convincing to include it with anything Lift-related. Sorry for the wicked negative vibe against AOP... but it's one of my hard-core things. Lee On Mon, Mar 30, 2009 at 11:15 AM, marius d. marius.dan...@gmail.comwrote: Welcome Jonas ! On Mar 30, 7:52 pm, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, Please join me in welcoming Jonas as a Lift committer. I had the pleasure of meeting Jonas as QCon in London this month. Jonas, Tim, and I went out a grabbed a few pints and chatted. I think Jonas has a lot to contribute to Lift. So, please join me in welcoming him! Thanks, David -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Git some:http://github.com/dpp -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Welcome Jonas Bonér to the Lift committers
On Mar 30, 2009, at 6:25 PM, Charles F. Munat c...@munat.com wrote: I'd have to second David on this. If it ain't broke... Keep coding until it is? Although the standard use case in java for aspects is not so much needed in scala, I wouldn't throw it out completely. It's another tool that could be useful in the right circumstances, like the C language. David Pollak wrote: On Mon, Mar 30, 2009 at 11:26 AM, Lee Mighdoll leemighd...@gmail.com mailto:leemighd...@gmail.com wrote: Welcome Jonas! I'd been thinking that some judicious use of aspectJ might be a nice fit for lift. Rumor has it you know something about aspects... AspectJ over my dead body. :-) I think AOP is a dangerous and generally very bad thing to do (sorry Jonas). I have not found an application for it in Scala and would need a lot of convincing to include it with anything Lift-related. Sorry for the wicked negative vibe against AOP... but it's one of my hard-core things. Lee On Mon, Mar 30, 2009 at 11:15 AM, marius d. marius.dan...@gmail.com mailto:marius.dan...@gmail.com wrote: Welcome Jonas ! On Mar 30, 7:52 pm, David Pollak feeder.of.the.be...@gmail.com mailto:feeder.of.the.be...@gmail.com wrote: Folks, Please join me in welcoming Jonas as a Lift committer. I had the pleasure of meeting Jonas as QCon in London this month. Jonas, Tim, and I went out a grabbed a few pints and chatted. I think Jonas has a lot to contribute to Lift. So, please join me in welcoming him! Thanks, David -- Lift, the simply functional web frameworkhttp://liftweb.net http://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 http://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Git some:http://github.com/dpp -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: in a heap o' trouble
http://scala-tools.org/mvnsites/maven-scala-plugin/plugin-info.html
Click on any particular goal and you'll get a list of its configuration
options. A union of all those is the complete list for the plugin. Those
are generated from the annotations in the source code, so they should be
*way* more up-to-date than what's in my head (although, perhaps not
DavidB's). :)
-Josh
On Fri, Mar 20, 2009 at 6:16 PM, David Pollak feeder.of.the.be...@gmail.com
wrote:
On Fri, Mar 20, 2009 at 3:13 PM, Charles F. Munat c...@munat.com wrote:
AH HA! I thought so. In fact, I was busy searching Google for exactly
this.
Thank you very much. I can get down off the roof now.
Is there anywhere online where all these Maven POM settings are
documented? I've been to the Maven site, but can't find it.
In DavidB and Josh's heads. :-(
Chas.
David Pollak wrote:
In your pom.xml file:
plugin
groupIdorg.scala-tools/groupId
artifactIdmaven-scala-plugin/artifactId
version2.9/version
executions
execution
goals
goalcompile/goal
goaltestCompile/goal
/goals
/execution
/executions
configuration
jvmArgs
jvmArg-Xmx1024m/jvmArg
/jvmArgs
scalaVersion${scala.version}/scalaVersion
/configuration
/plugin
plugin
groupIdorg.scala-tools/groupId
artifactIdmaven-scala-plugin/artifactId
configuration
jvmArgs
jvmArg-Xmx1024m/jvmArg
/jvmArgs
scalaVersion${scala.version}/scalaVersion
/configuration
/plugin
Scalac doesn't obey MAVEN_OPTS
On Fri, Mar 20, 2009 at 2:35 PM, Charles F. Munat c...@munat.com
mailto:c...@munat.com wrote:
Suddenly, my Lift app won't compile. Maven complains that it is out
of
heap space. I have set Maven with MAVEN_OPTS=-Xmx768M -- which
should be
doubling the heap space. No effect.
I removed all the code I added since the last time it compiled. No
effect.
What could possibly be causing this? I'm completely at a loss...
Chas.
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: in a heap o' trouble
I just noticed that some of those documented configuration options aren't
very enlightening. I may take a pass at providing more in-depth
descriptions so one isn't left to guess what things mean. If anyone want to
help de-mavenize the descriptions, feel free to contribute! (The goals
documentation is automatically generated from the javadoc comments on the
various injected fields for a given mojo).
- Josh
On Mon, Mar 23, 2009 at 3:38 AM, Josh Suereth joshua.suer...@gmail.comwrote:
http://scala-tools.org/mvnsites/maven-scala-plugin/plugin-info.html
Click on any particular goal and you'll get a list of its configuration
options. A union of all those is the complete list for the plugin. Those
are generated from the annotations in the source code, so they should be
*way* more up-to-date than what's in my head (although, perhaps not
DavidB's). :)
-Josh
On Fri, Mar 20, 2009 at 6:16 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
On Fri, Mar 20, 2009 at 3:13 PM, Charles F. Munat c...@munat.com wrote:
AH HA! I thought so. In fact, I was busy searching Google for exactly
this.
Thank you very much. I can get down off the roof now.
Is there anywhere online where all these Maven POM settings are
documented? I've been to the Maven site, but can't find it.
In DavidB and Josh's heads. :-(
Chas.
David Pollak wrote:
In your pom.xml file:
plugin
groupIdorg.scala-tools/groupId
artifactIdmaven-scala-plugin/artifactId
version2.9/version
executions
execution
goals
goalcompile/goal
goaltestCompile/goal
/goals
/execution
/executions
configuration
jvmArgs
jvmArg-Xmx1024m/jvmArg
/jvmArgs
scalaVersion${scala.version}/scalaVersion
/configuration
/plugin
plugin
groupIdorg.scala-tools/groupId
artifactIdmaven-scala-plugin/artifactId
configuration
jvmArgs
jvmArg-Xmx1024m/jvmArg
/jvmArgs
scalaVersion${scala.version}/scalaVersion
/configuration
/plugin
Scalac doesn't obey MAVEN_OPTS
On Fri, Mar 20, 2009 at 2:35 PM, Charles F. Munat c...@munat.com
mailto:c...@munat.com wrote:
Suddenly, my Lift app won't compile. Maven complains that it is out
of
heap space. I have set Maven with MAVEN_OPTS=-Xmx768M -- which
should be
doubling the heap space. No effect.
I removed all the code I added since the last time it compiled. No
effect.
What could possibly be causing this? I'm completely at a loss...
Chas.
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Upgrading from lift 0.8 to lift 1.0
Hi lift community! I'm ugprading a lift application that I was not the
author of and am trying to figure out what changes I need to make. here's
my current state of brokenness (all in boot.scala)-
S.addAround(User.requestLoans)
LiftRules.rewrite.prepend {
case Req(login :: Nil,_,_) =
Login.login //This is the only Req
pattern match I've fixed so far, I still don't know what happened to the
Login object
case Req(_, ParsePath(logout :: Nil, _, _), _, _) = Login.logout
case Req(r, _, _, _) if r.uri.endsWith(/home/index) =
ignore = Full(RedirectResponse(/))
case Req(r, ParsePath(attendees.txt :: Nil, _, _), _, _) if
User.superUser_? =
ignore = Full(User.attendees)
case Req(r, ParsePath(redirect_to :: edit :: which :: page :: _,
_, _), _, _) =
ignore = Full(RedirectResponse(/+which+/edit/+page))
case Req(r, ParsePath(go :: home :: _, _, _), _, _) =
ignore = Full(RedirectResponse(/))
}
The application appears to not be using the menu system (but I haven't dug
in too thoroughly). My question is, where did all this Login/User stuff
go? I'm using the MetaMegaProtoUser magic, so I'm a bit out of my element
here.
Anyway, if someone could help me out with what happened User.requestLoans
and the Login object, I would highly appreciate!
-Josh
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] AJAX Experience Call for papers!
I really think a general overview of lift architecture and perhaps a few shiny app screenshots/demos would really be a great thing to see at this conference! http://ajaxian.com/archives/share-your-knowledge-at-the-ajax-experience-2 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Eclipse + Lift question: WebAppContext is not a member of _root_.org.mortbay.jetty.webapp
All the eclipse maven plugins are actually using embedded maven 2.1 pre-releases. M2e is unique in that you can specify what maven version to use. How are you doing eclipse dependency management? Q4e, m2e or maven- eclipse-plugin? On Mar 5, 2009, at 4:57 PM, Amy de Buitléir mhwom...@gmail.com wrote: I'm following the example in chapter 2 of the Starting With Lift book, and I'm trying to use Eclipse. Everything compiles fine outside of Eclipse, but within Eclipse I get these compilation errors on RunWebApp.scala (which I have not modified). WebAppContext is not a member of _root_.org.mortbay.jetty.webapp not found: type WebAppContext I did some Googling, and I believe this indicates that I'm using the wrong version of Jetty. I checked Java Build Path Libraries Maven Dependencies in Eclipse, and sure enough, it's picking up jetty-7.0.0.pre5.jar instead of Jetty 6. However, I'm using the exact same pom.xml both inside and outside Eclipse, so I don't understand why Eclipse is using Jetty 7. (I created the Eclipse project by importing the pom.xml.) I can manually change the library in Eclipse, but I don't know if that would be overwritten the next time it reads pom.xml. Is there a right way to fix this? I suppose I should really ask this on the Eclipse Maven Integration forum, but I'm guessing that others on this forum have encountered this problem and would know how to solve it. Thank you in advance, Amy de Buitléir --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Tracking the latest with maven.. but not too quickly
David, great suggestion! I recommend either Archiva http://archiva.apache.org/ or Nexushttp://nexus.sonatype.org/for corporate or 'intranet' repositories. If you're using maven for any corporation and you don't have a corporate repository, you're certainly missing out! We're using Archiva at my workplace (with a slow/shared internet connection), and it has drastically improved build times. We've also manually edited our project poms so they only use the corporate repository (not central). This has the benefit of ensuring a company copy of all artifacts used from central (or other remote repositories) and drammatically decreasing internet traffic during builds. I also recommend backing up your Archiva/Nexus instance as if it were your VCS/SCM system. Just remember to set up automatic purging of SNAPSHOT artifacts when new snapshots become available. And if you're doing things locally and you have a spare box, throw a VM up that can run a repository. It's definitely worth it for any long-running project. -Josh On Tue, Mar 3, 2009 at 11:56 PM, David Pollak feeder.of.the.be...@gmail.com wrote: Lee, It's also possible for your to host your own Maven repository and just publish the versions of Lift you want up to your repository. If your repository comes first in your Maven config, it will be consulted before other Maven repositories. Thanks, David On Tue, Mar 3, 2009 at 5:34 PM, Lee Mighdoll leemighd...@gmail.comwrote: I've a local copy of the lift sources that I'd like to build and debug my app against. So I currently reference the 1.1-SNAPSHOT artifact in my application's pom.xml. But maven seems to pull stuff down from the net more often than I'd like. I'd like my snapshot not to change until I git pull the latest lift version manually. What's the best way to do this? I was thinking perhaps one way would be to locally modify the version in all the lift pom.xml files to 1.1-SNAPSHOT.local. Or maybe there's some configuration option? Or perhaps I should setup a local maven repository? -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Tracking the latest with maven.. but not too quickly
Make sure you're using maven 2.0.10 if you plan on working on 1.1-SNAPSHOT (or any other SNAPSHOT dependency). Otherwise -o is broken. On Tue, Mar 3, 2009 at 8:42 PM, Jorge Ortiz jorge.or...@gmail.com wrote: You can run Maven in offline mode with the -o flag. That should stop it from fetching anything. --j On Tue, Mar 3, 2009 at 5:34 PM, Lee Mighdoll leemighd...@gmail.comwrote: I've a local copy of the lift sources that I'd like to build and debug my app against. So I currently reference the 1.1-SNAPSHOT artifact in my application's pom.xml. But maven seems to pull stuff down from the net more often than I'd like. I'd like my snapshot not to change until I git pull the latest lift version manually. What's the best way to do this? I was thinking perhaps one way would be to locally modify the version in all the lift pom.xml files to 1.1-SNAPSHOT.local. Or maybe there's some configuration option? Or perhaps I should setup a local maven repository? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: eclipse plugin and scala shell
The eclipse plugin does mostly support the interactive shell, but the integration isn't that great right now (I'm allowed to crtique it, as I added it). I'm working on upgrading for better functionality. In the meantime, if you're not using windows, you should be able to run the interpreter via right clicking on a project in the Package explorer and selecting Scala - Create interpreter in XYZ On Sun, Mar 1, 2009 at 6:30 PM, Jon Hancock shellsha...@gmail.com wrote: Does the eclipse plugin support the scala interactive shell? I would like to be able to develop my lift app in eclipse and interactively test model and controller behavior with the shell. How do others do this with lift?? thanks, Jon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: eclipse plugin and scala shell
Depends on when I get enough free time to work out the remaining bugs! I try to keep my work public and up-to-date here: http://github.com/jsuereth/scala-plugin/tree/master See the interpreter-dev branch. I believe the current interpreter only works on ubuntu, but that branch should fix for all platforms (assuming you have the right run configuration setup) On Sun, Mar 1, 2009 at 6:49 PM, Jon Hancock shellsha...@gmail.com wrote: I see what you mean. Just tried it and the shell cranks up but doesn't seem to work at all. I'm on OS X 10.5.6 typing :help doesn't work typing 1 + 2 also doesn't do anything. any idea when you might have a new release? Jon On Mar 1, 5:36 pm, Josh Suereth joshua.suer...@gmail.com wrote: The eclipse plugin does mostly support the interactive shell, but the integration isn't that great right now (I'm allowed to crtique it, as I added it). I'm working on upgrading for better functionality. In the meantime, if you're not using windows, you should be able to run the interpreter via right clicking on a project in the Package explorer and selecting Scala - Create interpreter in XYZ On Sun, Mar 1, 2009 at 6:30 PM, Jon Hancock shellsha...@gmail.com wrote: Does the eclipse plugin support the scala interactive shell? I would like to be able to develop my lift app in eclipse and interactively test model and controller behavior with the shell. How do others do this with lift?? thanks, Jon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: eclipse plugin and scala shell
Not too bad (it's more how much memory should you give), If I have some time to test on windows, the new patch may work. On Sun, Mar 1, 2009 at 7:33 PM, Miles Sabin mi...@milessabin.com wrote: On Mon, Mar 2, 2009 at 12:27 AM, Josh Suereth joshua.suer...@gmail.com wrote: See the interpreter-dev branch. I believe the current interpreter only works on ubuntu, but that branch should fix for all platforms (assuming you have the right run configuration setup) I don't think it's distro-specific ;-) Works fine for me on Fedora ... How difficult would it be to just fix the OOMs on Mac OS and Windows? Cheers, Miles -- Miles Sabin tel:+44 (0)1273 720 779 mobile: +44 (0)7813 944 528 skype: milessabin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: OS X lift installer
On Fri, Feb 27, 2009 at 5:14 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Fri, Feb 27, 2009 at 2:03 PM, Jon Hancock shellsha...@gmail.comwrote: thanks. based on your above mention that maven is web aware and some comment I read from David Pollak that his demo didn't go so well when he lacked an internet connection, is it the case that I have to always have a working internet connect to use maven/lift? When Maven works the way it is supposed to, you do not need to be online when you use it, but you do have to be online when you do an initial build so that all the JARs can be downloaded. I have had issues recently with the Maven-Scala plugin, but that is a defect, not the correct behavior. Please do tell! (I'd would like to add the issues to our integration/regression tests) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: OS X lift installer
I feel obligated to note that this was indeed an issue with maven itself. I believe it's fixed in the most recent release of Maven (2.0.10) [see herehttp://maven.apache.org/release-notes.html]. Please upgrade and let me know if it continues so I can open many JIRAs! -Josh On Sat, Feb 28, 2009 at 11:14 AM, David Pollak feeder.of.the.be...@gmail.com wrote: On Sat, Feb 28, 2009 at 2:19 AM, Josh Suereth joshua.suer...@gmail.comwrote: On Fri, Feb 27, 2009 at 5:14 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Fri, Feb 27, 2009 at 2:03 PM, Jon Hancock shellsha...@gmail.comwrote: thanks. based on your above mention that maven is web aware and some comment I read from David Pollak that his demo didn't go so well when he lacked an internet connection, is it the case that I have to always have a working internet connect to use maven/lift? When Maven works the way it is supposed to, you do not need to be online when you use it, but you do have to be online when you do an initial build so that all the JARs can be downloaded. I have had issues recently with the Maven-Scala plugin, but that is a defect, not the correct behavior. Please do tell! (I'd would like to add the issues to our integration/regression tests) I have had repeated failures trying to run the latest plugin in -o (offline) mode. The plugin seems to ignore the parameter and try to go out to the internet to get resources and then it complains that the sites are not available and blacklists them... then the mvn -o jetty:run fails. It was a complete (okay, maybe a semi) disaster then I tried to give a demo @ SalesForce last week. I'm hoping to get this issue resolved before 3/8 when I get to spend 12 hours on a flight from SF to London and would like some of those hours to be productive. -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: maven scala plugin
Hey, part of this sounds like a netbeans issue, the other part could be a maven issue. Mind sending me (not the list) a zip file of your failing project so I can take a look? Thanks! -Josh On Wed, Feb 18, 2009 at 10:34 PM, Oliver ola...@gmail.com wrote: Hi, I know its not exactly a lift specific problem, but I create a lift project using mvn archetype:generate -U -DarchetypeGroupId=net.liftweb -DarchetypeArtifactId=lift-archetype-blank -DarchetypeVersion=0.10 -DremoteRepositories=http://scala-tools.org/repo-releases -DgroupId=demo.helloworldhttp://scala-tools.org/repo-releases%0A-DgroupId=demo.helloworld-DartifactId=helloworld -Dversion=1.0-SNAPSHOT This creates a pom.xml with 2.7.3 as the version of Scala - Everything appears fine. I add a variable that uses an Enumeration and use the new valueOf method. When I open the project in netbeans, it says the valueOf method doesnt exist, but when I do a mvn clean build, everything is happy When I extend an Enumeration and define a valueOf method (without overriding it) maven fails at the test stage, saying I need to override When I override the valueOf method, maven fails at the compilation stage, saying valueOf is not defined in the parent Any ideas what the maven scala plugin is doing? cheers Oliver --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
Re: [maven-and-scala] [Lift] Build problems...
If it's a command-line length limitation the new plugin has a configuration parameter you can set called fork which is by default true. plugins ... plugin grouporg.scala-tools/group artifactIdmaven-scala-plugin/artifactId configuration forkfalse/fork /configuration /plugin Hope that helps! Anyway, as the command line itself is giving a segmentation fault, I'll look into what could be causing that on a mac, but It appears rather strange (especially since the plugin's integration tests are passing). -Josh On Tue, Feb 17, 2009 at 3:34 AM, David Bernard david.bernard...@gmail.comwrote: Hi, I don't know Mac, there is a command line length limitation (as windows) and is it possible that the shell block the execution and return exit code = 139 (without message) ? which version of java do you have ? Sorry to not be able to help you more :( /davidB On 17/02/2009, at 3:35 PM, Josh Suereth wrote: Hm All the integration tests pass, perhaps you should try using the new maven-scala plugin (run mvn install on the maven-scala- plugin directory). You do *not* want to clear your .m2 directory after doing so. Then see if the new plugin fixes whatever issue is causing lift to break. The other thing is try the scala command- line directly and see if you get a useful error meessage. Once again, sorry I could not be more help! Same result with the built plugin... hmmm. Not a problem on the help side of things! lift applications build rather nicely. Just can't build lift itself :( Marc --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: [ANN] some jar on maven central repository
Great News! and Great work getting this all set up! On Fri, Feb 13, 2009 at 3:30 AM, David Bernard david.bernard...@gmail.comwrote: Hi, just to inform you that the following groupId are sync (24H delay) from http://scala-tools.org/repo-releases to maven central repository : * org.scala-lang * org.scala-tools * net.liftweb So you no more need to include the following code into your pom.xml (except if you use lib from other groupId like specs, scalachecks, scalaz) repositories repository idscala-tools.org/id nameScala-Tools Maven2 Repository/name urlhttp://scala-tools.org/repo-releases/url snapshots enabledfalse/enabled /snapshots /repository /repositories pluginRepositories pluginRepository idscala-tools.org/id nameScala-Tools Maven2 Repository/name urlhttp://scala-tools.org/repo-releases/url /pluginRepository /pluginRepositories The archetypes will be updated later. /davidB --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Lift Installers
Actually, I believe it's more due to the maven archetype plugin not knowing about the most recent lift. When we start mirroring the scala-tools repository on central, this should be fixed. On Sun, Jan 18, 2009 at 3:54 PM, Tim Perrett he...@timperrett.com wrote: Matt, Well spotted - this must be something to do with what's hosted on scala-tools. I'll drop David B a note about this... Tim On Jan 18, 6:02 pm, Matt Harrington mbh.li...@gmail.com wrote: Update: mvn archetype:generate gets you Lift 0.8, but mvn archetype:generate -DarchetypeCatalog=http://scala-tools.org/; gets you 0.9. Matt On Sun, Jan 18, 2009 at 9:50 AM, Matt Harrington mbh.li...@gmail.com wrote: An updated catalog would certainly be helpful. I believe it still has Lift 0.8, and it's broken. Matt On Fri, Jan 16, 2009 at 3:37 PM, Tim Perrett he...@timperrett.com wrote: Possibly - but this is what I mean about using the auto-generated, one liner with maven rather than the -D hell we have... I'll tap up David B and see if he knows how far that system can be extended (i.e. to add another stage to say if you want snapshot, or release version of lift) Thoughts? Cheers Tim On Jan 16, 9:46 pm, Matt Harrington mbh.li...@gmail.com wrote: I like the idea of sticking with plain maven. What do you think about lifting, no pun intended, the maven syntax generator from Wicket's quickstart page? http://wicket.apache.org/quickstart.html Matt On Fri, Jan 16, 2009 at 10:54 AM, Tim Perrett he...@timperrett.com wrote: People, I'm going to finish the lift installers this weekend and I just got to thinking about writing some shell scripts to include as well. However, I then got to think about previous conversations had on this list and im wondering if we even need shell scripts to wrap the maven commands? I mean, as lift nears 1.0, the API is solidifying, and the need for users to track the snapshots will become less and less unless someone has a direct need to (or want to), or they are a committer. In this way, I see: mvn archetype:generate -DarchetypeCatalog=http://scala-tools.org/ becomming the main way to get started with lift? The installers would then just need to provide a well setup environment etc (which I have covered off already). It just strikes me that I don't want to start re- inventing the wheel by creating generation scripts etc etc when maven can handle stuff like project templates. Thoughts? 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 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: scalac java compilation
Use an older version of the maven plugin (like 2.8) *or* wait till I have the free time to make the option. -Josh On Tue, Jan 13, 2009 at 2:34 PM, Meredith Gregory lgreg.mered...@gmail.comwrote: Scalads and lasses, i believe i've hit a bug in the scalac java compilation. i'm not 100% certain. To verify i need a way to tell scalac *not* to compile java files in the mvn build process for a lift app. i will briefly describe a portion of my build process. i'm building several DSLs. i use BNFC to rapid prototype the grammars the build the java parsers. Then i use the parsers in scala+lift applications. The reason i mention this is because BNFC squirts out a makefile to build the java. So, i've got a standalone build using gnu make just for the java parser. i can compare this to mvn build. The parser is included in the model part of a lift app and built using the mvn build system. i just made a change to a parser and verified it builds and works as a java parser. Then i essentially copied the working code into the lift app. Note, when i build my app with mvn i've got the javac compilation line configured to show the command line. So, when i hit the following error, i'm pretty sure this is coming from the scalac compiler. Since the file in question compiles just fine, i'm fairly certain this is a bug in scalac. i can make all the code available, but i really, really don't have the cycles just now to reduce this to a smallest test case. i don't have to be blocked it i can just stop scalac from compiling the java files. Best wishes, --greg -- L.G. Meredith Managing Partner Biosimilarity LLC 806 55th St NE Seattle, WA 98105 +1 206.650.3740 http://biosimilarity.blogspot.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: scalac java compilation
Yes, see the inline response
On Tue, Jan 13, 2009 at 2:55 PM, Meredith Gregory
lgreg.mered...@gmail.comwrote:
Josh,
Thanks for the response. Just to be clear, is the plugin in question the
one listed below? What is the configuration that gets me the 2.8 version?
Best wishes,
--greg
plugin
groupIdorg.scala-tools/groupId
artifactIdmaven-scala-plugin/artifactId
version2.8/version
executions
execution
goals
goalcompile/goal
goaltestCompile/goal
/goals
/execution
/executions
configuration
scalaVersion${scala.version}/scalaVersion
/configuration
/plugin
On Tue, Jan 13, 2009 at 11:42 AM, Josh Suereth
joshua.suer...@gmail.comwrote:
Use an older version of the maven plugin (like 2.8) *or* wait till I have
the free time to make the option.
-Josh
On Tue, Jan 13, 2009 at 2:34 PM, Meredith Gregory
lgreg.mered...@gmail.com wrote:
Scalads and lasses,
i believe i've hit a bug in the scalac java compilation. i'm not 100%
certain. To verify i need a way to tell scalac *not* to compile java files
in the mvn build process for a lift app.
i will briefly describe a portion of my build process. i'm building
several DSLs. i use BNFC to rapid prototype the grammars the build the java
parsers. Then i use the parsers in scala+lift applications. The reason i
mention this is because BNFC squirts out a makefile to build the java. So,
i've got a standalone build using gnu make just for the java parser. i can
compare this to mvn build. The parser is included in the model part of a
lift app and built using the mvn build system.
i just made a change to a parser and verified it builds and works as a
java parser. Then i essentially copied the working code into the lift app.
Note, when i build my app with mvn i've got the javac compilation line
configured to show the command line. So, when i hit the following error, i'm
pretty sure this is coming from the scalac compiler. Since the file in
question compiles just fine, i'm fairly certain this is a bug in scalac.
i can make all the code available, but i really, really don't have the
cycles just now to reduce this to a smallest test case. i don't have to be
blocked it i can just stop scalac from compiling the java files.
Best wishes,
--greg
--
L.G. Meredith
Managing Partner
Biosimilarity LLC
806 55th St NE
Seattle, WA 98105
+1 206.650.3740
http://biosimilarity.blogspot.com
--
L.G. Meredith
Managing Partner
Biosimilarity LLC
806 55th St NE
Seattle, WA 98105
+1 206.650.3740
http://biosimilarity.blogspot.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Swampland
If you keep a good plugin system, that is very helpful! I'm excited to see what this looks like. Here's my list of bug tracking neatos * Easy Query/filter with dynamic fields on bugs - Some bug tracking tools really don't do this well(Gforge...) * Easy creation of Change list or new features for a release. * Custom dashboard when logging in that lets me see pertinent information for my development on a project. - I tend to use Eclipse Mylyn to make up for lacking bug tracking websites * Easy/Fast to enter/edit bugs - We used GForge for a few projects I had, and the bug tracking was ok, except it took FOREVER to create/edit/delete bugs. Part of this was that you couldn't multi-select/multi-edit. If you need beta testers (when the time is ready), I'm willing to use it to track bugs for a few of my open source projects (once I find a host). Also, I've recently heard of the GNU Affero license. I head it's GPL for the web. What's the main difference between this and vanilla GPL? - Josh --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Can or Box or something else
Do any conversions exist to treat a Box[_] as an
Either[Option[_],Exception] or as an Option[_]? Are there any helper
functions that lift could benefit from by having these?
Also, anytime I see the line I leave this as an excercise to the
reader I feel like I'm being lectured :)
On Jan 6, 2009, at 7:38 PM, Jorge Ortiz jorge.or...@gmail.com wrote:
For most people, is does not always and exclusively mean bi-
implication. You are free to think this way, if you choose, but
please don't impose your Language Police on us.
--j
On Tue, Jan 6, 2009 at 5:49 PM, Tony Morris tonymor...@gmail.com
wrote:
When talking about data types is means is congruent to or is
isomorphic to. You are not free to use is arbitrarily, since if you
are then Can is anything I want it to be.
Since equivalence can be broken into an implication both ways e.g. A
- B and B - A then it is quite easy to test if Can is an Option.
def f[A](o: Option[A]): Can[A] // this should be total and bijective
def g[A](c: Can[A]): Option[A] // this should be total and bijective
The use of = in function signatures means logical implication. Does
Can imply Option? Yes (you can complete the g function). Does Option
imply Can? No (you cannot complete the f function). Therefore, Can is
not an Option. It was not even close (lack of totality in this test is
catastrophic).
If you want to try to save this notion of Well Can is a something,
then I have already pointed out a suggestion. Try to think of others,
but do not say that Can is an Option - it is not, not even close. Poor
Oliver was all confuzzled when he popped this one to me the other day.
--
Tony Morris
http://tmorris.net/
S, K and I ought to be enough for anybody.
Jorge Ortiz wrote:
It depends on what the meaning of is is.
If Option were not sealed, Can could be implemented as an
Option... by adding Failure and Empty as subclasses of None. In
this (OO) sense, a Can is an option.
In the algebraic sense, then you're probably right that a Can is
not an Option.
--j
On Tue, Jan 6, 2009 at 5:23 PM, Tony Morris tonymor...@gmail.com
mailto:tonymor...@gmail.com wrote:
No this is a mistake. Can is not an Option. Indeed it is (almost)
impossible to write Can using Option (if you are familiar with
Peano Arithmetic you will understand the need to qualify with
almost). There is an arrow from forall A. Can[A] to Option[A] but
not from forall A. Option[A] to Can[A] (easily) - try it for
yourself. To suggest that Can is an Option (or an Option with more
features or an Either) is a mistake of misintegration (Peikoff
DIM Hypothesis). Indeed the Can algebra has nothing to do with
Option (except for the aforementioned function). There is no
isomorphism between Can and Option - they are not the same, not
even close.
Here is a bit of code for fun. Note the bijective function using
Either alone:
sealed trait T[+A] { val e: Either[(String, T[Throwable],
List[(String, Throwable)], Either[A, Unit]]
// bijection to e val c: Can[A] = e match { case Left(m, e, c) =
Failure(m, e, // Can makes the mistake of using a data constructor
as a type. // Unfortunately Scala permits this. c map toFailure)
case Right(e) = e match { case Left(a) = Full(a) case Right(_) =
Empty } } }
object T { // construct with Either or Can }
-- Tony Morris http://tmorris.net/
S, K and I ought to be enough for anybody.
David Pollak wrote:
It's an Option.
It contains a value or it doesn't. In the case that it does not
contain a value, it may contain out of band information. This is
not any different from None which contains information. It
contains the information that it lacks information.
Sure, you can write Option[T] as Either[T, Nothing], but the
value of only having on type is lost.
On Tue, Jan 6, 2009 at 2:59 PM, Tony Morris
tonymor...@gmail.com mailto:tonymor...@gmail.com
mailto:tonymor...@gmail.com mailto:tonymor...@gmail.com
wrote:
Right, that's what Oliver said and I was reinforcing it with
deductive reasoning. It is also not Option. It is something else
altogether. Nevertheless, an isomorphism can easily be written
with
Either alone (ignoring bottoms). So in some loose sense it is an
Either.
-- Tony Morris http://tmorris.net/
S, K and I ought to be enough for anybody.
David Pollak wrote:
Tony,
Can (now Box) is not an Either.
David
On Tue, Jan 6, 2009 at 2:37 PM, Tony Morris
tonymor...@gmail.com mailto:tonymor...@gmail.com
mailto:tonymor...@gmail.com mailto:tonymor...@gmail.com
mailto:tonymor...@gmail.com mailto:tonymor...@gmail.com
mailto:tonymor...@gmail.com mailto:tonymor...@gmail.com
wrote:
Can is not an Option and to call it so in any way is an error
of misintegration. Indeed it would be an error to replace
Option
with
Can - they are completely different algebras. Either is kinded
* - * - * so cannot possible
[Lift] Re: box can boogie... working
I can at least answer your maven questions: Maven requires you (in version 2.x) to hardcode the version of a dependency you're using. This means if lift switches versions (from 0.9 - 0.10-SNAPSHOT or 0.10-SNAPSHOT - 0.10) that you have to manually update your pom first. (This is migrating to a different style in Maven 3.x) If you're just trying to pull the latest snapshot *always* do as already suggested and use the -U option. Otherwise it updates once in a while. It could be possible that some of your lift artifacts were updated without *all* of them being updated, but I've never actually seen that happen. On Mon, Dec 29, 2008 at 7:03 PM, Charles F. Munat c...@munat.com wrote: Well, I got it working, but it required deleting and re-cloning the liftweb directory, and deleting liftweb from the .m2 repository. As I suspected, the code is correct on the server. So what am I doing wrong here? Why is it that git won't update the local code properly? Why do I have to keep deleting things from the Maven repository? Shouldn't the -u option update things? Is all this stuff broken or am I missing some important concept? I assume there is some sort of flag I need to add to get everything to update properly. I still haven't figured out how to get Maven to download the lift-webkit without me installing it locally. Any git or maven geniuses out there willing to divulge the secret? Chas. Charles F. Munat wrote: When I do a git pull on the lift 0.10-SNAPSHOT (I think), I get an interesting melange of Box and Can that does not compile. Am I doing something wrong, or are there still some references that need to be changed over? I'll keep trying. Chas. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: pom.xml
Chas,
Please send your poms.
Note:
Wiping the maven repo is the CTRL-ALT-DEL windows-style fix for maven. You
can just delete the Lift directory (as long as you get the meta-data poms
associated with it) you should be ok. Once again, this is more of a hack,
than a fix. If you're in a jam, just do it. If not, it's usually better to
figure out why it's bombing so you can not run into the problem again.
Also remember that if youmvn install something it goes into your local
repo. The mvn -U command tells maven to check the remote repositories for
newer versions *than the ones found in your local repository* (i.e. if you
install locally, you will automatically use that version and the -U will not
do anything useful).
One side note, please make sure you're not using ${pom.version} in
dependencies with snapshot pom versions... (see here:
http://jira.codehaus.org/browse/MNG-2796 )
Cheers,
-Josh
On Mon, Dec 29, 2008 at 7:12 PM, Charles F. Munat c...@munat.com wrote:
Is it necessary to wipe the whole repo, or just net/liftweb? It seems a
big pain to keep re-downloading everything every week or so.
Thanks for the help. I ended up downloading a clean copy of lift and
then running mvn install, which installed everything nicely. So now,
will it update itself when I run mvn with the -u flag, or will I need to
reinstall lift manually after each update? Maybe that's the problem...
Is this the way it's supposed to work, or is something a bit broken with
Maven?
Thanks!
Chas.
Derek Chen-Becker wrote:
It should be able to pull lift-webkit from the repos. I'm guessing you
already have, but just as a sanity check did you wipe your maven repo?
Derek
On Mon, Dec 29, 2008 at 3:24 PM, Charles F. Munat c...@munat.com
mailto:c...@munat.com wrote:
I am using the JPA demo as my basis and have tried to change the
included pom.xml from one that inherits from the main lift pom.xml to
a
standalone pom.xml, but I am missing something because I continue to
get
the error below. Can anyone post a copy of a good standalone pom.xml
(or
all three) from a JPA/Lift site? Thanks!
Failed to resolve artifact.
Missing:
--
1) net.liftweb:lift-webkit:jar:0.10-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-webkit -Dversion=0.10-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-webkit -Dversion=0.10-SNAPSHOT -Dpackaging=jar
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
Path to dependency:
1) com.xxx:yyy-app:war:0.10-SNAPSHOT
2) net.liftweb:lift-webkit:jar:0.10-SNAPSHOT
--
1 required artifact is missing.
Chas.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: box can boogie
Chas, One last question... What timezone are you in vs. the timezone of hudson? On Mon, Dec 29, 2008 at 7:47 PM, Tim Perrett he...@timperrett.com wrote: Chas, You say you are trying both local installs, and pulling from the snapshot repo? Can I suggest persisting with a single path at any one time? They are different and conflicting workflows really - unless your modifying the lift codebase to your own ends, Hudson will build the very latest JAR about an hour after the commit, so that should be more that acceptable time wise :-) Blow your .m2 away for now, and then decide on a workflow. A nice clean start! You should find that doing one or the other is a lot more consistant than doing both. Cheers, Tim Sent from my iPhone On 30 Dec 2008, at 00:34, David Pollak feeder.of.the.be...@gmail.com wrote: On Mon, Dec 29, 2008 at 4:14 PM, Charles F. Munat c...@munat.com c...@munat.com wrote: Any ideas what might cause a partial update rather than a full update? Is it because I've only got the webkit in my pom.xml and not the other parts of lift (I'm not using the mapper, e.g.)? It's working fine now, but I'd like to avoid this problem in the future. It seems to crop up with depressing regularity. Still not clear if I'm doing something wrong or if this is just the current state of git/maven/lift. Git and Maven are two very different things and have nothing to do with each other. If you're getting messed up git pulls, that's a really serious issue, but something way beyond this list. You should take any failure Git updates to the GitHub or main Git lists. In terms of Maven, I don't know what to tell you. I run Maven and about once a month or so, I blow away my repositories. Since I've been periodically blowing about .m2, I haven't had a single Maven-related problem. The only thing I can think of is that you should include both the Lift Webkit and Lift Utils in your POM file. They are different packages and perhaps Maven isn't updating them in sync... perhaps Maven is pulling Lift Webkit when you do a -U, but not pulling the Lift Utils package that the WebKit depends on. Thanks. Chas. David Pollak wrote: Sounds like you're getting a partial update. The code is clean on all my machines which means it's clean in GitHub. If you're still having issues, please post up examples of compilation failures. On Mon, Dec 29, 2008 at 3:37 PM, Charles F. Munat c...@munat.com c...@munat.com mailto: c...@munat.comc...@munat.com wrote: When I do a git pull on the lift 0.10-SNAPSHOT (I think), I get an interesting melange of Box and Can that does not compile. Am I doing something wrong, or are there still some references that need to be changed over? I'll keep trying. Chas. -- Lift, the simply functional web framework http://liftweb.net http://liftweb.net Collaborative Task Management http://much4.ushttp://much4.us Follow me: http://twitter.com/dpphttp://twitter.com/dpp Git some: http://github.com/dpphttp://github.com/dpp -- Lift, the simply functional web framework http://liftweb.net http://liftweb.net Collaborative Task Management http://much4.ushttp://much4.us Follow me: http://twitter.com/dpphttp://twitter.com/dpp Git some: http://github.com/dpphttp://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Can or Box or something else
And all my hopes for Can has x are gone...
Perhaps I'll make my own change in my lift app. :
import {Box = Bukkit}
On Sun, Dec 28, 2008 at 10:03 AM, David Pollak
feeder.of.the.be...@gmail.com wrote:
Good points. I'll make the changes today and check up the code. It'll be
massive code breakage... but for a good reason.
On Sun, Dec 28, 2008 at 6:41 AM, Tim Perrett he...@timperrett.com wrote:
I think this debate could go on for some time ;-)
Being pragmatic, we have to look at the impact on the lift code base
and its users. Would a change to Box[MyClass] really improve user
understanding and lower the learning curve to a point where making
such a fundamental change in the lift API would be justified?
This is really the question we should now be asking now.
personal_opinion
Being english, the semantic of Box seems more logical, however, right
now im sitting on the fence on weather or not the change is justified.
Lets look at the dictionary:
== Can
1 be able to
2 be permitted to
3 used to indicate that something is typically the case
== Box
noun
1 a container with a flat base and sides, typically square or
rectangular and having a lid : a cereal box | a hat box.
3 a small structure or building for a specific purpose, in particular
• a separate section or enclosed area within a larger building, esp.
one reserved for a group of people in a theater or sports ground or
for witnesses or the jury in a law court : a box at the opera | the
jury was now in the box.
4 a protective casing for a piece of a mechanism.
The fact that Box only really has a single meaning, is very attractive
from a cognitive point of view IMO
/personal_opinion
Realistically, what would the damage be API wise if we moved to box?
Have we any way of understanding the impact in real terms?
Cheers, Tim
--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Can or Box or something else
First:
http://icanhascheezburger.com/2007/01/11/i-can-has-cheezburger-3/
Then:
http://lolcode.com/
Anyway, it's an internet meme that I found amusing. Every time I'm writing
Can in lift, I have to fight the urge to right has afterwords.
On Sun, Dec 28, 2008 at 1:26 PM, Tim Perrett he...@timperrett.com wrote:
lol - am I missing something josh? How does the Box has x semantic
differ?
(if its a joke, my apologies! Its been a long day!!)
On 28/12/2008 15:46, Josh Suereth joshua.suer...@gmail.com wrote:
And all my hopes for Can has x are gone...
Perhaps I'll make my own change in my lift app. :
import {Box = Bukkit}
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Can or Box or something else
In the spirit of LOLCode, I make the following proposal: Can becomes Bukkit Full becomes BukkitOf (or Bukkit of via some DSL like syntax) Empty becomes Noob (or Bukkit of Noob via some DSL like syntax) Failure becomes WTF? val x : Bukkit[String] = WTF?(new RuntimeException(O NOES!)) val y : Bukkit[String] = Noob val z = BukkitOf(Cheezburger) Trust me, every time you need to use a bukkit, you'll ROFL (without the ROF) to yourself. On Sun, Dec 21, 2008 at 4:20 PM, Tim Perrett he...@timperrett.com wrote: IMO, and echo'ing jorge's comments, I *really* dont think using ? is a good idea. The rational of this being: - Code that's littered with Can[MyType] is readable, compared with ? [MyType] which would be confusing and non-obvious for new-commers. - Using operands for such common operations / idioms I would be strongly against, as its not the usual case. Im down with Box[MyType] however... either way, if we move to Box, or stick with Can, more documentation / examples is a must. Cheers, Tim On Dec 21, 8:07 pm, Charles F. Munat c...@munat.com wrote: I, too, like ?, but I agree that others may not. Could mean too many things. But what about ??? instead? Or just two (??)? Or why not steal Haskell's thunder and use Maybe? Chas. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Can or Box or something else
On Sat, Dec 20, 2008 at 2:37 PM, Oliver Lambert ola...@gmail.com wrote: Yup, when you chose the original name, you did a good job - why second guess yourself now. Can we just leave it the way it is. Pun intended As to my vote (if I'm allowed one)... Can was slightly confusing, but looking at it vs Option makes a lot of sense. Option is also slightly confusing, because I expected it to behave like Either. Either is a great name, as you can tell what it's doing. Result seems ok, but I would vote for something more like Storage. Can is pretty succinct, and once you know how to use it, it's not hard to remember the convention. So I'd swing on the side of sticking with Can unless a really good name is discovered. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: maven problem - can't make ToDo example work - or even get off the ground.
Make sure the scala-tools snapshot repository is defined in your ppm Sent from my iPhone On Dec 10, 2008, at 7:29 PM, mike beckerle [EMAIL PROTECTED] wrote: Ok, that helped. Lots happened butI still get a bunch of errors. I can follow the instructions here in that it can't seem to download scala, but the lift-related stuff is a surprise to me. ...mike [INFO] --- - [ERROR] BUILD ERROR [INFO] --- - [INFO] Failed to resolve artifact. Missing: -- 1) org.scala-lang:scala-library:jar:2.7.2 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.scala-lang - DartifactId=scala-library -Dversion=2.7.2 -Dpackaging=jar -Dfile=/ path/ to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.scala-lang - DartifactId=scala-library -Dversion=2.7.2 -Dpackaging=jar -Dfile=/ path/ to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) com.liftworkshop:todo:war:1.0-SNAPSHOT 2) org.scala-lang:scala-library:jar:2.7.2 2) net.liftweb:lift-core:jar:0.10-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=0.10-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=0.10-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file - Durl=[url] -DrepositoryId=[id] Path to dependency: 1) com.liftworkshop:todo:war:1.0-SNAPSHOT 2) net.liftweb:lift-core:jar:0.10-SNAPSHOT 3) net.liftweb:lift-util:jar:0.10-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- util -Dversion=0.10-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- util -Dversion=0.10-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file - Durl=[url] -DrepositoryId=[id] Path to dependency: 1) com.liftworkshop:todo:war:1.0-SNAPSHOT 2) net.liftweb:lift-core:jar:0.10-SNAPSHOT 3) net.liftweb:lift-util:jar:0.10-SNAPSHOT 4) net.liftweb:lift-webkit:jar:0.10-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- webkit -Dversion=0.10-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- webkit -Dversion=0.10-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file - Durl=[url] -DrepositoryId=[id] Path to dependency: 1) com.liftworkshop:todo:war:1.0-SNAPSHOT 2) net.liftweb:lift-core:jar:0.10-SNAPSHOT 3) net.liftweb:lift-webkit:jar:0.10-SNAPSHOT 5) net.liftweb:lift-mapper:jar:0.10-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- mapper -Dversion=0.10-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- mapper -Dversion=0.10-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file - Durl=[url] -DrepositoryId=[id] Path to dependency: 1) com.liftworkshop:todo:war:1.0-SNAPSHOT 2) net.liftweb:lift-core:jar:0.10-SNAPSHOT 3) net.liftweb:lift-mapper:jar:0.10-SNAPSHOT 6) net.liftweb:lift-machine:jar:0.10-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- machine -Dversion=0.10-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- machine -Dversion=0.10-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file - Durl=[url] -DrepositoryId=[id] Path to dependency: 1) com.liftworkshop:todo:war:1.0-SNAPSHOT 2) net.liftweb:lift-core:jar:0.10-SNAPSHOT 3) net.liftweb:lift-machine:jar:0.10-SNAPSHOT 7) net.liftweb:lift-record:jar:0.10-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file
[Lift] Re: maven problem - can't make ToDo example work - or even get off the ground.
Thanks, and sorry for the typos.
What you want (in either your ~/.m2/settings.xml or ${project.dir}/pom.xml)
is the following:
repositories
repository
idscala-tools.org/id
nameScala-tools Maven2 Repository/name
urlhttp://scala-tools.org/repo-releases/url
/repository
repository
idsnapshots.scala-tools.org/id
nameScala-tools Maven2 Snapshot Repository/name
urlhttp://scala-tools.org/repo-snapshots/url
/repository
/repositories
On Thu, Dec 11, 2008 at 7:24 AM, Tim Perrett [EMAIL PROTECTED] wrote:
I think Josh meant to say defined in your pom.xml
On Dec 11, 12:14 pm, Josh Suereth [EMAIL PROTECTED] wrote:
Make sure the scala-tools snapshot repository is defined in your ppm
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: maven plugin - scala:console - how to for lift apps - debugging aid
Typo in codehause, it should be org.codehaus.classworlds.Launcher. On Wed, Dec 10, 2008 at 2:36 PM, Dano [EMAIL PROTECTED] wrote: Hi Tyler! I am trying to run my lift app which I usually do by issuing 'mvn jetty:run'. I believe this runs the class org.codehause.classworlds.Launcher with the arguments - Dclassworlds.conf=/usr/local/apache-maven/apache-maven-2.0.9/bin/ m2.conf -Dmaven.home=/usr/local/apache-maven/apache-maven-2.0.9. Currently, I am trying to run MainGenericRunner.main(args) where I am stuffing the above into the args. It complains that error: value codehause is not a member of package org. So maybe I just have to figure out how to import that class. Thanks. Dan On Dec 10, 11:12 am, TylerWeir [EMAIL PROTECTED] wrote: What are you attempting? if you run: import com.your.classpath.model._ You should be able to create and play with model objects. What are you looking to do? On Dec 10, 1:39 pm, Dano [EMAIL PROTECTED] wrote: Hello Lifters, I am looking into using the maven scala:console plugin as an aid to debugging with the hope that I can start my lift app thru the console, and then after it comes up, be able to issue calls to 'static' methods which will return data which can help me see what is going on. My attempts to use NetBeans as a debugger for my lift app have failed miserably. I need a robust simple way to debug and the console plug- in seems like a good way to go. Per the instructions located athttp:// scala-tools.org/mvnsites/maven-scala-plugin/usage_console.html, I have done the following: % mvn scala:console jetty:run scala new bootstrap.liftweb.Boot().boot However, jetty is not running yet and I am not sure how to prod into life. Has anyone tried this or have any suggestions? Thanks in advance. Dano --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Why JPA?
As a side note...
The LazyInitialization exception wasn't an issue for me when using the
OpenSessionInView pattern. However it became a large issue when trying
to use hibernate to back a thick-client GUI. With what I've used of lift,
I can't see JPA being any more difficult to manage then using another
web-framework (perhaps even simpler in some regard). The key is just to
understand what leaving the hibernate session open does to your transaction
length and how you cna remedy troubles as you see them.
-Josh
On Sat, Dec 6, 2008 at 9:59 PM, philip [EMAIL PROTECTED] wrote:
Hi Derek,
Thanks, these are good reasons to use the JPA.
About the use of the JPA in SEAM - the SEAM in Action (http://
manning.com/dallen/) book says
Lazy loading of entity associations has unfortunately established a
bad reputation. The first thing that comes to mind in most developers'
minds when you talk about lazy loading is Hibernate's
LazyInitializationException. The culprit is the detached entity
instance.
...
If the persistence manager is closed after the action method is
invoked, the Course instance is detached when the view is rendered.
...
A call to the method getHoles() triggers an exception because the
EntityManager that loaded the Course instance is no longer available
to further communicate with the database. The same problem arises on
postback, even if a lazy association wasn't hit in the view.
So within Liftweb it would then make sense to place the JPA
persistence manager within a stateful snippet. Since the snippet is
bound to the session, then navigation of the lazy loading entitys
wouldn't cause a LazyInitializationException?
Is this what is happening on the JPA example within Liftweb? it
doesn't look like it - in file Books.scala
def add (xhtml : NodeSeq) : NodeSeq = {
def doAdd () = {
Model.merge(book)
redirectTo(list.html)
}
The SEAM book says
Merging is a crude operation and should be avoided if possible. It
first loads an entity
instance with the same identifier as the detached instance into the
current persistence
context, resulting in a database read. Then, the property values from
the detached
instance are copied onto the properties of the managed instance. The
main problem
with this operation is that merging clobbers any changes that may have
been made to
the database record since the detached instance was retrieved (unless
object version-
ing is used). There are other problems as well. If an entity instance
with the same
identifier as the detached instance has already been loaded into the
current persis-
tence context, a non-unique object exception is thrown because the
uniqueness con-
tract of entities in a persistence context is violated. You may also
run into a lazy
loading exception if you hit an uninitialized association on the
detached instance dur-
ing the merge. Avoid merging if at all possible.
Thanks, Philip
On Dec 6, 10:47 pm, Derek Chen-Becker [EMAIL PROTECTED] wrote:
Here are a couple of features that JPA has that can be very useful:
1. More powerful query language. The tradeoff is that HQL is not
type-safe like Mapper's findXXX methods, so you need to test your
query
syntax to make sure it returns what you want. Granted, you can use SQL
directly in Mapper, but it's tied directly to the DB while HQL allows
you to
abstract away some of the smaller details, particularly with join
associations. However, HQL does allow you to easily
1. Do flexible joins between large graphs of objects
2. Select scalar values (i.e. select distinct player.age from
TeamMember player where ...)
3. Prefetch otherwise lazily loaded properties (select player from
TeamMember left join fetch player.coach)
2. IMHO, better definition of associations between classes.
HasManyThrough works well for a subset of usages, but it:
1. Can't be treated as a real, live collection (no updates, no
cascades)
2. Only runs once (it's lazy). Given the duration of a web request
cycle this would usually not be a big deal unless you have a
high number of
concurrent users operating on the same data
3. Doesn't map well to many-to-many relationships; you have to
build
your own binding entity to represent the join table
3. JPA has a number of implementations available for an intermediate
cache to improve performance
4. JPA supports locking of objects for read and write
That's what I can come up with off the top of my head. Having SEAM
generate
the classes for you is also nice, although I'm sure a similar tool could
be
written for Mapper. Now, as for SEAM's (ab)use of the entity manager (I'm
assuming that's what you mean by transaction manager), I'm not so sure
that
it's actually keeping the EM open across the entire conversation, but
rather providing an interface that makes it appear
[Lift] Re: noob question: working with scala 2.7.2
Here's your issue: [INFO] Archetype repository missing. Using the one from [net.liftweb:lift-archetype-blank:RELEASE - http://scala-tools.org/repo-releases] found in catalog internal It's not pulling from the snapshot repository. Try using archetype:create instead of archetype:generate. (The generate goal is from the new alpha of the archetype plugin and I don't htink it uses the -DremoteRepositories property). -Josh On Thu, Dec 4, 2008 at 9:21 AM, Harshad RJ [EMAIL PROTECTED] wrote: On Thu, Dec 4, 2008 at 6:39 PM, David Bernard [EMAIL PROTECTED]wrote: It's the correct server. Could you retry (the command from the initial mail) with -e argument at end (to print error + stackstrace) ? Here is the whole trace: ~/local/apache-maven-2.0.9/bin/mvn archetype:generate -U \ ~/w/lift -DarchetypeGroupId=net.liftweb \ -DarchetypeArtifactId=lift-archetype-blank \ -DarchetypeVersion=0.10-SNAPSHOT \ -DremoteRepositories=http://scala-tools.org/repo-snapshots \ -DgroupId=foogroup -DartifactId=foo -e Warning: JAVA_HOME environment variable is not set. + Error stacktraces are turned on. [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-blank:RELEASE - http://scala-tools.org/repo-releases] found in catalog internal [INFO] snapshot net.liftweb:lift-archetype-blank:0.10-SNAPSHOT: checking for updates from lift-archetype-blank-repo Downloading: http://scala-tools.org/repo-releases/net/liftweb/lift-archetype-blank/0.10-SNAPSHOT/lift-archetype-blank-0.10-SNAPSHOT.jar [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] The desired archetype does not exist (net.liftweb:lift-archetype-blank:0.10-SNAPSHOT) [INFO] [INFO] Trace org.apache.maven.BuildFailureException: The desired archetype does not exist (net.liftweb:lift-archetype-blank:0.10-SNAPSHOT) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:579) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:227) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) 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.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoFailureException: The desired archetype does not exist (net.liftweb:lift-archetype-blank:0.10-SNAPSHOT) at org.apache.maven.archetype.mojos.CreateProjectFromArchetypeMojo.execute(CreateProjectFromArchetypeMojo.java:201) at
[Lift] Re: JPA and Record
- I'm pretty close to having a releasable version of the maven-scala-plugin
that supports compiler plugins.
- Adding integration between the maven-pom and eclipse is going to take some
time (but is possible). I'm not sure about the netbeans/IntelliJ tools,
but this could be an awkward integration for all of them.
Don't know if that helps. (Personally I think compiler plugins are better
for POCs).
On Mon, Dec 1, 2008 at 1:22 PM, David Pollak
[EMAIL PROTECTED]wrote:
My 2 cents:
- I'm strongly opposed to any compiler plugins as they (1) mean that
IDEs will work less well and (2) they require some sort of installation (if
they can be rolled into the Maven building stuff, it makes this objection
go
away)
- I'm strongly opposed to mixing annotations and the Record stuff.
It'll just make for wicked ugly looking code.
I believe there are ways to use Record's deep knowledge of class layouts to
generate data structures and/or XML to send to JPA to do the right thing.
On Sun, Nov 30, 2008 at 7:45 AM, Derek Chen-Becker [EMAIL PROTECTED]wrote:
The whole point of integrating (and I use the word integrating here
loosely) is so that there's a common form framework for people to use.
Really, the point of Record as far as I can tell is to loosen and/or remove
the tight coupling with the datastore, and in that sense Record is
succeeding. As Tim points out, there are going to be people with existing
JPA libraries and what we're trying to propose is a means for them to
leverage their existing libraries alongside the nice work done in Record. As
ugly as the boilerplate for delegation may seem, I don't see any better
solution without adding significant complexity. I've done bytecode
manipulation in the past and while it can be very handy, it makes things a
lot more complex on the backend and I'm really trying to avoid complexity
(this includes a compiler plugin, too).
Delegation provides the cleanest approach I can come up with; it actually
helps in the case where someone wants to use an existing JPA library because
you could simply wrap an instance and delegate to it:
class MyEntry extends Record[MyEntry] {
var inner : RealEntry = _
object name extends StringField(this) with Delegation
name.delegate(inner.name, inner.name = _)
...
}
By adding a few lines of boilerplate in each class you get validation,
form generation, presentation HTML, JSON representation, etc. It's up to the
end-user to determine whether these features are worth the cost of a few
LoC.
I'm not saying this is a perfect solution, just that I think that this is
the best first cut at it. Also, no one is saying that people have to use JPA
with Record. I'm assuming that the majority of new Lift apps will probably
use Record/Mapper because they're simple, easy to use and quite capable of
handling most data models. But for the people with existing JPA libraries,
or for people who would like to use JPA for the additional features,
compatibility with Java apps, etc, I'd like to have a better answer than an
absolute Don't use Record or Switch to Record.
Derek
On Sun, Nov 30, 2008 at 1:40 AM, Marius [EMAIL PROTECTED] wrote:
I totally agree with you Viktor! ... although it seems like a workable
solution in this case a Record contains to distinct entities to
represent the same data and of course the boilerplate.
It was mentioned above compiler plugins which I expressed my opinion
about it (I'd stay away) but there might be another way to alter the
bytecode at runtime. I'm talking about dynamic class weaving.
Basically it is a class loader that before returning the actual
updated class. Kind of what AspectJ is doing. A while ago a wrote a
bytecode level manipulation framework and combined with a special
classloader I was able to modify a class dynamically and use it.
Of course there are caveats:
1. Complexity induced by bytecode level manipulation
2. How a dynamic class loader cope with container's classloader that
essentially loads the web application. Of course it would delegate the
loading to the container's classloader but these modifiable classes
should probably not live in WEB-INF/classes or WEB-INF/lib folder.
But all in all I'm not convinced that this effort really worth it.
AFAIC I still don;t get the whole point of integrating Record/Field
with JPA. If someone wants to switch easily from JPA to Record or vice-
versa, to have this flexibility perhaps consider to abstract these
layers from the rest of the application and using other persistence
technologies would not affect the application business logic ... but
this is about how the appliation is designed etc.
Br's,
Marius
On Nov 30, 9:56 am, Viktor Klang [EMAIL PROTECTED] wrote:
IMHO:
@Column{val name = my_name}
var name : String = _
object nameField extends StringField(this,100) with Delegated
nameField.delegate(name, name = _)
That's just too much boilerplate.
[Lift] Re: Recommended tools ?
Not sure if this helps, but I've been succesfully using Eclipse + Q + Multi-module projects + scala for several months now. Yes the scala plugin is a bit flaky, but with some persuasion I can usually make it do what I want. That being said, the presentation compiler tends to die on any project more complex than the eclipse plugin itself... -Josh On Sat, Nov 15, 2008 at 7:20 PM, Derek Chen-Becker [EMAIL PROTECTED]wrote: Out of curiosity, how does Netbeans handle Maven projects, particularly ones with nested modules? The most recent Eclipse plugin still has some warts, but it generally seems to work OK if I set up the .classpath file properly to point at all of the source folders. Thanks, Derek On Sat, Nov 15, 2008 at 11:25 AM, David Pollak [EMAIL PROTECTED] wrote: I've been using netbeans very succesfully. I recomend it. Thanks, David On Nov 15, 2008 8:53 AM, Oscar Picasso [EMAIL PROTECTED] wrote: Hi, Which tools would you recommend to work for a lift project, and more generally with scala? The requirement being that the project also uses maven. I have tried the Eclipse plugin a number of times and I found it too unstable. The last Intellij IDEA plugin is decent, I was considering switching to IDEA. Howver I ran lately in some issues. The more important being that if I define implicits somewhere their containing folder keep loading... forever. I could use emacs but I would like some pretty formatting, code completion and error checking. On a scala list post I read David P. explaining that there are a number of decent tools to work with lift. Which ones? BTW: the lift wiki search does not work. It always returns a *No such special page*. Oscar --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Thanks!
Hey Lift community. Just wanted to say thanks for working on the Lift Web Framework. I began using it (to be honest) because I have to interface with EJBs and Lift has much better maven-support than Grails, and I wanted a language that had some power (i.e. not Java). I'm now more than happy with the choice of Lift. Lift really is *not* just another Rails. I'm amazed at how different and consistent the paradigm is! (I had heard similar things about Wicket). Anyway, my only real complaint is lack of documentation, but I'm hoping to help contribute to this problem (as soon as I know enough to help). Anyway, just wanted to say great job, and I'm liking how my application is turning out so far! -Josh --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Scala+Lift Philosophical Question
I'd also like to say you should pick a technology that meets your goals. Lift/Grails/Django/Rails/Seam/JSF/Spring/Struts (etc..) have their own quirks and if you try to deviate too far from the paradigm, you'll run into them quickly. For me, (so far) Lift is really amazing at doing quick ajaxy websites that have multiple components on each page. If you're programming one of these style websites, you start to realize the power right away (big win with the CometActors). I would argue if your application needs to be developed quickly, and you want to do *anything* with Comet, Lift is the only way to go. It took me a day to read enough documentation and play around before I had a working Comet-based widget in my pages. It would have taken (much) less time if I hadn't been trying to communicate with EJBs on my app server. Anyway, after coming from Grails, Spring and raw Servlets + ExtJS, I'd like to say this: Make sure your framework/tools help you do your work, and that can only be determined by you! Web frameworks are not interchangeable. Find one that suits your needs. Lift provides a new perspective and a lot of power, but if you deviate from its design too far you will run into quirks (like any other framework). I think lift has a good stretch factor, which is another reason why I've chosen it for my current assignment. Anyway, hope that helps from someone who's just started using Lift for production code. -Josh On Wed, Oct 22, 2008 at 11:44 AM, Tim Perrett [EMAIL PROTECTED] wrote: +1 Viktor. In troubled economic times such as these, its in the business interest to run as efficiently as possible - in short, more productive programmers... what you said is bang on. 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
