After 1.5+ years of Ruby and Rails programming, I have finally started working on one of the new projects in Scala and Lift. Basically I'm trying to write an API for accessing information from a huge database (millions of rows). Lift should help me code the frontend of this project (the API part). But now, this also involves a module that would read from a compressed ZIP XML file to initially populate the database with rows. This module would need to run once in 3 months.
Where should I place this module code? or rather, How should I organise my Lift and Scala code? Where does the background processes go? Any pointers in this regard are welcome.
I'm a little uncertain if this is what you're after, but I'm using SBT (http://code.google.com/p/simple-build-tool/). It draws up a default project structure. You should especially look at sub projects (http://code.google.com/p/simple-build-tool/wiki/SubProjects).
For scheduled processes you could use an actor and the ActorPing to restart the process on regular intervals. For such long intervals as 3 months you could keep track of last invocation by touching a file and checking the date on application restart. The ActorPing need to be initiated on application startup; this can be done in the lift boot. If you need to modularise it more you could create a servlet that initiates the ActorPing on servlet init.
Lift follows (at least the versions I use) a standard Maven 2 structure, so there is nothing special there. Just add the code in the src folder. The packages to create will depend on your design/preferences, we can't really help you with that :)
The "standard" Lift project using SBT as the build usually calls for the following project structure:
project
src
main
scala
bootstrap
liftweb
Boot.scala
project-name
comet
lib
model
snippet
view
resources
webapp
WEB-INF/web.xml
index.html
test
resources
scala
RunWebApp.scala
If you are using the Lift Mapper ORM, you generally put your models in the src/main/scala/project-name/model directory. Likewise, any of your CometActors should go in src/main/scala/project-name/comet. Any custom Snippets you write should be in src/main/scala/project-name/snippet and any custom View components in the view directory under project-name. All of the code related to booting up your application and establishing database connectors, etc, should go in src/main/scala/bootstrap/liftweb/Boot.scala. The rest of the structure falls out like the previous answers have said, which follows the general Maven 2 structure.
This is just the general structure that is provided by the default Lift app. The only thing that is required is the bootstrap.liftweb.Boot.scala file, as the Lift Servlet looks for that class during boot.
Related
When writing a contract for an API i found myself repeating the same things over and over. For example regex validations for complex json object need to be copy pasted.
Thats tedious and not very DRY.
I'm using Kotlin DSL and Maven
I tried to extract the common parts in another file to reuse it. (Kotlin extension functions ftw.)
After trying multiple things to reuse that file I gave up.
The common parts should be as close to the actual contracts as possible. I don't want to export them in another project, and build them seperat, as they are an vital part of the contracts.
I tried it the following ways:
just put the file in the same directory and importing the functions, hoping it would be resolved as it would in java - did not work at all (my expectations were low, was worth a shot)
putting it in another maven module, and add that as dependency to the spring-cloud-contract-maven-plugin. that worked, as long as the dependant module was built and installed in the local maven repo. if no built version was available maven could not resolve it.
experimenting with kotlin script #file:Import() and #file:DependOn to tackle my issue, no luck.
Is there another way, that I missed? Is there a prefered way doing this?
This must be a common issue, right?
Use Play Framework as a component got a server up, but configuring the file system paths for routes file, views, etc, give or take having to take care of a thread pool for the embedded play server is a different story. Basing on the aforementioned, I started a template for including play as a library, but it remains unclear how to wire the paths, hopefully in an IDE-import friendly way too, so that Play can be nicely used in an existing non-play project, as a library.
How do you configure the file system paths for the routes file and views?
What else should be handled for being as robust as running as the framework?
Anything special for bundling the project for deploy with Play now included?
Motivation: Adding Play to a project, in the current state of affairs, means wrapping the project definition and structure around Play, and losing full compilation in sbt (because only run completes the compilation when using the play sbt plugin). As future Spray support is vague and Akka http is beta-ish, using Play as a library seems to plug a hole.
Somehow this didn't pop up in google, until someone suggested the link on gitter: https://www.playframework.com/documentation/2.5.x/ScalaEmbeddingPlay
Note that an application.conf file containing the required crypto secret can simply sit under src/main/resources in this embedded mode (up until you want to override it for production as per the documentation about it). This is quite enough for a REST server.
However now back to the docs, in case you want more than REST:
This can be used in conjunction with the Twirl template compiler and Play routes compiler
So for Play view templates (which are twirl templates really), refer to the repo I mention in the question body, in which #JonasAnso kindly enabled exactly that.
I think (see below) that I would like to structure a Clojure project as multiple modules, with ordered dependencies - just like Maven lets me do with multi-modules projects.
But I can't see how to do this with Leiningen - all I can see is the checkouts fix described in the FAQ which doesn't seem to be as powerful.
Will lein do this? Should I be using Gradle instead? Or is this kind of thing not needed?
Some more context: I am wondering how to architect a modular application that supports plugins (which I imagine means jars dumped on the classpath). And am wondering to what extent I can structure that as a core + plugins (I am thinking I should be able to do something with Clojure's dynamic code loading and not have to go with Java/OSGi). So I guess the driving motivation for a single project comes from wanting some way of packaging everything (the core + default plugins) as a single blob that is easy for the end user, but which can also be divided up (and which is built and tested in fragments, testing the logical independence of each module). More general advice about this is welcome
Update
A possible solution that wasn't mentioned below is using a Maven plugin - I assume that supports everything Maven does, but compiles Clojure, so will work with nested modules, etc.
First, it does not seem like Leiningen supports a module hierarchy like Maven does. The checkouts are the next closest thing it has. It should be sufficient though to develop a modular application in Clojure though.
For the project structure, I would have an API project, a "core" project, the plugins themselves, and a separate packaging project. The core and the plugins should only depend on the API. Which build tool you use to create the packaging project is up to you. Gradle would probably be more effective at handling the packaging, however having the "checkout" functionality Leiningen offers could make development of the system as a whole easier.
I would take a look at the code for Leiningen and Noir to figure out how to effectively handle this.
For dynamically loading the plugins, I would start with looking how Noir handles it in two of their files:
server.clj has namespace loading for all files under a particular namespace. Under the hood it uses tools.namespace, but you can easily see how it's used to require every namespace under a particular base. This is how Leiningen handles custom tasks as well - the base definition for the task should be in the leiningen.$task namespace.
core.clj has what I would use for plugin registration. In summary, use a map under an atom and add plugins to that map. I would advice wrapping the registration with a macro to keep your code cleaner.
What I listed above should be sufficient if you don't need to handle adding plugins at run time. If you don't have every plugin on the classpath during start-up, I would recommend utilizing pomegranite to add entries to the classpath. You can see an example in classpath.clj.
Context
big project with multi maven module or single maven module structure
Question
did you finally use multi-maven-module or single-maven-module structure?
Details
If you've worked on a big project that had long development duration and contains lots of functionality(i.e. not a trivial project), did you choose to split the project into multiple maven modules or went with the single-module approach?
For example, having a multi-module structure, crashes when running maven commands like mvn gwt:eclipse(see http://bit.ly/gs4Rmo). I guess this would have worked well with single module GWT project. And there could be other commands like the above that has issues with multi-module structure.
However, the multi-module structure could bring the benefits of a faster development, i.e. if you separate the "server" from "client" module, you could compile the business logic(server) separately and package it into resulting web archive. Compiling the GWT code, takes about 20 seconds, so if you only modify the server package, it could save you lots of time in the long run.
Which other cases like the one above did you encounter when working with a multi-module/single module project?
Thank you!
A few notes:
On development server you don't have to compile the code "by hand": dev server compiles the code automatically and reloads it. Just keep dev server running, change some code and then reload the page in browser. (this is only true if you change existing classes and don't change project structure)
Multiple maven modules have nothing to do with multiple GWT modules.
You would want to have multiple GWT modules (= multiple entry points) if you have code that executes in different environments: for example you have web and mobile sites that have quite different code bases. Then you would split the project into three modules: web, mobile and common. Then you'd reference common in both web and mobile.
Another case for multiple GWT modules would be if you, for some reason, want to have a multiple host (entry) HTML pages. There are rare cases when you'd want this, for example when you need to do redirects when integrating OpenID. The other case would be that you already have existing Web pages where you are only adding GWT to add some functionality.
Don't split the GWT project into multiple modules just to reduce download size: use Code Splitting instead.
If your main gripe is long gwt compile times then read: How do I speed up the gwt compiler?
We started with multiple modules and eventually merged into a single module. The main reason for this was maintenance of modules is a huge overhead. Each module had a pom to build the UI, RPC layer and backend services. So with 30 modules we had 90 maven projects to manage.
Merging the modules turned 90 maven projects into 3 with one parent level pom.
This considerably lowers maintenance overhead and improves build times. GWT's compiler is notoriously slow so having a single compile parsing source files once instead of multiple times makes things much faster.
On the flip side, a single module means the compiler slurps everything up into memory at once. This could make split points intolerably slow to find if you insert any in your code. Therefore if you intend to split, it may be worth considering where you're putting those points and arrange your project accordingly.
I completed my very first project in zend framework!! Thanks to stackoverflow community!!
While uploading files, i didn't know how to include zend library so i uploaded the whole library in the /library folder of my project base.
Is there a way to determine which library is used and which in not (like compilation that automatically copies dependent files to library folder incase webhost does not provide zend library ..)? i would be awfully bad to manually add each file and test weather the particular library is added or not.
This answer essentially says don't worry about including the whole library. I usually put the whole library in the project library folder, just like you did.
But if it is truly problematic to include the whole library, you could take a look at Jani Hartikainen's Packageizer which, at least in a previous form that I played with, allowed you to specify the components you needed and it would chase the dependencies and wrap them in a neat little package.
Disk space is cheap. Just have the entire ./Zend library directory (and maybe ./ZendX, if you are using that) into your own library directory where it will used. With autoloading, nothing that isn't being used will take up any significant memory. taking even 5 minutes trying to figure out is time (and therefore money) that is more usefully spent writing code.
I wonder if it would be worthwhile/reliable to subclass the autoloader for this and have it optionally log each class it loads during site operation (sort of how Zend_Translate can log untranslated strings).
You could have it turned off normally but in your testing environment you would turn it on (via your application.ini), and have it build your dependency list while your unit tests are running.