Case in question: A Maven based project that has a Maven Run Configuration with its 'Command line' parameters defined as clean install.
Clicking the green arrow to invoke 'Run my_maven_config' downloads all necessary packages from Nexus and completes the build successfully.
Selecting 'Build Project' however, invokes a seemingly similar process but after building successfully for quite a while, it fails on a missing Hibernate package.
Why is this difference?
Shouldn't the build part of 'Run' be identical to the "standalone build"?
They are not identical. IntelliJ IDEA imports the external project model from Maven and converts it to the internal project model. It's not 100% accurate, some Maven plug-ins are not supported, some dependencies may fail to resolve, etc.
See this answer to perform the diagnostics. Try re-importing the project (delete .idea directory first if it doesn't help).
Delegating build/run actions to Maven as it can be done now with Gradle will be supported later (probably in IntelliJ IDEA 2018.3).
Now IntelliJ IDE allow to delegate Build actions to maven.
Go to Preferences and search for "Delegate IDE build actions to maven".
So when you build a project, IntelliJ IDEA invokes the appropriate Maven goals.
Related
I am currently working on a project that involves utilizing Gephi's backend tools and frontend visualizers. For this, I have cloned Gephi's repository, https://github.com/gephi/gephi.git. The following tutorial walks users through how to clone and modify Gephi's sourcecode so that you may add "circle creation logic" to Gephi's visualizer, https://seinecle.github.io/gephi-tutorials/generated-html/working-from-the-source-en.html. I have found that running the project through NetBeans is a straightforward process, build the dependencies and run.
Unfortunately, such an option doesn't exist in IntelliJ and the maven "Lifecycle" goals that I can run (clean, validate, compile, test, package, verify, install, site, and deploy) build successfully, but does not actually run the project within the environment unlike NetBeans does. I am wondering what I am missing here, or how NetBeans can simply run the maven project node, but such an option doesn't exist in IntelliJ? How do I perhaps edit my run configuration within the IntelliJ IDE so that I can run such an instance?
The equivalent in IntelliJ IDEA would be the following:
Run the compile goal
Run nbm:cluster-app
Run nbm:run-platform
The last 2 goals are provided by the nbm Maven plug-in.
In IntelliJ IDEA they are visible under the Plugins node of the module in the Maven tool window:
What is the difference between IntelliJ, Maven and Gradle build system in IntelliJ IDEA?
Has IntelliJ IDEA its own build system?
In addition, what is the difference between run in IntelliJ and Gradle bootRun?
Build project is IntelliJ's own build-in build mechanism, it simply compiles all modified and dependent files in the project.
However, it's a "plain vanilla" build. It doesnt do fancy things like creating artifacts, deploying to repositories, codegen from a wsdl - etc. That's what we use build automation tools for, and there are 2 of them (maven and gradle) in widsepread use.
Maven and gradle allow developers to set up a custom (and more complex) build configuration.
The maven pom.xml defines lifecycle goals and the gradle build.gradle defines tasks.
Via a plugin architecture, maven / gradle can accomplish almost anything in a build process. Whilst the maven / gradle "run" task can operate similarly to IntelliJ "Build Project", it's not the same thing - in this case the build is instrumented by the build tool (maven or gradle) and can be configured differently, and be part of a more complicated build process.
What is difference build project in IntelliJ and gradle build?
IntelliJ build uses IDE's own jps project model and builder for compiling the java-based projects. Including incremental build support.
With Gradle build it actually uses Gradle to build the project (think Gradle build task).
In addition, What is difference run in IntelliJ and gradle bootRun?
Basically same as above: IntelliJ runner - uses build results of IDE's builder and IDE's own Run/Debug Configuration to launch the application ant tests. With Gradle runner - IDE delegates this to corresponding (bootRun) Gradle task.
See also Configure the build and run actions for additional details.
I tested this locally in my project, using two builds: one using IntelliJ IDEA's "build project" and the second using Gradle's own build command.
Then I checked the contents of the .build directory in my project and found that the former (IntelliJ IDEA's build) produced less files than the latter (Gradle). I think Gradle's build system is more powerful than IntelliJ IDEA's, which is why I prefer to use Gradle in my projects.
For a Maven-driven project in IntelliJ 2018, when should I choose to use…
The IntelliJ 2018.1 menu item Build > Rebuild Project
The Maven panel’s clean and install Lifecycle items
Under what circumstances is either appropriate?
My situation is a Vaadin 8 application using the vaadin-archetype-application-multimodule Vaadin archetype.
The Question, Does IntelliJ Build > Rebuild Project invoke maven? has a single Answer that says the Rebuild Project does not invoke Maven at all. But no guidance is given on when to use route versus the other.
Well, if you make substancial changes within a pom.xml file (new plugins, new modules within a multi-module project), you'd better run "mvn clean install". I personally never use the "Rebuild Project" within a Maven project. usually I just "make" the project so the class files are updated, or I start a real Maven build to get new / updated dependencies.
The third important option (for me) is the "Reimport all Maven projects" option, which is quite useful if a pure Maven build runs fine, but IntelliJ still thinks that there is something wrong within your project.
When you have a multi-module Maven project and:
Start your tests and application programmatically by IntelliJ (Main.java):
You do not need to use Maven at all, no clean, no install, only Make. And Rebuild when the project gets screwed up.
Click Reimport when you change dependencies or someone deploys a new dependency snapshot to your repo.
If IntelliJ refuses to download the snapshot, then try mvn clean install.
And why would you even do all that? It is faster and more user friendly.
Start your tests and application by Maven in IntelliJ (mvn jetty:run):
You have to install your modules which are as dependencies for the module on which you start your application (mvn jetty:run), because Maven does not use your compiled output for dependencies, but takes an artifact from your remote/local repository. For this case Make/Rebuild is useless, you have to use mvn (clean) install.
If you have made changes only in a module on which you run mvn jetty:run then you do not need to use package/install, but sometimes you have to use clean or Rebuild as Maven does not remove deleted resources.
Make is good for hot-swap - for that reason, it is a good idea to import all Maven projects you develop and on which you depend into a single IntelliJ project. Initial Rebuild comes handy, because without it, Make would compile the whole project instead of only changed classes, then possibly failing hot-swap or it would just take too long.
Or you could just click Make before you run your application, but it could leave some old resources created by Maven in compiled output, Rebuild would take care of that.
You can also configure your app-server to restart/reload when it detects updated files from Make or Rebuild - certainly faster than restarting the JVM or compiling by Maven, but you might like to disable that and use only hot-swap, which is still way faster if you do small changes.
Either way you might want to take a look at Maven Helper plugin for IntelliJ, it will make things way easier in big projects.
Since I'm having performance issues while building a workspace with lots of maven-projects I wonder if it is possible to deactivate the Maven Project Builder.
If I understand that right, the Maven Project Builder does not compile anything. Instead it refreshes the project-config from the POMs. I believe this is exactly what happens if I run "Maven -> update Project". If that is true I could deaktivate the Project Builder... Does anybody know if this is right?
You need to track all your library dependencies from .m2 folder, so you can restore them easily, and check if there are some scripts in pom.xml that run on build, test, or deployment and see if you can reproduce them without Maven.
In addition you should check if there are other project in your system that depends on your project and vice versa via Maven.
I found an annoying issue working with m2eclipse in Eclipse.
My workspace contains 2 projects, an application A and a library B. The application A POM has B as a dependency and everything works correctly. (The project dependecy is found and used when I build the application)
But if I change some code in project B and I forgot to mvn:install it, when I build the application it uses the last built version of the library and it loses my last changes.
Is there a way to force Maven / M2Eclipse to check if the source code of the dependecy is newer than the last version built, and to install it when installing/ deploying the main application?
Or maybe my approach is wrong or is something obvious that I'm missing?
You can tell m2eclipse to use resolve dependencies from the workspace rather than through the normal mechanisms. In your project properties (NOT workspace properties), select Maven->Resolve dependencies from Workspace projects.
This will mean that when you change B and subsequently build A, the changes should be picked up automatically.
If, however, you build outside Eclipse, you'll have to do the normal mvn install to get the correct dependencies.
I don't know of a way to tell maven to build the library first, then build your project. You could put two maven commands into a script and run the script.
Alternatively, you could put both projects inside a maven parent project, and then build the parent. This causes all child project to be built too (so in your case the library, and the application).
I think you have couple of options here
If you can change the maven project set up, I would suggest you to use maven multimodule
Option two might solve your problem but still involves a manual stop when you change your dependent project B, Do this on for your dependent project in eclipse
Select Library B ==> Properties ==> Maven ==> in the input box under Goals to invoke after project clean: ==> enter : install
To deploy any change that you made to Project B in eclipse to maven local/remote repo, You have to run Clean build in eclipse, This will deploy the latest Library B to the maven repository
Also make sure your Library B version is a SnapShot during the development
If you are looking to run the latest snapshots on your local machine you should try to set things up to launch directly from Eclipse.
Apart from avoiding the problem you originally posted about, it also has other advantages.
It will save you a lot of time by not having to perform intermediate build steps.
You can start and stop servers without having to leave your IDE.
The Eclipse console has extra features that you don't get from the system console.
You don't have to modify your start scripts to attach a debugger.