In Opendaylight, Whenever a change I made, I will build the whole project instead of specific project. mvn clean install -DskipTests=true.. Is there any way to skip the whole build and build the particular pom.xml of project.. E.g In ovsdb, If I want to run southbound project alone what i have to do?
There can be a better way but the workaround I use is :
I use a bash script to copy the jars + config files.
If I make code changes to a module,
I build the modified module
Execute the script. to copy the built jar file, config files to the specific folder location inside System folder of the unziped ODL distribution.
I restart ODL. bin/karaf clean.
Part of the bash script which I use to update common jars+config
local.sh:
elif [ $1 == common ]; then
cp /home/user/workspaces/workspace-odl/myproject/common/implementation/target/common-impl-2.0.0-SNAPSHOT.jar /home/user/controller/myproject-karaf-2.0.0-SNAPSHOT/system/com/myproject/common-impl/2.0.0-SNAPSHOT/common-impl-2.0.0-SNAPSHOT.jar
cp /home/user/workspaces/workspace-odl/myproject/common/model/target/common-model-2.0.0-SNAPSHOT.jar /home/user/controller/myproject-karaf-2.0.0-SNAPSHOT/system/com/myproject/common-model/2.0.0-SNAPSHOT/common-model-2.0.0-SNAPSHOT.jar
cp /home/user/workspaces/workspace-odl/myproject/common/config/src/main/resources/initial/89-common.xml /home/user/controller/myproject-karaf-2.0.0-SNAPSHOT/system/com/myproject/common-config/2.0.0-SNAPSHOT/common-config-2.0.0-SNAPSHOT-config.xml
rm /home/user/controller/myproject-karaf-2.0.0-SNAPSHOT/etc/opendaylight/karaf/89-common.xml
echo "Updated common"
Execution:
./local.sh common
This will copy the updated jars, and the next time you will run ODL, updated jars will be picked up.
This is fast, and doesn't require me to rebuild whole ODL project.
If you are using for first time build the whole project using command
mvn clean install -DskipTests -Dcheckstyle.skip=true
For subsequent changes say you have changed in southbound-impl build southbound-impl using above command.
Next build southbound-karaf using above command. Then you can start the karaf to test. for target/assembly/bin/karaf.[sh|bat]
Assuming you have the appropriate entries in you Maven settings.xml, you can build any module in an OpenDaylight Maven project by running Maven in its folder; for ovsdb southbound:
cd southbound
mvn clean install
Alternatively, from the project's root:
mvn -f southbound clean install
If you only want to build a single module (none of its children):
mvn -pl southbound clean install
(These are all standard Maven options.)
OpenDaylight includes a few nice extras you can use to iterate on builds more quickly:
the q profile skips all goals which don't contribute to the resulting artifact (static analysis, tests, documentation...):
mvn -f southbound clean install -Pq
updated JARs can be installed directly in a pre-existing Karaf system folder using the addInstallRepositoryPath variable:
mvn -f southbound clean install -DaddInstallRepositoryPath=.../karaf/system
(replacing ... with the appropriate path).
These can be combined, so
mvn -f southbound clean install -DaddInstallRepositoryPath=.../karaf/system -Pq
builds and installs the JARs in an existing Karaf (which can even be running — it will re-load the bundles).
Related
I'm running my testng xml from docker file. When I tried docker run, it throws "You must specify a valid lifecycle phase or a goal in the format"
The same command is executing in the CLI mode. Below is my docker file
FROM maven:3.6.0-jdk-8
ADD pom.xml pom.xml
RUN mvn compile
ADD . .
CMD ["mvn","clean install test -Dsurefire.suiteXmlFiles=testng.xml"]
your
CMD ["mvn","clean install test -Dsurefire.suiteXmlFiles=testng.xml"]
is the equivalent of
mvn 'clean install test -Dsurefire.suiteXmlFiles=testng.xml'
outside the container. It other words the whole clean install test -Dsurefire.suiteXmlFiles=testng.xml is treated as maven phase and of course it can not be found.
What you are trying to do can be correctly written like this:
CMD ["mvn","clean", "install", "test", "-Dsurefire.suiteXmlFiles=testng.xml"]
That said, there are few other issues with your approach:
You run mvn compile after just adding the POM (before adding the working dir). Depending on what is in the POM that may do nothing or fail.
There is no need to call install in a container. It will add the resulting artifact in the local (to the container) repo which will be destroyed together with the container. Unless there is something else in the container that expects to find your artifact in the local repo this is pointless. Normally verify or package (if there are no integration tests) is more than enough
you run install first and test later. However both are part of the same build lifecycle. So what will happen is, all phases (including test) up to install will be executed. Then all phases up to test will be executed again. That is probably not what you want
I have a Maven build job in Jenkins and in the "Build" section, I have given Maven Version and Root POM and in the "Goals and Options" filed, I am executing the pom with customized goals. I need to write the output of the execution to a file, I tried below
clean install -Dmaven.test.skip=true -nsu -l output.log
clean install -Dmaven.test.skip=true -nsu -DoutputFile=output.log
clean install -Dmaven.test.skip=true -nsu -Doutput=output.log
Nothing works for me. Could anyone please help in either the above way or any other option available to direct the output log to a file?
According to mvn -help, the following works for me:
clean install -l output.log
The file is stored to the job workspace, if you want to publish it as an artifact, you need to add a Publish artifact or Publish document post-step (or Publish document post-build option in Maven project).
Based on the question Sonar + Clover only runs on src-instrumented, it is suggested using first mvn clean clover2:setup install clover2:clover, then: mvn sonar:sonar.
Just wonder why we cannot use mvn clean clover2:setup install clover2:clover sonar:sonar?
In the past it was the recommended way to run goal sonar:sonar alone. This is no more the case since SonarQube Scanner for Maven stopped trying to run unit tests + collect coverage for you by forking a new Maven lifecycle.
General advice is now to run goals in a single command. For example mvn clean package sonar:sonar
In the case of Clover the clover:setup goal will alter the Maven Model to make all other plugins (like surefire) use instrumented classes instead of original source code. This is indeed a problem because it will prevent SonarQube to match class files. So in your case you should either stick with two separate goals, or manually configure sonar.sources to refer to original source code.
Compared the maven logs and found the possible reason:
The "mvn clean clover2:setup install clover2:clover sonar:sonar" seems having issue to find the Source dirs. The log shows it uses ${project}\target\clover\src-instrumented and ${project}\target\generated-sources\annotations as the source dirs.
If explicitly specify src/main/java, then this single command works well. The only tricky thing is why running the goals separately doesn't need to specify sonar.sources but the plugin can still find the right folder for source dirs.
I've added some gradle task to my project. However, I still want to continuous build to run maven. My first attempt was to add an explicit script
script:
- mvn install -DskipTests=true -Dmaven.javadoc.skip=true -B -V
- mvn test -B
This doesn't work. I tried to rename the build.gradle file. This doesn't work either. I probably need to remove gradlew but before that, is there a better solution?
I have some files that I only need for local development, and do not want to be packaged up in a release.
How can I add an automatic step to the POM so that it removes files when I do a mvn release:prepare?
If the files for local development are in a self contained module then you can pass an -N flag.
Source - http://maven.apache.org/maven-release/maven-release-plugin/faq.html
or look at How to exclude file on maven release:prepare and release:perform?
If you are using version 2.1 or higher.