Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spring Boot Support #10

Closed
appreciated opened this issue Nov 6, 2017 · 14 comments
Closed

Spring Boot Support #10

appreciated opened this issue Nov 6, 2017 · 14 comments
Assignees
Labels

Comments

@appreciated
Copy link

appreciated commented Nov 6, 2017

Hello very neat solution you got here.

I have the following problem I have a "ready to go" packaged jar file with spring boot which you can simply start via java -jar ... which I want to package with electron, which should be pretty easy with this project.
The existing test application provides it's own source, which does not quite match my own usecase,
and I couldn't find instructions what to do If I only want to use an existing jar. Before diving deep into the scripts I wanted to ask if there might by an easy way to get my usecase running.

Regards.

@jreznot
Copy link
Owner

jreznot commented Nov 6, 2017

Unfortunately, I have no time to provide any ready to use solutions. It is just a Proof-Of-Concept solution that you should adopt to your needs and not a framework at all.

@jreznot jreznot closed this as completed Nov 6, 2017
@jreznot jreznot self-assigned this Nov 6, 2017
@appreciated
Copy link
Author

Which is totally understandable! Would you accept pull requests that make it easier to include custom jars (I was thinking about an additional script parameter and a concerning tweak for the readme)?

@jreznot
Copy link
Owner

jreznot commented Nov 6, 2017

Including custom JARs is available right now, just add necessary dependencies in build.gradle file. In case of Spring Boot - you have to start an additional servlet in org/strangeway/electronvaadin/Launcher.java to be able to work with it or integrate it somehow into Vaadin application. Please note, that this demo uses Vaadin as UI and it cannot be changed, since it is the main idea of the sample - use Java only for the entire application.

@jreznot
Copy link
Owner

jreznot commented Nov 6, 2017

I'm interested in any generic ideas / pull requests that can help developers to build apps using this stack.

@appreciated
Copy link
Author

appreciated commented Nov 6, 2017

Please note, that this demo uses Vaadin as UI and it cannot be changed, since it is the main idea of the sample - use Java only for the entire application.

I'm aware of that 🙂.

Including custom JARs is available right now, just add necessary dependencies in build.gradle file. In case of Spring Boot - you have to start an additional servlet in org/strangeway/electronvaadin/Launcher.java to be able to work with it or integrate it somehow into Vaadin application.

Just to make things more clear, I am talking about a Vaadin Springboot application.
My goal is that I add the built jar to a specific directory and then build the electron application via a script which then outputs the executable.

This probably requires me to add beforehand some extra dependencies since you seem to do some interprocess communication via JS right?

Another question of mine, I found that you didn't add any license to this repo, in my country if i'm correctly informed this forbids me even to download your repository? Or evenmore so any commercial use of your code. Is this intended by you 😅?

@jreznot
Copy link
Owner

jreznot commented Nov 6, 2017

As of the license - it is the same as other stuff of CUBA Platform team on the Github - Apache License 2.0. I've just added the LICENSE file to the repo. If you provide Vaadin SpringBoot integration it would be great, just do not bring any specifics of your application and usage, use generic approaches. If you are planning to add custom jars from files then it is not interesting approach for others. Just fork the repo and create your application.

In fact - this repo is not a library/framework, it does not have any APIs, so anything can be changed dramatically in the future.

@appreciated
Copy link
Author

Thank you for adding the license I will try my best, and I will keep in mind to only use generic approaches 😉.

@appreciated
Copy link
Author

If you are interested you can checkout my fork it is already working.
Do you have some ideas what could be improved?

@jreznot
Copy link
Owner

jreznot commented Nov 11, 2017

Hi, I've checked your improvements. I do not want to merge them here, because they are relevant only for those who do not use Vaadin for UI. I'd rather implement Spring integration with Vaadin-Spring Add-on: https://vaadin.com/directory/component/vaadin-spring , see #11

Also, I see that you propose to add jars as files, this is a strange approach. It would be better if we can add jars as Maven dependencies. Anyway, it is not the case for this demo repository. I propose to extract JS launcher to a separate project if you want to use it for Spring Boot applications with custom front-end. There is no need to add Vaadin dependencies for such projects, but instead, we can provide Spring Boot template application.

@appreciated
Copy link
Author

appreciated commented Nov 11, 2017

Hi, I've checked your improvements. I do not want to merge them here, because they are relevant only for those who do not use Vaadin for UI. I'd rather implement Spring integration with Vaadin-Spring Add-on: https://vaadin.com/directory/component/vaadin-spring , see #11
Also, I see that you propose to add jars as files, this is a strange approach. It would be better if we can add jars as Maven dependencies. Anyway, it is not the case for this demo repository. I propose to extract JS launcher to a separate project if you want to use it for Spring Boot applications with custom front-end. There is no need to add Vaadin dependencies for such projects, but instead, we can provide Spring Boot template application.

First of all if you don't want to merge the new approach thats fine. By reading your comment I got the feeling you might have misunderstood the alternative approach so just to recap:

The new approach is for users who have a slightly different use case than the current one.
If the user wants to ship his ready programmed application as an executable (no matter what framework he is actually using [I tested it with a Vaadin UI]) without adding any code to his application. He can simply built his Vaadin application (with f.e. SpringBoot) externally with the Buildtool of his choice as jar and drop it in the jar folder and run the build script. This will output an Electron Application which starts his jar file and then call a specific url.

If the user requires to actually communicate with the electron framework which is in your solution the case the user needs to add code to his application.

So the difference is that the user does not need to add code to his existing application but is still able to wrap it in electron which I personally find quite nice. Also it allows Users who built their Webapp with another framework to use the library (but this was only a side effect) my primary goal was to make it simpler for a user with a different use case.

Edit:
There is the possibility that I keep this as a fork for users who have the same use case as I do.

@jreznot
Copy link
Owner

jreznot commented Nov 11, 2017

In this case, lets build something like electron-vaadin-wrapper that will contain only code that is required for wrapping an application. That will be really useful for existing applications. But I'd like to keep this demo as a separate PoC on the approach rather than ready to use tool/framework. You can develop your fork in parallel or even rename (if you want) it to fill the niche of electron-runner for java apps. Actually, your approach does not require java source at all, so I recommend that you remove them completely from the project.

My concern is only for purpose of these two approaches. It seems, they should be implemented in separate projects / separate starters.

@jreznot
Copy link
Owner

jreznot commented Nov 11, 2017

Besides, thank you for joining me in this direction of the application development. I'm glad that this topic is relevant for someone else.

@appreciated
Copy link
Author

appreciated commented Nov 12, 2017

In this case, lets build something like electron-vaadin-wrapper that will contain only code that is required for wrapping an application. That will be really useful for existing applications. But I'd like to keep this demo as a separate PoC on the approach rather than ready to use tool/framework. You can develop your fork in parallel or even rename (if you want) it to fill the niche of electron-runner for java apps.

Sounds like a good idea. I also think that it is better to fork it and keep it separate.

Actually, your approach does not require java source at all, so I recommend that you remove them completely from the project.

I will do so 😉.

Besides, thank you for joining me in this direction of the application development. I'm glad that this topic is relevant for someone else.

You are welcome!

@pgerhard
Copy link

hey guys, thanks for both your work in this direction. I was looking for something like this for a side project

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants