when using Finagle you can place the thrift file in the directory src/main/thrift/, and when compiling it can generate thrift file automatically in the directory target/scala-2.10/src_managed/main/.
How can the Play framework do the same thing automatically?
You just need to configure the SBT plugin or the Maven plugin. Though note that this will still produce Finagle-oriented implementations - Scrooge only really supports those. (I have a pull request outstanding to add support for other kind of server implementations).
Related
I just recently used Github, and when I was trying to upload my java project I realized that I was using some external libraries like apahce poi in this project, and these files have to be stored in libs for my application to function, do I need to upload these files because I realize that might violate some issues(maybe ?).
If yes, then what is the correct way to upload or maybe just post a link to those dependency
Use a tool that provides a dependency management system such as Maven or Gradle (these are both common choices in the Java ecosystem). Your project will then include a configuration file that Maven or Gradle will use to download dependencies so you don't need to distribute them with your project.
I have an IntelliJ with Scala plugin intalled on the server. The server is disconnected from the global internet and all the updates can be done ocsasionally only.
Would like to download some libraries once (e.g. Spark libraries, some libraries from Java) and use them in IntelliJ in the multiple projects without need of downloading them, but loading from local direcories. Also it would be great to have a 'full' bundle of libraries (e.g. all Spark libraries) and be able to use only particular classes when it's necessary (e.g. Spark Context only).
TK
P.S. Question is somewhat related to the: Use Scala on computer without internet connection
As #MarioGalic sugested, the cluse was to move a required libraries to the ~/.ivy2 directory.
Somethimes the case is to add libraries manually in IntelliJ project setup, insted of using SBT or Maven to manage the dependencies.
I'm trying to build a Vert.X app using Scala, and generating the routes using an OpenAPI 3 spec through the OpenAPI3RouterFactory.
I need to generate the models described in my spec as Scala classes.
Is there any simple and straightforward way to accomplish this?
I'm using SBT to build my app, and I've already tried some sbt codegen plugins for Swagger, but none of them seem to work.
With vertx-web-api-contract, Router and validation handlers are generated at runtime, so you don't need to generate the routes. You can just start using the Router factory and mount the handlers you want as if it would be a Vert.x Web Router. If you want to bootstrap a new project there is a community tool called vertx-starter, but there is no Scala support now
Talking about the models, what you can do is organize your OpenAPI specification in different files, putting all data model definitions under a specific directory like spec/models (You can find a good guide here). Then you can configure jsonschema2pojo (sbt plugin) to generate a Scala case class for each schema inside that directory. Then, if you want to repack the spec in a single file, you can configure tools like swagger-cli to run during the compilation and pack the spec back in a single file
I can't seem to find a idiomatic way to access FTP files from a Scala library.
Are there any mature libraries for this in Scala, or whould the prefered way be, to use the Java libraries for instance the Apache FTP client?
Thanks in advance.
There doesn't seem to be a dedicated Scala library.
The only scala project managing FTP access is Scalanet, but:
it hasn't been updated since 2009
it simply encapsulates the org.apache.commons.net.ftp classes from the Apache Commons Net™ library (as seen in the FTP.scala class)
Does anyone know any sane reason for such bundling decision? Google engineers act wisely in most cases, so this kinda surprized me.
This would cause collisions with other versions of servlet API pulled via Maven dependencies:
webapp classpath will likely contain
version which is bundled with GWT;
container may refuse to load the GWT
jar as it contains the javax.servlet
package;
in most cases this will
likely deviate classpaths across your
IDE's debugger and the really
executing VM.
Link to the jar in question (just so you see the same thing after unzipping as I do, if you don't believe that GWT contains servlet API classes in the same jar):
http://repo1.maven.org/maven2/com/google/gwt/gwt-user/1.7.0/gwt-user-1.7.0.jar
You shouldn't be including gwt-dev.jar or gwt-user.jar in your war file. You only need gwt-servlet.jar in your war, and that too only if you are using RPC. If you notice, gwt-servlet.jar (ironically) does not contain any of the servlet classes.
gwt-dev.jar contains the compilers and linkers. Your code will never need this to compile.
gwt-user.jar contains the gwt framework that ultimately gets translated to javascript. You only need this during development mode.
gwt-servlet.jar contains the server side code that is needed if you use RPC framework. This is the only jar that should be present in your war file.
The reason the classes are in the package is to provide a full working solution for users who only use the gwt-user file in development. Without it GWT RPC wouldn't compile. This is/was the general view of the GWT team as can be found in this lively discussion on the GWT issue tracker: http://code.google.com/p/google-web-toolkit/issues/detail?id=3851
However, GWT 1.7 also contains the javax source files, which can cause additional problems. For example for maven and probably also for the points you mention. This was addressed in the GWT issue and in later version of GWT the javax source files have been removed from the gwt-user jar file.
For deployment you should use the gwt-servlet jar, which doesn't contain the javax classes or any other third party libraries. In the past several it could happen GWT files designed for client side use also used on the server side were missing from the gwt-servlet jar file. Losts of these issues have been addressed and classes were added to the servlet jar file. If you still find a GWT class you need is missing from the gwt-servlet you should file an issue report. In your case, assuming you're using 1.7, it might mean to upgrade to a newer version of GWT.