I have a Maven project within which I need execute two code generation steps. One generates some Java types, then the second depends on those Java types to generate some more code. Is there a way to have both of these steps happening during my build?
At the moment my steps are:
execute first code generation plugin (during generate-sources)
add directory of generated types to build path
execute second code generation plugin (during compile)
However my problem is that anything generated by the second code generation plugin will not be compiled (because the compile phase has finished). If I attach the second code generation plugin to an earlier phase, it fails because it needs the classes from the first code generation plugin to be present on the classpath.
I know I could split this into two modules with one dependent on the other, but I was wondering if this could be achieved in one pom. It seems like a need a way to invoke compile again after the normal compile phase is complete.
Any ideas?
You can always configure two executions of the compiler plugin, both tied to the compile phase. In one you include the extra stuff:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.2</version>
<executions>
<execution>
<id>one</id>
<phase>compile</phase>
<goals>
<goal>compile</goal>
</goals>
<configuration></configuration>
</execution>
<execution>
<id>two</id>
<phase>compile</phase>
<goals>
<goal>compile</goal>
</goals>
<configuration>
<compilerArgument>-verbose -bootclasspath ${java.home}\lib\rt.jar</compilerArgument>
</configuration>
</execution>
</executions>
<plugin>
You may try as well <includes><include>path/</include></includes>
According the official documentation:
When multiple executions are given that match a particular phase, they are executed in the order specified in the POM, with inherited executions running first.
But I quite not get what you exactly want.
http://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-source-and-target.html
The obvious solution (generate code after the compile phase) doesn't work since Maven doesn't allow to reorder the phases.
The correct solution is to use modules. You need two: The first module contains the code generator. In the second module, you can use the generator from the first module to generate something in the generate-sources phase.
The big advantage of this approach: You can never get caught in some kind of loop (like "A" needs generated code which needs "A"). So your build will be more simple and you will spend less time hunting odd bugs.
[UPDATE] In my projects, I run the code generator from tests. Without a special option, the files are generated into the temp folder and compared to the sources. That allows me to see when I have unexpected changes in my generated code (which I put under version control).
When the system property is set, the source files are overwritten and I can commit the changes to my VCS.
Related
I noticed maven plugins has goals and they are bound to different phases. But it seems some goals will only be executed after we explicitly config them in side execution tag. For example, maven-jar-plugin has two goals jar and test-jar. If you don't config test-jar goal explicitly inside execution tag then it will not be executed. It will only be triggered with below config where test-jar is explicitly config inside execution tag
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>3.1.0</version>
<executions>
<execution>
<phase>test-compile</phase>
<goals>
<goal>test-jar</goal>
</goals>
</execution>
</executions>
</plugin>
But for goal jar whether you config it with execution tag or not, it will always be triggered. In this case, I wonder to trigger a goal of a plugin should we config it inside execution tag or not? I didn't see official doc has any clarification on this either. Thanks.
The jar goal is by default bound to the default life cycle (jar) so it's triggered automatically.
All plugins which are bound by the default life cycle (for example maven-compiler-plugin etc) will run automatically during a build.
Any other goals which are not bound will not run automatically and have to be bound manually if needed.
All goals like the jar goal of the maven-jar-plugin should never being bound manally... because they are already bound to the life cycle.
Furthermore you should always check the documentation of the appropriate plugin (here the maven-jar-plugin) and check the goal page for the text: Binds by default to the lifecycle phase: package.
This means you can omit the <phase>..</phase> part of your configuration because the plugin knows the life cycle phase when it should start.
I have created a Maven project, which contains Java domain classes that are generated from database tables, using hibernate3-maven-plugin.
The same project however also contains Dao classes that make use of these generated domain classes.
When compiling the project using mvn clean compile, the build will fail because the Dao classes won't compile: the domain classes have not been compiled yet.
The domain classes won't be generated because the build fails. As if running in a circle. :-)
How can I make sure, the plugin generates the domain classes, before the dao classes are compiled?
Thanks!
You must bind the generation of the domain classes i.e. the execution of the hibernate plugin to a Maven phase that is executed before the compile phase, e.g. generate-sources.
<build>
<plugins>
<plugin>
<artifactId>hibernate3-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>(goal for generating sources)</goal>
</goals>
<phase>generate-sources</phase>
See
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
When you generate your sources to the target dir, the Maven compiler plugin should pick them up and compile them.
i am new to maven and learning how and when phases/goals get executed in plugin
Say i have below code snippet in my pom
<plugin>
<groupId>org.codehaus.modello</groupId>
<artifactId>modello-maven-plugin</artifactId>
<version>1.4</version>
</plugin>
Now if i execute mvn install, all phases(and all goals corresponding to each phase) of modello that comes prior to install will be executed. Right?
But if do below modification to introduce specific goal, only one goal i.e java goal will be executed
(as it under generate-sources phase which comes prior to install phase). Is that correct?
<plugin>
<groupId>org.codehaus.modello</groupId>
<artifactId>modello-maven-plugin</artifactId>
<version>1.4</version>
<executions>
<execution>
<goals>
<goal>java</goal>
</goals>
</execution>
</executions>
</plugin>
No, it doesn't work like that. First of all, please use mvn verify (instead of install), unless you really want your project to be copied to your local repository.
If you only specify a plugin, which is not part of the default lifecycle (e.g. maven-compiler-plugin is already specified for the default lifecycle, all jars need to compile, right?), nothing will happen. So you need to specify which goals need to be executed within an execution-block. In some cases the goal has a default phase to bind to, e.g. modello:java binds by default to the generate-sources-phase. In this case you don't have to specify a <phase> in the execution-block.
I would like to run the following basic procedure within my Maven 3.0.4 project. I have all the basics in place and haven't had any issues but am running into problems on step #3. For some reason the basic solution is eluding me, since it seems like something that should be very obvious.
Run a basic clean/install (without annotation processing)
Request that a site build be run
Before the site build kicks off, run annotation processing on the compiled classes using an annotation processor class that was compiled in the initial steps
I tried setting up the annotation processing goal as follows:
<plugin>
<groupId>org.bsc.maven</groupId>
<artifactId>maven-processor-plugin</artifactId>
<executions>
<execution>
<id>process</id>
<goals>
<goal>process</goal>
</goals>
<phase>pre-site</phase>
<configuration>
<outputDirectory>${basedir}/target/generated-documentation</outputDirectory>
<processors>
<processor>com.mydomain.MyFancyAnnotationProcessor</processor>
</processors>
</configuration>
</execution>
</executions>
</plugin>
For some reason this doesn't seem to be working.
I feel like I'm doing something very, very silly that is preventing it from working.
I am using the Maven Annotation Plugin instead of the basic, Mojo Apt Plugin. I don't mind switching if someone has a working solution with that one. I tried both without any immediate signs of success. Again, it feels like it's just something obvious that I'm overlooking.
Error received:
[INFO] diagnostic error: Annotation processor 'com.mydomain.MyFancyAnnotationProcessor' not found
[ERROR] error on execute: error during compilation
My guess would be that the plugin is not including the current project itself in its classpath. The best solution would be to separate the annotation processor into its own (sub-)module if possible. If you can't do that, you may be able to just add this project itself as a dependency of the plugin (using a <dependencies> section under the plugin node).
As a diagnostic note, you can run maven with the '-X' argument to see detailed info about the build. This should show you exactly what is on the classpath when the plugin is executed.
I'm a lone Emacs user in a group that's hung up on Eclipse. Time and again, code diffs are made larger by imports that have been "organized" or "cleaned up" by Eclipse.
I don't have a strong opinion on the subject of import style in Java, but I do want to minimize our diffs. What can I do?
We use Maven2 for builds; is there a plugin that can help me? Can a piece of Eclipse be abstracted out & turned into a Maven plugin? I currently use ImportScrubber and have encountered a few other stand-alone pieces that do the same thing. What I'm really looking for is a Maven plugin that can integrate with the build.
Barring the above, I'll put an ImportScrubber invocation into my .git/hooks/post-commit.
The Hybridlabs beautifier which is used internally in the openArchitectureWare project (an open source generator framework) is doing what you're looking for. As explained in this blog entry, the beautifier is available as a Google Code project and its documentation describes a maven 2 plugin:
<plugin>
<groupId>org.hybridlabs</groupId>
<artifactId>maven-beautifier-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>beautify-imports</goal>
</goals>
</execution>
</executions>
<configuration>
<!-- Recursively scan for *.java and beautifies imports -->
<inputDirectory>${pom.basedir}/..</inputDirectory>
<!--outputDirectory>${pom.basedir}/..</outputDirectory>
<runBeautifier>true/runBeautifier>
<runJalopy>false</runJalopy-->
</configuration>
</plugin>
There is indeed a mojo in the source tree but it doesn't match the groupId mentioned above (this is a bit confusing) and I've not been able to find the plugin in maven's public repository.
Maybe you'll be more lucky with the version available in AndroMDA plugin repository as documented in this thread (the plugin is indeed present in http://team.andromda.org/maven2/).
The plugin is under
org.apache.maven.plugins.maven-beautifier-plugin.
It can be run with the short form:
mvn beautifier:beautify-imports. It
can also be run as part of a project
pom by adding the plugin declaration
under <build><plugins>:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-beautifier-plugin</artifactId>
<version>1.0</version>
<executions>
<execution>
<goals>
<goal>beautify-imports</goal>
</goals>
</execution>
</executions>
<configuration>
<inputDirectory>${pom.basedir}/target/src</inputDirectory>
</configuration>
</plugin>
Or contact the project's author (e.g. through twitter or by mail).
I think all of you (Eclipse, Emacs or whatever users) should use something like Jalopy which supports both Eclipse and Maven. This way it becomes irrelevant where the code was modified as long as it has been run through pretty-printer as part of checking code in. Said that - I'm not sure if Jalopy supports organizing imports beyond sorting these up
I have also found an ImportScrubber plugin. Can't as of yet attest to its quality.
Does your shop have code standards for how imports should be organized? If so then you are out of luck. Minimizing diffs is a small sacrifice to make towards incremental code improvement.