My maven project packages a war, which only gets deployed and is itself not a dependency to other projects (in other words is a final deployable).
Questions:
is there any reason to ever run mvn install on that package, which, in addition to mvn package only puts it in the localRepository?
Why should a final deployable be installed if nothing ever depends on it?
For a final deployable artifact indeed there may be no reason to invoke the install phase instead of the package phase: you want to build the .war file and you don't need to install it in your local repository indeed.
However, you may want as an habit to always run integration tests, if any. Looking at the default Maven lifecycle these phases happen after the packaging:
package take the compiled code and package it in its distributable format, such as a JAR.
pre-integration-test perform actions required before integration tests are executed. This may involve things such as setting up the required environment.
integration-test process and deploy the package if necessary into an environment where integration tests can be run.
post-integration-test perform actions required after integration tests have been executed. This may including cleaning up the environment.
verify run any checks to verify the package is valid and meets quality criteria.
install install the package into the local repository, for use as a dependency in other projects locally.
Hence, by invoking install you would make sure to always execute integration tests as well. Indeed a shorter invocation would be
mvn clean verify
Less popular but more effective in these cases.
Related
I can disable the particular phase in pom: Disable phases in Maven lifecycle. It is possible to disable test from the command line: -Dmaven.test.skip=true Is it possible to start mvn lifecycle from the particular phase, for example compile using only the command line options ?
By default, a lifecycle is as follows (from Introduction to the Build Lifecycle):
validate - validate the project is correct and all necessary information is available
compile - compile the source code of the project
test - test the compiled source code using a suitable unit testing framework
package - take the compiled code and package it in its distributable format, such as a JAR
verify - run any checks on results of integration tests to ensure quality criteria are met
install - install the package into the local repository, for use as a dependency in other projects locally
deploy - done in the build environment, copies the final package to the remote repository for sharing with other developers and projects.
While we can build applications without automated testing, we can't execute the package phase without an earlier code compilation.
Just as we are not able to install the package into the local repository without the .jar/.war packages, that are created in package phase.
For compilation you can use Apache Maven Compiler Plugin.
Then you can run compilation by executing
mvn compile
The command will execute maven goal compiler:compile
I wrote a Mojo that creates a new Java class and puts it in /target/generated-sources/annotations. in addition, I have configured build-helper-maven-plugin to declare that folder as source folder.
The problem is when I do: mvn clean install from CLI it generates the source file but it doesn't compile it.
Note, if I run Maven Install from within Eclipse (using the m2e connector) then it works fine.
What am I missing?
Without an actual plugin definition, we can only speculate.
I can't comment on m2e, I see one obvious difference that you state by yourself: mvn clean install vs mvn install, but from the "bare" maven's standpoint,
here is one possible reason:
Maven has a concept of phases that comprise the lifecycle. An information about phases of default lifecycle is available here
Plugins (more precisely the "goals" of plugins) are something that usually gets attached to a particular phase.
Maven compiler plugin is attached to the compile phase, for example.
So, maybe the plugin that you've developed runs later than the compiler plugin.
Usually, source generation plugins are attached to generate-resources phase.
Its possible to run a full lifecycle in maven, in fact its what people usually do, for example, running mvn test actually means, run all phases of the default lifecycle up-to (including) phase test.
It's also possible however to run a particular plugin goal "directly" without attaching it to the phase. Of course, in this case, its pre-conditions should be met.
For example, mvn surefire:test means that we should invoke the surefire plugin directly. Of course the source code and test code should be compiled beforehand (bytecode has to exist in the target directory)
So I suggest you to run the following series of commands (Adjust if you have tests):
Run mvn clean install on the plugin project to place it to local m2 repo
Run the plugin directly: mvn ::: and check
whether the source is generated in the target folder
Make sure in pom.xml of the project that the source folder are configured correctly
Run mvn compile (phase up-to, including, compile) on pom even without the plugin
After this phase, there will be compiled sources in the target directory. Don't run
clean because it will wipe out all the target directory
This will effectively help to make sure that plugin does the job right
I have eclipse ide with m2e plugin, maven and weblogc app server running from my local box.
I have imported someone else's multiple maven projects from bitbucket to my box. I was told that one of them is main and rest are dependencies in which I never seen anything like that before. I have always dealt with single maven project. Anyhow from the instruction, it says I have to run maven command such as "clean install -U".
In the IDE so I touched run configuration for each mvn project by setting goal as "clean install -U". By reading maven guide, I kind understand what each term means but when you combine together with a passing parameter, what does it do actually? I didn't expect a jar (web app) to be deployed to an application server but it did also.
-U forces maven to check any external dependencies (third party dependencies) that might need to be updated based on your POM files.
clean install are both basic maven lifecycle phases (https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html).
install normally would simply take the artifact that is built and put it in the local repository, i.e. a directory on the box you are building on (.m2 directory most of the time). It would not do a deployment to a server - typically the deploy phase would be used to do that.
However, developers can override and add to what maven does in the various phases, so just like in the days of ant things can easily devolve into chaos no one can understand on complex projects ;-).
sometimes in the integration-test phase, developers will tell maven to start up a container temporarily to run the web app on, so that tests can be run against it, and then that container is shut down when the integration-test phase completes.
I have a multi-module project with a parent pom.xml and several modules where some of the modules depend on each other. In the project directory I can call
mvn test
to run unittests in each module. No problem here. But if I call
mvn site
one of the modules reports
[ERROR] Failed to execute goal on project myModule_C: Could not resolve dependencies
for project org.myModule_C:jar:0.0.1-SNAPSHOT: The following artifacts could not be
resolved: org.myModule_A:jar:0.0.1-SNAPSHOT, org.myModule_B:jar:0.0.1-SNAPSHOT: Failure
to find org.myModule_A:jar:0.0.1-SNAPSHOT in http://artifactory-server:8081/artifactory/repo
was cached in the local repository, resolution will not be reattempted until the update
interval of server has elapsed or updates are forced -> [Help 1]
I think this should not happen since these dependencies are found during "mvn test". Also, they are not in the artifactory-server but part of the parent project. The goal that is mentioned in the ERROR is the goal site. Why does the mvn test succeed (with respect to dependencies it finds) and mvn site does not? Do I have to build the site in a special way - because this is a reactor build?
You should execute the mvn install as least once. Please see further information at the Maven Build Life Cycle and Maven in 5 Minutes.
Here is the overview
Maven Phases
Although hardly a comprehensive list, these are the most common default lifecycle phases executed.
validate: validate the project is correct and all necessary information is available
compile: compile the source code of the project
test: test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed
package: take the compiled code and package it in its distributable format, such as a JAR.
integration-test: process and deploy the package if necessary into an environment where integration tests can be run
verify: run any checks to verify the package is valid and meets quality criteria
install: install the package into the local repository, for use as a dependency in other projects locally
deploy: done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.
There are two other Maven lifecycles of note beyond the default list above
They are:
clean: cleans up artifacts created by prior builds
site: generates site documentation for this project
I hope this may help.
I tend to avoid using mvn install in my multi-module projects because I feel like I then don't know which exact version of a submodule is then used when building / launching other submodules (particularly when switching between branches very often).
I tend to use mvn package a lot and then mvn verify.
I'm now facing the issue in a FOSS project (a Maven archetype moreover) where I'd like to use Maven's best practices.
It's a multi-module project with a webapp submodule depending on the other modules, and what worries me is the ease of development along with mvn jetty:run (or jetty:start).
Currently, I defined 2 profiles:
prod, the default one, declares dependencies on the other submodules;
dev on the other hand does not depend on the other modules, and configures the jetty-maven-plugin by adding the other modules' output directories as extraClasspath and resourcesAsCSV.
That way, I can mvn package once and then cd webapp && mvn jetty:start -Pdev and quickly iterate, reloading the webapp without the need to even stop the server.
AFAICT, extraClasspath was added for that exact purpose (JETTY-1206).
I've been pointed at the tomcat7-maven-plugin which can resolve modules from the reactor build when using Maven 3 (and I raised an issue to bring the same to Jetty: JETTY-1517), but that hardly solve my
If I hadn't removed the dependency on the other submodules from in dev profile, I'd have had to do an mvn install first so that validating the POM doesn't fail, even if jetty:start doesn't use those dependencies afterwards.
So here's my question: is mvn install really that common? or my approach of putting the intra-reactor dependencies only in the prod profile OK?
(note that I have the exact same problem with the gwt-maven-plugin, so please don't tell me to simply switch to Tomcat; that wouldn't even work actually, details here)
The mvn install is common in particular in relationship with multi-module builds, cause it will give you the chance to run a single module from your multi-module build.
This can be achieved by using:
mvn -pl submodule LifeCycle
I just found a workaround (which seems logical as an afterthought): https://jira.codehaus.org/browse/JETTY-1517?focusedCommentId=306630&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-306630
In brief: skip the plugin by default in the parent module then re-enable it where needed.
This however only works if the plugin can be skipped (i.e. has a skip configuration) and is only used in one specific submodule, and it has to be selectively done for each plugin you need/want to run that way (in my case, jetty:run and gwt:run).
I do most of my development on my laptop. For the projects I'm currently working on, my local repository is really more of a temporary holding area. I run mvn install all the time. Putting artifacts in one's local repo is the only way I know of to share built artifacts between projects, especially if you are working on projects which are related but are not (and should not be) part of the same multi-module build.
When I'm done developing I commit changes to the shared SCM and let Jenkins build & deploy the code to the shared remote repo. Then I either blow away the changed projects in my local repository so the next build brings down the freshly built artifacts, or I run Maven with -U to force updates.
This works well for me, YMMV.