Develop Reference

How to fix the maven check style error

Currently I just tried to download and build to make the Netty source code work. But when I tried to run the command mvn eclipse:eclipse in the source folder. I got an error said
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-checkstyle-plugin:2.10:check (check-style) on project netty-common: Failed during checkstyle execu
tion: There are 304 checkstyle errors. -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-checkstyle-plugin:2.10:check (check-style) on proj
ect netty-common: Failed during checkstyle execution
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.MojoExecutor.executeForkedExecutions(MojoExecutor.java:352)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:197)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException: Failed during checkstyle execution
at org.apache.maven.plugin.checkstyle.CheckstyleViolationCheckMojo.execute(CheckstyleViolationCheckMojo.java:374)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
... 24 more
Caused by: org.apache.maven.plugin.checkstyle.CheckstyleExecutorException: There are 304 checkstyle errors.
at org.apache.maven.plugin.checkstyle.DefaultCheckstyleExecutor.executeCheckstyle(DefaultCheckstyleExecutor.java:218)
at org.apache.maven.plugin.checkstyle.CheckstyleViolationCheckMojo.execute(CheckstyleViolationCheckMojo.java:365)
It is error of the checkstyle plugin when validating the code netty-common project.
I am not familiar with this plugin . I want to know if I can just ignore it by removing the configuration from the pom.xml(in the ). like below.
<plugin>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>2.10</version>
<executions>
<execution>
<id>check-style</id>
<goals>
<goal>check</goal>
</goals>
<phase>validate</phase>
<configuration>
<consoleOutput>true</consoleOutput>
<logViolationsToConsole>true</logViolationsToConsole>
<failsOnError>true</failsOnError>
<failOnViolation>true</failOnViolation>
<configLocation>io/netty/checkstyle.xml</configLocation>
<includeTestSourceDirectory>true</includeTestSourceDirectory>
</configuration>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>netty-build</artifactId>
<version>21</version>
</dependency>
</dependencies>
</plugin>
Any idea ? Thanks.

Skip the check style execution using
-Dcheckstyle.skip
Ex
mvn [YOUR_COMMAND] -Dcheckstyle.skip

CheckStyle is a module of maven that check the style of the code for things like tabs instead of spaces. Netty is using this to prevent basic formatting mistakes.
If you are planning to contribute to Netty, you should NOT remove the plugin as it probably means your patch will never applied.
If you are just using to play with, you are free to remove that plugin as its only purpose is to verify the installation, and not to change things from the installation.
If you choose to keep it, you should look in the output log to see what the mistakes are it detected, to quickly fix the mistakes, see this answer by Matthew Farwell.
Right click on the java file in Package Explorer or whatever, and select 'Apply Checkstyle Corrections'.
Click on the error in the problems view, and select 'Quick fix'. This corrects the problem.

Whereas I am neither familiar with Netty nor the maven eclipse plugin, I did face an issue with the maven-checkstyle-plugin while building the pwm project.
This was the error:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-checkstyle-plugin:2.17:check (validate) on project pwm: Failed during checkstyle configuration ....
My Solution (which also solves many maven related errors btw):
Delete the maven's .m2 folder, then build the project again.
On linux systems, the .m2 folder is usually in your home folder /home/<username>/.m2

If you've just cloned the repository and the build failed, I believe you are using Windows and you have a problem with your Git configuration. Please set the 'core.autocrlf' option to 'true', re-clone the repository, and try again.
git config --global core.autocrlf true

I faced the same issue and I disabled checkstyle from pom, by adding the following in my pom file and it worked for me.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<executions>
<execution>
<id>checkstyle-validation</id>
<phase>none</phase>
</execution>
</executions>
</plugin>

On Linux OS I solved using dos2unix.
cd presto;
find . -type f -exec dos2unix {} \;

Just do "mvn spotless:apply", worked for me

In my case I just tried to execute same goal but with -X option (enabling debug level) and found what class check style plugin is complaining about. Corrected style and run maven again -> Build success.

Best approach to fix this issues by running the mvn install with -X option it will give you detail about the style issues in class. You can fix the class accordingly.

I solved this problem by removing the check-style configuration in my pom.xml and rebuilding maven. When I later re-inserted and build, it worked without error.

Running app jar file on spark-submit in a google dataproc cluster instance

I'm running a .jar file that contains all dependencies that I need packaged in it. One of this dependencies is com.google.common.util.concurrent.RateLimiter and already checked it's class file is in this .jar file.
Unfortunately when I hit the command spark-submit on the master node of my google's dataproc-cluster instance I'm getting this error:
Exception in thread "main" java.lang.NoSuchMethodError: com.google.common.base.Stopwatch.createStarted()Lcom/google/common/base/Stopwatch;
at com.google.common.util.concurrent.RateLimiter$SleepingStopwatch$1.<init>(RateLimiter.java:417)
at com.google.common.util.concurrent.RateLimiter$SleepingStopwatch.createFromSystemTimer(RateLimiter.java:416)
at com.google.common.util.concurrent.RateLimiter.create(RateLimiter.java:130)
at LabeledAddressDatasetBuilder.publishLabeledAddressesFromBlockstem(LabeledAddressDatasetBuilder.java:60)
at LabeledAddressDatasetBuilder.main(LabeledAddressDatasetBuilder.java:144)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.apache.spark.deploy.SparkSubmit$.org$apache$spark$deploy$SparkSubmit$$runMain(SparkSubmit.scala:672)
at org.apache.spark.deploy.SparkSubmit$.doRunMain$1(SparkSubmit.scala:180)
at org.apache.spark.deploy.SparkSubmit$.submit(SparkSubmit.scala:205)
at org.apache.spark.deploy.SparkSubmit$.main(SparkSubmit.scala:120)
at org.apache.spark.deploy.SparkSubmit.main(SparkSubmit.scala)
It seems something happened in the sense of overwriting my dependencies. Already decompiled the Stopwatch.class file from this .jar and checked that method is there. That just happened when I ran on that google dataproc instance.
I did grep on the process executing the spark-submit and I got the flag -cp like this:
/usr/lib/jvm/java-8-openjdk-amd64/bin/java -cp /usr/lib/spark/conf/:/usr/lib/spark/lib/spark-assembly-1.5.0-hadoop2.7.1.jar:/usr/lib/spark/lib/datanucleus-api-jdo-3.2.6.jar:/usr/lib/spark/lib/datanucleus-rdbms-3.2.9.jar:/usr/lib/spark/lib/datanucleus-core-3.2.10.jar:/etc/hadoop/conf/:/etc/hadoop/conf/:/usr/lib/hadoop/lib/native/:/usr/lib/hadoop/lib/*:/usr/lib/hadoop/*:/usr/lib/hadoop-hdfs/lib/*:/usr/lib/hadoop-hdfs/*:/usr/lib/hadoop-mapreduce/lib/*:/usr/lib/hadoop-mapreduce/*:/usr/lib/hadoop-yarn/lib/*:/usr/lib/hadoop-yarn/*
Is there anything I can do to solve this problem?
Thank you.

As you've found, Dataproc includes Hadoop dependencies on the classpath when invoking Spark. This is done primarily so that using Hadoop input formats, file systems, etc is fairly straight-forward. The downside is that you will end up with Hadoop's guava version which is 11.02 (See HADOOP-10101).
How to work around this depends on your build system. If using Maven, the maven-shade plugin can be used to relocate your version of guava under a new package name. An example of this can be seen in the GCS Hadoop Connector's packaging, but the crux of it is the following plugin declaration in your pom.xml build section:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.3</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<relocations>
<relocation>
<pattern>com.google.common</pattern>
<shadedPattern>your.repackaged.deps.com.google.common</shadedPattern>
</relocation>
</relocations>
</execution>
</execution>
</plugin>
Similar relocations can be accomplished with the sbt-assembly plugin for sbt, jarjar for ant, and either jarjar or shadow for gradle.

How to add jars to JMeter's classpath in non-GUI mode

I have created a test plan in the JMeter GUI which uses the "Java Request Sampler".
I added the jarfile which contains the implementation to my sampler to /lib/ext/ of my jmeter installation.
This all works fine when I run it in GUI mode.
However when I switch to non gui mode using
./jmeter -n -t Test\ Plan.jmx
I get:
com.mycompany.JavaSamplerTest java.lang.ClassNotFoundException
2014/01/23 15:25:25 ERROR - jmeter.protocol.java.sampler.JavaSampler: StandardJMeterEngine#5efbfd6e-Java Request Exception initialising: com.mycompany.JavaSamplerTest java.lang.ClassNotFoundException: com.mycompany.JavaSamplerTest
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:270)
at org.apache.jmeter.protocol.java.sampler.JavaSampler.initClass(JavaSampler.java:117)
at org.apache.jmeter.protocol.java.sampler.JavaSampler.testStarted(JavaSampler.java:263)
at org.apache.jmeter.engine.StandardJMeterEngine.notifyTestListenersOfStart(StandardJMeterEngine.java:214)
at org.apache.jmeter.engine.StandardJMeterEngine.run(StandardJMeterEngine.java:336)
at java.lang.Thread.run(Thread.java:744)
I have no clue why this behaves differently when using -n -t. Does anybody have a solution to this?
I work on Linux using openjdk if this is somehow a helpful information.

As per How do I run JMeter in non-gui mode article you can use -J key to provide additional classpath elements location to JMeter like below:
./jmeter -Juser.classpath=/some/folder/your/extension.jar -n -t ${path_to_your_script} -l ${path_to_results}

Put the jar in jmeter/lib folder.
lib/ext is for real plugins.

Below is how I have the plugin set-up for maven pom
<plugin>
<groupId>com.lazerycode.jmeter</groupId>
<artifactId>jmeter-maven-plugin</artifactId>
<version>2.7.0</version>
<executions>
<execution>
<id>jmeter-tests</id>
<goals>
<goal>jmeter</goal>
</goals>
</execution>
</executions>
<configuration>
<testPlanLibraries>
<artifact>org.apache.commons:commons-lang3:3.0</artifact>
</testPlanLibraries>
<propertiesSystem>
<user>${username}</user>
</propertiesSystem>
</configuration>
</plugin>

I had the same issue today with jmeter 5.4 on a linux machine.
Thanks to my colleague we identified the root cause.
In jmeter.properties we use the following line to extend the classpath libs.
user.classpath=../lib;../lib/ext
Howerver on a linux machine this line hast to be look like:
user.classpath=../lib:../lib/ext
Thus use : instead of ;
In our case this fits our problem.

Add it as a dependency inside the jmeter plugin:
<dependencies>
<dependency>
<groupId>postgresql</groupId>
<artifactId>postgresql</artifactId>
<version>9.0-801.jdbc4</version>
</dependency>

Java Web Service Contacting Hive - DataNucleus ClassLoaderResolver Error

I have a Java web service (made with a proprietary technology at my company), which is being used to service requests/responses, and while processing requests, it is attempting to talk to Hadoop's Hive and execute a query. However, it is failing immediately when I simply try to initialize the connection.
Here is the line of code it fails on. I am largely using the code sample from https://cwiki.apache.org/confluence/display/Hive/HiveClient:
String connString = "jdbc:hive://";
Connection con = DriverManager.getConnection(connString, "", "");
Here is the stack trace:
javax.jdo.JDOFatalInternalException: Unexpected exception caught.
at javax.jdo.JDOHelper.invokeGetPersistenceManagerFactoryOnImplementation(JDOHelper.java:1186)
at javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:803)
at javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:698)
at org.apache.hadoop.hive.metastore.ObjectStore.getPMF(ObjectStore.java:246)
at org.apache.hadoop.hive.metastore.ObjectStore.getPersistenceManager(ObjectStore.java:275)
at org.apache.hadoop.hive.metastore.ObjectStore.initialize(ObjectStore.java:208)
at org.apache.hadoop.hive.metastore.ObjectStore.setConf(ObjectStore.java:183)
at org.apache.hadoop.util.ReflectionUtils.setConf(ReflectionUtils.java:70)
at org.apache.hadoop.util.ReflectionUtils.newInstance(ReflectionUtils.java:130)
at org.apache.hadoop.hive.metastore.HiveMetaStore$HMSHandler.getMS(HiveMetaStore.java:407)
at org.apache.hadoop.hive.metastore.HiveMetaStore$HMSHandler.executeWithRetry(HiveMetaStore.java:359)
at org.apache.hadoop.hive.metastore.HiveMetaStore$HMSHandler.createDefaultDB(HiveMetaStore.java:504)
at org.apache.hadoop.hive.metastore.HiveMetaStore$HMSHandler.init(HiveMetaStore.java:266)
at org.apache.hadoop.hive.metastore.HiveMetaStore$HMSHandler.<init>(HiveMetaStore.java:228)
at org.apache.hadoop.hive.service.HiveServer$HiveServerHandler.<init>(HiveServer.java:131)
at org.apache.hadoop.hive.service.HiveServer$HiveServerHandler.<init>(HiveServer.java:121)
at org.apache.hadoop.hive.jdbc.HiveConnection.<init>(HiveConnection.java:76)
at org.apache.hadoop.hive.jdbc.HiveDriver.connect(HiveDriver.java:104)
at java.sql.DriverManager.getConnection(DriverManager.java:582)
at java.sql.DriverManager.getConnection(DriverManager.java:185)
at (...my package...).RemoteCtrbTest.kickOffRemoteTest(RemoteCtrbTest.java:52)
NestedThrowablesStackTrace:
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at javax.jdo.JDOHelper$16.run(JDOHelper.java:1958)
at java.security.AccessController.doPrivileged(Native Method)
at javax.jdo.JDOHelper.invoke(JDOHelper.java:1953)
at javax.jdo.JDOHelper.invokeGetPersistenceManagerFactoryOnImplementation(JDOHelper.java:1159)
at javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:803)
at javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:698)
at org.apache.hadoop.hive.metastore.ObjectStore.getPMF(ObjectStore.java:246)
at org.apache.hadoop.hive.metastore.ObjectStore.getPersistenceManager(ObjectStore.java:275)
at org.apache.hadoop.hive.metastore.ObjectStore.initialize(ObjectStore.java:208)
at org.apache.hadoop.hive.metastore.ObjectStore.setConf(ObjectStore.java:183)
at org.apache.hadoop.util.ReflectionUtils.setConf(ReflectionUtils.java:70)
at org.apache.hadoop.util.ReflectionUtils.newInstance(ReflectionUtils.java:130)
at org.apache.hadoop.hive.metastore.HiveMetaStore$HMSHandler.getMS(HiveMetaStore.java:407)
at org.apache.hadoop.hive.metastore.HiveMetaStore$HMSHandler.executeWithRetry(HiveMetaStore.java:359)
at org.apache.hadoop.hive.metastore.HiveMetaStore$HMSHandler.createDefaultDB(HiveMetaStore.java:504)
at org.apache.hadoop.hive.metastore.HiveMetaStore$HMSHandler.init(HiveMetaStore.java:266)
at org.apache.hadoop.hive.metastore.HiveMetaStore$HMSHandler.<init>(HiveMetaStore.java:228)
at org.apache.hadoop.hive.service.HiveServer$HiveServerHandler.<init>(HiveServer.java:131)
at org.apache.hadoop.hive.service.HiveServer$HiveServerHandler.<init>(HiveServer.java:121)
at org.apache.hadoop.hive.jdbc.HiveConnection.<init>(HiveConnection.java:76)
at org.apache.hadoop.hive.jdbc.HiveDriver.connect(HiveDriver.java:104)
at java.sql.DriverManager.getConnection(DriverManager.java:582)
at java.sql.DriverManager.getConnection(DriverManager.java:185)
at (...my package...).RemoteCtrbTest.kickOffRemoteTest(RemoteCtrbTest.java:52)
Caused by: org.datanucleus.exceptions.NucleusUserException: Persistence process has been specified to use a ClassLoaderResolver of name "jdo" yet this has not been found by the DataNucleus plugin mechanism. Please check your CLASSPATH and plugin specification.
at org.datanucleus.OMFContext.getClassLoaderResolver(OMFContext.java:319)
at org.datanucleus.OMFContext.<init>(OMFContext.java:165)
at org.datanucleus.OMFContext.<init>(OMFContext.java:137)
at org.datanucleus.ObjectManagerFactoryImpl.initialiseOMFContext(ObjectManagerFactoryImpl.java:132)
at org.datanucleus.jdo.JDOPersistenceManagerFactory.initialiseProperties(JDOPersistenceManagerFactory.java:363)
at org.datanucleus.jdo.JDOPersistenceManagerFactory.<init>(JDOPersistenceManagerFactory.java:307)
at org.datanucleus.jdo.JDOPersistenceManagerFactory.createPersistenceManagerFactory(JDOPersistenceManagerFactory.java:255)
at org.datanucleus.jdo.JDOPersistenceManagerFactory.getPersistenceManagerFactory(JDOPersistenceManagerFactory.java:182)
... 35 more
I found one other question that has a similar error message, but it was about Maven and didn't contain Hive (which is the one using DataNucleus in it's code): Datanucleus, JDO and executable jar - how to do it?
I am using a hive-site.xml file to specify some properties for hive and datanucleus. The datanucleus ones are below. The last two I tried to try to fix the issue and when I change whatever I specify for datanucleus.classLoaderResolverName, it changes the error message that is in quotes.
<property>
<name>datanucleus.autoCreateSchema</name>
<value>false</value>
</property>
<property>
<name>datanucleus.fixedDatastore</name>
<value>true</value>
</property>
<property>
<name>datanucleus.classLoaderResolverName</name>
<value>jdo</value>
</property>
<property>
<name>javax.jdo.PersistenceManagerFactoryClass</name>
<value>org.datanucleus.jdo.JDOPersistenceManagerFactory</value>
</property>
The part that I cannot figure out is if somehow the service is re-bundling the jars, as in the other stackoverflow question that I linked to above, messing up the location of plugin.xml and/or the Manifest.mf file. I'm also not sure how the plugin file interacts with the hive-site file.
The classpath here requires to add specific jars instead of just a classpath. I am using the following datanucleus jars:
* datanucleus-connectionpool-2.0.3.jar
* datanucleus-enhancer-2.0.3.jar
* datanucelus-rdbms-2.0.3.jar
* datanucleus-core-2.0.3.jar
Any input you can give to help me would be greatly appreciated. I can provide more information if you need it so please do ask.

In case you are using Spring framework in your application made with proprietary technology at your company, then you can take advantage of Spring-Hadoop support.
All you have to do is just add below configuration in your applicationContext:
<hdp:configuration>
fs.default.name=${fs.default.name.url}
mapred.job.tracker=${mapred.job.tracker.url}
</hdp:configuration>
<hdp:hive-client-factory host="${hadoop.hive.host.url}" port="10000"
xmlns="http://www.springframework.org/schema/hadoop" />
<hdp:hive-template />
After that, autowire HiveTemplate,
#Autowired
HiveTemplate hiveTemplate;
And then query Hive as shown below:
List<String> list = hiveTemplate.query(queryString, parameterMap);

DataNucleus apparently uses an OSGi-based plugin mechanism. If you are not running it in an OSGi container and are just using a standard maven project, what's probably happening is the plugins are on the classpath but are not registered due to an issue with manifests. You might try something like this:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.4</version>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/jars</outputDirectory>
<overWriteReleases>false</overWriteReleases>
<overWriteSnapshots>false</overWriteSnapshots>
<overWriteIfNewer>true</overWriteIfNewer>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
This was answered previously.

Unable to generate classes from JAXB in Maven environment

I'm using the xjc plugin in Maven environment and trying to generate classes from the Schema
I'm able to do this (Create classes) using xjc from command line, but unable to do the same using maven target generate-sources.
Getting the following exception
[ERROR] null[5,30]
org.xml.sax.SAXParseException: A class/interface with the same name "<className>" is already in use. Use a class customization
to resolve this conflict.
at com.sun.tools.xjc.util.CodeModelClassFactory.createClass(CodeModelClassFactory.java:100)
at com.sun.tools.xjc.util.CodeModelClassFactory.createClass(CodeModelClassFactory.java:61)
at com.sun.tools.xjc.generator.bean.ImplStructureStrategy$1.createClasses(ImplStructureStrategy.java:42)
at com.sun.tools.xjc.generator.bean.BeanGenerator.generateClassDef(BeanGenerator.java:371)
at com.sun.tools.xjc.generator.bean.BeanGenerator.getClazz(BeanGenerator.java:403)
at com.sun.tools.xjc.generator.bean.BeanGenerator$1.onBean(BeanGenerator.java:291)
at com.sun.tools.xjc.generator.bean.BeanGenerator$1.onBean(BeanGenerator.java:299)
at com.sun.tools.xjc.model.CClassInfo.accept(CClassInfo.java:352)
at com.sun.tools.xjc.generator.bean.BeanGenerator.getContainer(BeanGenerator.java:281)
at com.sun.tools.xjc.generator.bean.BeanGenerator.getUsedPackages(BeanGenerator.java:337)
at com.sun.tools.xjc.generator.bean.BeanGenerator.<init>(BeanGenerator.java:169)
at com.sun.tools.xjc.generator.bean.BeanGenerator.generate(BeanGenerator.java:151)
at com.sun.tools.xjc.model.Model.generateCode(Model.java:230)
at com.sun.tools.xjc.Driver.run(Driver.java:317)
at org.codehaus.mojo.jaxb2.XjcMojo.execute(XjcMojo.java:301)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Can anyone help me find whats missing here.

As stated on the JAXB site, use the following Maven plugin:
<plugin>
. <groupId>org.jvnet.jaxb2.maven2</groupId>
<artifactId>maven-jaxb2-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>generate</goal>
</goals>
</execution>
</executions>
</plugin>
http://java.net/projects/maven-jaxb2-plugin/pages/Home
http://jaxb.java.net/
It seems, you're using a different plugin (org.codehaus.mojo.jaxb2.XjcMojo on your stack trace for which Google leads me to http://mojo.codehaus.org/jaxb2-maven-plugin/ ).

Since it works command line but not in Maven the class with the conflict must appear somewhere on your classpath. Any chance that is happening?
For an example on how to resolve name conflicts see:
How do I create JAXB bindings for docbook

May be you have two sub-elements with the same name, so the generated class name is the same?
If this is the case, you can customized the produced class name using the schema annotations:
First add the following namespaces to your xsd:
<xs:schema xmlns:jaxb="http://java.sun.com/xml/ns/jaxb" jaxb:version="2.0">
Second add annotation for the relevant element:
<xs:complexType name="ComplexType">
<xs:annotation><xs:appinfo>
<jaxb:class name="MyClass">
<jaxb:javadoc>This is my class.</jaxb:javadoc>
</jaxb:class>
</xs:appinfo></xs:annotation>
</xs:complexType>