I am an Eclipse user having metaphysical question before fully switching to IntelliJ.
I have 2 Maven modules:
"main" module which is my main app which uses
"shared" module which is shared by misc applications
I'd like to:
work at the same time on both modules, meaning the changes in "shared" code would be automatically picked by my main app when I run it.
Ideally I would not have to be forced to create & install in my .m2 folder the artifact "shared-SNAPSHOT.jar" for my main app to use the updated code.
be able to work independantly on each one (own .idea containing each it's own launchconfiguration) while sharing in their own respective git repo their own configuration. It would mean:
each can have it's own set of launchconfigurations (the folders in the .idea where are defined the launch configurations)
each would have it's own code formatter setting
=> with this requirement, I want a new dev to be able to just git clone one project and work on it directly with minimal configuration.
What I managed to do:
If I open the "main" module with a .idea preconfigured inside it is ok: I directly have my formatter & my launch configs.
BUT if I then try to open the "shared" module, IntelliJ proposes:
either to open in a new window. The problem is then that I have to INSTALL the shared-SNAPSHOT.jar in my .m2 repo in order for the updated code to be seen by my main app. Is there any way for 2 IntelliJ windows to 'see' the code from one another ?
or to keep the same window, BUT it adds a new config for the imported "shared" module inside "main"'s .idea folder. Which I don't want because I'd like "main" module to be unaware of "shared" (apart from the maven dependency). And I don't want to force any colleague working on "main" to be forced to also import "shared".
Do you have a best practise for me or should I stay with Eclipse ;) ?
Related
I am trying to make use of modules and gradle subprojects and either receive compile time errors or complaints from IntelliJ.
My project structure is as follows:
Root
- settings.gradle
- core
- build.gradle
- desktop
- build.gradle
- src/main/java/module-info.java
The desktop build.gradle file as a requirement on core as:
dependencies {
implementation project(":core")
}
There is no reference to the "core" project in the module-info.java files.
In this configuration, IntelliJ doesn't like usage of classes from the "core" project in the "desktop" project (I see a lot of red), but running gradlew.bat desktop:run works with no issues. Bug with IntelliJ? I am using microsoft's openjdk, but hopefully that doesn't matter.
My best attempt to fix this, was to add a module-info.java file to the core project as well and reference the core project in the desktop project's module-info.java file. Unfortunately this configuration, while making IntelliJ happy, renders me unable to run the desktop from command line anymore. I get errors about the core project being unable to find required modules that are the exact same as the required modules I pull in for the desktop module. I think this might be an error on my part, but I'm not sure how or what to do to fix it.
Would appreciate any insight.
P.S. Of these issues, I think I would prefer to get IntelliJ working with the first setup, because I intend to have this core library be shared between the desktop project and an android project, and while I haven't looked into it yet, I am not sure Android supports new java modules?
I think terminal should be the first priority. If your original setup made it compiled successfully under terminal, then there is no problem in your project. Do not add extra files for just making the IDE happy.
There's still something you can do. The first step is compiling your project successfully under terminal. This step downloads all the necessary dependencies before IntelliJ, reducing the problem scope to IntelliJ's linking and indexing. Then there are some options:
In the Gradle tool window, click the top-left button Refresh all Gradle projects.
Delete all the .idea folders in your project. Then open the root folder of your project via UI or CLI.
Click the invalidate caches/restart in the main menu.
You can also also create a new Gradle multi-module project with command gradle init, and open it with IntelliJ. It should be analyzed by IntelliJ normally. Then you can compare its project structure with yours. Maybe there's something different.
Hope these steps could help you.
I'm trying to do this getting started guide from Spring. So I cloned the project using git from the command line. As I'm working with Gradle, I removed the Maven files from the repository to clean the project.
After that I open my STS and go to File -> Open Projects from File System and navigate to the /initial folder of the repository. The project is imported correctly but when I try to add some "java stuff" (packages, classes, etc.) I get several errors and I can only add folders and files, which is quite annoying for working.
To be more descriptive, I'll add some images so you can see what's happening. This is the project initially imported into STS as I described above:
Then I try to add some java stuff, let's say for example a source folder. So Right Click on library -> New -> Source folder and this is the result:
And in the properties of library I have the following:
So the question is: how can I tell to STS to recognize the library folder as a Java Project (or Gradle module, I don't know how to call it) instead of a plain folder so I can add my packages and classes?
Thanks in advance for your answers.
In case you would like to work with Gradle, you should use the Gradle integration for Eclipse (project Buildship) and install that into your STS environment. After that, you should be able to import the projects either from disc as existing Gradle project (not as file system) or via the wizard that integrates the spring guides into STS (Import Getting Started Content). The wizard for the guides also let you choose between the Maven and the Gradle variant, so you don't need to close and delete stuff yourself.
Hope this helps!!!
Working in a multi-module Maven project, call it "app." I need to work on the source of one of the dependencies, call it "lib", and be able to easily test/debug "app" against my changes in "lib."
In Eclipse this is an option for its Maven and Gradle plug-ins, and is obvious since Eclipse doesn't bind the concepts of "workspace" and "project" as tightly as IntelliJ does. When I cloned the repo for "lib", IntelliJ offered to create a new project for it, but how do I force "app" to use the local working copy of "lib" for compilation and runtime?
To put it another way, can IntelliJ basically encapsulate doing build install on "lib" behind the scenes so that "app" uses the updated (snapshot) of it?
The obvious, cleanest choice would be to combine the two projects into a common Maven multi-pom project. If that is something you can't do (perhaps the projects belong to different teams etc.), then I could imagine you could fake it by using symlinks.
Create a wrapper project with just a pom file and two modules. Instead of folders for the modules, use symbolic links to the actual file locations. Obviously the reactor root pom would not be the parent pom.
Now open the wrapper pom as IntelliJ project.
I don't know if this works, but it's worth a try.
I am having trouble bringing in a subrepository in my project. The idea is that I bring a module in /arbitrary/folder and I want to include it on my current project located at /important/project
When using the GUI Import Module... from the menu the actual folders are copied into my project subfolder. Given that both projects are in different repositories there is a maintenance problem as for every update the files need to be manually reimported and then committed to the main project. Mercurial also doesn't allow you to have subrepos at any depth bigger than root.
What is the correct approach to solve this problem?
You're right that the GUI for Import Module makes a copy instead of importing it in-place. Until that functionality is improved, you'll need to set it up by hand.
In your module being imported, make sure it has a build.gradle file that's properly set up to build the module. Then in your application's settings.gradle file, include it like this:
include ':some_module'
project(':some_module').projectDir = new File('/path/to/module')
Then you can depend on it from another module in the usual way, either by adding a dependency through the Project Structure UI or by adding this to the module:
dependencies {
compile project(':some_module')
}
I'm developing a plugin for Eclipse (4.2 on windows) that uses a bunch of external files (batch scripts, xml files, ecc).
I'm asking if there is a good method to manage those files inside the project in order to:
keep all the plugin resources inside the project for version control in SVN
possibly have an automated plugin installation (including those files outside the plugin jar)
Edit: Can an additional "Feature Project" be a solution?
Instead of having a project I would manage two: one for the plugin and one for the "feature" that references the plugin and gathers the non-plugin data.
In that case, I see that eclipse "Features" have an "installation" section (in "feature.xml"). How could I specify for each "non-plugin" file the install path location?
I'm using nested projects for this.
Create a parent project that will contain everything. For each sub-project, deactivate the default location when you create it and select the parent project's root folder instead.
Here is an example: http://git.eclipse.org/c/tmf/org.eclipse.xtext.git/tree/
It doesn't have a .project file in the root but having one doesn't hurt.
Just remember to import the sub-projects before you start working on them. Otherwise, you and Eclipse might get confused.