-
Notifications
You must be signed in to change notification settings - Fork 93
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
Comments
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. |
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)? |
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. |
I'm interested in any generic ideas / pull requests that can help developers to build apps using this stack. |
I'm aware of that 🙂.
Just to make things more clear, I am talking about a Vaadin Springboot application. 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 😅? |
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. |
Thank you for adding the license I will try my best, and I will keep in mind to only use generic approaches 😉. |
If you are interested you can checkout my fork it is already working. |
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 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: |
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. |
Besides, thank you for joining me in this direction of the application development. I'm glad that this topic is relevant for someone else. |
Sounds like a good idea. I also think that it is better to fork it and keep it separate.
I will do so 😉.
You are welcome! |
hey guys, thanks for both your work in this direction. I was looking for something like this for a side project |
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.
The text was updated successfully, but these errors were encountered: