Can't seem to get my fatjar to run, find the main class

[bytor99999]

I am sure it is me just being stupid and also that I think the last time I ran from a jar file was maybe 10-15 years ago. So not sure what I am missing.

/Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/bin/java -Dfile.encoding=UTF-8 -jar /Users/mark/devroot/projects/hdpoker/game-server/target/game-server-0.1.0-SNAPSHOT-fat.jar

Error: Could not find or load main class com.hdpoker.gameserver.verticle.HDPokerGameServer

I have the pom file with creating the manifest file, exactly copied from the examples with the maven shade plugin. The class and package are 100% correct. And I see the class in the jar file. 

Thanks

Mark 

[bytor99999]

I resolved it. Had to get rid of a bunch of <scope>provided</scope> from our pom files. :D

Mark

[bytor99999]

However, the docs say this..

The fat jar must have a manifest with:

• Main-Class set to io.vertx.core.Starter

• Main-Verticle specifying the main verticle (fully qualified name)

But the simplest maven sample project puts your main class in as the Main-Class without a Main-Verticle.

Which way is correct?

Thanks

Mark

[Assen Todorov]

Hi Mark,

The simplest maven sample project is an example how to use Vertx in embedded mode (as the name of the main class says ;-) ). That's why, there is no need to start your application via io.vertx.core.Starter, hence the Main-Verticle element is not set.

Regards,

Assen

[bytor99999]

Thanks. So then why does that project create a fat-jar then? Sorry, I am confused. I thought what you did for a fat-jar was create a class that has public static void main() that would have code to start up Vert.x Vertx.vertx() etc. And then you call code to deployVerticles and such. It there a second way to use fat-jars where it would be exactly like what you had in mod.json and modules? Where there is no main class with psvm>. Because I think the two are very different and both should be very well documented.

Thanks

Mark

[Tim Fox]

A fatjar just means it's an executable java jar with all the dependencies wrapped up inside.

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[bytor99999]

But there are two ways in regards to Vert.x how to set that up. One where it runs the Verticle you want as your "startup" verticle, and the other where you just call a class that has a static void main in it. And the docs just represent the first way. Whereas, we are doing it the second way. For us this let's us instantiate a Spring ApplicationContext. Since all our Handlers are created as Spring Beans and our Verticle can lookup by type, and loop through them to register them all in a few lines of code. It also allows us to segregate each "message" type we receive into individual classes per message use case. And to extract all the commonalities into an abstract base handler.

Anyway, I digress.

Thanks

Mark

[Tim Fox]

On 26/06/15 19:00, bytor99999 wrote:

But there are two ways in regards to Vert.x how to set that up. One where it runs the Verticle you want as your "startup" verticle, and the other where you just call a class that has a static void main in it.

Whether you're using Spring Boot, Vert.x or any other framework, a fatjar is simply an executable jar that contains the application's dependencies and a manifest which tells the JVM what the main class is. None of that is Vert.x specific.

It's completely up to you what you decide to use as your main class. If you want to run Vert.x completely embedded as in the "maven-simplest" and "gradle-simplest" examples in the examples repository then you can just write your own main class and just use that.

But of course, Vert.x comes with its own main class called io.vertx.core.Starter - and that's exactly the same main class that gets run when you install Vert.x on your path and run Vert.x on the command line with "vertx run".

So, if you're writing your code as verticles then it makes sense to just use that! You could write your own main class and call vertx.deployVerticle() in it, but that's pretty much what Starter does anyway, plus it handles all the command line args for you.

The examples "maven-verticle" and "gradle-verticle" in the examples repo show examples of using Starter as your main class.

And the docs just represent the first way.

Which docs are you referring to?

[bytor99999]

On Friday, June 26, 2015 at 11:24:48 AM UTC-7, Tim Fox wrote:

On 26/06/15 19:00, bytor99999 wrote:

But there are two ways in regards to Vert.x how to set that up. One where it runs the Verticle you want as your "startup" verticle, and the other where you just call a class that has a static void main in it.

Whether you're using Spring Boot, Vert.x or any other framework, a fatjar is simply an executable jar that contains the application's dependencies and a manifest which tells the JVM what the main class is. None of that is Vert.x specific.

It's completely up to you what you decide to use as your main class. If you want to run Vert.x completely embedded as in the "maven-simplest" and "gradle-simplest" examples in the examples repository then you can just write your own main class and just use that.

But of course, Vert.x comes with its own main class called io.vertx.core.Starter - and that's exactly the same main class that gets run when you install Vert.x on your path and run Vert.x on the command line with "vertx run".

So, if you're writing your code as verticles then it makes sense to just use that! You could write your own main class and call vertx.deployVerticle() in it, but that's pretty much what Starter does anyway, plus it handles all the command line args for you.

The examples "maven-verticle" and "gradle-verticle" in the examples repo show examples of using Starter as your main class.

And the docs just represent the first way.

Which docs are you referring to?

Vert.x 3.0 Documentation. And that is my only point. Is that there are different ways to make your fat-jar run your Vert.x application an that the documentation should represent and say that. But it only says one thing, Main class is Starter and Main-verticle needs to be set.

My only point is that the documentation has to be updated so that people like me that just don't get it and spend days trying to get the simplest thing to just work. Yes, it took me days to realize this and get my fatjar Vert.x application just to start up. Unfortunately, and I have been in the same position, that you are too close to the code and how things work, that you take a lot of things for granite on what should be "common" easy to see knowledge, that really isn't. 

Something as common and stupid as running java -jar is small and common knowledge by itself. But when you add one thing like Vert.x to the mix, and the Vert.x documentation says it only one way, and that isn't how you have it, because there is another way, you want some help and the documentation to be complete. 

That is it, just that one suggestion that I am asking here is to add to the Vert.x documentation on running a fatjar to have either Main-class be your own application's psvm class, or have main-class point to Vert.x Starter class, but that you also then have to set main-verticle in your manifest file.

 Thanks

Mark

[Tim Fox]

On 27/06/15 22:07, bytor99999 wrote:

On Friday, June 26, 2015 at 11:24:48 AM UTC-7, Tim Fox wrote:

On 26/06/15 19:00, bytor99999 wrote:

But there are two ways in regards to Vert.x how to set that up. One where it runs the Verticle you want as your "startup" verticle, and the other where you just call a class that has a static void main in it.

Whether you're using Spring Boot, Vert.x or any other framework, a fatjar is simply an executable jar that contains the application's dependencies and a manifest which tells the JVM what the main class is. None of that is Vert.x specific.

It's completely up to you what you decide to use as your main class. If you want to run Vert.x completely embedded as in the "maven-simplest" and "gradle-simplest" examples in the examples repository then you can just write your own main class and just use that.

But of course, Vert.x comes with its own main class called io.vertx.core.Starter - and that's exactly the same main class that gets run when you install Vert.x on your path and run Vert.x on the command line with "vertx run".

So, if you're writing your code as verticles then it makes sense to just use that! You could write your own main class and call vertx.deployVerticle() in it, but that's pretty much what Starter does anyway, plus it handles all the command line args for you.

The examples "maven-verticle" and "gradle-verticle" in the examples repo show examples of using Starter as your main class.

And the docs just represent the first way.

Which docs are you referring to?

Vert.x 3.0 Documentation.

Do you mean this:

http://vertx.io/docs/vertx-core/java/#_executing_verticles_packaged_as_a_fat_jar ?

This is actually the first time I have read this part of the documentation.

This part of the documentation specifically talks about running *verticles* as fat jars, so it seems correct to me.

And that is my only point. Is that there are different ways to make your fat-jar run your Vert.x application an that the documentation should represent and say that. But it only says one thing, Main class is Starter and Main-verticle needs to be set.

Yes, but only if you want to run your *verticle* as a fatjar.

Clearly you can set manifest in an executable java jar to point to any main class you like - e.g. your own alternative main class that's not Vert.x specific, it's just the way java works and you can do that with any Java application. I'm not sure it's necessary to make that point here, but I guess we could add a line if it makes things any clearer...

My only point is that the documentation has to be updated so that people like me that just don't get it and spend days trying to get the simplest thing to just work.

If you had gone to the first page of the docs http://vertx.io/docs/ then followed the link in the first paragraph "Getting Started" to the helloworld example in Gradle - that would give you a working example of *exactly* what you want - a fatjar that *doesn't* use verticles.

I'm not sure how we could make this any simpler...

Yes, it took me days to realize this and get my fatjar Vert.x application just to start up. Unfortunately, and I have been in the same position, that you are too close to the code and how things work, that you take a lot of things for granite on what should be "common" easy to see knowledge, that really isn't. 

Something as common and stupid as running java -jar is small and common knowledge by itself. But when you add one thing like Vert.x to the mix, and the Vert.x documentation says it only one way,

The Vert.x documentation doesn't say there is only one way, and as mentioned above the first links from the "Getting Started" take you directly to where you want to go.

[Tim Fox]

I've made some updates to this section anyway, hope it makes it clearer:

https://github.com/eclipse/vert.x/commit/dd6332a8684c3695d7d7c6c6b60614268666868f

[bytor99999]

Yeah, it is just to make the docs clearer. I understand that both ways are fine, both ways work. I just got confused by the docs. And since we are using Maven, we wouldn't have looked at the gradle example project. The first place anyone will go to first is the documentation, then to any examples that are appropriate to their own environment. Most of us want to be able to find things quickly and easily, and I think most of us first go to the documentation. Then to examples or Javadocs. Since Manifest wouldn't be in javadocs, the first place I would go it documentation.

That is my only point. We need it in the docs. And you have made the change, so thank you very much.

Mark

[Tim Fox]

On 28/06/15 19:31, bytor99999 wrote:

Yeah, it is just to make the docs clearer. I understand that both ways are fine, both ways work. I just got confused by the docs. And since we are using Maven, we wouldn't have looked at the gradle example project.

I said Gradle because I thought you were using Gradle, but if you're using the Maven, there's one for that too!

Start from the docs page:

http://vertx.io/docs/http://vertx.io/docs/

"Getting started". It's assumed that folks that want to get started will start there. That's why we put it at the very top of the docs page, as it's assumed most folks will start reading a page from the top to the bottom.

Literally the _very first example_ link (Click on the word Maven) will take you to a fully working example that shows you exactly what you want to do (fatjar with no verticle).

It's called "Maven simplest" and is basically the simplest Maven fatjar project. https://github.com/vert-x3/vertx-examples/tree/master/maven-simplest

[Tim Fox]

On 28/06/15 19:56, Tim Fox wrote:

On 28/06/15 19:31, bytor99999 wrote:

Yeah, it is just to make the docs clearer. I understand that both ways are fine, both ways work. I just got confused by the docs. And since we are using Maven, we wouldn't have looked at the gradle example project.

I said Gradle because I thought you were using Gradle, but if you're using the Maven, there's one for that too!

Start from the docs page:

http://vertx.io/docs/http://vertx.io/docs/

Somehow that link got garbled so here it is again:

http://vertx.io/docs/

Alternatively you could just go to http://vertx.io and click the big tab at the top that says "documentation" ;)

[bytor99999]

I know that maven simplest is there. This isn't about that. Most people first go to the documentation and read that. That is all I did. I typically don't go through examples because they are just that, too simple of examples. Our examples are a perfect example of too simple and not matching what we have in the "real" world. 

And it is understandable, you want to have the simplest smallest example that completely demonstrates that one thing it is showing. 

But, for example all the Groovy vertx-unit examples and tests are all based on vertx-unit Groovy, but none of them demonstrated integration with JUnit. Well we have hundreds of JUnit Integration tests that need to be converted to the new vertx-unit. The examples were great, but showed me nothing of what I needed to change. It took many days to get it correct, because the examples and documentation did NOT get us 100% there. Maybe about 40-50% there.

There is NOTHING wrong with that. I am just trying to help to make the documentation and then examples that much better to get us closer. 

This problem happens in most projects, the developers are too close to the code to be able to write detailed documentation covering areas that are fully needed because you have to take certain things for granite, or what seems like common sense to the developer. But is difficult for someone on the outside to see or understand. Call us newbies, simpletons, or whatever, but sometimes what seems simple and easy for the developer of the project is NOT to those trying to use it in their applications.

Thanks

Mark

[Tim Fox]

Sorry Mark, I have to disagree here.

Docs can always be improved, but we specifically have a "Get Started" section right at the beginning of the docs, where the first link would have taken you exactly where you wanted to go and prevented "days" of you trying to figure out how to do it.

We've designed it deliberately that way, and the expectation is that a new user will start there. Now, of course we can't force users to look at that section, and some users will ignore it. But if you choose to ignore that section you can't then turn around and complain that the Vert.x docs were structured in a way that made it really hard to figure out how to get started ;)

[Tim Fox]

On 28/06/15 23:41, bytor99999 wrote:

I know that maven simplest is there. This isn't about that. Most people first go to the documentation and read that. That is all I did. I typically don't go through examples because they are just that, too simple of examples. Our examples are a perfect example of too simple and not matching what we have in the "real" world. 

And it is understandable, you want to have the simplest smallest example that completely demonstrates that one thing it is showing. 

But, for example all the Groovy vertx-unit examples and tests are all based on vertx-unit Groovy, but none of them demonstrated integration with JUnit.

The example is here https://github.com/vert-x3/vertx-examples/blob/master/unit-examples/src/test/java/io/vertx/example/unit/test/MyJUnitTest.java

[Tim Fox]

On 28/06/15 23:41, bytor99999 wrote:

I know that maven simplest is there. This isn't about that. Most people first go to the documentation and read that. That is all I did. I typically don't go through examples because they are just that, too simple of examples. Our examples are a perfect example of too simple and not matching what we have in the "real" world. 

And it is understandable, you want to have the simplest smallest example that completely demonstrates that one thing it is showing. 

But, for example all the Groovy vertx-unit examples and tests are all based on vertx-unit Groovy, but none of them demonstrated integration with JUnit. Well we have hundreds of JUnit Integration tests that need to be converted to the new vertx-unit. The examples were great, but showed me nothing of what I needed to change. It took many days to get it correct, because the examples and documentation did NOT get us 100% there. Maybe about 40-50% there.

There is NOTHING wrong with that. I am just trying to help to make the documentation and then examples that much better to get us closer. 

This problem happens in most projects, the developers are too close to the code to be able to write detailed documentation covering areas that are fully needed because you have to take certain things for granite, or what seems like common sense to the developer. But is difficult for someone on the outside to see or understand.

That's true.

Call us newbies, simpletons, or whatever, but sometimes what seems simple and easy for the developer of the project is NOT to those trying to use it in their applications.

Well I know you're not a newbie Mark. And your feedback is always appreciated :)

[bytor99999]

On Monday, June 29, 2015 at 12:18:16 AM UTC-7, Tim Fox wrote:

Sorry Mark, I have to disagree here.

Docs can always be improved, but we specifically have a "Get Started" section right at the beginning of the docs, where the first link would have taken you exactly where you wanted to go and prevented "days" of you trying to figure out how to do it.

I agree with that. However, since we have been using Vert.x for almost 3 years now, we aren't "getting started" But we are converting from one version to another. But in good news is that I am writing all this down and we could add it to the documentation, or blog post. ;)

Thanks again.

Mark