vert-x / vertx-maven

Vert.x 2.x is deprecated - use instead
https://github.com/vert-x3/vertx-maven-starter
Other
22 stars 31 forks source link

Need to add groovy-all and groovy-lang dependencies #16

Closed jplumhoff closed 10 years ago

jplumhoff commented 10 years ago

As reported on the google group, If you load the archetype and then try to run the integration tests without changing anything, the tests will fail unless the groovy-all and groovy-lang dependencies are added to the pom. It's not surprising, and is easy to fix, but it would be nice to add them (even if commented out) for new users.

javaboon commented 10 years ago

Hi. This issue was reported here in more detail: https://groups.google.com/forum/#!topic/vertx/oK9WRl6ADeY I am still getting this error message with maven archetype 2.0.1: "Groovyc: unable to resolve class org.vertx.groovy.testtools.VertxTests"

javaboon commented 10 years ago

I got it working too. This is for fellow google search engine vert.x trail blazers (how did I ever develop software before google).

    <lang-groovy.version>2.0.0-final</lang-groovy.version>
    <groovy.version>2.2.1</groovy.version>

...

      <dependency>
          <groupId>org.codehaus.groovy</groupId>
          <artifactId>groovy-all</artifactId>
          <version>${groovy.version}</version>
          <scope>provided</scope>
      </dependency>

      <dependency>
          <groupId>io.vertx</groupId>
          <artifactId>lang-groovy</artifactId>
          <version>${lang-groovy.version}</version>
          <scope>provided</scope>
      </dependency>

This is my second Vert.x project. The first one was a big success. Vert.x just works. I admire the simplicity and speed of Vert.x. Ok that was the sugar.

I view archetypes as help for new users to get started. I was very committed to making Vertx work as I had read all about it and even benchmarked an earlier version of it against Node.js and for our use case Vertx was 2x faster and could handle 2x more connections than Node.js. I was hooked. (There was another product that was faster and could handle even more connections but it was not free, and its docs were not great.)

On the real project I used the archetype and ignored all error messages and just hacked and hacked as I had a very short delivery window. (We need this in production yesterday type project which is nice in that the simplicity is built-in and scope creep is impossible.)

(this is Rick Hightower btw. javaboon is a project name (it is a paid repo on github, I love github), and I happen to be using the browser that is logged into that project).

Now I am returning to this with fresh eyes. This archetype is just wrong.

This is an everything and the kitchen sink archetype and what you want is a getting started, it just all works archetype. You can have this one, but it can't be missing libs whereby it does not work.

The first rule of archetypes is that they have to just work. Vert.x has too much polish everywhere else to have a sucky archetype that has compile issues. (This is of course opinion.)

You really need a Java only archetype, a JavaScript only archetype and then the kitchen sink that just works.

I say this not as a Vert.x detractor, but as a Vert.x fan. I have already had one client switch to Spring websocket support because they could not get this stuff to work. So far with my clients, vert.x has only gone to production if I was on the project helping.

Now if your plan is to exclude new users, then this archetype is ok. Sort of a litmus test, you can ride this ride but you have to be this tall. If your plan is to attract new users, then you need a better archetype IMO.

BTW I say this as a fan and supporter.

javaboon commented 10 years ago

Also.. Boon (my pet project) has no archetype and no where near the docs that vert.x has so I say this all in complete hypocrisy as an end user. FYI. I hope Boon one day has 1/2 the polish that vert.x does.

purplefox commented 10 years ago

I'm not sure I understand what the issue is here.

I've tried to creating a new project using the latest archetype (latest is 2.0.2-final), and it all seems to run fine including all groovy integration tests without me having to change anything:

Please see https://gist.github.com/purplefox/8516718

purplefox commented 10 years ago

I also tried this with the previous version of the archetype (2.0.1-final) which you used in this report, and it appears to be work ok with that too:

https://gist.github.com/purplefox/8516760

purplefox commented 10 years ago

I'm going to close this as a non issue, but if anyone can provide any hints as to how I can replicate this, I will re-open it.