search

giovannicandido / slush-spring-aurelia

This is a slush generator to start with a modern FrontEnd Aurelia.io Backend by Java Spring Boot Framework
MIT License
9 stars 3 forks source link

Compilation issue during gradle build #3

Closed cparaskeva closed 7 years ago

cparaskeva commented 7 years ago

:server:compileScala FAILED

FAILURE: Build failed with an exception.

BUILD FAILED

giovannicandido commented 7 years ago

Hi @cparaskeva thanks for the contribution. I will take a look.

Could you also test https://github.com/giovannicandido/generator-spring-spa ?

I take a different path because of standard tools for the client side, so I don't need to maintain the client build all by myself. It also integrates with angular2. Note: The documentation is still very rudmentary

cparaskeva commented 7 years ago

I have also problems running https://github.com/giovannicandido/generator-spring-spa

:server:compileJava FAILED

FAILURE: Build failed with an exception.

BUILD FAILED

giovannicandido commented 7 years ago

Strange, could you please tell me what is the JDK version, vendor and your operation system? Also run with --stacktrace to see the compilation error.

The project is tested with Macosx and Linux using Oracle JDK 1.8.x

But if you are using a different env. I will setup a virtual machine to try replicate.

Thank you very much in advance

cparaskeva commented 7 years ago

I am now able to compile & run the project. Just a question i noticed that you are serving both UI & business logic from spring-boot. Is there a reason why you not splitting each one to seperate server e.g. UI to be served via node and REST API via spring-boot. Finally just a question is thymeleaf template engine "compatible" with aurelia framework?

giovannicandido commented 7 years ago

Hi @cparaskeva

The UI and server logic are served by spring-boot because my current production env is manual administered and takes less time of the sysadmin with a single service. They are not used to a distributed services (even if that is simple as only two components)

But in a cloud env, makes more sense to complete separate the two, specially if the deployment is more automated.

In that cases, the link between the two could be take care by an internal proxy.

Another approach is to use a service discovery, or even simple env variables.

That is an interesting thing to automate in cloud.

You will notice that gulp can serve the client as well, and that is the recommend way in development env.

As with your other question, the template engine in server is completed different from the SPA, and that makes confusion. For instance, if you want to know the current login name, thymeleaf has methods to do that, but that is rendered on the server and the SPA has no strait forward way to read that.

My initial approach has to create a javascript variable in the thymeleaf template, that the SPA could read. I'm not appreciating this anymore because it couples the serve with the client and generates complexity. I going to change that, for a initialization in JSON, every variable that needs to be generated in the server, but consumed in the client will be served as a rest endpoint and consumed as JSON. That way we can completely remove the need for Thymeleaf

cparaskeva commented 7 years ago

Thank you for your explanatory answer. I look forward for your updates!