I have to generate sources using wsimport and i assume that it should go to /target/generated-sources/wsimport rather than /src/main/java.
The problem is that wsimport needs target folder created before execution and it fails. Can I create that dir first using any maven plugin. I can do it using ant but i prefer to keep it in POM.
Try using the add source goal of the build helper 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>${basedir}/target/generated/src/wsimport</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
I have to generate sources using wsimport and i assume that it should go to /target/generated-sources/wsimport rather than /src/main/java.
This is a correct assumption.
The problem is that wsimport needs target folder created before execution and it fails. Can I create that dir first using any maven plugin. I can do it using ant but i prefer to keep it in POM.
I never noticed this problem (and would consider it as a bug, a plugin has to take care of such things).
The weird part is that WsImportMojo seems to do what is has to by calling File#mkdirs():
public void execute()
throws MojoExecutionException
{
// Need to build a URLClassloader since Maven removed it form the chain
ClassLoader parent = this.getClass().getClassLoader();
String originalSystemClasspath = this.initClassLoader( parent );
try
{
sourceDestDir.mkdirs();
getDestDir().mkdirs();
File[] wsdls = getWSDLFiles();
if(wsdls.length == 0 && (wsdlUrls == null || wsdlUrls.size() ==0)){
getLog().info( "No WSDLs are found to process, Specify atleast one of the following parameters: wsdlFiles, wsdlDirectory or wsdlUrls.");
return;
}
...
}
...
}
Could you show how you invoke the plugin and its configuration?
Related
I have a maven multi module groovy project. When I run a main method in a groovy class thats in one of the submodules, intellij is not re-compiling before running it. It always runs the version last compiled when I manually initiated maven:compile. I don't recall having to do this manually or set any special intellij project settings in the past for this to work.
I've tried reimporting my project, several incarnations of updates to my poms, and then ultimately I had to create a run configuration where I specify a "Before Launch" configuration that executes mvn compile first. This just seems like a hack though. Its unclear to me if my issue is in a poorly constructed set of poms or if I'm truly missing some intellij configuration.
This works the first time
class MyClass2 {
static void main(String... args) {
print("foo")
}
}
but if I add another print statement such as printing bar, the output of the program only prints foo and not foo and bar.
class MyClass2 {
static void main(String... args) {
print("foo")
print("bar")
}
}
My module structure is like this:
my-project
module-1
src/main/groovy/com/foo/MyClass2.groovy (Depends on Module1)
module-2
src/main/groovy/com/foo/MyClass1.groovy
My pom file for this submodule has this build section:
<build>
<plugins>
<plugin>
<groupId>org.codehaus.gmavenplus</groupId>
<artifactId>gmavenplus-plugin</artifactId>
<version>1.7.1</version>
<executions>
<execution>
<goals>
<goal>addSources</goal>
<goal>compile</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
I can add more pom config if the problem is rooted there or provide screenshots of intellij config. I suspect intellij is the root of the problem because mvn compile and mvn clean install works just file at the parent as well as all submodules. I have no issues referencing MyClass1 from MyClass2; dependencies seem to be setup correctly.
Verify that you have Build step in Before launch section of Run Configuration added:
I got a liferay-portlet-project with a sample application/portlet that I want to become an archetype. Inside the project there is a folder containing two *.launch files to redeploy the webapp. Both have the following line which I have trouble with:
<stringAttribute key="org.eclipse.jdt.launching.WORKING_DIRECTORY" value="${workspace_loc:/rawportlet}"/>
where "rawportlet" is the project's name. If I change it manually to ${artifactId} this variable is not resolved when using the archetype to create a project. Resolving this variable during project-generation would be nice.
Is there a way to achieve this? Or a workaround? Thanks in advance for your help.
Workaround: write a maven goal that the user can run after using the archetype. So the steps would be (for example):
generate project from archetype
mvn archetype:generate -DarchetypeCatalog=local
do some post-generation cleanup (execute in project's base dir)
mvn antrun:run
So my code for this is in "pom.xml" in the archetype:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<id>default-cli</id>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<replace token= "rawportlet" value="${artifactId}" dir="runConfigs">
<include name="**/*.launch"/>
</replace>
</tasks>
</configuration>
</execution>
</executions>
</plugin>
The "runConfigs" directory is where the *.launch files are stored.
Credits to:
Full search and replace of strings in source files when copying resources
Maven, configure specific goal
I have this same problem, and I used a different solution that works okay (but isn't perfect either).
Use value="${workspace_loc}/${artifactId}" in your launch config.
This will work as long as people do an archetype:gen at the workspace root. This works better for me than the selected answer because running that post processing requires another launch configuration (which somewhat defeats the whole purpose).
A POM dependency contains native libraries (DLLs inside a JAR file). How do I programmatically look up the path of the downloaded JAR file so I can pass it into "java.library.path"?
Answering my own question: http://web.archive.org/web/20120308042202/http://www.buildanddeploy.com/node/17
In short, you can use the maven-dependency-plugin:unpack goal to extract the libraries into a known path, and pass that into java.library.path:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>unpack</id>
<phase>compile</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>org.jdesktop</groupId>
<artifactId>jdic-native</artifactId>
<version>${jdic.version}</version>
<classifier>${build.type}</classifier>
<type>jar</type>
<overWrite>true</overWrite>
<outputDirectory>${project.build.directory}/lib</outputDirectory>
</artifactItem>
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>
Since System.load() can't load libraries from within a jar, you will have to use a custom loader which extracts the library to a temporary file at runtime. Projects With JNI discusses this approach and provide code for the custom loader.
Library loader
We now have our JNI library on the
class path, so we need a way of
loading it. I created a separate
project which would extract JNI
libraries from the class path, then
load them. Find it at
http://opensource.mxtelecom.com/maven/repo/com/wapmx/native/mx-native-loader/1.2/.
This is added as a dependency to the
pom, obviously.
To use it, call
com.wapmx.nativeutils.jniloader.NativeLoader.loadLibrary(libname).
More information is in the javadoc for
NativeLoader.
I generally prefer to wrap such things
in a try/catch block, as follows:
public class Sqrt {
static {
try {
NativeLoader.loadLibrary("sqrt");
} catch (Throwable e) {
e.printStackTrace();
System.exit(1);
}
}
/* ... class body ... */
}
An alternative would be to unpack the dependency, for example using dependency:unpack.
You can use the maven dependency plugin to copy the artifacts to a predefined path:
http://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-artifacts.html
If the DLL is inside the JAR, then you will need to copy it out to a directory before it can be loaded. (JARs that include native libraries usually do this themselves.) If your JAR isn't doing this, then you can use Class.getResourceAsStream() and write this to a directory that you've added to the java.library.path.
For an example of this, see loadNativeLibrary in JNA. It uses this technique to load it's own library (a JNI library) from a JAR.
I am having a project A being built with mvn assembly:assembly which gives me a jar file with dependencies. This project basically gets a file path and converts it to XML.
Now I need to create a new project B which will wrap A by walking a directory and calling several times to A. NOTE: They must be different applications. I am not able to modify A changing it's parameters.
I would like that when B builds, it will first build A and gets it's jar file.
Which is the best way to configure this in a pom file? Should I have two poms?
Same pom but two jars being build?
Thanks for reading!
I would handle this by adding an aggregator POM with A and B as modules. Then you simply build the aggregator each time to have A built before B. This gives you the flexibility to build A and B individually as well as both together.
If you are determined to invoke A's build from within B, it could be done by using the maven-exec-plugin to invoke another Maven instance.
For example:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.1</version>
<executions>
<execution>
<goals>
<goal>exec</goal>
</goals>
</execution>
</executions>
<configuration>
<executable>mvn</executable>
<!--specified as a property below-->
<workingDirectory>${projectA.path}</workingDirectory>
<arguments>
<argument>clean</argument>
<argument>install</argument>
</arguments>
</configuration>
</plugin>
...
<properties>
<projectA.path>/path/to/project/a</projectA.path>
</properties>
In my maven2 project I have a directory ${basedir}/autogen that contains some autogenerated source code files produced by wsdl2java.
When running mvn compile I get an compilation error, because of duplicate classes, that lives in ${basedir}/autogen. This is true. But what is the compilation phase doing in ${basedir}/autogen? I have not told maven to add this directory as a source directory.
And there seems to be no way of telling maven to ignore the directory.
I had the same problem when using the maven-processor-plugin and found that the solution was to configure the maven-compiler plugin as follows:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.1</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
<compilerArgument>-proc:none</compilerArgument>
</configuration>
</plugin>
-proc:none means that compilation takes place without annotation processing and therefore no duplicate classes (which are typically generated in the generate-sources phase)
I hope that helps.
I've seen this a few times. In almost all cases, it is due to the generated classes being added to the main src tree then checked into version control.
In my case, it worked when I changed source directory.
New POM looks like,
<build>
<sourceDirectory>src</sourceDirectory>
Pointing just a src folder with sourceDirectory tag.
Earlier it was
<build>
<sourceDirectory>.</sourceDirectory>
Note that earlier it was working in IntellIJ, but not on cmd.
Now it works on both.
I had a similar problem with JPA model generator. It occurred on this dependency:
<dependency>
<groupId>org.eclipse.persistence</groupId>
<artifactId>org.eclipse.persistence.jpa.modelgen</artifactId>
<version>2.1.1</version>
</dependency>
I wrongly added the scope=provided and that resulted in:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.1:compile (default-compile) on project mocker: Compilation failure: Compilation failure:
[ERROR] \Projects\entity\MockVehicle_.java:[10,7] duplicate class: entity.MockVehicle_
I had the exact same issue. In my case the problem was that I called maven with -f=./pom.xml. I have no idea why this leads to a different result (would be nice if someone can explain) but maybe good to know if someone else has the same issue.
I resolve it by remove generateAsync from my pom.xml the the GWT plugin will look like
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>${gwtVersion}</version>
<executions>
<execution>
<goals>
<goal>compile</goal>
<goal>test</goal>
<!-- <goal>i18n</goal> -->
</goals>
</execution>
</executions>
Its hard to change default maven behaviour, i think its better to go with it - you could generate those files with maven wsdl2java-maven-plugin
I my case helped this:
<!-- https://mvnrepository.com/artifact/javax.annotation/javax.annotation-api -->
<dependency>
<groupId>javax.annotation</groupId>
<artifactId>javax.annotation-api</artifactId>
<version>1.3.2</version>
</dependency>
All answers here where not helpful. This may be the correct answer:
Another StackOverflow user wrote:
I have found an JetBrains Team member comment stating that:
IDEA automatically excludes the build 'target' folder, providing that
there are no generated sources under it, otherwise it excludes all
sub-folders but the generated.
Avro by standard in a generated-sources folder. This folder it not ignored by maven ans the generated classes in there will count as duplicate.
Maven will only igonre the target folder by default.
To fix add this line in the pom.xml:
<sourceDirectory>${project.basedir}/src/main/target/resources/avro</sourceDirectory>
Context:
<groupId>org.apache.avro</groupId>
<artifactId>avro-maven-plugin</artifactId>
<version>${avro.version}</version>
<executions>
<execution>
<phase>generate-sources</phase>
<goals>
<goal>schema</goal>
<goal>protocol</goal>
<goal>idl-protocol</goal>
</goals>
<configuration>
<sourceDirectory>${project.basedir}/src/main/target/resources/avro</sourceDirectory>
<stringType>String</stringType>
<createSetters>false</createSetters>
<outputDirectory>${project.basedir}/target/</outputDirectory><enableDecimalLogicalType>true</enableDecimalLogicalType>
<fieldVisibility>private</fieldVisibility>
</configuration>
</execution>
</executions>
This will put the generated-resources folder under the target folder.
I resolve the same issue
cleaning maven project :-mvn clean
delete com folder from src then compile
copy com from generated to src->main-->java
again compile
Hope this Help..