Intellij IDEA With Multiple Gradle Projects - intellij-idea

I am working on two Gradle projects. One of these projects is a supporting library that will be used by other projects in the future so project A depends on project B but not as a 'multi module project'. The dependency is to be resolved through the artifact repo so project a declares it as a compile dependency using it's maven coordinates.
My problem is when working on these two projects in IntelliJ changes to project B aren't made available to project A until I install it (using the Gradle Maven plugin) in my local repo. This is kind of annoying and slows down my workflow. Is there a way to get IntelliJ to automatically update the dependency internally?

This is supported in the latest versions of Gradle and IntelliJ. It is known as a Composite Build.
Composite builds can be declared in the project's settings.gradle file as follows:
includeBuild '../my-app'
or by using the --include-build command line argument:
$ gradle --include-build ../my-utils run
Take a look at the Composite Builds with Gradle and IntelliJ IDEA Webinar for instructions on how to configure the integration.

In IDEA 2017 you can right-click on the gradle module and use Composite Build Configuration to link the current module to one or more gradle module already opened in the current workspace.

Related

How do you change the default Gradle wrapper and build file in IntelliJ?

I'm trying to switch over to Gradle Kotlin DSL from vanilla Gradle for all my IntelliJ/Kotlin projects. This requires me to specify the distributionUrl property in a Gradle wrapper task of the build file. However whenever I create a Gradle project and choose the "default Gradle wrapper" option, IntelliJ automatically generates a vanilla Gradle version 4.0 (atleast as of right now) wrapper and builds the project using it. Not only does this install an unused Gradle distro on my machine and makes me manually have to recreate the build file and wrapper, but also Gradle 4.0 isn't compatible Java 9.
Is there any way to change what default Gradle wrapper/build file is generated by IntelliJ as I see no wrapper configuration options in the settings tab of the Gradle plugin?
So this is actually a requested feature (thanks to #y.bedrov for the info), but I've found a temporary workaround...
Instead of using the Gradle project creation wizard, you can import a custom buildscript via Import Project. This actually supports Kotlin DSL! However for that, you'll have to add a wrapper task in the buildscript and set the distributionUrl to one of the releases here.

Getting contents and natures of all projects in a Maven build

Currently I'm working on a Maven plugin that should generate files in all projects (OSGi bundles) that have a certain Eclipse project nature.
How can I access the contents of the projects included in the build and the project natures by using the Maven API?
Maven is a standalone build tool, not an Eclipse plugin. You cannot access Eclipse project settings from core Maven API.
Eclipse supports Maven with the M2E Eclipse plugin. It is possible to write M2E extensions and in the extension you can query the project natures via the functions of AbstractProjectConfigurator class.
However, M2E extensions will not run when you compile your code in the command line. I suggest that you choose one of the followings:
Write an Eclipse plugin that generates the source code into the src folder of the maven project. Code generation should be started by the user manually (selecting a context menu in the project or something).
Avoid using Eclipse project natures and solve your questions based on analyzing the source and pom of your project.
If you need to react on certain aspects in the source code like it looks from the thread with Balazs then you can simply write an ordinary maven plugin and include it in the parent pom. It will then run in every project and can analyze the code and react based on it.

IntelliJ IDEA with multiple gradle subprojects

I'm working on multiple Gradle projects with internal and external dependencies, and so far I am happy that thanks to Gradle's dependency management I can modify a library project without affecting every application that uses the library.
When I need to modify a library project and test it using an application project that uses it, I need to do the following,
Modify the library project and commit to SCM
Trigger CI to build the library project and push it to my Gradle repository
Update the application project's build.properties to refer to the new version of library project
Iterate the above steps until everything works and there is no bug
So it became quite combersome now. Can I configure IntelliJ IDEA so that
All my Gradle projects are in one window, like the screenshot below, which is Twitter's Finagle imported using its pom.xml. Sadly IntelliJ's JetGradle plugin doesn't seem to understand Gradle subprojects.
When build.properties's dependencies are my subprojects, read dependency from local snapshot, otherwise download them from the Gradle repository
Thanks.
If you want to open all projects in a single IDEA window, you'll have to aggregate them into a multi-project build, at least until IDEA 13 hits the market. Before IDEA 13, it's better to use Gradle's IDEA integration. Once you have a multi-project build, all you need to do is to add allprojects { apply plugin: "idea" } to the root build script, run gradle (cleanIdea) idea, then open the generated IDEA project.
Currently in IntelliJ IDEA 2019.2 you can add the gradle subprojects like so
Open Gradle Tool Window via View > Tool Windows > Gradle menu
Click on "Link Gradle Project" button (the plus sign)
Select the build.gradle file corresponding to the subproject
Go to File > Project Structure > Modules > NameOfSubproject
Navigate to main/java and click on Mark as: Sources
Mark the main/resources as Resources
Restart IntelliJ IDEA
The sources of the subproject will be recognized by IntelliJ and you can use Navigate Class action for the classes in the subproject

Maven2_Builder vs. Maven Project Builder

I inherited a project that relies on Maven 2 to build it. Via project's Properties > Builders I can see that it has two builders, in this order:
Maven2_Builder
Maven Project Builder
I thought that there should be only one Maven builder...
Why two?
What the relation between the two?
Using the m2e plugin, I can clean the project at any given time via the project's context menu Run As > 6 Maven Clean. Does this mean Eclipse's Project > Clean... is no longer relevant?
Looks like you are using Eclipse with M2E. These days that works very well.
Before one would run
mvn eclipse:eclipse
Which would generate the typical Eclipse configuration files.
These days, just use the Eclipse Import as Maven Project and all necessary files are created.

Maven Source Code Dependencies

I have a couple of projects that I'm working on in Eclipse (or any IDE, so I don't want to depend on specific eclipse dependency maven capabilities). Some projects depend on other projects. Typically in Eclipse I would add the projects as references to other projects, but I'm not sure how to handle this when using Maven. In the deployment environment, there will be jars created and the maven build can pull the latest jars from the repository. Is there a way to reference another project's source code using maven while in the dev environment? For example...
I have this scenario:
Project A depends on B
I need to make a change to B and that will require an update to A. I don't want to make the change to B and check it in without checking in A since that will break A. And I would like to manage these dependencies through Maven -- any help would be appreciated.
thanks,
Jeff
The maven 2 eclipse plugin has 'workspace dependency resolution', where the dependencies are first looked up in the workspace, and then in the repository.
What I do is use SNAPSHOT version when doing my development. Project A depends on the latest SHAPSHOT version of Project B, so when I change Project B, I have Team City recompile and push out a new SHAPSHOT artifact to artifactory. Then I clean and compile project A to get the new Project B.