Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I am having a dispute will a colleague. We use maven to build our software and we both have a fair amount of experience with it. However something I have never seen done before is to disable maven tests by default with a profile. If the developer wants to skip tests then the -DskipTests option is available. His argument is that: You don't want every CI pipeline to re-run all the previous steps. Well if that is the case then instead of using:
mvn clean install
then use
- mvn clean
- mvn compile test-compile
- mvn test
- mvn verify
- mvn package
However this also is unacceptable. He says at every company he has worked at this is standard. I cannot think of a single project I have looked at in OSS that uses maven that uses the convention of disabling mavens test functionality by default.
Am I confused? The whole selling point is that the build is standard and it requires direct intent to avoid running tests.
You don't skip tests as default.
And you don't let different CI steps repeat the ones before. So don't try to split the Maven build and first run mvn test and then mvn verify and then mvn package because you do a lot of work thrice.
Just use mvn clean deploy and you'll be fine.
Related
I am using Gitlab CI/CD for a Java/Maven project and am confused by the many examples which show multiple stages, where each stage calls a specific Maven phase (e.g. clean, compile, test, install)
The maven documentation is very clear that each phase implicitly invokes all prior phases. So my question is, why do the examples not just invoke the last phase listed in the stages? For example, if the last non manually-invoked stage in the yml does an 'mvn install', why not just have that be the sole stage in the yml? It seems it is just a waste of CPU and time since the install will also call 'clean, compile, test, which have already all been called as part of the previous stages in the pipeline.
The "tutorials" that advice you to first call mvn compile then mvn test etc. have not understood the Maven lifecycle.
Just call one command, like mvn install for installing or mvn deploy if you want to deploy it with the help of Maven to some Maven repository.
The main reason for running different maven goals in different stages is clarity.
If a test fails and the pipeline has one job which runs mvn deploy you need to take a look at the logs why the pipeline failed.
But if a separate job exists where mvn test is executed you see at a glance that the pipeline failed because of tests.
In the example from the gitlab documentation they use cache to cache the output of mvn compile so the maven goals in the next steps don't compile from scratch but use the cache instead.
Maven -T not working with release plugin
I start to write as answer cause the comment area is too limited.
The mentioned point 2. must have failed with an error cause -T requires parameters (Missing argument for option: T`)
Furthermore the given call release:prepare release:perform clean install deploy is simply wrong.
Let us begin with some basics. A combination of install and deploy shows that there is a misunderstanding about the Maven life cycle.
So using install only makes sense if you want to install the artifacts only into your local repository ($HOME/.m2/repository) to be consumed by other project on the same machine which is usually not the case.
Using deploy (which includes install) is used to upload the created artifacts into a remote repository (like Nexus, Artifactory) which is in corporate environments the case.
Based on the output I can see that you are using extremely old plugin versions like maven-dependency-plugin:2.1: this version is ten years old. Furthermore I see the usage of a sources goal which is used to resolve sources of the dependencies where I would ask: Why do you need that?
The mentioned point 1:
mvn deploy -U -T 1C -DskipTests -Dmaven.install.skip=true
this shows that you have not understand the purpose of install and deploy phase cause the install phase is needed to install the artifacts and deploy phase will transfer them to the remote repository which means it does not make sense to skip the install part (I doubt that this will work). Furthermore using -U only would make sense if you have SNAPSHOT dependencies otherwise this is waste of time.
The usage of -DskipTests gives me the impression you seemed to have long running unit tests (or they might be integration tests instead?)...
To make a release with Maven you should go:
mvn release:prepare release:perform
Nothing else. Based on the supplemental parameters you are giving during a release it looks like your pom files seemed to be not in optimal state.
The given option -DcheckModificationExcludeList=pom.xml looks from my point of view like a problem cause usually you don't need that and furthermore during a release the pom.xml will be changed (the version) so from that point of view it does not make sense. The modification is to check if something not checked in before running a release..(The whole thing looks not concise to me).
Based on the error message you have given:
[ERROR] Failure executing javac, but could not parse the error:
I bet your maven-compiler-plugin version is very old? Which version do you use?
I recommend to use an up-to-date version of maven-release-plugin which is hopefully correctly configured in your pom file (which I can't tell you cause you haven't showed the full pom files).
Also I recommend to use a most recent version of Maven and check all plugins (using most recent versions) and in particular the configuration of the appropriate plugins if the configuration is correct and really needed and fulfills your needs.
This question already has an answer here:
Running groovy tests with Maven
(1 answer)
Closed 7 years ago.
Maven handles java unit tests well by defaulting to:
src/test/java
We're writing quite a few Groovy unit tests right now, and I'd like to find a way in Maven to specify a folder such as:
src/test/groovy
as a test folder. This would help us to import a Maven project into, say, IntelliJ, without additional setup.
Someone mentioned this was possible, but I wasn't able to find a way searching the Maven docs, or SO. Does anyone know how to mark the directory in the pom?
Thank you
Update: I am not asking how to run the tests in Maven! The tests are already running fine. I'm asking how to mark the directories as test directories in Maven.
As described at http://maven.apache.org/ref/3.3.3//maven-model/maven.html#class_build the build section of the pom.xml has an entry to specify the test folder.
When I build my application with maven, I run mvn clean install. As a part of the install lifecycle, I run appengine:devserver_start from Google's GAE Maven plugin. This appears to be already bound to a step in the lifecycle and therefore it reruns some build steps from the beginning, even though me running mvn install did those. For example, the resources step is rerun. I had my own Java script run to download the latest resources for my build. But because of appengine:devserver_stop, I need to uselessly run this cript again because the resources step is re-executed.
I can think of two ways I can avoid this, but I'm not sure how to configure both ways. The first would be to somehow skip re-running build steps that I've already run. The other way would be to change the Maven POM properties just for the plugin execution. I have a Maven property set, either to true or false, that I can use to set the skip setting for the Java script I use during resources (because I run this script using the exec-maven-plugin). Think of this as a Maven property that can be set with the -D flag. Can I have this property changed just for the plugin?
If you are having trouble thinking about my scenario, consider what happens when you run mvn compile install. All build lifecycle steps until compile will run, then all compile steps until install will run, including compile.
A common/easy way to solve this kind of problems is to use maven profile. Just create a new profile that includes the plugin with preferred phases.
You should probably don't fight with it and just run clean appengine:devserver_start instead of clean install. Read my answer here for a more detailed explanation:
https://stackoverflow.com/a/17638442/2464295
I have a multimodule maven project in which there are 7 several modules.
Every time I modify a code in one of the module and run mvn clean install, it takes some time and I think there might be a way to reduce time of builds since I only change small part of the code and I think it effects only limited area.
So I guess instead of running "mvn clean install" there is a better command option.
I am using maven 2.x.
Any better ideas?
TIA
The "clean" goal deletes all the target folders which contain the compiled classes, it should not be necessary to run that goal as part of the modify-compile-test cycle that you may run many times per day. In your case most of the time is probably spent re-compiling all the Java files, due to the class files having been deleted during the "clean" goal. So I would use "mvn install" when testing local changes, and "mvn clean install" only periodically, like when you get other developers changes to integrate with, or when testing immediately before a release.
I would suggest to use the following:
mvn -pl TheModuleYouHaveChanged -amd install
or maybe a
mvn -pl TheModuleYouHaveChanged -amd package
is enough.