i did a maven plugin that overwrites "maven-jar-plugin" following this doc:
How do I create a new packaging type for Maven?
you can find my plugin here:
http://mvnrepository.com/artifact/org.lucee/lco-plugin/1.0
the source is here:
https://github.com/lucee/lco-maven-plugin
I only change the extension, nothing else, i get the right extension as expected, problem is the configuration is ignored
<plugin>
<groupId>org.lucee</groupId>
<artifactId>lco-plugin</artifactId>
<version>1.01-SNAPSHOT</version>
<!-- when I use this the configuration works!
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.6</version>-->
<configuration>
<archive>
<manifestFile>${project.build.outputDirectory}/META-INF/MANIFEST.MF</manifestFile>
</archive>
</configuration>
<extensions>true</extensions>
</plugin>
any idea what i do wrong?
You can do further debugging by running your maven build with the -X -e flags activated. This way, you'll see for each running plugin which configuration is loaded.
As the configuration is not loaded, I would suggest it's typically an activation issue that the aforementionned method will allow you to solve.
Related
I am using FindBugs with maven, using the following configuration:
<reporting>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
<version>3.0.3</version>
<configuration>
<xmlOutput>true</xmlOutput>
<xmlOutputDirectory>target/site</xmlOutputDirectory>
<plugins>
<plugin>
<groupId>com.mebigfatguy.fb-contrib</groupId>
<artifactId>fb-contrib</artifactId>
<version>6.2.0</version>
</plugin>
</plugins>
</configuration>
</plugin>
</plugins>
</reporting>
I run:
mvn clean
mvn package
mvn site
mvn findbugs:gui
And I get all errors listed in GUI, but I realized that all bugs detected by fb-contrib plugin are shown under Experimental\Testing prototype and incomplete bug pattern\Unknown bug pattern and FindBugs doesn't show any info about bug pattern.
Is this correct? Is it possible to get bug pattern info as with the FindBugs pattern bugs?
Thanks in advance.
findbugs-maven-plugin doesn't supply the configured plugins, when it launches the FindBugs GUI (Issue #37). I've submitted a pull request fixing this, you could grab my fork and build the plugin.
Alternatively, if your plugins don't change often, you could add them manually in the GUI: open the menu Edit -> Preferences, switch to the Plugins tab, install the plugin jar from the local Maven repository. At least on Windows the plugin configuration persists between GUI launches via the registry.
I have written a custom maven plugin which works in package phase of maven's default life cycle. In addition I have added a custom packaging type to it. In order to support the custom packaging type I have introduced components.xml so it will override the default maven life cycle. In the component/configuration/lifecycles/lifecycle/phases/package section of component.xml I have added my plugin to execute in package phase.
When I use my plugin I pass the configuration to the plugin through the pom.xml as follows;
<build>
...
<plugins>
<plugin>
<groupId>sample</groupId>
<artifactId>sampleArtifact</artifactId>
<extensions>true</extensions>
...
<executions>
<executions>
<phase>package</phase>
<goal>generate</generate>
<configuration>
//Configuration goes here.
</configuration>
</executions>
</executions>
...
</plugin>
</plugins>
...
</build>
Problem:
the configuration I passed into mojo as above is not getting set in the mojo. However, if I set the plugin configuration in one level below the tag(where the executions tag present), then it works. Since this plugin works in package phase I need the plugin configuration passed in through as above. Without custom packaging, the above configuration works well. Any thoughts on what I miss here?
Team,
Our project makes use of EJB, was 6.1 is our server, While deploying the code , am in need of stub files to be present in EAR (Maven Generated). Inorder to achieve this, am using was6 plug in our pom.xml
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>was6-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>ejbdeploy</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-ejb-plugin</artifactId>
<configuration>
<archive>
<manifest>
<addClasspath>true</addClasspath>
<classpathPrefix>lib/</classpathPrefix>
</manifest>
</archive>
</configuration>
</plugin>
</plugins>
For this we need to set the environment variables "WAS_HOME".
But we cannot set the wasHome in continuum build server and hence we are getting BUILD ERROR - "wasHome not defined"
Is that any other way to achieve this?
- Creating the stub files for all ejb class without using WAS 6 maven plugin in Maven.
WAS6_HOME environment variable is the default value used by was6-maven-plugin to know where Websphere is located,
but people often use the wasHome attribute to indicate this.
From here it's possible to use Maven properties in the pom or in the settings file and Maven profiles.
On the other hand, you can generate the EJB Stubs without the maven plugin, but you will always need to know where websphere is installed.
Regards
Inorder to achieve this we can set the parameter(ejbdeploy = true) in was6 server install configuration xml
and its worked.
Thanks for all the responses.
I wanna generated java classes from xsd files bt soome how whenever i run the code it shows the error
No Schema has been found... here is the code... Kindly help...
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.5.1</version>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxb2-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>xjc</goal>
</goals>
</execution>
</executions>
<configuration>
<schemaDirectory>src/main/resources/xsd</schemaDirectory>
<includeSchema>**/*.xsd</includeSchema>
<!-- <generatepackage>org.onesync.esb.datasync.model</generatepackage> -->
<!-- The package in which the source files will be generated. -->
<packageName>org.onesync.esb.datasync.model</packageName>
<!-- The working directory to create the generated java source files. -->
<outputDirectory>src/main/java/org/onesync/esb/datasync/model</outputDirectory>
</configuration>
</plugin>
</plugins>
I don't think <includeSchema>**/*.xsd</includeSchema> is valid syntax for jaxb2-maven-plugin:xjc Try omitting that parameter.
If you don't specify schemaFiles it should use all XSD files in the schemaDirectory.
"schemaFiles -- List of files to use for schemas, comma delimited. If none, then all xsd files are used in the schemaDirectory. This parameter also accepts Ant-style file patterns." (see jaxb2-maven-plugin documentation)
BTW, it is usually a good idea to use maven's configuration parameters to refer to a directory. For example, change <schemaDirectory>src/main/resources/xsd</schemaDirectory> to <schemaDirectory>${project.basedir}/src/main/resources/xsd</schemaDirectory>.
Finally, you might also want to refer to this similar SO post.
I am also using maven configuration and spent almost to compile the project stuff. Later on i came to know that it looking for the schema file i.e. schema.xsd.
If you are using the MAVEN configuration then by default you can put the schema file under the resources directory.
But if you want to specify your path for finding the schema file then you can use the includeSchema tag of schemaDescription in plugin configuration.
OR
You can use the effictive pom to search for specific tag also.
Command for effective pom in maven: mvn help:effective-pom
Thanks
Sometimes, my Talend Open Studio components have resources but not Java sources (they are purely metadata components). I need to disable the generation of JAR files in such a case.
I configured the maven-jar-plugin this way:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.4</version>
<configuration>
<forceCreation>false</forceCreation>
<skipIfEmpty>true</skipIfEmpty>
<useDefaultManifestFile>false</useDefaultManifestFile>
</configuration>
</plugin>
but I still get the ${project.name}.jar file with pom.properties, pom.cml, the manifest and an empty file App.class containing only "class {}"
While I can disable the includes of all maven stuff using this:
<archive>
<addMavenDescriptor>false</addMavenDescriptor>
</archive>
I still get a JAR with the manifest file inside it
Are there some configuration parameters I misconfigured?
Most efficient way to disable the creation of jars is to configure the maven-jar-plugin like this:
<plugins>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<version>2.3.1</version>
<executions>
<execution>
<id>default-jar</id>
<phase>none</phase>
</execution>
</executions>
</plugin>
</plugins>
It will place the default jar creation in the none phase, it will never be run.
I found the solution by myself, even if it's only a workaround. I delete the JAR using a delete antrun task if /src/main/java directory doesn't exist:
<!-- remove the empty JAR if not needed -->
<if>
<not><available file="${basedir}/src/main/java" type="dir" /></not>
<then>
<delete file="${project.build.directory}/${project.name}-${project.version}.jar"/>
</then>
</if>
this task requires antcontrib to work properly and, ofc, it doesn't work if you plan to do releases with maven (but it's ok for metadata-only components, like Talend Open Studio plugins)
You can instruct maven-jar-plugin to not generate META-INF/maven/*/pom. files, as explained in Maven Archiver Reference.
Also, you can use its skipIfEmpty option.
Following code combines both these (just to have them copy-paste ready):
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.4</version>
<configuration>
<skipIfEmpty>true</skipIfEmpty>
<archive>
<addMavenDescriptor>false</addMavenDescriptor>
</archive>
...
This works fine, but when you do mvn install, it fails due to missing project artifact.
Similar problem will probably be with mvn deploy and with release, but I didn't check these.
However, if you can live with antrun's delete, the property skipIfEmpty will probably work well for you, and is a bit more elegant. At least it does not introduce a new execution and its dependencies etc.