Getting Started Problems, again

[Eric Kolotyluk]

I really wish Scala IDE had better diagnostics and sanity checking to tell you what is wrong when it barfs... (see below)

Here is what I did...

1. Installed Kepler 4.3.1 Standard
2. Installed Scala IDE 3.0.0 from Marketplace
3. Created a Scala project from net.alchim31.maven
4. Eyes glazed over looking at all the meaningless errors
5. Practiced relaxation exercises so I could try to troubleshoot the problems
   

Interestingly enough, if I run "mvn test" from Eclipse, everything compiles without incident, and all the test pass, so my intuition tells me there is something wrong with Scala IDE and/or Eclipse.

Is there some way to make Scala IDE more robust, so that it can do some basic sanity checking before barfing all over the problems tab?

After a bit more thought, I realized that (as usual) Eclipse is running the Java compiler on a .scala file because the Scala nature has not been added to the project. Why do I always have to remember this bit of tribal knowledge? Is this a problem with the maven archetype? Is there not some way Eclipse/Scala IDE can't detect this VERY COMMON problem?

Is there not some way Eclipse/Scala IDE could actually look at the source file name and say "hey, that ends in .scala, so maybe I should use the scala compiler instead of the Java compiler."

When I add the Scala nature to my project, why can't Eclipse say "hey, something changed in the project configuration, maybe I should rebuild the project." As it is, I have to do a Project Clean.

The main point is, almost every time I try to start up a new Scala project, I run into these annoying kinds of problems that waste my time and leave me terribly frustrated. On the other hand, starting a new Java project is generally painless, and has been that way in Eclipse for almost a decade.

- Eric

<barf>
Description    Resource    Path    Location    Type
Syntax error on tokens, ClassHeader expected instead    App.scala    /files/src/main/scala/net/kolotyluk/scala/files    line 1    Java Problem
Syntax error on token ":", delete this token    App.scala    /files/src/main/scala/net/kolotyluk/scala/files    line 8    Java Problem
Syntax error on token "String", delete this token    App.scala    /files/src/main/scala/net/kolotyluk/scala/files    line 8    Java Problem
Syntax error on token "=", { expected    App.scala    /files/src/main/scala/net/kolotyluk/scala/files    line 8    Java Problem
Syntax error, insert ")" to complete SingleMemberAnnotation    specs.scala    /files/src/test/scala/samples    line 28    Java Problem
Syntax error on token ",", . expected    App.scala    /files/src/main/scala/net/kolotyluk/scala/files    line 8    Java Problem
must cannot be resolved to a type    specs.scala    /files/src/test/scala/samples    line 28    Java Problem
Syntax error, insert ";" to complete BlockStatements    App.scala    /files/src/main/scala/net/kolotyluk/scala/files    line 8    Java Problem
Syntax error on token "def", invalid AssignmentOperator    App.scala    /files/src/main/scala/net/kolotyluk/scala/files    line 10    Java Problem
Syntax error on tokens, AnnotationName expected instead    specs.scala    /files/src/test/scala/samples    line 28    Java Problem
The left-hand side of an assignment must be a variable    specs.scala    /files/src/test/scala/samples    line 28    Java Problem
Syntax error on token ">", delete this token    App.scala    /files/src/main/scala/net/kolotyluk/scala/files    line 8    Java Problem
Syntax error, insert ")" to complete MethodInvocation    App.scala    /files/src/main/scala/net/kolotyluk/scala/files    line 10    Java Problem
Syntax error, insert ";" to complete BlockStatements    specs.scala    /files/src/test/scala/samples    line 28    Java Problem
Syntax error, insert "AssignmentOperator Expression" to complete Expression    specs.scala    /files/src/test/scala/samples    line 28    Java Problem
Syntax error on token ":", ( expected    App.scala    /files/src/main/scala/net/kolotyluk/scala/files    line 10    Java Problem
Syntax error, insert "}" to complete Block    specs.scala    /files/src/test/scala/samples    line 28    Java Problem
Syntax error, insert ";" to complete BlockStatements    App.scala    /files/src/main/scala/net/kolotyluk/scala/files    line 11    Java Problem
Syntax error, insert ";" to complete Statement    App.scala    /files/src/main/scala/net/kolotyluk/scala/files    line 10    Java Problem
Syntax error, insert ";" to complete BlockStatements    specs.scala    /files/src/test/scala/samples    line 28    Java Problem
Syntax error, insert "}" to complete ClassBody    App.scala    /files/src/main/scala/net/kolotyluk/scala/files    line 15    Java Problem
Syntax error on token(s), misplaced construct(s)    App.scala    /files/src/main/scala/net/kolotyluk/scala/files    line 12    Java Problem
Syntax error, insert ";" to complete ConstructorDeclaration    specs.scala    /files/src/test/scala/samples    line 28    Java Problem
Syntax error, insert ")" to complete ConstructorDeclaration    specs.scala    /files/src/test/scala/samples    line 28    Java Problem
Syntax error, insert "Identifier (" to complete ConstructorHeaderName    specs.scala    /files/src/test/scala/samples    line 28    Java Problem
must cannot be resolved to a type    specs.scala    /files/src/test/scala/samples    line 22    Java Problem
Syntax error, insert ";" to complete BlockStatements    specs.scala    /files/src/test/scala/samples    line 22    Java Problem
Syntax error, insert ";" to complete BlockStatements    specs.scala    /files/src/test/scala/samples    line 22    Java Problem
The method size(int) is undefined for the type MySpecTest    specs.scala    /files/src/test/scala/samples    line 22    Java Problem
Syntax error, insert ")" to complete MethodInvocation    specs.scala    /files/src/test/scala/samples    line 22    Java Problem
Syntax error, insert ";" to complete Statement    specs.scala    /files/src/test/scala/samples    line 22    Java Problem
Syntax error, insert "}" to complete Block    specs.scala    /files/src/test/scala/samples    line 22    Java Problem
Syntax error, insert ")" to complete MethodInvocation    specs.scala    /files/src/test/scala/samples    line 22    Java Problem
Syntax error, insert ";" to complete Statement    specs.scala    /files/src/test/scala/samples    line 22    Java Problem
Syntax error on token "intercept", delete this token    scalatest.scala    /files/src/test/scala/samples    line 104    Java Problem
Syntax error, insert ";" to complete Statement    scalatest.scala    /files/src/test/scala/samples    line 102    Java Problem
Syntax error on tokens, AnnotationName expected instead    specs.scala    /files/src/test/scala/samples    line 25    Java Problem
must cannot be resolved to a type    specs.scala    /files/src/test/scala/samples    line 25    Java Problem
Syntax error, insert ";" to complete AssertStatement    scalatest.scala    /files/src/test/scala/samples    line 99    Java Problem
Syntax error, insert ")" to complete SingleMemberAnnotation    specs.scala    /files/src/test/scala/samples    line 25    Java Problem
Syntax error on token "=", delete this token    scalatest.scala    /files/src/test/scala/samples    line 99    Java Problem
Syntax error, insert "Identifier (" to complete ConstructorHeaderName    specs.scala    /files/src/test/scala/samples    line 25    Java Problem
Syntax error, insert ")" to complete ConstructorDeclaration    specs.scala    /files/src/test/scala/samples    line 25    Java Problem
Syntax error, insert ";" to complete ConstructorDeclaration    specs.scala    /files/src/test/scala/samples    line 25    Java Problem
Syntax error, insert "AssignmentOperator Expression" to complete Expression    specs.scala    /files/src/test/scala/samples    line 28    Java Problem
Syntax error on token "}", ; expected    scalatest.scala    /files/src/test/scala/samples    line 107    Java Problem
Syntax error on token "RunWith", ; expected after this token    specs.scala    /files/src/test/scala/samples    line 3    Java Problem
Syntax error on token "samples", ; expected after this token    specs.scala    /files/src/test/scala/samples    line 1    Java Problem
Syntax error on token "_", ; expected after this token    specs.scala    /files/src/test/scala/samples    line 4    Java Problem
The import org.specs2.mutable._ cannot be resolved    specs.scala    /files/src/test/scala/samples    line 4    Java Problem
Syntax error on token "_", ; expected after this token    specs.scala    /files/src/test/scala/samples    line 5    Java Problem
Syntax error, insert ";" to complete BlockStatements    junit.scala    /files/src/test/scala/samples    line 10    Java Problem
The import org.specs2.runner._ cannot be resolved    specs.scala    /files/src/test/scala/samples    line 5    Java Problem
JUnitRunner cannot be resolved to a variable    specs.scala    /files/src/test/scala/samples    line 18    Java Problem
classOf cannot be resolved to a variable    specs.scala    /files/src/test/scala/samples    line 18    Java Problem
Specification cannot be resolved to a type    specs.scala    /files/src/test/scala/samples    line 19    Java Problem
Syntax error, insert "ClassBody" to complete ClassDeclaration    specs.scala    /files/src/test/scala/samples    line 19    Java Problem
Syntax error on token(s), misplaced construct(s)    specs.scala    /files/src/test/scala/samples    line 21    Java Problem
Syntax error on token(s), misplaced construct(s)    specs.scala    /files/src/test/scala/samples    line 21    Java Problem
Syntax error on token "in", invalid AssignmentOperator    specs.scala    /files/src/test/scala/samples    line 21    Java Problem
Syntax error on token "in", invalid AssignmentOperator    specs.scala    /files/src/test/scala/samples    line 21    Java Problem
Syntax error on token "have", @ expected    scalatest.scala    /files/src/test/scala/samples    line 73    Java Problem
Syntax error on token "samples", ; expected after this token    junit.scala    /files/src/test/scala/samples    line 1    Java Problem
Syntax error on token "should", ; expected    scalatest.scala    /files/src/test/scala/samples    line 73    Java Problem
Syntax error, insert "EnumBody" to complete BlockStatement    scalatest.scala    /files/src/test/scala/samples    line 73    Java Problem
Syntax error on token "_", ; expected after this token    junit.scala    /files/src/test/scala/samples    line 3    Java Problem
The import org.junit._ cannot be resolved    junit.scala    /files/src/test/scala/samples    line 3    Java Problem
Syntax error, insert "enum Identifier" to complete EnumHeaderName    scalatest.scala    /files/src/test/scala/samples    line 73    Java Problem
Syntax error, insert ";" to complete LocalVariableDeclarationStatement    scalatest.scala    /files/src/test/scala/samples    line 74    Java Problem
Syntax error on token "should", ; expected    scalatest.scala    /files/src/test/scala/samples    line 74    Java Problem
Syntax error, insert ";" to complete Statement    scalatest.scala    /files/src/test/scala/samples    line 74    Java Problem
Syntax error, insert "AssignmentOperator Expression" to complete Assignment    scalatest.scala    /files/src/test/scala/samples    line 74    Java Problem
Syntax error, insert ";" to complete LocalVariableDeclarationStatement    scalatest.scala    /files/src/test/scala/samples    line 68    Java Problem
def cannot be resolved to a type    junit.scala    /files/src/test/scala/samples    line 10    Java Problem
Test cannot be resolved to a type    junit.scala    /files/src/test/scala/samples    line 9    Java Problem
Syntax error on token "should", ; expected    scalatest.scala    /files/src/test/scala/samples    line 68    Java Problem
Syntax error, insert ";" to complete Statement    scalatest.scala    /files/src/test/scala/samples    line 71    Java Problem
The method assertTrue(boolean) is undefined for the type AppTest    junit.scala    /files/src/test/scala/samples    line 10    Java Problem
Syntax error on token "=", { expected    junit.scala    /files/src/test/scala/samples    line 10    Java Problem
Syntax error on token "}", invalid AssignmentOperator    scalatest.scala    /files/src/test/scala/samples    line 69    Java Problem
Syntax error on token "have", @ expected    scalatest.scala    /files/src/test/scala/samples    line 72    Java Problem
Syntax error on token "_", ; expected after this token    junit.scala    /files/src/test/scala/samples    line 4    Java Problem
The import Assert cannot be resolved    junit.scala    /files/src/test/scala/samples    line 4    Java Problem
Syntax error on token "should", ; expected    scalatest.scala    /files/src/test/scala/samples    line 72    Java Problem
Syntax error, insert "}" to complete ClassBody    junit.scala    /files/src/test/scala/samples    line 7    Java Problem
Syntax error, insert "EnumBody" to complete BlockStatement    scalatest.scala    /files/src/test/scala/samples    line 72    Java Problem
Test cannot be resolved to a type    junit.scala    /files/src/test/scala/samples    line 6    Java Problem
Syntax error, insert "enum Identifier" to complete EnumHeaderName    scalatest.scala    /files/src/test/scala/samples    line 72    Java Problem
Syntax error on token ""A Stack"", delete this token    scalatest.scala    /files/src/test/scala/samples    line 92    Java Problem
Syntax error, insert ";" to complete BlockStatements    scalatest.scala    /files/src/test/scala/samples    line 94    Java Problem
Syntax error, insert "ArrayInitializer" to complete ArrayCreationWithArrayInitializer    scalatest.scala    /files/src/test/scala/samples    line 95    Java Problem
Syntax error, insert ";" to complete BlockStatements    scalatest.scala    /files/src/test/scala/samples    line 95    Java Problem
Syntax error, insert ";" to complete Statement    scalatest.scala    /files/src/test/scala/samples    line 96    Java Problem
Syntax error, insert ";" to complete Statement    scalatest.scala    /files/src/test/scala/samples    line 97    Java Problem
Syntax error on token "=", delete this token    scalatest.scala    /files/src/test/scala/samples    line 98    Java Problem
Syntax error, insert ";" to complete AssertStatement    scalatest.scala    /files/src/test/scala/samples    line 98    Java Problem
Syntax error on token "import", ; expected    scalatest.scala    /files/src/test/scala/samples    line 87    Java Problem
Syntax error on token(s), misplaced construct(s)    scalatest.scala    /files/src/test/scala/samples    line 87    Java Problem
Syntax error on token "import", < expected    scalatest.scala    /files/src/test/scala/samples    line 88    Java Problem
The import scala.collection.mutable.Stack is never used    scalatest.scala    /files/src/test/scala/samples    line 88    Java Problem
The type FunSpec cannot be the superclass of ExampleSpec; a superclass must be a class    scalatest.scala    /files/src/test/scala/samples    line 90    Java Problem
Syntax error, insert "}" to complete ClassBody    scalatest.scala    /files/src/test/scala/samples    line 90    Java Problem
Syntax error, insert "}" to complete ClassBody    scalatest.scala    /files/src/test/scala/samples    line 90    Java Problem
Return type for the method is missing    scalatest.scala    /files/src/test/scala/samples    line 92    Java Problem
def cannot be resolved to a type    scalatest.scala    /files/src/test/scala/samples    line 42    Java Problem
Syntax error, insert ";" to complete AssertStatement    scalatest.scala    /files/src/test/scala/samples    line 39    Java Problem
Syntax error on token "=", delete this token    scalatest.scala    /files/src/test/scala/samples    line 39    Java Problem
Syntax error, insert ";" to complete AssertStatement    scalatest.scala    /files/src/test/scala/samples    line 38    Java Problem
Syntax error on token "intercept", delete this token    scalatest.scala    /files/src/test/scala/samples    line 44    Java Problem
String cannot be resolved to a variable    scalatest.scala    /files/src/test/scala/samples    line 43    Java Problem
Cannot define dimension expressions when an array initializer is provided    scalatest.scala    /files/src/test/scala/samples    line 43    Java Problem
val cannot be resolved to a type    scalatest.scala    /files/src/test/scala/samples    line 43    Java Problem
Syntax error, insert "ArrayInitializer" to complete ArrayCreationWithArrayInitializer    scalatest.scala    /files/src/test/scala/samples    line 35    Java Problem
Plugin execution not covered by lifecycle configuration: net.alchim31.maven:scala-maven-plugin:3.1.3:compile (execution: default, phase: compile)    pom.xml    /files    line 69    Maven Project Build Lifecycle Mapping Problem
Int cannot be resolved to a variable    scalatest.scala    /files/src/test/scala/samples    line 35    Java Problem
Plugin execution not covered by lifecycle configuration: net.alchim31.maven:scala-maven-plugin:3.1.3:testCompile (execution: default, phase: test-compile)    pom.xml    /files    line 69    Maven Project Build Lifecycle Mapping Problem
val cannot be resolved to a type    scalatest.scala    /files/src/test/scala/samples    line 35    Java Problem
Version is duplicate of parent version    pom.xml    /files    line 11    Maven pom Loading Problem
def cannot be resolved to a type    scalatest.scala    /files/src/test/scala/samples    line 34    Java Problem
Syntax error on token "=", delete this token    scalatest.scala    /files/src/test/scala/samples    line 38    Java Problem
Syntax error, insert ";" to complete Statement    scalatest.scala    /files/src/test/scala/samples    line 37    Java Problem
Syntax error, insert ";" to complete Statement    scalatest.scala    /files/src/test/scala/samples    line 36    Java Problem
Syntax error, insert ";" to complete BlockStatements    scalatest.scala    /files/src/test/scala/samples    line 35    Java Problem
Syntax error on token "samples", ; expected after this token    scalatest.scala    /files/src/test/scala/samples    line 16    Java Problem
Syntax error on token "Test", ; expected after this token    scalatest.scala    /files/src/test/scala/samples    line 30    Java Problem
The type Assertions cannot be the superclass of StackSuite; a superclass must be a class    scalatest.scala    /files/src/test/scala/samples    line 32    Java Problem
Syntax error on token "Stack", ; expected after this token    scalatest.scala    /files/src/test/scala/samples    line 28    Java Problem
Syntax error on token "Assertions", ; expected after this token    scalatest.scala    /files/src/test/scala/samples    line 29    Java Problem
Syntax error, insert ")" to complete MethodDeclaration    scalatest.scala    /files/src/test/scala/samples    line 63    Java Problem
Syntax error on token ")", . expected    scalatest.scala    /files/src/test/scala/samples    line 62    Java Problem
Return type for the method is missing    scalatest.scala    /files/src/test/scala/samples    line 66    Java Problem
Syntax error, insert ";" to complete MethodDeclaration    scalatest.scala    /files/src/test/scala/samples    line 63    Java Problem
Syntax error on token "should", ; expected    scalatest.scala    /files/src/test/scala/samples    line 67    Java Problem
Syntax error on token ""A non-empty list should not be empty"", delete this token    scalatest.scala    /files/src/test/scala/samples    line 66    Java Problem
Invalid character constant    scalatest.scala    /files/src/test/scala/samples    line 67    Java Problem
Syntax error on token "be", = expected after this token    scalatest.scala    /files/src/test/scala/samples    line 67    Java Problem
Syntax error, insert "}" to complete Block    scalatest.scala    /files/src/test/scala/samples    line 62    Java Problem
Syntax error, insert "}" to complete Block    scalatest.scala    /files/src/test/scala/samples    line 62    Java Problem
Syntax error, insert "}" to complete Block    scalatest.scala    /files/src/test/scala/samples    line 62    Java Problem
Syntax error, insert ";" to complete BlockStatements    scalatest.scala    /files/src/test/scala/samples    line 62    Java Problem
should cannot be resolved to a type    scalatest.scala    /files/src/test/scala/samples    line 62    Java Problem
Syntax error on token(s), misplaced construct(s)    scalatest.scala    /files/src/test/scala/samples    line 62    Java Problem
Invalid character constant    scalatest.scala    /files/src/test/scala/samples    line 62    Java Problem
Invalid character constant    scalatest.scala    /files/src/test/scala/samples    line 62    Java Problem
Syntax error on token "FunSuite", { expected after this token    scalatest.scala    /files/src/test/scala/samples    line 59    Java Problem
The type FunSuite cannot be the superclass of ListSuite; a superclass must be a class    scalatest.scala    /files/src/test/scala/samples    line 59    Java Problem
with cannot be resolved to a type    scalatest.scala    /files/src/test/scala/samples    line 59    Java Problem
The method test(String) is undefined for the type ListSuite    scalatest.scala    /files/src/test/scala/samples    line 61    Java Problem
Syntax error, insert ";" to complete BlockStatements    scalatest.scala    /files/src/test/scala/samples    line 61    Java Problem
Syntax error, insert ";" to complete BlockStatements    scalatest.scala    /files/src/test/scala/samples    line 61    Java Problem
The method List() is undefined for the type ListSuite    scalatest.scala    /files/src/test/scala/samples    line 62    Java Problem
Syntax error, insert ";" to complete BlockStatements    scalatest.scala    /files/src/test/scala/samples    line 62    Java Problem
NoSuchElementException cannot be resolved to a variable    scalatest.scala    /files/src/test/scala/samples    line 44    Java Problem
Syntax error, insert ";" to complete BlockStatements    scalatest.scala    /files/src/test/scala/samples    line 46    Java Problem
Syntax error on token "import", @ expected    scalatest.scala    /files/src/test/scala/samples    line 53    Java Problem
Syntax error on token "import", . expected    scalatest.scala    /files/src/test/scala/samples    line 54    Java Problem
Syntax error on token "import", . expected    scalatest.scala    /files/src/test/scala/samples    line 56    Java Problem
Syntax error on token "import", . expected    scalatest.scala    /files/src/test/scala/samples    line 57    Java Problem
classOf cannot be resolved to a variable    scalatest.scala    /files/src/test/scala/samples    line 58    Java Problem
JUnitRunner cannot be resolved to a variable    scalatest.scala    /files/src/test/scala/samples    line 58    Java Problem
</barf>

[David Bernard]

Hi,

Do you use m2e and m2eclipse-scala ?

see http://scala-ide.org/docs/tutorials/m2eclipse/index.html

--
You received this message because you are subscribed to the Google Groups "Scala IDE User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-user/52FBDCE3.8010308%40gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

[iulian dragos]

Hi Eric,

I agree that the out-of-the-box experience should be better. A first step in getting there is angry emails :) Next we have to see what we can do...

On Wed, Feb 12, 2014 at 9:43 PM, Eric Kolotyluk <eric.ko...@gmail.com> wrote:

I really wish Scala IDE had better diagnostics and sanity checking to tell you what is wrong when it barfs... (see below)

Here is what I did...

1. Installed Kepler 4.3.1 Standard
2. Installed Scala IDE 3.0.0 from Marketplace
3. Created a Scala project from net.alchim31.maven
4. Eyes glazed over looking at all the meaningless errors
5. Practiced relaxation exercises so I could try to troubleshoot the problems
   

Interestingly enough, if I run "mvn test" from Eclipse, everything compiles without incident, and all the test pass, so my intuition tells me there is something wrong with Scala IDE and/or Eclipse.

Is there some way to make Scala IDE more robust, so that it can do some basic sanity checking before barfing all over the problems tab?

The errors come from Java, so Scala IDE has, so to say, nothing to do with that. Hijacking Java projects and adding the Scala nature if there's a Scala file inside seems like the only solution, but I'm not sure what's the best way: do it the first time after installation? On every workspace? On every startup?

 

After a bit more thought, I realized that (as usual) Eclipse is running the Java compiler on a .scala file because the Scala nature has not been added to the project. Why do I always have to remember this bit of tribal knowledge? Is this a problem with the maven archetype? Is there not some way Eclipse/Scala IDE can't detect this VERY COMMON problem?

Is there not some way Eclipse/Scala IDE could actually look at the source file name and say "hey, that ends in .scala, so maybe I should use the scala compiler instead of the Java compiler."

When I add the Scala nature to my project, why can't Eclipse say "hey, something changed in the project configuration, maybe I should rebuild the project." As it is, I have to do a Project Clean.

Usually this is done by having "Build Automatically" enabled. Was it the case, and still it didn't rebuild?

The main point is, almost every time I try to start up a new Scala project, I run into these annoying kinds of problems that waste my time and leave me terribly frustrated. On the other hand, starting a new Java project is generally painless, and has been that way in Eclipse for almost a decade.

The Maven route needs the "m2e-connector" plugin (see David's reply to this thread). We provide a fully packaged Eclipse distribution (based on Kepler) that comes pre-loaded with Scala IDE and the necessary maven connector. That should ease some of this pain (if you tried it and wasn't happy with it, let us know what's missing).

cheers,

iulian

 

--

You received this message because you are subscribed to the Google Groups "Scala IDE User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-user/52FBDCE3.8010308%40gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

[Eric Kolotyluk]

No, I was not aware of m2eclipse-scala, so thanks for the tip. I have now installed that, and will test it later to see if it helps.

Here is the problem though, it is just one more piece of knowledge that is not easy to find, otherwise I would have found it.

Over the years I have come to realize the following important lesson: don't document it, automate it. In fact, that is why I really like Maven so much, because it embodies that principle.

A better solution would be, that when I install Scala IDE, some automated process should also install m2eclipse-scala. As a backup, when the scala-ide tooling initializes in Eclipse, it should check to see if m2eclipse-scala is also installed, and tell the user that should be installed too.

I worked on a project a few years ago, sort of a light weight enterprise service bus, I went to extraordinary lengths to automate as much as I could. In particular, I deferred much of the setup/installation/deployment to the actual run-time. For example, there was a file intersystem-service.jar that was the normal service run-time. It was started with "java -jar intersystem-service.jar" -- that's it, no other crap about classpaths or other settings. One of the things it depended on was PostgreSQL, so when it started, it looked to see if PostgreSQL was installed, and if it was not, it would install it. Then it would check to see if all the databases had been configured properly, and if not, it would configure them; and so on, and so on. The point was, this made the service 'self healing' so if someone accidentally deleted the database, it would recreate it.

I called this approach to software design: paranoid programming. That is, always assume the worst, in particular that developers and users don't really know what they are doing, and are not willing to take the time to read any documentation. Furthermore, assume that people will do stupid things to break your product, so always check that things are sane, and restore them to sanity if necessary.

The results of this approach were better than I had hoped, and not only did it simplify a lot around installation and deployment, but it made development and testing much more productive. For example, if I was playing around with some database ideas, and made a mess, I would just delete the database, and restart the service, knowing with confidence it would all be restored automatically.

So, in my world, if m2eclipse-scala is a necessary part of a good Scala IDE experience, then Scala IDE should ensure that m2eclipse-scala is present.

Cheers, Eric

To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-user/CAK3XY7QEb_XNGoztWKuo9gFZvzdmJbdovR0k2pByWzGahFfBqw%40mail.gmail.com.

[Eric Kolotyluk]

Well, I am always willing to follow up angry/frustrated e-mails with bug reports, so I have created ticket #1002048 on Scala IDE.

Cheers, Eric

To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-user/CAOwe9fYb_TWuu39Gjuzt1rMUwvSLmbO2O7SZWVYc6qX4i7URFQ%40mail.gmail.com.

[Simon Schäfer]

I would prefer having an update manager which works - not that mess that is built in into Eclipse. Preinstalling packages is easy but the risk slow down everything is high. And Eclipse is not very user friendly in removing packages once they are installed.

I hope day someone finds the time to integrate an update manager like sublime has one - automatic checking for potential dependencies included.

To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-user/52FD013A.405%40gmail.com.

[Eric Kolotyluk]

I agree, also a good solution.

Cheers, Eric

To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-user/52FD0863.4080507%40antoras.de.

[iulian dragos]

On Thu, Feb 13, 2014 at 6:30 PM, Eric Kolotyluk <eric.ko...@gmail.com> wrote:

No, I was not aware of m2eclipse-scala, so thanks for the tip. I have now installed that, and will test it later to see if it helps.

Here is the problem though, it is just one more piece of knowledge that is not easy to find, otherwise I would have found it.

Over the years I have come to realize the following important lesson: don't document it, automate it. In fact, that is why I really like Maven so much, because it embodies that principle.

A better solution would be, that when I install Scala IDE, some automated process should also install m2eclipse-scala. As a backup, when the scala-ide tooling initializes in Eclipse, it should check to see if m2eclipse-scala is also installed, and tell the user that should be installed too.

I worked on a project a few years ago, sort of a light weight enterprise service bus, I went to extraordinary lengths to automate as much as I could. In particular, I deferred much of the setup/installation/deployment to the actual run-time. For example, there was a file intersystem-service.jar that was the normal service run-time. It was started with "java -jar intersystem-service.jar" -- that's it, no other crap about classpaths or other settings. One of the things it depended on was PostgreSQL, so when it started, it looked to see if PostgreSQL was installed, and if it was not, it would install it. Then it would check to see if all the databases had been configured properly, and if not, it would configure them; and so on, and so on. The point was, this made the service 'self healing' so if someone accidentally deleted the database, it would recreate it.

I called this approach to software design: paranoid programming. That is, always assume the worst, in particular that developers and users don't really know what they are doing, and are not willing to take the time to read any documentation. Furthermore, assume that people will do stupid things to break your product, so always check that things are sane, and restore them to sanity if necessary.

The results of this approach were better than I had hoped, and not only did it simplify a lot around installation and deployment, but it made development and testing much more productive. For example, if I was playing around with some database ideas, and made a mess, I would just delete the database, and restart the service, knowing with confidence it would all be restored automatically.

So, in my world, if m2eclipse-scala is a necessary part of a good Scala IDE experience, then Scala IDE should ensure that m2eclipse-scala is present.

This is the crux of the matter: is it absolutely necessary for a good experience? I don't think it's a (technical) problem to add a dependency on m2eclipse-scala and pull it automatically in our update site. I was under the impression that maven was less used in the Scala world, and people hate bloated software. My reasoning is: if people want an easy start, they pick the prepackaged Eclipse download (it comes with all plugins, including m2e-scala). If they want to handle installation themselves, they get only what they explicitly install. So going back to my previous email, is there something wrong with the prepackaged Eclipse bundle? 

On a related note: if you import an existing maven project, don't you get a wizard asking to find connectors for (some) maven phases? That would normally point out there's an error, and the project won't work well. I'm not sure exactly how/if m2eclipse-scala is showing up, but I think it might be related to the m2e market place (David, maybe this would make it automatically resolve?):

https://wiki.eclipse.org/Submitting_M2E_marketplace_entries

iulian

 

To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-user/52FD013A.405%40gmail.com.

For more options, visit https://groups.google.com/groups/opt_out.

--

[iulian dragos]

On Thu, Feb 13, 2014 at 6:48 PM, Eric Kolotyluk <eric.ko...@gmail.com> wrote:

Well, I am always willing to follow up angry/frustrated e-mails with bug reports, so I have created ticket #1002048 on Scala IDE.

Tickets are good, pull requests are better! :)

thanks,

iulian

 

To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-user/52FD057F.7090903%40gmail.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Clint Gilbert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/13/2014 12:30 PM, Eric Kolotyluk wrote:
>
> Over the years I have come to realize the following important

> lesson: /*don't document it, automate it*/.

Hear, hear.

> So, in my world, if m2eclipse-scala is a necessary part of a good
Scala IDE experience, then Scala IDE should ensure that
m2eclipse-scala is present.

I've been burnt by forgetting to install m2e-scala in the past as
well. I now install it by rote, but I could imagine a newcomer would
not know to do that and would have a bad experience.

This is likely a naive question, by why isn't m2e-scala just part of
the ScalaIDE distribution? Or, why doesn't ScalaIDE support Maven
better immediately post-install?

Is it because Maven isn't fashionable in the Scala community? I don't
like Maven very much - I don't know anyone who does - but it works,
and for a variety of reasons, we prefer Maven at my organization to
SBT or anything else. It would be very nice to see ScalaIDE support
Maven well out-of-the-box.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlL9FSsACgkQ0GFaTS4nYxsuAACgpDBoBm+dI/DtOUSxt/JTGcEx
VKoAoLSE/bY2NWYPnKTCOM79H5Oe/5F1
=JToJ
-----END PGP SIGNATURE-----

[Clint Gilbert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/13/2014 01:27 PM, iulian dragos wrote:
> So going back to my previous email, is there something wrong with
> the prepackaged Eclipse bundle

> <http://scala-ide.org/download/sdk.html>?

No, there isn't, but I'd like to point out a scenario that's pretty
common where I work.

1) A developer works on a few projects, some Java, some in other
languages, and already uses Eclipse.

2) the developer is assigned to work on a Scala project, or wants to
add some Scala to their existing Java project.

3) The developer thinks "ok, I'll just google for a Scala plugin.
Cool, there's ScalaIDE, I'll install that."

I'll try the prepackaged Eclipse bundle in the future when it's time
for an Eclipse do-over, but it's never occurred to me to use it until
now, because I've always had an Eclipse setup that works.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlL9Fv4ACgkQ0GFaTS4nYxt6PwCfYicIUtK+TdkuhgOEHCtpWZfR
5M0AoJ07AWEDzIH3gUEfgULFtEeDsvb/
=G1IE
-----END PGP SIGNATURE-----

[iulian dragos]

On Thu, Feb 13, 2014 at 8:03 PM, Clint Gilbert <clint_...@hms.harvard.edu> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/13/2014 01:27 PM, iulian dragos wrote:
> So going back to my previous email, is there something wrong with
> the prepackaged Eclipse bundle

> <http://scala-ide.org/download/sdk.html>?

No, there isn't, but I'd like to point out a scenario that's pretty
common where I work.

1) A developer works on a few projects, some Java, some in other
languages, and already uses Eclipse.

2) the developer is assigned to work on a Scala project, or wants to
add some Scala to their existing Java project.

3) The developer thinks "ok, I'll just google for a Scala plugin.
Cool, there's ScalaIDE, I'll install that."

Thanks for sharing your experience, it's very valuable. It's not that we want to hurt maven users (after all, we're using Maven for the IDE itself), but we don't know how people get started (or have wrong assumptions).

Is it common to "Import existing Maven project" in Eclipse? If so, on my machine I get a wizard that flags the Scala maven plugin as needing a "connector", and offers to download one from the m2e "marketplace". That part didn't work for me, but if David publishes his m2e-scala to the marketplace, it would be automatically resolved. Would that be a good experience?

We'd have to check the license of m2e-scala before we redistribute it, of course.

I'll try the prepackaged Eclipse bundle in the future when it's time
for an Eclipse do-over, but it's never occurred to me to use it until
now, because I've always had an Eclipse setup that works.

Ok, thanks!

iulian

 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlL9Fv4ACgkQ0GFaTS4nYxt6PwCfYicIUtK+TdkuhgOEHCtpWZfR
5M0AoJ07AWEDzIH3gUEfgULFtEeDsvb/
=G1IE
-----END PGP SIGNATURE-----

--
You received this message because you are subscribed to the Google Groups "Scala IDE User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-use...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-user/52FD16FE.2060600%40hms.harvard.edu.

For more options, visit https://groups.google.com/groups/opt_out.

[David Bernard]

Hi,

Few month ago, I start the process to integrate the maven connector marketplace. But there was some issue (change in the process) and I wasn't an active scala developer (so real need). I'll take a look to try again to integrate m2e-scala in the marketplace.

To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-user/CAOwe9fZ6cw5_X%3DM4X5DNN98K04YPra6_36dN2UXNYQq39O0skw%40mail.gmail.com.

[iulian dragos]

On Fri, Feb 14, 2014 at 11:10 AM, David Bernard <david.be...@gmail.com> wrote:

Hi,

Few month ago, I start the process to integrate the maven connector marketplace. But there was some issue (change in the process) and I wasn't an active scala developer (so real need). I'll take a look to try again to integrate m2e-scala in the marketplace.

Thanks, David! Let us know if you need any help!

 

To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-user/CAK3XY7R%3DmyzsBMO2QGECRgmjafmAEOUg4xMWsC2fH%3DRs_9Mz4g%40mail.gmail.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Eric Kolotyluk]

On 2/13/2014 10:27 AM, iulian dragos wrote:

On Thu, Feb 13, 2014 at 6:30 PM, Eric Kolotyluk <eric.ko...@gmail.com> wrote:

No, I was not aware of m2eclipse-scala, so thanks for the tip. I have now installed that, and will test it later to see if it helps.

Here is the problem though, it is just one more piece of knowledge that is not easy to find, otherwise I would have found it.

Over the years I have come to realize the following important lesson: don't document it, automate it. In fact, that is why I really like Maven so much, because it embodies that principle.

A better solution would be, that when I install Scala IDE, some automated process should also install m2eclipse-scala. As a backup, when the scala-ide tooling initializes in Eclipse, it should check to see if m2eclipse-scala is also installed, and tell the user that should be installed too.

I worked on a project a few years ago, sort of a light weight enterprise service bus, I went to extraordinary lengths to automate as much as I could. In particular, I deferred much of the setup/installation/deployment to the actual run-time. For example, there was a file intersystem-service.jar that was the normal service run-time. It was started with "java -jar intersystem-service.jar" -- that's it, no other crap about classpaths or other settings. One of the things it depended on was PostgreSQL, so when it started, it looked to see if PostgreSQL was installed, and if it was not, it would install it. Then it would check to see if all the databases had been configured properly, and if not, it would configure them; and so on, and so on. The point was, this made the service 'self healing' so if someone accidentally deleted the database, it would recreate it.

I called this approach to software design: paranoid programming. That is, always assume the worst, in particular that developers and users don't really know what they are doing, and are not willing to take the time to read any documentation. Furthermore, assume that people will do stupid things to break your product, so always check that things are sane, and restore them to sanity if necessary.

The results of this approach were better than I had hoped, and not only did it simplify a lot around installation and deployment, but it made development and testing much more productive. For example, if I was playing around with some database ideas, and made a mess, I would just delete the database, and restart the service, knowing with confidence it would all be restored automatically.

So, in my world, if m2eclipse-scala is a necessary part of a good Scala IDE experience, then Scala IDE should ensure that m2eclipse-scala is present.

This is the crux of the matter: is it absolutely necessary for a good experience? I don't think it's a (technical) problem to add a dependency on m2eclipse-scala and pull it automatically in our update site. I was under the impression that maven was less used in the Scala world, and people hate bloated software. My reasoning is: if people want an easy start, they pick the prepackaged Eclipse download (it comes with all plugins, including m2e-scala). If they want to handle installation themselves, they get only what they explicitly install. So going back to my previous email, is there something wrong with the prepackaged Eclipse bundle? 

On a related note: if you import an existing maven project, don't you get a wizard asking to find connectors for (some) maven phases? That would normally point out there's an error, and the project won't work well. I'm not sure exactly how/if m2eclipse-scala is showing up, but I think it might be related to the m2e market place (David, maybe this would make it automatically resolve?):

https://wiki.eclipse.org/Submitting_M2E_marketplace_entries

iulian

While many people in the Scala world use SBT, SBT does not do all the things that Maven does, so there are still many good reasons to use Maven with Scala projects. In some cases, people invoke SBT from Maven.

The main problem with the prepackage Eclipse bundles, such as http://scala-ide.org/download/sdk.html, is that they do not fit every organization's workflow. Consequently, it is still important/useful for Scala to work with a variety of Eclipse packaging styles, and I think we should strive to improve the user experience going this route as well.

I can't comment on "if you import an existing maven project, don't you get a wizard asking to find connectors for (some) maven phases?" It has been a while since I tried this. When I was starting from scratch and creating a Scala project based on a Maven archetype, I saw no such useful warning about the m2eclipse-scala connector.

Cheers, Eric

To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-user/CAOwe9fZwyzG8fX7CMZhrkCNF3D2eOxQDUU2_yt2AQD2LNvUKyg%40mail.gmail.com.

[Eric Kolotyluk]

On 2/13/2014 10:55 AM, Clint Gilbert wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 02/13/2014 12:30 PM, Eric Kolotyluk wrote:
>> Over the years I have come to realize the following important
>> lesson: /*don't document it, automate it*/.
> Hear, hear.
>
>> So, in my world, if m2eclipse-scala is a necessary part of a good
> Scala IDE experience, then Scala IDE should ensure that
> m2eclipse-scala is present.
>
> I've been burnt by forgetting to install m2e-scala in the past as
> well. I now install it by rote, but I could imagine a newcomer would
> not know to do that and would have a bad experience.

I have been burnt several times by this because I do not do it enough to
install m2e-scala by rote. That is the problem with infrequent
activities, you forget the steps you previously did.

>
> This is likely a naive question, by why isn't m2e-scala just part of
> the ScalaIDE distribution? Or, why doesn't ScalaIDE support Maven
> better immediately post-install?
>
> Is it because Maven isn't fashionable in the Scala community? I don't
> like Maven very much - I don't know anyone who does - but it works,
> and for a variety of reasons, we prefer Maven at my organization to
> SBT or anything else. It would be very nice to see ScalaIDE support
> Maven well out-of-the-box.

I actually like Maven quite a bit. Sure it has caused me a lot of pain,
but with some of the great material such as:

http://www.packtpub.com/getting-started-with-apache-maven/video

using Maven is less scary than it used to be.

[Clint Gilbert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/14/2014 11:43 AM, Eric Kolotyluk wrote:
> using Maven is less scary than it used to be.

That's definitely true. I suppose I've never used a build tool that I
/liked/, because they've all been messy and complicated. But builds
are a messy, complicated topic, and probably always will be, so I
don't mean to pick on Maven. It's what I prefer to all the
alternatives, after all.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlL+dD8ACgkQ0GFaTS4nYxvX0gCePqpZTqLp/CCLB5HEu/ta3xr1
nXwAniP4lUUgRDLL2DoBXa3HvM+iR0C2
=Tmx4
-----END PGP SIGNATURE-----

[Clint Gilbert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/14/2014 04:43 AM, iulian dragos wrote:
> Is it common to "Import existing Maven project" in Eclipse? If so,
> on my machine I get a wizard that flags the Scala maven plugin as
> needing a "connector", and offers to download one from the m2e
> "marketplace". That part didn't work for me, but if David publishes
> his m2e-scala to the marketplace, it would be automatically
> resolved. Would that be a good experience?

I use "Import existing Maven project" almost exclusively. I've
learned the hard way to either install the m2e connectors I need, or
ignore the warnings; the "download from 'marketplace'" option has
never worked reliably.

Maybe the marketplace stuff will work better in the future, but until
then, I'd love to be able to say, conceptually, "install the Scala
plugin" and have everything I need to do Scala work installed. If
m2e-scala was another box I could check off when installing ScalaIDE
via an update site, that would be very nice.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlL+dYYACgkQ0GFaTS4nYxuRzQCgwr5PuVQvOlo7LvLtgQ5+9SYN
8V0An3oKpQezlvQtnMmCS8N81aVVr3Co
=J453
-----END PGP SIGNATURE-----

[iulian dragos]

On Fri, Feb 14, 2014 at 8:59 PM, Clint Gilbert <clint_...@hms.harvard.edu> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/14/2014 04:43 AM, iulian dragos wrote:
> Is it common to "Import existing Maven project" in Eclipse? If so,
> on my machine I get a wizard that flags the Scala maven plugin as
> needing a "connector", and offers to download one from the m2e
> "marketplace". That part didn't work for me, but if David publishes
> his m2e-scala to the marketplace, it would be automatically
> resolved. Would that be a good experience?

I use "Import existing Maven project" almost exclusively.  I've
learned the hard way to either install the m2e connectors I need, or
ignore the warnings; the "download from 'marketplace'" option has
never worked reliably.

Maybe the marketplace stuff will work better in the future, but until
then, I'd love to be able to say, conceptually, "install the Scala
plugin" and have everything I need to do Scala work installed.  If
m2e-scala was another box I could check off when installing ScalaIDE
via an update site, that would be very nice.

We'll look into it. If it was under the same category as the worksheet and ScalaTest, would it be discoverable enough?

 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlL+dYYACgkQ0GFaTS4nYxuRzQCgwr5PuVQvOlo7LvLtgQ5+9SYN
8V0An3oKpQezlvQtnMmCS8N81aVVr3Co
=J453

-----END PGP SIGNATURE-----

--
You received this message because you are subscribed to the Google Groups "Scala IDE User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-use...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-user/52FE7586.4020603%40hms.harvard.edu.

For more options, visit https://groups.google.com/groups/opt_out.

[Clint Gilbert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/26/2014 12:03 PM, iulian dragos wrote:
>
> Maybe the marketplace stuff will work better in the future, but
> until then, I'd love to be able to say, conceptually, "install the
> Scala plugin" and have everything I need to do Scala work
> installed. If m2e-scala was another box I could check off when
> installing ScalaIDE via an update site, that would be very nice.
>
>
> We'll look into it. If it was under the same category as the
> worksheet and ScalaTest, would it be discoverable enough?

Yes, that would be good, especially if the m2e component could have a
descriptive name or other description associated with it. "m2e-scala"
is a perfectly fine name, but if you're not familiar with the
particular implementation of Maven integration bundled by Eclipse,
"m2e-scala" isn't terribly evocative.

Thanks for considering this! Maven isn't fashionable in the Scala
world - and I don't know anyone who /likes/ it - but it's how a lot of
projects get built. Making ScalaIDE Maven integration easier
out-of-the-box will improve people's perception of Scala.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlMOKpUACgkQ0GFaTS4nYxvBygCgmID2sxOMh96M9mQ+BqjtsDOe
nxoAnjXUie7cEj6nbBPFx8fyn19Zo+Cr
=KjvY
-----END PGP SIGNATURE-----