I kind of understand most things in Maven, but trying to understand goals is very frustrating. The main problem is that Maven seems to want to hide everything and anything to do with Goals.
If I have a plugin with an execution, and this execution has a goal,
does the goal attach itself somewhere near particular other goals?
How does it know which phase it belongs in?
Does it somehow replace some other goal?
Case in point :
<plugins>
<plugin>
<groupId>org.jvnet.jax-ws-commons</groupId>
<artifactId>jaxws-maven-plugin</artifactId>
<version>2.3</version>
<executions>
<execution>
<id>wsimport-from-jdk</id>
<goals>
<goal>wsimport</goal>
</goals>
<configuration>
<executable>${tool.wsimport}</executable>
<wsdlUrls>
<wsdlUrl>http://WorkPC:8080/server-web/AirlineWS?wsdl</wsdlUrl>
</wsdlUrls>
<packageName>com.bluewalrus</packageName>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
This is a wsImport goal which generates artifacts from a web service. It happens before I compile my project. How on earth can this XML tell me where this goal should execute? It just doesn't seem clear to me.
I mean what I am saying, is that I would expect something like "bind-to-process-resources right after goal-xyz". It all seems a bit nebulous to me.
Unfortunately, the pom.xml cannot tell you everything about how a plugin's goals are bound. A plugin can define a default lifecycle phase to bind to and this will not be reflected in the pom.xml. Looking at the documentation for the jaxws-maven-plugin I see this line for the wsimport goal:
Binds by default to the lifecycle phase: generate-sources.
You can override the lifecycle phase to bind to by adding a <phase> element to the plugin's <execution>. For example, if you wanted the goal to run right before packing the artifact (not sure why you would, but bear with me for this example) you could specify <phase>package</phase> after the execution <id>
I would recommend taking a look at the official Maven guide to configuring plugins for more details.
Also you would want to read:
The phases's order in standard lifecycles
The phases's bindings for lifecycle and packaging types
Related
I want to deploy two jar artifacts with different classifiers, but at the moment that fails because both supply their own version of pom.xml. How can I fix that, so that both pom.xmls can be uploaded along with their artifacts?
Example - I have com.test.company.somelib-1.0.0-cmp1.jar and com.test.company.somelib-1.0.0-cmp2.jar, where cmpX is a classifier. Both packages contain (logically) the same code and classes (of the same version), they only differ slightly in the way they were preprocessed. The classifier annotation is there due to backwards compatibility we need to maintain.
Long story short, first artifact uploads fine, second one fails with Forbidden, because our repository does not allow overwriting artifacts (and I want to keep it that way).
There is a slightly different pipeline that creates both the packages, so it is easier to have their builds separate. I just want to deploy them as two packages of the same name and different classifier.
Thanks for help
Edit: it has been suggested to use Maven profiles. I can see that they would work, but they would not be ideal.
Consider the setup I have depicted on the picture below - there is a CI server (TeamCity).
There is a "starter" build (Sources). This build checkouts all required source files.
From this starter build several other builds are triggered (processing using x.x.x/compile). Each of those builds adjusts a template-pom.xml (fills in particular classifier and other info), and then builds and deploys its artifact to our Artifactory.
With the setup I want to achieve if I decide to add another processing-build, all I need to do is add another "branch". If I was using profiles, I would need to also add a new profile to the pom.xml file.
Correct me if I am wrong please. Profiles seem to be able to achieve the goal, but not ideally, at least in my case.
I strongly discourage having 2 (or more) different pom files with the same GAV.
But I understand your need is raised by legacy reasons.
I have not tried this myself but it could be working:
Leave one build (= maven project) as you have it now. On the other build skip the normal deployment and manually invoke the deploy-file goal of the deploy plugin like so:
<build>
<plugins>
<!-- skip normal execution of deploy plugin -->
<plugin>
<artifactId>maven-deploy-plugin</artifactId>
<executions>
<execution>
<id>default-deploy</id>
<configuration>
<skip>true</skip>
</configuration>
</execution>
</executions>
</plugin>
<!-- invoke with goal: deploy-file -->
<plugin>
<artifactId>maven-deploy-plugin</artifactId>
<executions>
<execution>
<id>someId</id>
<phase>deploy</phase>
<goals>
<goal>deploy-file</goal>
</goals>
<inherited>false</inherited>
<configuration>
<file>path-to-your-artifact-jar</file>
<generatePom>false</generatePom>
<artifactId>xxx</artifactId>
<groupId>xxx</groupId>
<version>xxx</version>
<classifier>xxx</classifier>
<packaging>xxx</packaging>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
I have entered required config into my pom.xml to develop with ActiveJdbc, which includes one dependency and one plugin.
Dependency went ok, while plugin caused error message from Eclipse:
Plugin execution not covered by lifecycle configuration
I am new to plugins, and understand neither the error message nor the provided quick fixes.
What do they mean?
UPDATE
If I wrap <plugins> section into <pluginManagement> tag, error disappears. But at the same time, instrumentation does not execute anymore.
Is it possible to both remove an error message and leave instrumentation performed in Eclipse?
This is an error raised by the new M2E plugin (starting with version 1.0) when it encounters a plugin that has no lifecycle mapping information, which explicitly tells M2E how to handle the plugin executions. Personally, I have no problem sticking to the old m2eclipse (version 0.12) most of the time as long as it builds everything fine.
Still, to remove this error, you may try adding the following lifecycle mapping metadata for the activejdbc-instrumentation plugin to execute its goal:
...
<pluginManagement>
<plugins>
<plugin>
<groupId>org.eclipse.m2e</groupId>
<artifactId>lifecycle-mapping</artifactId>
<version>1.0.0</version>
<configuration>
<lifecycleMappingMetadata>
<pluginExecutions>
<pluginExecution>
<pluginExecutionFilter>
<groupId>org.javalite</groupId>
<artifactId>activejdbc-instrumentation</artifactId>
<versionRange>[1.4.9,)</versionRange>
<goals>
<goal>instrument</goal>
</goals>
</pluginExecutionFilter>
<action>
<execute />
</action>
</pluginExecution>
</pluginExecutions>
</lifecycleMappingMetadata>
</configuration>
</plugin>
</plugins>
</pluginManagement>
<plugins>
<plugin>
<groupId>org.javalite</groupId>
...
See http://wiki.eclipse.org/M2E_plugin_execution_not_covered for more information about this error.
Apparently, according to the type of pom packaging the build binds to different lifecycle phases by default. If you were trying to run the execution in phase: process-classes, try changing it into one the pom packagin has to go through. I'm not sure if this is the right way to fix it but it works for me. In the maven build lifecycle you can see that the pom packaging binds to packaging type, install and deploy, so if this was your package try modifing phase to "package" for example, which for the pom type would be the first phase.
Now if you run it in the console it will work but in eclipse will mark the error. If you change the phase then the error will go away and you can still run it.
This is more likely a quick fix but if you just want to make sure that it executes before the other plugins in the pom just make sure it is on a previous phase and not necesarily in the one it belongs to.
This is purely a eclipse plugin issue. Here are two solutions
Your project will try to build from command line. Try mvn clean install
You can switch to intellij - this has much better native support for maven without any plugin needed.
I have a Maven-based project, in which I trying to add some JAXB classes automatically generated by the "jaxb2-maven-plugin" Maven plugin. However, my first cut has me in a circular dependency loop:
Because these JAXB classes aren't generated yet, my other sources which reference them have compilation errors.
Because those other sources have compilation errors, these JAXB classes don't get generated.
It seems like there are two obvious possibilities for solving this:
Comment-out the broken references, so that the project builds and the JAXB classes are automatically generated. Then copy those generated sources from /target into /src/main/java, so that references to them won't cause compilation errors.
Create an entirely separate project, consisting of nothing but the JAXB stuff. Include it as a dependency in my main project.
Am I missing something here? Option #1 seems flat-out ridiculous... that just can't be the manner in which people use JAXB. Option #2 seems more rational, but still rather inefficient and cumbersome. I really have to take on the overhead of an entirely separate project just to use JAXB?
Are there any more elegant approaches that developers use to reference JAXB-generated classes in the same project where the Maven plugin generates them?
UPDATE: By request, here is the relevant portion of my POM:
<build>
<plugins>
<plugin>
<!-- configure the compiler to compile to Java 1.6 -->
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.6</source>
<target>1.6</target>
</configuration>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxb2-maven-plugin</artifactId>
<version>1.4</version>
<executions>
<execution>
<phase>generate-sources</phase>
<goals>
<goal>xjc</goal>
</goals>
</execution>
</executions>
<configuration>
<!-- The name of your generated source package -->
<packageName>com.mypackage</packageName>
</configuration>
</plugin>
</plugins>
</build>
When I run mvn clean package, I DO see my JAXB sources being generated beneath the /target subdirectory. However, those generated sources are not being automatically added to the classpath for the compile phase.
POST-RESOLUTION UPDATE: It turns out that my compilation issues had more to do with the fact that I was running in Eclipse, and its Maven integration has some issues with "jaxb2-maven-plugin". See this StackOverflow question for more detail on that issue and its resolution.
How did you configure your jaxb maven plugin? Normally it runs in the generate-sources lifecycle, which comes before the compile lifecycle. So your JAXB generated classes should already be there when your own code gets compiled, Maven puts them in target/generated-source and puts that folder on the classpath.
Edit:
This is my code we use at work (and which works as expected):
<plugin>
<groupId>com.sun.tools.xjc.maven2</groupId>
<artifactId>maven-jaxb-plugin</artifactId>
<executions>
<execution>
<phase>generate-sources</phase>
<goals>
<goal>generate</goal>
</goals>
</execution>
</executions>
<configuration>
<schemaDirectory>src/main/resources/<companyname>/xsd</schemaDirectory>
<includeSchemas>
<includeSchema>retrieval.xsd</includeSchema>
<includeSchema>storage.xsd</includeSchema>
</includeSchemas>
</configuration>
</plugin>
Apparently we use yet another jaxb plugin... (see also this thread: Difference of Maven JAXB plugins).
i would suggest you to split jaxb-generated classes (api) and your BL classes (implementation) to 2 maven projects with separate pom.xml for each, and the main root pom.xml with the compilation order. that way, you will be able to build api.jar, then maven will install it inside the local repo, and after that you can use it as the dependency of your implementation. so it will looks like:
-API\
--pom.xml - for api, jaxb generation
-IMPL\
--pom.xml - for impl, api dependency is here
pom.xml - main pom.xml with references to the projects above
Maybe try using the maven-jaxb2-plugin instead:
<plugin>
<groupId>org.jvnet.jaxb2.maven2</groupId>
<artifactId>maven-jaxb2-plugin</artifactId>
<version>0.8.2</version>
<executions>
<execution>
<goals>
<goal>generate</goal>
</goals>
</execution>
</executions>
</plugin>
The answer from dfuse is correct, though. Either plugin should generate sources before compiling, and the result of the source generation will be on the classpath. I tested this with both plugins. Is it possible for you to post your schema, or at least the schema for the type that your code is failing to pick up on the classpath?
Right now, I'm writing a small java application by my own, with few maven pom.xml files. I want to make all my maven packages to compile with jdk 1.6, and I can't find a good way to do it without manually setting it on every single POMs - I'm sick of copy-and-pasting
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.6</source>
<target>1.6</target>
</configuration>
in every single pom.xml file I generate.
Is there a simpler way to resolve this issue?
Create a pom-only (<packaging>pom</packaging>) project that has the compiler settings (and any other default settings) you want. You give treat it like any other project (release it; deploy it to your Maven repo, etc.).
Put a parent declaration at the top of your pom files:
<parent>
<groupId><!-- parent's group id --></groupId>
<artifactId><!-- parent's artifact id --></artifactId>
<version><!-- parent's version --></version>
</parent>
It doesn't help much if all you want to set is compiler settings. But if you find yourself configuring lots of plugins, reports and dependencies in the same way across project, you can create one parent to rule them all.
BTW - be careful about declaring dependencies and plugins in your parent pom file. Usually you'll want to favor dependencyManagement and pluginManagement. See the documentation for more details.
You could specify this plugin and configuration in your ~/.m2/settings.xml, which will then apply it to all projects.
However this has the downside of making your projects no longer portable - attempting to build the same code with the same pom.xml will fail on other machines that don't have the same settings.xml values as you.
I'm sick of copy-and-pasting
Yes, and you should use POM inheritance to avoid this and configure the maven-compiler-plugin in the parent POM.
Another option would be to use the solution suggested by #matt (and he nailed down pros and cons of the use of settings.xml).
In both cases, this is typically a setting that I like to check using the maven-enforcer-plugin and its requireJavaVersion rule that you would configure like this:
<project>
[...]
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<executions>
<execution>
<id>enforce-versions</id>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<requireJavaVersion>
<version>1.6</version>
</requireJavaVersion>
</rules>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
[...]
</project>
But it can do more (like checking the maven version). Very useful.
I want to make all my maven packages to compile with jdk 1.6
If this is multi-module project just put these settings to top-level POM under pluginManagement.
If you have many independent project just copy-and-paste this configuration. Beware of "smart" solutions like setting this somewhere globally. Some day you will want to use different compiler settings for one or two of your projects and the nightmare will begin :-)
Remember...
Keep things as simple as possible, but no simpler.
I have installed the Maven for Eclipse plugin from Sonatype.
(update site: http://m2eclipse.sonatype.org/update/)
I am creating a Maven project, and choosing to use the groovy-maven-archetype as my starting point.
However, halfway through, I am seeing:
04/03/09 12:52:28 GMT: [FATAL ERROR]
org.codehaus.mojo.groovy.stubgen.GenerateStubsMojo#execute()
caused a linkage error (java.lang.NoSuchMethodError). Check the realms:
... snip ...
Realm ID: plexus.core
org.codehaus.plexus.PlexusContainer.createChildContainer
(Ljava/lang/String;Ljava/util/List;Ljava/util/Map;)
Lorg/codehaus/plexus/PlexusContainer;
How can I fix this?
At a command prompt, enter this: mvn archetype:generate
Then, choose 40 (gmaven-archetype-basic)
Then, follow the prompts.
Once you have a maven project, you can enable Eclipse support by saying: mvn eclipse:eclipse
You can read Building Groovy Projects for more information.
Seems like a versioning problem to me. Are you sure you used all the right versions of the jars?
Getting Groovy-Eclipse, gmaven, and Eclipse all working together seems to be pretty tricky at the present. Once you've got a project created with mvn archetype:generate, as AWhitford mentions, this site will show you a few of the tweaks you'll need to make it work.
GMaven's stub creation for Java files interferes with Groovy-Eclipse, hence the section on that page about commenting out stub creation. However, I went with the method mentioned in the comments for the relevant bug (GMAVEN-61) and created multiple executions for the gmaven plugin, like so:
<build>
<plugins>
<plugin>
<groupId>org.codehaus.groovy.maven</groupId>
<artifactId>gmaven-plugin</artifactId>
<version>1.0-rc-3</version>
<!-- http://jira.codehaus.org/browse/GMAVEN-61 -->
<executions>
<execution>
<id>default-cli</id>
<goals>
<goal>compile</goal>
<goal>testCompile</goal>
</goals>
</execution>
<execution>
<id>stubsonly</id>
<goals>
<goal>generateStubs</goal>
<goal>generateTestStubs</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
I'm still not certain myself that this is clean for both pure Maven usage as well as within Eclipse, but it at least got me to the point where I stopped spending hours trying to get anything to work and got me coding on my actual project.
The Groovy-Eclipse and GMaven documentation are good reading for background info.