Comments (7)
The whole IntelliJ IDEA stuff is very complex compared with what is needed to support Eclipse. I checked the wole thing some months ago. I'll try to write down what I remember about it....
If I create a new GWT project in IntelliJ I get the following things preconfigured:
- A library referencing gwt-user
- Web facet
- GWT facet
- referencing GWT SDK
- referencing Web facet
- exploded-war artifact
- Referencing Web facet, GWT facet output and gwt-servlet.jar
- Module containing the facets and referencing the gwt-user library
The whole stuff is only necessary if you have a fully feature GWT web application. If you simply need the GWT compiler, you will only need a subset (mainly the GWT facet with SDK + gwt-user library).
If using Gradle's "idea" plugin, you won't get anything of the above mentioned. So to really support IntelliJ integration, the gwt-gradle-plugin would have to do everything mentioned above depending on weather you have a web application or not. In my opinion, much of that stuff would better be part of Gradle's "idea" plugin, but I guess this won't happen.
If using IntelliJ's Gradle plugin, IntelliJ will generate the artifact and war facet for you. If the gwt-gradle-plugin would generate the above mentioned things, you will have some duplicates. So in this case, the gwt-gradle-plugin would only have to generate a subset of those things and generate those to work with the ones generated by IntelliJ itself.
A problem would be that you would have to manipulate e.g. the artifact generated by IntelliJ to respect the GWT specific stuff (e.g. the GWT compiler output and gwt-servlet).
So this isn't really ideal.
Back to the original question: I don't really see how adding the mentioned configurations to the provided Classpath of the IntelliJ project. As far as I see, this only enables IntelliJ to do a working Java compilation but it doesn't enable IntelliJ to provide real GWT support. I think, the clean way would be to do at least the GWT SDK, GWT facet and gwt-user library stuff to have some usefull support.
But this wouldn't solve the whole GWT web application thing.
Sorry if I'm totally wrong about this, but I don't use IntelliJ often. To be hones, I only used it to look what it generates for a GWT project :)
from gwt-gradle-plugin.
The Gradle "idea" plugin has become less important as Gradle support in IntelliJ has been greatly improved. IntelliJ uses the Gradle Tooling API to get information about the project and then configures the project accordingly.
I have just created a Gradle project with a GWT module and a web.xml in src/main/webapp/WEB-INF. The gradle build file applies the plugins: idea, java, gwt, war. I have then deleted all IntelliJ project settings and imported the project using IntelliJ's "import Gradle project" feature.
It detects GWT and Web facet (done via file detection of web.xml and the GWT module) and creates four artifacts (a normal one and a draft one both packed and exploded). The only thing it doesn't do is to tell the GWT facet which Web facet to use and it does not add GWT compiler output to the Web facet. Also not adding gwt-servlet.jar to the artifact seems to be an IntelliJ decision as it also doesn't do so automatically if you create a GWT+Web project in IntelliJ. You have to do that manually.
So overall the Gradle import is actually not that bad.
I think at the end it would be enough for your plugin to just put GWT SDK on classpath the way I do it in my build files so that Java compilation does not fail and let IntelliJ figure out the rest.
If you want to make it truly portable and fool proof (e.g. configure GWT compiler / DevMode parameters correctly inside the IDE based on Gradle build file, etc.) then you have to write out IDE configuration files anyways and people must use the Gradle "idea" / "eclipse" plugins before importing the project. In that case it is true that you probably have to do a bit more work for IntelliJ.
But for now I would be happy to have gwtSdk and gwt configurations on class path with provided scope out of the box :) And once IntelliJ reuses gwtSdk libraries for the GWT facet the overall experience would just be a lot better.
from gwt-gradle-plugin.
It seems that I have to check your approach :) It really doesn't sound so bad.
from gwt-gradle-plugin.
I followed the suggestions made by @jnehlmeier, and it worked out pretty well for me. I was previously generating the idea modules from gradle directly, then simply opening them in idea. The gradle import is much cleaner, and I'll be using it from now on.
from gwt-gradle-plugin.
I've just seen this issue here for the first time, but independently I've come to the same solution in PR #45. Works pretty well for me and it also works with the IntelliJ Community Editions, which doesn't have real GWT support.
from gwt-gradle-plugin.
@steffenschaefer this has been resolved by 21a3a3b
from gwt-gradle-plugin.
The idea plugin support was added almost 2 years ago but the related code is not yet released and so not very useful. It would make sense to consider releasing version 0.7 soon or at least to provide available patches in some intermediate version (i.e 6.1)
from gwt-gradle-plugin.
Related Issues (20)
- [gwt 2.7.0/gradle 2.12./plug-in 0.6] gwtSuperDev - java.lang.OutOfMemoryError HOT 8
- [GWT 2.8/Pluging 0.6] Issue with gwt sub-projects HOT 1
- [GWT 2.8-SNAPSHOT/Gradle 2.13] Properties issue HOT 5
- Make gwt-unitcache and war directories configurable
- gwt + gradle + lombok issues resolved
- Have any way to generate i18n and generateAsync supported by gwt-maven-plugin? HOT 6
- vaadinCompile issue, with vaadin 8 at 1.0 version
- compileGwt is missing module descriptor of a submodule on classpath HOT 8
- Make the compile tasks cacheable
- Missing support for Gradle Composite Builds
- Gradle ... single directory for all classes .. is scheduled to be removed in Gradle 5.0 HOT 1
- gwt-gradle-plugin uses deprecated api by Gradle 4.0 HOT 3
- Updated GPE Changes Property Variables
- GenerateGdt Task Needs To Also Be a Dependency of eclipseWtp
- Gradle upgrade to 5.4 causes build failure HOT 3
- CreateProcess error=206, The filename or extension is too long HOT 1
- Buildship Support HOT 1
- Has this plug-in been tested with GWT 2.8.Beta? HOT 2
- Integreation with Gretty plugin
- example build failed HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gwt-gradle-plugin.