eeperson

Is this actually true for Scala? I was under the impression that statically typed languages run basically the same as Java on Android. Granted it has some other issues (such as running in to limits on the number of classes).

The old versions of the keys and scopes with the hyphens are still present for backwards compatibility. However, you don't need to use those.

Yeah, I can certainly understand your frustration about finding info for the '<<=' operator. This is an unfortunate side effect of cleaning up the API. All of the old examples uses it but now the documentation doesn't explain it up front.

It sounds like your problem with examining the dependency tree might be solved by one of the 'inspect' sub commands (tree|uses|definitions). Running 'inspect tree <command>' will give you the entire dependency tree for '<command>'.

I'm not sure I understand your last point. What do you mean by 'better pure Scala API, rather than DSL'? Do you mean that the SBT API is not very good? Do you mean that the '.sbt' files are annoying to use? I'm a little confused since the DSL is a Scala API.

I think this due to Groovy's fragmented ecosystem (Groovy's 2 big recognizable projects, Grails and Gradle, don't play well together) combined with the fact that you can't use Groovy everywhere you use Java.

Does Grails and Gradle really have a tight relationship? In the past my experience has been that these two work really poorly together. Has this changed?

Agreed. I'm kind of amazed that nothing dramatically better than Bash has come along on *nix (sure Zsh is better but only incrementally so). It seem like we could create a command line oriented programming language that would be miles ahead of Bash by incorporating the last 25 years of language design. I would love a shell with the following:

- Real functions instead of having to use 'echo' to return values

- Parsing script params also defines autocompletion (think completion parser combinators such as those found in SBT (Simple Build Tool))

- Support for FRP (funtional reactive programming) would make interacting with streams and sockets much easier

- Support for JSON streams as well as plain text

Maybe one day I will finally get the time to write such a shell.

Have you tried SBT 0.13? I think it addresses some of your issues with SBT syntax. The DSL usage has been greatly simplified (many fewer operators to remember). Also, the identifiers are now the same in both the config files and the shell.

In older versions of SBT (SBT 0.7 and earlier) the configuration was done using immutable settings. In SBT 0.10 there was a switch to the current model. I believe this was done to make the configuration more declarative. A side of affect of this is that builds can now be easily parallelized without becoming nondeterministic. It also means that, in general, you shouldn't care what order tasks a re run in.

As far determining what keys are available in which scopes, I have always found this pretty easy to determine by using the 'inspect' command in the SBT repl. Although, perhaps I am not entirely under standing your issue here.

SBT does have a problem for specific cases when you do need tasks to run in a particular order. However, this is something that is currently intended to be addressed[1] in the SBT 1.0 release, which is scheduled for the end of this year.

[1] https://github.com/sbt/sbt/issues/1001

SBTs upcoming client server split[1] should make such tooling IDE agnostic.

[1] https://github.com/sbt/sbt/wiki/Client-server-split

JVMs can have a separate heap for each thread. See the Avian JVM[1] for an example of this.

[1] http://oss.readytalk.com/avian/

I think a lot of the incompatibility you are seeing in the Gradle plugin ecosystem is a problem specific to Gradle. My experience has been that Gradle plugins aren't isolated very well and as such tend to have conflicts. This combined with the fact certain pieces of core functionality tends to be tied to specific plugins (such as the 'provided' scope being tied to the 'war' plugin), results in situations like this where you need different plugins depending on what other plugins you have installed. I haven't seen this same problem on build tools that have more clearly defined integration points.

The last thing that still bothers me (now that Firefox 30 added margin/padding highlighting) is that the built in dev tools don't have a way to manage cookies.

Quasar also relies on JVM threads. Akka's lightweight actors are just as native as Quasar's lightweight threads.

You can also have separate heaps per thread in Java if you use a JVM that supports it, such as Avian: http://oss.readytalk.com/avian/

Tomcat is just a Java application. Its install is just a bunch of jar files with some shell scripts to simplify running them. If you look at an install you see that it is just running the Java class ' org.apache.catalina.startup.Bootstrap'. I'm not sure what linking you are worrying about.

For setting JVM arguments, I think you are thinking of 'setenv.sh' or 'setenv.bat'. These are shell scripts where you can set environment variables used when running Tomcat. This includes the standard 'JAVA_OPTS' to set VM arguments.

Why does standalone Tomcat need any more integration with the system than an app with embedded Tomcat? They are both Java applications.

Tool support is not server specific. In both cases you set the appropriate VM arguments. What XML file would you have to edit?

Yes, hot code replacement is faster (although it comes with other tradeoffs). Why can't you do that with standalone Tomcat? What is unreliable about reloading? You can leak PermGen space if you don't finalize your threads properly, but why wouldn't you be running the latest code?

You're right about the web.xml file. I had forgotten about that. I can see why you might prefer to write that in Java code rather than XML.

These arguments don't make sense to me.

I'm not sure why it matters that different distros put Tomcat in different locations. Embedding Jetty just means that now you have to restart every time. You could just do the same thing with standalone Tomcat instance. The only reason you are running out PermGen space on the redeploys is because your application is not cleaning up its threads on shutdown.

Why is it difficult to do any of those development things without having the server embedded in your application? Pretty much every Java build tool (Maven, SBT, Gradle, Lein) makes those things easy to do without specifying an XML file for your server. Also, they will frequently let you reload your application, which is faster.

The difficulties you mention (aside from upgrading servers) is about the having multiple apps in a single server not standalone vs embedded. Although, if you are careful, it can actually be faster and easier to deploy to a multi-app server [0].

I grant you, upgrading servers can be more involved depending on how you do it.

[0] - http://tomcat.apache.org/tomcat-7.0-doc/deployer-howto.html#...

Looks like I should have read the Capsule Github page. I didn't realize Capsule was caching the project dependencies. I could certainly see that making projects much faster to deploy.

Aren't the app servers and the embedded servers the same servers just configured differently? Standalone it is configured with XML and and embedded it is configured with Java code. It doesn't seem to me like there is much of a set up difference.

As far as I can tell, it comes down who cares more about the settings for the server, the people who maintain the machines or the people who maintain the code. If those people are the same then it sounds like it really doesn't matter.

As a Java developer, I thought this article had some interesting information about logging and monitoring. However, the deployment section had my scratching my head a little.

I've never totally understood why people want to make fat jars. It seems like a process full of headaches since you can't have jars in jars. Wouldn't it be much easier to create a regular zip file with a small script to set the classpath and and run the project?

I'm not sure I understand the motivation for embedded instead of standalone servlet container. The article linked to some slides but they mostly seemed be demonstrating that you can function using an embedded container rather than providing clear benefits. Maybe it would have made more sense with the associated talk.

Can anyone provide more insight to these?

Thanks!

Writing tests for your build script is an interesting idea. I wonder if this would be easy to do in something like SBT where the build definition is itself an SBT project.

Shake?

Would you mind elaborating on what you mean by a monadic style for .scala build files?

PS - You may already know this, but you can change IntelliJ's compile output directory [0].

[0] - http://www.jetbrains.com/idea/webhelp/configuring-module-com...

I've never had to change anything between upgrades (aside from changing deprecated stuff). Are you referring to the jump between from 0.7 to 0.10 a few years ago or have you had more recent issues?

The performance problems are definitely the most annoying part of using Gradle. The Gradle daemon helped a little but tended to break other things and Gradle was still pretty slow.

If you are looking for something faster and more declarative, you may want to check out SBT[0]. It is way faster than any of the other JVM build tools. Also, in the future[1] it should have much better tooling support than anything else on the JVM.

[0] - http://www.scala-sbt.org/ [1] - https://github.com/sbt/sbt/wiki/Client-server-split

Is Grails really pushing Gradle adoption? My experience has always been that the integration between the two is pretty bad. Are things better now that they finally... released a real Gradle plugin to support Grails 2?

The details for Maven an Lein are a bit off. They both use the same repositories (I think they even use the same library to download packages) yet they are reported as having different qualities in this area (licensing, mirrors, etc.). I don't think licenses are mandatory for either and there are tons of mirrors. You can even create your own pretty easily [1] (at least for the subset of libraries you actually use).

[1] http://www.sonatype.org/nexus/

I'm inclined to agree that this law is something of a tautology. If nothing else, I think it is the wrong way to look at abstractions. I think it was Rich Hickey who said something to the effect of "abstractions are not about hiding, they are about pulling something to the forefront".

It is entirely possible to produce an abstraction over some concept that is capable of expressing the exact same things but brings different areas to the forefront. I think assembly language acts as a simple example of this. You can express all of the same things you can with machine code but it is clearly an abstraction.

Edit: grammar

Weird, I have the exact opposite feeling about git integration. I'm okay with the Egit functionality but I always use the command line with IntelliJ because the git support gives you no way to interact with git's staging area.

A comment in the article, from one of the Play developers, provides a good explanation about what iteratees provide that is not provided by rx: http://brikis98.blogspot.com/2013/11/play-scala-and-iteratee...

Do you know it does this ? I've heard this before and I'm not sure how C# can do this.