I am using querydsl in my spring project and want to generate Q classes at src/main/java/xxx/xxx/model/here . When I write except for src/main/java at my pom.xml, it will work. But, When I write src/main/java, it will not work.(doesn't generate q classes.) Do you know why? In src/main/java, there are another classes I wrote. Is it impossible to generate Q classes at existing place?
Here is my pom.xml
<plugin>
<groupId>com.mysema.maven</groupId>
<artifactId>apt-maven-plugin</artifactId>
<version>1.1.3</version>
<executions>
<execution>
<phase>generate-sources</phase>
<goals>
<goal>process</goal>
</goals>
<configuration>
<outputDirectory>src/main/java</outputDirectory>
<processor>
com.querydsl.apt.jpa.JPAAnnotationProcessor
</processor>
</configuration>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>com.querydsl</groupId>
<artifactId>querydsl-apt</artifactId>
<version>${querydsl.version}</version>
</dependency>
</dependencies>
</plugin>
You should add the directory path in target like this:
target/generated-sources/java
First of all why do you think of generating them in source folder. That way you are complicating your actual codebase. They are auto generated files.
They are supposed to be as given below
<configuration>
<outputDirectory>target/generated-sources/querydsl</outputDirectory>
<processor>com.querydsl.apt.jpa.JPAAnnotationProcessor</processor>
</configuration>
But if you still need them in src folder , follow steps below.
Disable Project › Build Automatically…
Run Maven goal 'generate-sources', which runs apt-maven-plugin
Refresh the project in Eclipse, the generated source files are present as expected
Project › Build Project
The folder with generated sources is created.
You may look at the class path setting for the project. Now you can use all Q classes wherever you need.
Related
When running mvn versions:display-dependency-updates for the Version Maven Plugin I see lots of things like this:
[INFO] org.slf4j:slf4j-api ........................... 1.7.36 -> 2.0.0-alpha7
But just because I'm not using the alpha version of a later version doesn't mean I'm not using the latest available release version. Another Stack Overflow answer indicated that I can set up a rules.xml file to ignore versions like *.-alpha*, putting something like this in my POM:
<configuration>
<rulesUri>file:///${project.basedir}/rules.xml</rulesUri>
</configuration>
My question: is this rules.xml file inheritable? If I put it in a separate project in a parent POM of <packaging>pom</packaging>, published to Maven Central, will the child POMs pick it up? Or will the child projects look for a rules.xml file in the child project directory?
I want to configure the versions-maven-plugin in the parent POM (as I do already) and run mvn versions:display-dependency-updates on any child POM or descendant POM. How can I set up the ignore rules in the parent POM so that these version ignore rules will be picked up when I check for dependency updates in a child POM? (Is there no way to include the rule within the POM itself?)
Or will the child projects look for a rules.xml file in the child project directory?
Yes, if you define the rules.xml file via ${project.basedir} it will resolve to the current local base directory of the child project. I've verified this with a simple parent-child pom setup. So that will not work, unless you duplicate the rules file in every project.
If you wish to include the plugin configuration and ruleset in the parent pom without duplicating the rules file, you have two options:
If you have your ruleset xml file hosted at, for example, http://www.mycompany.com/maven-version-rules.xml then the following configuration in your corporate pom would ensure that all projects use this rule set.
<configuration>
<rulesUri>http://www.mycompany.com/maven-version-rules.xml</rulesUri>
</configuration>
or
You can provide your ruleset xml file also within a jar, if you want to distribute your ruleset xml as Maven artifact. Therefore you have to declare the containing jar as direct dependency of the versions-maven-plugin and to use classpath as protocol.
<configuration>
<rulesUri>classpath:///package/foo/bar/rules.xml</rulesUri>
</configuration>
<dependencies>
<dependency>
<groupId>com.mycompany</groupId>
<artifactId>version-rules</artifactId>
<version>1.0</version>
</dependency>
</dependencies>
Source:
https://www.mojohaus.org/versions-maven-plugin/version-rules.html
The configuration in the pom only has rudimentary includes and excludes filters. Those will allow you to exclude any dependency as a whole, but not specific update versions. As far as i can tell from the available documentation there is no way to define version rules in any other way.
See
https://www.mojohaus.org/versions-maven-plugin/examples/advancing-dependency-versions.html
Update 09-2022
In the github ticket we found in the comments we can see the following update:
It looks like a feature like this has recently been implemented by #369. Please see #318 where it's possible to provide inclusion and exclusion filters for determining which dependency patterns will be considered. Thanks to that, you can rule out patterns such as .*-beta. or .*_ALPHA, albeit not using regexp, but simple asterisk wildcards.
This will land in today's release (2.12.0).
This will add the following features:
Version 2.12.0 will introduce new arguments: dependencyIncluded, dependencyExcludes, dependencyManagementIncludes, dependencyManagementExcludes.
With the following example configuration in pom.xml given:
<profile>
<id>display-dependency-updates</id>
<build>
<plugins>
<plugin>
<groupId>${project.groupId}</groupId>
<artifactId>${project.artifactId}</artifactId>
<version>${project.version}</version>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>display-dependency-updates</goal>
</goals>
<configuration>
<dependencyIncludes>org.apache.maven.*:doxia*</dependencyIncludes>
<dependencyManagementIncludes>com.puppy*:*</dependencyManagementIncludes>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
This will also be implemented for filtering plugin and pluginManagement, but that will probably be added in a later release:
So, I've just added the missing plugin- and plugin management filtering which works likewise. I really doubt it will land into today's release though.
Pasting my answer here from Github, because I think it might benefit others.
Provided you have a directory called rules-test in your project containing the rules template file:
<ruleset comparisonMethod="maven"
xmlns="http://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0
https://www.mojohaus.org/versions-maven-plugin/xsd/rule-2.0.0.xsd">
<ignoreVersions>
<ignoreVersion type="regex">${ignoredVersions}</ignoreVersion>
</ignoreVersions>
</ruleset>
Then, in your main project, create the following profile:
<profile>
<id>rules-test</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>3.3.0</version>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<resources>
<resource>
<directory>rules-test</directory>
<filtering>true</filtering>
</resource>
</resources>
<outputDirectory>${project.basedir}</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>versions-maven-plugin</artifactId>
<version>2.12.0</version>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>display-dependency-updates</goal>
</goals>
<configuration>
<rulesUri>file://${project.basedir}/compiled-rules.xml</rulesUri>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
If you then execute the following Maven target:
mvn -P rules-test "-DignoredVersions=.*-(M\d*|.*-SNAPSHOT)" clean validate
then you will get a dependencies report using the filter in the -DignoredVersions argument (filtering out both *-M* and *-SNAPSHOT).
And if you put your ignoredVerions property in your project instead of passing it as a -D argument, then it will be inheritable!
I have a maven project, I need to generate three separate jars
one for the main application (default)
one for the source code (maven-source-plugin)
and one for my app documentation which reside in target/docs
Question: How can I create a jar containing only the target/docs folder?
You could add the following to your maven pom.xml file, build/plugins section:
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<version>3.0.1</version>
<executions>
<execution>
<configuration>
<classifier>docs</classifier>
<classesDirectory>${project.build.directory}/docs</classesDirectory>
<includes>**/*</includes>
</configuration>
<id>pack-docs</id>
<phase>package</phase>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
Which is basically:
Using the maven-jar-plugin, jar goal to pack a new artefact for the project
Adding (or attaching) it as a classifier (docs suffix appended to the normal convention for project artefacts, e.g. artifactId-version.jar)
Setting the target\docs as source of files, using the standard ${project.build.directory} property instead of target (which is its value by default)
Running
mvn clean package
You would then have as part of the output
The jar file normally created, e.g. sample-project-1.0.0-SNAPSHOT.jar
The new docs file, e.g. sample-project-1.0.0-SNAPSHOT-docs.jar
Got some issues with axis generation from wsdl
Once generated, classes are not visible eclipse /target folder (I can see them in a terminal...)
I cannot include them and use them.
I guess I'm missing something here, axis and soap are such a pain...
The project jar contains the generated classes, I can add it to build path manually and that works.
If I'm including the maven module in another module, maven complains "
<plugin>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2-wsdl2code-maven-plugin</artifactId>
<version>1.5.4</version>
<executions>
<execution>
<id>generate 1</id>
<goals>
<goal>wsdl2code</goal>
</goals>
<configuration>
<packageName>com.test</packageName>
<wsdlFile>path.to.wsdl</wsdlFile>
</configuration>
</execution>
</executions>
</plugin>
The issue here is that axis2-wsdl2code-maven-plugin is putting the JAR in a non standard place - this is why maven complains when you try in add it as a dependency.
Can you see the JAR being installed into your local maven repo?
I have two projects:
A
/src/main/resources/schema.xsd
pom.xml
B
/src/main/gen
pom.xml
I want in B project generate classes from XSD, that exists in A Project
In pom.xml of B project I have:
<dependencies>
<dependency>
<groupId>test</groupId>
<artifactId>A</artifactId>
<version>${project.version}</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxb2-maven-plugin</artifactId>
<executions>
<execution>
<id>xjc</id>
<goals>
<goal>xjc</goal>
</goals>
</execution>
</executions>
<configuration>
<schemaDirectory>src/main/resources</schemaDirectory>
<outputDirectory>src/main/gen</outputDirectory>
</configuration>
</plugin>
</plugins>
</build>
But xsd file is not found in classpath:
Failed to execute goal org.codehaus.mojo:jaxb2-maven-plugin:1.5:xjc (xjc) on project B: No schemas have been found
How can I use xsd from another project?
My maven-jaxb2-plugin supports separate schema compilation.
How to do this:
Add your artifact a as episode.
If a.xsd is imported into b.xsd, you have to make this schema available to JAXB when compiling b:
One way to do this is to extract a.xsd from the artifact a using Maven dependency plugin, for instance.
Another way would be to use a catalog file to rewrite the location of a.xsd into the artifact a
See this test project for example.
The project a is totally unspectacular. Just compiles the schema a.xsd.
The project b is more interesting. Let's take a look.
pom.xml:
<plugin>
<groupId>org.jvnet.jaxb2.maven2</groupId>
<artifactId>maven-jaxb2-plugin</artifactId>
<configuration>
<catalog>src/main/resources/catalog.cat</catalog>
<episodes>
<episode>
<groupId>org.jvnet.jaxb2.maven2</groupId>
<artifactId>maven-jaxb2-plugin-tests-MAVEN_JAXB2_PLUGIN-82-a</artifactId>
</episode>
</episodes>
</configuration>
</plugin>
The configuration says use the artifact a as episode. So when JAXB/XJC meets classes compiled in a, it will reuse them instead of generating new ones.
By the way, you can use the useDependenciesAsEpisodes instead of configuring individual episodes. In this case all the dependencies will be treated as episodes which is very convenient (less configuration).
The configuration also says to use the catalog file:
REWRITE_SYSTEM "http://www.ab.org" "maven:org.jvnet.jaxb2.maven2:maven-jaxb2-plugin-tests-MAVEN_JAXB2_PLUGIN-82-a:jar::!"
This instructs JAXB/XJC to rewrite all schema URLs starting with http://www.ab.org to start with maven:org.jvnet.jaxb2.maven2:maven-jaxb2-plugin-tests-MAVEN_JAXB2_PLUGIN-82-a:jar::! instead. The latter will be processed by the maven-jaxb2-plugin and finally resolved to the resource in a.
Let's take a closer look. The schema b.xsd imports http://www.ab.org/a.xsd:
<import namespace="urn:a" schemaLocation="http://www.ab.org/a.xsd"/>
This will be rewritten to maven:org.jvnet.jaxb2.maven2:maven-jaxb2-plugin-tests-MAVEN_JAXB2_PLUGIN-82-a:jar::!/a.xsd which will be resolved to the a.xsd inside the JAR of the project a. So, finally, JAXB/XJC will be able to read this schema from the a's JAR artifact.
You can also use PUBLIC instead of REWRITE_SYSTEM to reference a.xsd per namespace URI instead of schema location (which is logically better):
PUBLIC "urn:a" "maven:org.jvnet.jaxb2.maven2:maven-jaxb2-plugin-tests-MAVEN_JAXB2_PLUGIN-82-a:jar::!/a.xsd"
However there's a bug in JAXB/XJC this does not work if you have schemaLocation in your xs:import.
This would work at the moment:
<xsd:import namespace="urn:a"/>
This won't work at the moment:
<xsd:import namespace="urn:a" schemaLocation="a.xsd"/>
I've sent Oracle a pull request which fixes that but it's not applied yet.
The explanation above applies to the maven-jaxb2-plugin and works in versions 0.10.0 and higher.
Your original question is about jaxb2-maven-plugin from Codehaus which is a different Maven plugin. This plugin does not have all the features I've described above, but at least episodes should work via arguments. Catalogs must also work, but I believe, jaxb2-maven-plugin does not support resolving schemas in Maven artifacts. You can use the maven-dependency-plugin to extract a.xsd from artifact a instead.
SO disclaimer: I am the author of the maven-jaxb2-plugin.
Note for reviewers: it is NOT my intention here to push/advertise my plugin, I just want to provide a solution to the asked question. And it appears that my project offers the best/most elegant and full solution.
The problem with this configuration is that <schemaDirectory> expects a File name/path. The thing about File is that it looks for files on the file system, searching from the current working directory. In which case the project root. But the resource from project A is not in the src/main/resources of the project B. It is a classpath resource, of which (when build in maven), the src/main/resources doesn't even exist anymore.
I've never tried to do with with the jaxb2-maven-plugin, so I am not sure if it is possible.
But with the maven-jaxb2-plugin, it allows Compiling a schema from a Maven artifact. You could so something like
<plugin>
<groupId>org.jvnet.jaxb2.maven2</groupId>
<artifactId>maven-jaxb2-plugin</artifactId>
<version>0.9.0</version>
<executions>
<execution>
<goals>
<goal>generate</goal>
</goals>
</execution>
</executions>
<configuration>
<schemas>
<schema>
<dependencyResource>
<groupId>projecta.groupid</groupId>
<artifactId>project-a</artifactId>
<version>${project.version}</version>
<resource>/schema.xsd</resource>
</dependencyResource>
</schema>
</schemas>
<generateDirectory>src/main/gen/</generateDirectory>
<generatePackage>mypackage</generatePackage>
</configuration>
</plugin>
In which case, it's resource (schema.xsd) is in the src/main/resources of project A. The plugin will generate the class files to the mypackage package and sources the src/main/gen
We can also use as below in pom.xml file
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxb2-maven-plugin</artifactId>
<version>1.5</version>
<executions>
<execution>
<id>id1</id>
<goals>
<goal>xjc</goal>
</goals>
<configuration>
<outputDirectory>src/main/java</outputDirectory>
<clearOutputDir>false</clearOutputDir>
<packageName>com.subu.xsd.model</packageName>
<schemaDirectory>src/main/java/schemadir</schemaDirectory>
<schemaFiles>XYZ.xsd</schemaFiles>
</configuration>
</execution>
</executions>
</plugin>
I have a project in IntelliJ IDEA that consists of both Java and Groovy classes. These classes are contained in folders "groovy" and "java" that I've marked as source folders. I have many Java classes that import classes from the "groovy" source folder, but when I try running them, I consistently get the error "java: package foo does not exist". Package "foo" exists directly under the "groovy" folder, so this should be working. I included a visual below. (I'm trying to avoid any specific details. I may or may not be working on a top secret Area 51 project.)
Structure visual:
project-folder
|
-src
|
-main
|
-groovy (marked as source)
||
|-foo
| |
| -bar.groovy
-java (marked as source)
|
- java class that imports "foo.bar"
Error:
java: package foo does not exist
Things that don't work:
Taking everything under "framework" and placing them directly under "groovy" folder. Results in "Cannot resolve symbol bar"
Unmavenizing project and rebuilding
You should not have to "unmavenize" your project. (Although I understand the troubleshooting reasoning for suggesting you do such.) I suspect the issue is a corrupted cache or index. Go to File > Invalidate Cache. Select to invalidate the cache and then restart IDEA. Let IDEA re-index the project. Things should be fine. If not, check that 1) you are using the latest version of IDEA (12.1.5) and 2) the latest version of the Groovy plug-in (File > Settings > [IDE Settings] > Plugins).
When you do use maven, you will need to identify the "groovy" directory as an additional source directory in your POM. If you do not, when IDEA re-imports the project (i.e. re-syncs to the POM), it will drop the groovy directory as a source since by default maven does not consider it a source. How you do this depends on what plugin you use. Since GMaven is no longer maintained, I've been using the groovy-eclipse-compiler plugin. If you use that plug-in, the plug-in will automatically include src/main/groovy as a source (as long as there is at least one java or groovy file in src/main/java). However, IDEA does not pick that directory up and include it as a source as well. That means if you manually (or IDEA automatically) runs a maven re-import, your src/main/groovy directory will get unmarked as a source, and IDEA will show compile errors. You need to specify the additional directory. You can use the build-helper-maven-plugin to do this as the groovy-eclipse-compiler documentation recommends.
Here's the meat & potatoes of a POM for a working Java/Groovy project:
<properties>
<groovy.version>2.1.5</groovy.version>
<groovy-eclipse-compiler.version>2.8.0-01</groovy-eclipse-compiler.version>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<configuration>
<compilerId>groovy-eclipse-compiler</compilerId>
</configuration>
<dependencies>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-eclipse-compiler</artifactId>
<version>${groovy-eclipse-compiler.version}</version>
</dependency>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-eclipse-batch</artifactId>
<version>2.1.5-03</version>
<scope>compile</scope>
</dependency>
</dependencies>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<executions>
<execution>
<id>add-source</id>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>src/main/groovy</source>
</sources>
</configuration>
</execution>
<execution>
<id>add-test-source</id>
<phase>generate-test-sources</phase>
<goals>
<goal>add-test-source</goal>
</goals>
<configuration>
<sources>
<source>src/test/groovy</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-all</artifactId>
<version>${groovy.version}</version>
</dependency>
</dependencies>
Restart IntelliJ :-) Dumb, but that's what worked for me. No idea what was causing the issue, but I'm glad it's fixed. Hopefully that helps someone else too.
I had the similar problem. In my case, groovy compilation logged RuntimeException as warning. This is because of No suitable classloader found for grab.
After I fixed this issue, groovy sources were successfully compiled and Java classes were able to see them on the classpath.