I come from a Ruby on Rails background and I am learning Java Spring MVC right now. When I try to compile my code using Maven in STS it wants me to include a goal. All the guides I read on this seem vague and unclear. What is the point of a goal? Why can't I just compile my source code and run it?
You have to understand that Maven is complex and modular.
It does not have any concept of "compiling" your code or "running" your code. What it does is trigger plugins in the order of the build lifecycle.
Running a Maven goal triggers a particular Maven plugin. For example, running mvn compile triggers the Maven compiler plugin.
This all seems to be overkill for someone just starting in Java, and there are many "why can't Maven just do what its told" questions on SO.
Most of these stem from a fundamental misunderstanding of what Maven is. It is not (strictly speaking) designed to "compile and run" your code. It is designed to carry out a number of preconfigured steps in a particular order.
When it comes to "running your code", this gets even trickier:
to run your code with the maven exec plugin, call mvn exec:java. You obviously need to configure the plugin
to run your code as a webapp with an embedded Tomcat server, call mvn tomcat7:run-war.
to run your code as GWT application in devMode on an embedded webserver call mvn gwt:run
What all these goals have in common is that they trigger a specific, pre-configured, plugin that carries out the task you have asked for.
It is further worth pointing out that Maven is designed to compile, test and install your code, not really to run it. So whilst may plugins for running code do exist, the real strength of Maven comes from being able to automate the compiling, testing and deployment of code to a Maven repository.
As a final note, the massive red warning at the top of the page you linked says:
Apache Maven 1.x has reached its end of life, and is no longer
supported.
Take heed. We're now on Maven 3.2.X. Don't read documentation for ancient and obsolete versions. This will serve no purpose but to confuse you.
Related
The solution which needs bootstrapping is supplied as java code. Absolutely sure that this is necessary.
Receivers of the solution are guaranteed to have a suitable JDK
However, receivers of the solution are unable to install Maven (they don't know how to and cannot be taught)
My idea is to include some sort of Maven with the project, such that can be set up in a script like so:
set up maven repo as a folder under the solution folder (using relative reference)
set up anything else maven needs (don't know what, exactly)
call /path/to/maven/mvn compile -f /path/to/oneAndOnly/pom.xml
java /target/MySolutionClas
I am aware of: https://dzone.com/articles/embedding-maven but it gets confusing when he talks about configuring the portable maven into the pom.xml - wait, how is that pom.xml going to mean anything if maven is not configured yet?
(PS: I mean no disrespect to the author. I probably got it all wrong)
One could include a shell script that would setup maven if it is not already present.
The same for building and packaging encapsulating the complexities of the setup to just runing a couple of scripts.
Maven Wrapper aims to do just that, similar to the gradle wrapper seen in many gradle projects.
Running the wrapper goal of the maven wrapper plugin will generate a mvnw script in your project that can be run in place of a globally installed mvn command.
It's part of the maven 3.7.0 release, and documented more fully here: https://maven.apache.org/plugins/maven-wrapper-plugin/index.html
See https://github.com/takari/maven-wrapper for maven < 3.7.0
I wonder if when I hit Project > Clean, mvn is really involved in setting up the build process.
Is M2E (Maven to Eclipse, standard plug-in) just reading and analyzing the pom setting up / updating the Eclipse project the way specified by the pom or does it actually run the phases defined in the pom?
I just wonder what happens on Project > Clean when it comes to Maven... .
[Update]
Since people seam to get confused by the question here are more information:
I altered the build process of the project in maven and it seam to be not reflected by actions I trigger in the IDE directly. So M2E seams to be more like a translator of maven settings and applying the same settings to Eclipse without altering the behaviour. It also would explain why M2E is providing connectors in the first place.
Since I could not verify this, I boiled it down to a simple question that if answered, I know the answer to the more difficult question regarding Maven integration in Eclipse.
[Update2]
M2E has the ability to execute certain phases. I added an answer. This answer is not obvious since I searched the internet up and down before I asked this question. Also I only found the answer by some thoughts that were raised by the previous answer to this question which is what I asked for but only half of the picture.
This question is a perfect example why often on stack overflow the obvious is neither asked nor was implied nor is the final answer and the trigger happy close friendly swarm sometimes misses the point :-).
When you clean a eclipse project, eclipse clears output directories of the project, without invoking maven. This is a eclipse operation that is executed over all projects you have, whether or not the projects has been imported from maven.
If you want to run maven targets on an imported eclipse project, you could use Run configurations to explicitly invoke maven targets on the projects.
M2E does has its own mapping for each phase. Depending on this mapping Eclipse actions are replaced, extended or left-as-is.
From the following picture one can see that the clean command is set to ignore. You can view/change those mappings by Project Properties > Maven > Lifecycle Mapping. So this is actually (as-expected) a per phase mapping. By downloading new connectors M2E is able to provide additional mappings to special phases not supported by default installation.
In my IDEA project a Scala module depends on a Java module. When I try to compile the Scala module, only scalac is triggered. It compiles both Java and Scala sources.
I'd like scalac to compile only the Scala module, because javac is much faster for Java sources (and my Java project is a big one).
How to make IDEA use different compiler for different modules?
My workaround is to (for each dependency to Java module):
Delete module dependency in project configuration
Add dependency to appropriate compile output directory "MyJavaModule/target/classes"
Obviously I'm not happy with that, because every time I reimport Maven project I need to repeat all of this to have fast compilation. I hope somebody knows a better way.
Clarification: I'd like to stress, that tools like SBT or Maven don't solve my problem. It is not about compilation alone. It's about compilation in IDEA, required for things like Scala Worksheet or running unit tests from IDEA. My goal is to have full range of IDEA niceties (syntax highlighting, intelligent auto-completion, auto-imports, etc) with compilation speed of SBT. Now I have to either tolerate long compilation times (due to dependencies to my Java module) or to use bare-bones REPL and testing in SBT.
Randall Schulz has asked the right question in the comment: "Why does it matter which tool does the compilation?"
Up until now I believed that IDEA needs to compile all classes itself if you want to use its nice features (like IDEA's Scala Console or running tests from within it). I was wrong.
In fact, IDEA will pick up classes compiled by any other tool (like the great SBT for instance). You just need to assure that all classes are up-to-date before using any of IDEA's helpful features. The best way to do it is:
launch continuous incremental compilation in the background (for
example by issuing "~ compile" in SBT)
remove "make" step in IDEA's
run configurations
That's all! You can then use all cool features of IDEA (not only syntax highlighting and code completion, but all auto-imports in Scala Console, quickly running selected unit tests) without switching between different windows.
That's the workflow I missed until now! Thanks to everybody for all the comments about the issue.
You should look at using a dependency management suite like Apache Ivy or Apache Maven. Then put your Java source in a separate artifact, and have your Scala project be dependent on the Java project artifact.
If you go the Maven route, there is a Scala plugin.
Probably the simplest way to get compiled Scala and Java files is SBT - Simple Build Tool. Just create a project (+ add dependencies and so on) and compile it. Scala + Java compilation works out of the box. I've switched to SBT from Maven.
If you have a complex POM or if you have another reason not to migrate to SBT, you can try to configure the POM. Just adding (and possibly configuring) the Scala plugin should be enough. I hope it will not break the Java support.
I have the same problem like on the below link , and solution from there works
but i have a little of hard time in understanding what it cause this and how it affects the project.
Plugin execution not covered by lifecycle configuration (JBossas 7 EAR archetype)
I start reading about m2e
http://wiki.eclipse.org/M2E_plugin_execution_not_covered
What is the difference between the 'eclipse build' and maven one ?
Still not clear what is meant by "interesting" and "not-interesting" mojo executions:
https://docs.sonatype.org/display/M2ECLIPSE/Project+build+lifecycle+mapping
So there is the solution but , not the understanding of the problem.
Thanks for helping me understand the problem ...:)
Generally speaking, The way m2e used for resolving/mapping plugins' goal execution into Eclipse build life cycle has been reinvented after version 0.12. Now m2e requires explicit instructions what to do with all Maven plugins bound to "interesting" phases of a project build lifecycle. By either configure the lifecycle mapping in your project's pom, or use specific m2e configurator Eclipse plugin if somebody has kindly created it for the community.
By "interesting" they mean phases which normally occur during writing and debuging of code inside the IDE, mostly excluding packaging and deployment steps.
Also note (from this blog post):
M2E allows you to run Maven manually. You can invoke a goal like "mvn install" from within Eclipse just as you would do it from the command line. That works (and always worked) just fine. Unfortunately, Maven is also invoked automagically from M2E whenever Eclipse builds the project, for example after a clean. In such cases M2E acts as an "Eclipse Builder". It is these latter invocations that people have always had problems with and that the connectors should handle better.
We are running our continuous builds on Hudson currently with "mvn clean verify". That is what we always did and so we never questioned it.
The question is: Is it safe to run a continuous build with "mvn verify" only?
So that would mean the maven-compiler-plugin would only compile classes that got changed since the last build and save precious time.
Will the feedback be the same quality as with "clean" or are there any drawbacks to be expected?
The product being tested is a typical Java web application with lots of generated code (JSPs, reports). There is also code around using Dependency Injection.
No, it's not safe! The Maven compiler plugin is not smart enough to figure out that the API of a class A has changed and that it should check all other classes which use this API, too. It will only compile A and create a jar with a lot of broken classes.
Note: It's usually better to run mvn clean in advance and then run the build/verify/compile/install. That allows you to run the second command several times without cleaning all the time.