Several fixes concerning the Maven config plus GWT plugin - #2

I have no problem adding testatoo as a test scope dependency but I would prefer keep jetty as an explicit compile scope dependency. What's puzzling is that WebSocketTransport.java will not compile with any version of jetty newer than 7.1.6 (due to changes in the WebSocket interface). Yet it compiles with testatoo-container-jetty which depends on jetty 8.0.0.M2.

Also, the jetty-maven-plugin lets me run the samples from the command line.

Regarding the GWT sample, Inplace isn't necessary, I can just run jetty:run-exploded (which only needs mvn package, no clean install).

Hi,

Jetty must not be put as a compile scope dependency. This is a typical dependency scope error that you might do when you start using Maven. The reason is that Maven manages transitive dependencies for you. When you develop in a library with Maven, you have to think about how the project will be used and which library my project must really depend on to work.

If you put jetty as a compile dependency, it means an end-project depending on Socket.IO-Java will transitively get the jetty jars, and they will also get into the war file. This will create conflicts.

With Maven, scopes are really important:

• compile scope = transitive dependency which is bring when a project depend on your library
• optional scope = dependency that is not transitive: a project have to include is manually to activate features of your library
• provided = a dependency required at runtime but which is not transitive since provided by i.e. a container

In the case of your project, the core relies on jetty. So the scope must be optional or provided, since you deploy on jetty containers. The good scope would be provided.
But know you have to think about an other think: when you are running unit test or classes (like the Start* classes) from the test classpath in Maven, provided dependencies are not in the test classpath. This is normal since they are provided so the trick is to make some dependencies like those as optional: they are available in the test classpaths, to compile also, but does not come transitively with the project.

For GWT sample, yes it's true that you can run the app using jetty:run-exploded. It also would be the case if you use the maven plugin to execute the class Start*. The reason why an embedded containers is better to use is:

• you control the dependencies + the way to start the server for your samples
• This is faster than mvn:jetty xyz (what you want is to start the webapp, not to start the maven stack !)
• you can execute REAL automatic integration tests between the JS and the backend side: currently you have no test in your project. With Testatoo, you are able to run integration tests, start a jetty, execute a junit test managed by testatoo to run a browser and use the chat page as if a real human were behind, then close the browser. More generally, you can unit test, which you cannot if you remove it.

I'm an expert in Maven (+5 years) and in unit and ui testing so the commits I propose do not come from nowhere. We have a huge experience in working in maven project (libraries and webapp) and how to unit test them correctly in an automated environnment (i.e. Hudson). So I hope you'll understand the implications of all of this.

Please also note that we are pleased to contribute to this project (this is just a beginning), but if we always end up with discussions like this to prove our points to improve the project, it takes a lot of time and it will be much easier for use to make a distinct clone with a distinct name internally at Ovea and merge into our new open-source project the new features of Socket.IO-Java when they appear.

For your information, Socket.IO-Java runs each time a commit is done in our CI environnement. We are currently in a big project for mobiles and we plan to make these future contributions:

• move to the socket.io javascript trunk
• adding unit test + integration tests +browser tests
  we also might contribute to other features such as blackberry support, which we need.

Sorry for using mixed nomenclature. I'm aware of the difference between "provided" and "compile" scope dependencies. What I should have said that I prefer explicitly identifying the version of jetty needed to compile and run the modules.

If I specify version 7.1.6 of jetty WebSocketTransport.java compiles. If I specify version 8.0.0.M2, it fails to compile due to the changes made to the WebSocket interface in version 7.2.0 of Jetty. But, If I remove the jetty dependencies and instead use the testatoo-container-jetty dependency, it compiles even though testatoo-container-jetty depends on jetty 8.0.0.M2. Why is that? When I run "mvn dependency:tree" it displays:
[INFO] com.glines.socketio:socketio-core:jar:0.1-SNAPSHOT
[INFO] - org.testatoo.container:testatoo-container-jetty:jar:1.0-rc1:provided
[INFO] +- org.testatoo.container:testatoo-container-core:jar:1.0-rc1:provided
[INFO] - org.eclipse.jetty.aggregate:jetty-all:jar:8.0.0.M2:provided
[INFO] - org.mortbay.jetty:servlet-api:jar:3.0.20100224:provided

So how is it that WebSocketTransport.java compiles when the jetty 8.0.0.M2 WebSocket interface includes onFragment, yet WebSocketTransport doesn't override it and should't compile?

Given the MIT license I realize that you don't have to work with me at all so I appreciate that you are in fact trying to work with me. I've spent a lot of time over the last few days reading about maven and I'd appreciate if if you bear with me as I become familier with it.

Hi,

Yes they added a new method on the interface:

    public void onFragment(boolean more, byte opcode, byte[] data, int offset, int length);

So if you see in our fork, we've implemented it like this in WebSocketTransport.java (http://tinyurl.com/5u7j7ln):

    @Override
    public void onFragment(boolean more, byte opcode, byte[] data, int offset, int length) {
        throw new UnsupportedOperationException();
    }

This way, it will compile and run on jetty 8 and also work on jetty 7. Annotations are metadata not used at runtime so the implemented method will just not be used in jetty 7.

I did not check deeply yet on the implementation detail, i.e. if some implementation is required or not, if this method is used or not in the case of Socket.IO for jetty 8. But we are using Jetty 8 + Socket.IO and it works well.

Ah, I hadn't noticed that change to WebSocketTransport in your patch.
I haven't kept track of which browsers implemented which version of the websocket draft so I'm not sure if any of them even use that part of the protocol. Given that the WebSocket JS spec doesn't provide a means of sending fragments, leaving it stubbed out is probably the best approach.

I'll work on merging this pull request tomorrow.

Regarding the chat-gwt sample, do you have any objections to using the exploded war dir instead of placing the compiled GWT in the webapp dir? I like to avoid mixing output with source when I can.

Hi,
For the GWT sample, it simply does not make sense in a Maven project to no use the inplace option. The GWT Maven plugin documentation also recommend this way to go on maven project. The reasons are that it enables starting the webapp directly from an IDE (i.e. in unit tests) or from an automatic test set (junit) and it enables also the startup through mvn jetty:run. The standard way only generate GWT files in the target/output folder which is a temporary place before creating the war archive. So you cannnot unit test anything at all easily and cannot start from your IDE the webapp directly without going through all the maven stack (which is not what you want usually in a project - you want your webapp to start fast).
It's ok also to put generated sources in the webapp folder as long as you exclude the folders in .gitignore.
This is also the fastest way to test since you just need to do a mvn install to recompile the GWT stuff.