i'm not a maven expert. in my maven2 project i have a couple of report plugins (dependency, tattletale etc). some of them are bound to 'pre-site' phase, some to 'site' phase. this way i have a nice report on my site.
but sometimes, when tests don't pass i need this report to check what's wrong. is there any way to run the same plugins (in correct order) after compile or even after dependency resolution? i just want to skip all the findubs, checkstyle etc that are run at site phase and quickly have this single report to check why my project doesn't compile or why tests fail
i'm looking for something like:
mvn -P tattletale-report compile
but any other reasonable way will do
I don't know this plugin in particular but calling goals on the jetty plugin, it works with
mvn jetty:run-exploded
to give an example. Not knowing the plugin, i'd said
mvn tattletale:report
should work. Usually the plugin documentation should give you the right goals and commands. But hacking some words in Google, it appears to be a little more complicated.
Related
I am working with a rather complex open source Java project that uses Maven as its build tool.
It is a multi-module project with a parent POM, several submodules, WAR overlays, goals bound to nondefault phases and whatnot.
The build complexity is therefore high, and mvn help:describe -Dcmd=package is not informative enough to give an outline about what gets done during a build.
Is there a way to get an overview about all build steps?
As far as I know, I don't think that there's a Maven plugin that will do what you are asking out of the box. The way most of us Maven users do is to start from the root POM and simply run mvn clean install. What this gives you is more or less* all the plugin executions that are part of the default build.
Please note that there could also be profiles that may change things. Running mvn help:all-profiles will list all the available profiles and tell you where they come from (settings.xml, root POM, child POM, etc). This, together with perhaps mvn help:active-profiles, will help you get an idea of what is going on.
Also bear in mind that profiles are not mutually exclusive, so even though this allows for flexibility, they can sometimes cancel each other out or produce strange results for unexpected combinations.
I am sorry that I can't give you better advice than this. I don't know your level of Maven expertise so this information might be irrelevant to you.
I have a multi-module maven project with 5 modules. The modules are tiered such that a few depend on the first that builds (it's my model classes) and some depend on the second ones that build (those are core application classes). The final one that builds is a Spring WebMVC app which depends on all the other modules.
The problem I'm having is in Maven's --resume-from flag. It apparently doesn't do what I want. I must me misunderstanding what the word "resume" means in this context as I would expect it to, well, resume something.
If I run mvn verify and it fails at the rest-api sub-module, it tells me I can resume by running mvn --resume-from :rest-api verify. When I do that though, it downloads snapshots of the other modules from my project which rest-api depends on. That is so incredibly not what I want that it's comical. I wanted it to re-use the in-place jars it just built like 5 seconds ago inside this local checkout of the project!
Does anyone know what the nature of my misunderstanding is here? Am I misusing inter-module dependencies? Am I totally misunderstanding what --resume-from means? Is there some other argument to do what I want?
Use mvn install instead of mvn verify, as only after the install phase, Maven will be able to pull it from your local repo.
You probably also want the --also-make-dependents option.
See this blog for the full story.
I've been working with the release plugin, but am trying to automate its solution a little for our needs.
At the moment, all our builds run the following command:
mvn clean initialize release:prepare release:perform
While that's functional, it's not as concise as I would like it. I have a few plugins defined in my super-pom which are activated during the initialize phase and are required before the release plugin is run. Ideally, I would like to see my command as something like:
mvn doMyRelease
which in turn calls the necessary phases/goals of the different plugins.
Additionally, I'd like to create a phase called doMyStage which would do the following:
mvn clean initialize release:prepare release:stage
I figure that a custom plugin with a custom lifecycle is the way to go about this, but I am confused how to accomplish this. From what I read, the lifecycle is mapped to the packaging type. I do not wish to change the packaging type of any of my projects (as their packaging remains correct), but rather just provide a shortcut for the build command line.
I'm also having trouble finding a good tutorial/working maven 3 example for this concept. Most examples I see all refer to a components.xml file, but I read that this has been replaced with a default-bindings.xml descriptor in Maven 3.
I found this article https://developer.jboss.org/wiki/CreatingaCustomLifecycleinMaven?_sscc=t which touches a little on the issue, but like most examples, it requires changing the packaging type to match the lifecycle hint.
Is there a way to accomplish this?
Does anyone know the Maven build goals dependencies and order?
For instance, if I tell Maven to clean, it just cleans. But if I tell Maven to install, it also calls generate-sources, compile, test, etc. I am trying to figure out which goals are dependent on which other goals.
I have found this document, but it doesn't show dependencies.
It is sequential in the order mentioned under lifecycle section. You have clean and default lifecycle. The last command deploy under default lifecycle depends on every other command listed above it in the hierarchy. Similarly every command in a lifecycle depends on other commands listed above it.
I have a Maven project that is a set of a Selenium 2 tests that run using JUnit. In other words the only thing in the whole project is JUnit testcases and they all reside in the normal source directory i.e. src/main/java since they are the main source files in the project.
I want to be able to run these same tests using Maven, but since these tests are not actual unit tests or integration tests within the project (they are not testing themselves, they are testing a web app somewhere else), I don't want them to run during the normal build lifecycle. However I still would like to be able to define the test phases/goals within the POM file.
At this point I sort of understand the way the surefire plugin works, I just don't know how to de-couple the executions from the build. I would like all my new executions to be stand-alone so that I can simply run them by doing something like: mvn run-webtests and have the run-webtests phase be something completely different from the compile and package goals of my project.
So I guess I have two overall questions:
1.) Am I on the right track or is there some better way to think of this problem?
2.) What is it that I need to do next to make this work? Create a custom phase? Create a custom goal?
Sorry for asking such a seemingly basic question, but I wasn't able to find any examples of someone doing anything like this.
I think you're on the right track. It's just that Maven is unfortunately lacking in flexibility in some areas. Usually stuff can be made to fit in, but sometimes it can be a real pain. I think the simplest way to make this work is to use a different naming convention for your selenium tests and make sure those are excluded from your "normal" test runs. Then define a profile where you configure the surefire plugin to include your selenium tests and exclude the others. Then to run the selenium tests, you could just
mvn test -P selenium-tests
The only ways that you can set it up so that you could run mvn run-webtests, are
Define a custom lifecycle where "run-webtests" is a phase in the lifecycle, or
Write a plugin, though executing a plugin always has a ':' in it, so it would be more like mvn myplugin:run-webtests.
Those are both more work and harder to maintain than a simple profile in the pom.