As the title states.
I've made changes to .xml file only. Do I need to mvn clean install the whole project or a simple mvn install? Or maybe mvn generate-sources will do the stuff?
Can anyone elaborate?
To build the artifact, you need to call mvn package. If you do not do a clean, beware that remainders of the previous build might still exist. Changing the code of a class is generally fine, while changing the dependencies in the POM is not (you might end up with both versions of an artifact if you change the version in the POM).
Your hibernate case is somewhere in between, so you probably need to make experiments. Maven does not make any guarantees.
Related
I have a question which is pretty straight forward, but hard to find an exact answer.
When we are using mvn build, what are the exact situation where we must go for clean install in order to see latest code changes in our built artifact. i.e. just install would not do that for us.
Thanks in advance.
Basically
mvn clean install
is same as
mvn clean && mvn install
so as to answer your question, its required when cleaning the files and directories generated by Maven is the primary requirement prior to doing another install.
Related to the changes in code, I would assume this is more of cleaning the target folder generated by Maven, hence mostly the files compiled would be overwritten when there is not much of a change.
In cases where one has removed/refactored a class from the previous build. There might be references still left if you don't clean and that would get packaged into the jar created thereafter.
From the official documentation(formatting mine) shared by ernest,
But if we try to build the project with mvn install without any clean lifecycle, then we see 2 bugs
the maven build still succeeds to compile the project maven even
generates a jar which contains broken classes
moduleB does not get recompiled and is thus broken as well.
Also, a preferably suggested way is to instead use
mvn verify
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.
I couldn't really find an answer anywhere to this particular question.
I have a (Maven) project consisting of multiple modules, let's say a core module (a jar) and a webapp module (a war).
When I run mvn clean package on my webapp, does it automatically always build the core first and will it pick up any changes in it? Do I have to run mvn clean install instead? Or do I have to run mvn clean package/install on my parent pom?
Does it matter if the parent/module is a release or a snapshot?
If you are working with a so called Multi Module Build you should do everything what you like to do with your whole project from the parent level.
There you can do:
mvn clean package
than it will build all modules in the correct order (assuming you have defined the dependencies between them correct).
If you have such a multi module build all your modules incl. your parent should have the same version number. If you like to make a release of the whole you can simply start from the parent.
You have to build anything that's changed, upwards. So, if you change core, then rebuild core, then rebuild your war. If you've just changed your war, then you only need to rebuild your war. Cleaning is generally good practice. The reason not to do it would be if you're generating a bunch of entity classes, which takes a long time to redo.
I've seen a lot of mistakes because people forget to clean, and then some old piece of code is still active, even though they thought they'd deleted it.
Installing will put your latest build into your M2 repo, which is generally a good idea too. You really can't go wrong with "mvn clean install"
I'm new to Maven and m2e. It frustrates me that I have to ask this question, but the sparse m2e documentation and Google are failing me.
How do get m2e to build a JAR? I understand that this should happen during the maven package phase, but m2e doesn't seem to do this as part of the build process and I can't find a way to explicitly execute the package phase in Eclipse (nor any other phases that aren't part of the default build).
Thanks.
As long as you have your POM.xml file with the following parameters:
<modelVersion>[a model number eg 4.0.0]</modelVersion>
<groupId>[a group id eg com.myapp]</groupId>
<artifactId>[a unique artifact id within your packages eg myapp]</artifactId>
<version>[the version number eg 1.0-SNAPSHOT]</version>
<packaging>jar</packaging>
<name>[the name eg myapp]</name>
then you just need to run maven build with the goals clean install to create a jar file from your project. You can run maven build by right clinking on the project and going to run > maven build ...
The jar will be created in [project dir]/target
Although "Run As maven install" would do the trick, it can be good
to know that m2e will perform the equivalent of the package phase when doing "Export... Jar/War/EAR file". It seems to understand the plugin configurations too, at least a little bit, and at least for EARs...
As it will resolve artifacts using projects and the m2 repository,
it will also work for "unrelated" modules, as the dependency that resolves to a project is good enough for eclipse to package.
(That is, you don't have to install the unrelated dependency separately, it will be built automatically from the eclipse project.)
I'm not sure I would deploy anything it builds though :-)
Right now, I have two Eclipse projects - they both use Maven 2 for all their jar-dependency goodness.
Inside Eclipse, I have project Foo included in project Bar's build path, so that I can use Foo's classes from project Bar. This works really well in Eclipse land, but when I try:
mvn compile
inside Bar's directory, it fails because Maven doesn't know about the project-to-project relationship in Eclipse's build path.
If I were using Ant, I would just use it to do something silly like copy foo.jar into project Bar's classpath, but as far as I can tell, things are done a lot less hackishly in Maven-land.
I'm wondering if there's a standard workaround for this type of problem - it seems like it would be fairly common, and I'm just missing something basic about how Maven works.
Maybe you are referencing the other project via Eclipse configure-> build path only. This works as long as you use Eclipse to build your project.
Try running first mvn install in project Bar (in order to put Bar in your Maven repository), and then add the dependency to Foo's pom.xml.
That should work!.
Check out the m2eclipse plugin. It will automatically and dynamically update the project build path when you change the pom. There is no need for running mvn eclipse:eclipse.
The plugin will also detect if any dependency is in the same workspace and add that project to the build path.
Ideally, if you use m2eclipse, you would never change the project build path manually. You would always edit pom.xml instead, which is the proper way to do it.
As has been previously stated, Maven will not know about the Eclipse project build path. You do need to add all dependencies to the pom, and you need to make sure all dependencies are built and installed first by running mvn install.
If you want to build both projects with a single command then you might find project aggregation interesting.
I just needed to do this and I needed it to build with the external mvn clean install command. Here is the proper way to configure this in Eclipse. (With project B as a dependency of A)
Open the pom.xml for project A in Eclipse.
Go to the Dependencies tab.
Click the Add... button in the middle of the page (for the left side Dependencies box)
In the popup, there should be a box under a line with text above it saying Enter groupId, artifactId or sha1 prefix or pattern (*):. Enter the artifact ID for project B into this box.
Double click the jar you want to add as a dependency to this project
You may need to update the project after.
Right click project A in you Package explorer
Maven -> Update Project...
Then hit OK in the popup.
You might want to try an alternative approach, where you have a parent maven project and two children project. let's say:
Parent (pom.xml has references to both children projects/modules)
--> A (depends on B)
--> B
then when you run mvn eclipse:eclipse from the root of Parent, maven will generate eclipse projects for A and B, and it will have B as a required project in the classpath of A.
You can run mvn install from the root of Parent to get both projects to compile.
To complete your setup, you'll have to import both A and B into Eclipse, making sure you don't check "Copy projects into workspace".
I think the best way to handle it is to make Bar a Maven project just like Foo, and then mvn install it so it is available in your local Maven repository. The drawback is that you have to install that project every time you want Maven to see the changes you make to Bar.
Not a complete answer:
Bar's pom needs to include Foo in order to use maven to compile it.
I'm interested in this question too, but from the perspective of how to get eclipse to recognise a maven-added dependency is actually another project in the same workspace. I currently alter the build path after performing mvn eclipse:eclipse
If you reference a local project, but its version has been updated (usually increased), it could maybe only be found in your local repo and you have to update the (likely fixed) version of it in your POM(s).
We have a "common project" (used everywhere) which does not necessarily need to be versioned since we tag it via source control. so either
keeping it at a fixed version or
referencing it with the special LATEST version
are good workarounds to always be on the safe side.