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
Is there a way to let eclipse automatically run 'mvn install' when it builds a project (e.g. when a source file in the project is changed)?
My problem at the moment is that I have a large number of projects in eclipse, each of which is a Maven project as well. Projects depend on each other through Maven dependencies but are not parent/child projects.
My workaround is that I have a bash script running in the background which checks for changes in all directories for these projects and triggers 'mvn install' for every changed project. Unfortunately, this creates some problems since for some projects I have to call 'mvn clean' as well and this makes the eclipse projects unusable until I manually rebuild the project in eclipse (Maven -> Update Project ...).
Did you try Eclipse builders?
You may attach a builder to your different projects.
The builder will call your bash script each time its related project is built.
See the following article for reference: Non-Ant project builders
I am absolutely new in Maven and I am studying it. I am using Eclipse
I have the following doubt: into Eclipse I have a Maven project.
If I select this project and I do right click on it and then I select the Run As option I have some choice. What exactly represent these choice? Are Maven tasks or what?
In particular to perform my project I have 2 possible choices:
Maven build
Maven build...
What exactly does these tasks? It seems to me that build the project and perform the related unit test. Is it true or am I missing something?
What is the difference between the previous choices. In the tutorial that I am following it is used the Maven build... and then set the clean package as goals. What exactly do this goal?
Tnx
The Developing with Eclipse and Maven - 4.2. Running Maven Builds doesn't really give any clue about the "Maven build" command.
So:
the "Maven build..." allows to define a new run configuration
the "Maven build" allows to choose between the existing user's run configurations or to create a new one if none exists.
About a user's run configuration with "clean package": have you ever used Maven? May be a good tutorial would be a first step... In the mean time - those goals will:
delete the target sub folder
rebuild the project in the new empty target sub folder
generate the archive jar-s as specified in the project pom
We are having a frustrating problem with our Eclipse workspace. Here is a high-level example of what is happening:
ProjectA
-- src/main/java/...
-- build.gradle
ProjectB
-- src/main/java/...
-- build.gradle
After running gradle eclipse and importing the projects into Eclipse, we occasionally will get 'MyType cannot be resolved to a type' even though the following are true:
Our projects have the Gradle library container on their classpath
The projects have the correct workspace projects within their Gradle container
Things like CTRL + Click work from types that are showing up with red underline (i.e. compile error) meaning Eclipse knows exactly how to get to those types, but the compiler can't find them
Command-line Gradle builds work as expected
This is happening throughout the team and we cannot figure out why Eclipse keeps going out of sync and cannot compile from time to time. What usually fixes the problem is a combination of:
Project > Clean in Eclipse
Gradle cleanEclipse or gradle eclipse
Reimporting the projects
etc
Other notes:
Using Gradle version 2.2.1
Happens in both Eclipse Luna and Eclipse Mars
Using JDK 8
Has anyone else had these types of compile issues in Eclipse with Gradle projects?
One source of such problems can be letting Gradle generate the Eclipse project metadata/setup files (what you get by running gradle eclipse). I know that the Maven and Gradle teams really want their tool (Maven or Gradle) to generate that stuff, but they notoriously do a less-than-ideal job of it. For example, the last time I used Gradle it configured the .classpath to use a hard-coded JRE library path instead of the preferred Execution Environment. That kind of poor job of generating files makes for developer headaches.
Instead, the Eclipse recommendation is to manually configure your projects (for the most part), only letting Gradle manage its Classpath Container, then checking in the Eclipse .project, .classpath, and .settings files/folders in to your SCM (svn, git, etc.). That way, the process of checking out a project into a workspace is automatic and does not require running gradle eclipse or mvn eclipse:eclipse all the time.
That's the way that Eclipse projects were originally designed and intended to be managed, and it works very well. I've worked with setups like that on very large projects (100+ separate projects in Eclipse and dozens of developers). It also cuts down on the number of steps to go from zero to running app.
This is one of those philosophical differences between Maven/Gradle and Eclipse; when it comes down to it, IMO, the IDE should manage it's stuff and the build/dependency tool should just stay out of the way.
Try manually getting things just right in your project configuration and then checking in those files - see if it doesn't relieve the headaches your team faces in this area.
In IntelliJ 14.1 what exactly happens when Build > Rebuild Project is invoked for a maven project.
Does it call mvn compile?
Does it do something independent of maven?
I have tried to testing this and when I click Build > Rebuild Project I can't see any console output indicating that maven is running, if I run maven from the maven projects view I get maven output.
So what exactly is the relationship between IntelliJ Build > Rebuild Project and build tools such as maven / gradle / ant?
No, the IntelliJ IDEA make does not invoke Maven. When you open a Maven or Gradle project, it reads the settings of the project and stores them as part of its internal project model. When you invoke Build, it uses the imported settings to compile your project using its own build system. Rebuild Project keeps the existing imported settings, deletes all .class files and IntelliJ's incremental compilation caches, and performs a full build of the project using IntelliJ IDEA's build system.
The advantage of doing that is that the IntelliJ IDEA build system supports very fine-grained incremental rebuilds (for example, if you change the signature of the method, it will recompile only those classes which actually call the method, and not any other code).
Note that you can configure IntelliJ IDEA to run an Ant task or a Maven goal either before or after the main project compilation, so if your build is doing something non-standard, you can still use it with the IntelliJ IDEA build system.
From what I have understood, it is not the best way to open a project built with Maven in Intellij by using the idea plug-in, that is by calling:
mvn idea:idea
but by open directly the pom file (Intellij has default plug-in for Maven); the same thing, for eclipse.
Could you provide some arguments on why this is a better approach?
This applies equally to IntelliJ and Maven:
changing pom.xml file is not reflected in your IDE, you must rebuild the project (possibly losing some configuration (?)) every time. Moreover, if any team member modifies pom.xml, you have to remember about rebulding your project (which will require closing and reopening it).
additional step is required when opening new project
IDEs have some other Maven features, e.g. both of aforementioned environemnts can show dependency graphs
Use mvn plugin as a last resort only when your IDE goes crazy and cannot figure out maven configuration correctly.
For eclipse, the maven-eclipse plugin is not really maintained