How to execute another goal from an ant based maven plugin?
I am writing a ant based maven plugin. I need to execute another goal (to get a file from the maven repo) before executing the mojo that I am writing. Can I use the execution and goal tags as defined here to do that: http://maven.apache.org/plugin-tools/maven-plugin-tools-model/plugin-metadata.html Here is what my pluginMetaData looks: pluginMetadata mojos mojo goaldeploy/goal calldeploy-ear/call parameters . /parameters execution goalorg.apache.maven.plugin:maven-dependency-plugin:get/goal /execution /mojo /mojos /pluginMetadata Is this correct? How do I define the configuration parameters for this goal? Thanks, -Rakesh -- View this message in context: http://old.nabble.com/How-to-execute-another-goal-from-an-ant-based-maven-plugin--tp26879080p26879080.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
How to use was6-maven-plugin from the build servers without local WAS installation
was6-maven-plugin requires an installation of WAS on the build machine: http://mojo.codehaus.org/was6-maven-plugin/usage.html We want to use this plugin to automate the verification testing by deploying the ear (on a remote host) as part of the build and run some testcases. It is not practical to install the WAS on all the build servers. Any idea? Thanks, -Rakesh -- View this message in context: http://old.nabble.com/How-to-use-was6-maven-plugin-from-the-build-servers-without-local-WAS-installation-tp26420087p26420087.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: OutOfMemoryError when deploying large files
Ryan, Here is what we now have in the pom.xml to deploy large files distributionManagement repository idreleases/id urldav:http://nexus_server/content/repositories/releases/url /repository snapshotRepository idsnapshots/id urldav:http://nexus_server/content/repositories/snapshots/url /snapshotRepository /distributionManagement So we have changed the protocol to dav:http from http. -Rakesh -Original Message- From: Ryan Connolly [mailto:ryn...@gmail.com] Sent: Wednesday, July 01, 2009 9:33 AM To: Maven Users List Subject: Re: OutOfMemoryError when deploying large files Rakesh: We are experiencing this very same issue. Would you mind emailing me a pom snippet for the dav config you used to get around this? Your assistance would be most appreciated. Regards, Ryan On 6/30/09, Rakesh Arora rakesh.ar...@nortel.com wrote: We have resolved the problem by using dav:http protocol instead of http protocol. I have raised a jira against wagon-http-lightweight: http://jira.codehaus.org/browse/WAGON-272 -Rakesh -Original Message- From: Arora, Rakesh (CAR:9S00) Sent: Friday, June 26, 2009 4:19 PM To: users@maven.apache.org Subject: OutOfMemoryError when deploying large files When deploying a large artifact we get the OutOfMemoryError (please check the attached stack trace). This is similar to error reported here: http://www.mail-archive.com/users@maven.apache.org/msg99157.html We traced the issue to wagon-http-lightweight using PosterOutputStream/ByteArrayOutputStream.write(). This method consumes lot of memory when dealing with large files as reported here: https://issues.alfresco.com/jira/browse/ETHREEOH-974 In our case, we are trying to deploy a around 600M file and have set the maximum heap space to 1024M (-Xmx1024m). We are still running out of memory. We are using maven 2.0.8 but had the same issue when tried with 2.1.0 version. Is there a way to use another Wagon provider (wagon-http ?) that can deal better with large files? If yes, how can we configure this? Should I raise a jira for this (against which component maven-deploy-plugin or wagon-http-lightweight)? Thanks, -Rakesh ;-STACK TRACE- [DEBUG] -- end configuration -- [INFO] [deploy:deploy-file] Uploading: http://repo_url/group/foo/1.0/foo-1.0.zip [INFO] -- -- [ERROR] FATAL ERROR [INFO] -- -- [INFO] Java heap space [INFO] -- -- [DEBUG] Trace java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:2786) at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:94) at sun.net.www.http.PosterOutputStream.write(PosterOutputStream.java:61) at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:338) at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:305) at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:267) at org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:2 38) at org.apache.maven.wagon.StreamWagon.put(StreamWagon.java:143) at org.apache.maven.wagon.providers.http.LightweightHttpWagon.put(Lightw eightHttpWagon.java:148) at org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(D efaultWagonManager.java:237) at org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(Def aultWagonManager.java:153) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(Def aultArtifactDeployer.java:80) at org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo. java:240) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:447) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandalone Goal(DefaultLifecycleExecutor.java:493) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:463) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:224) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute
[Workaround] RE: OutOfMemoryError when deploying large files
We have resolved the problem by using dav:http protocol instead of http protocol. I have raised a jira against wagon-http-lightweight: http://jira.codehaus.org/browse/WAGON-272 -Rakesh -Original Message- From: Arora, Rakesh (CAR:9S00) Sent: Friday, June 26, 2009 4:19 PM To: users@maven.apache.org Subject: OutOfMemoryError when deploying large files When deploying a large artifact we get the OutOfMemoryError (please check the attached stack trace). This is similar to error reported here: http://www.mail-archive.com/users@maven.apache.org/msg99157.html We traced the issue to wagon-http-lightweight using PosterOutputStream/ByteArrayOutputStream.write(). This method consumes lot of memory when dealing with large files as reported here: https://issues.alfresco.com/jira/browse/ETHREEOH-974 In our case, we are trying to deploy a around 600M file and have set the maximum heap space to 1024M (-Xmx1024m). We are still running out of memory. We are using maven 2.0.8 but had the same issue when tried with 2.1.0 version. Is there a way to use another Wagon provider (wagon-http ?) that can deal better with large files? If yes, how can we configure this? Should I raise a jira for this (against which component maven-deploy-plugin or wagon-http-lightweight)? Thanks, -Rakesh ;-STACK TRACE- [DEBUG] -- end configuration -- [INFO] [deploy:deploy-file] Uploading: http://repo_url/group/foo/1.0/foo-1.0.zip [INFO] -- -- [ERROR] FATAL ERROR [INFO] -- -- [INFO] Java heap space [INFO] -- -- [DEBUG] Trace java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:2786) at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:94) at sun.net.www.http.PosterOutputStream.write(PosterOutputStream.java:61) at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:338) at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:305) at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:267) at org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:2 38) at org.apache.maven.wagon.StreamWagon.put(StreamWagon.java:143) at org.apache.maven.wagon.providers.http.LightweightHttpWagon.put(Lightw eightHttpWagon.java:148) at org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(D efaultWagonManager.java:237) at org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(Def aultWagonManager.java:153) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(Def aultArtifactDeployer.java:80) at org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo. java:240) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:447) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandalone Goal(DefaultLifecycleExecutor.java:493) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:463) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:224) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.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) [INFO] -- -- [INFO] Total time: 1 minute 22 seconds [INFO] Finished at: Fri Jun 26 15:10:36 EDT 2009 [INFO] Final Memory: 4M/1016M [INFO]
OutOfMemoryError when deploying large files
When deploying a large artifact we get the OutOfMemoryError (please check the attached stack trace). This is similar to error reported here: http://www.mail-archive.com/users@maven.apache.org/msg99157.html We traced the issue to wagon-http-lightweight using PosterOutputStream/ByteArrayOutputStream.write(). This method consumes lot of memory when dealing with large files as reported here: https://issues.alfresco.com/jira/browse/ETHREEOH-974 In our case, we are trying to deploy a around 600M file and have set the maximum heap space to 1024M (-Xmx1024m). We are still running out of memory. We are using maven 2.0.8 but had the same issue when tried with 2.1.0 version. Is there a way to use another Wagon provider (wagon-http ?) that can deal better with large files? If yes, how can we configure this? Should I raise a jira for this (against which component maven-deploy-plugin or wagon-http-lightweight)? Thanks, -Rakesh ;-STACK TRACE- [DEBUG] -- end configuration -- [INFO] [deploy:deploy-file] Uploading: http://repo_url/group/foo/1.0/foo-1.0.zip [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Java heap space [INFO] [DEBUG] Trace java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:2786) at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:94) at sun.net.www.http.PosterOutputStream.write(PosterOutputStream.java:61) at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:338) at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:305) at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:267) at org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:2 38) at org.apache.maven.wagon.StreamWagon.put(StreamWagon.java:143) at org.apache.maven.wagon.providers.http.LightweightHttpWagon.put(Lightw eightHttpWagon.java:148) at org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(D efaultWagonManager.java:237) at org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(Def aultWagonManager.java:153) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(Def aultArtifactDeployer.java:80) at org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo. java:240) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:447) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandalone Goal(DefaultLifecycleExecutor.java:493) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:463) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:224) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.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) [INFO] [INFO] Total time: 1 minute 22 seconds [INFO] Finished at: Fri Jun 26 15:10:36 EDT 2009 [INFO] Final Memory: 4M/1016M [INFO]
Problem with using cobertura to calculate unit testcoverage for projects using AspectJ
In our project we are using AspectJ only for unit testing. So we are using test-compile goal of aspectj-maven-plugin: http://mojo.codehaus.org/aspectj-maven-plugin/ We also use cobertura maven plugin to calculate the unit test coverage http://mojo.codehaus.org/cobertura-maven-plugin/ Cobertura is not reporting the test coverage correctly. It doesn't include the source code files that has been weaved by aspectj compiler for unit test coverage. Here is what happens during the build: * Cobertura instruments the java classes in target/generated-sources/cobertura * aspectj:test-compile weaves the classes from src/main/java and src/main/test into target/test-classes. So Cobertura instrumented files are not seen during the test run. Any idea how to fix this? Is there any other way to calculate the unit test coverage in this scenario? Thanks, -Rakesh
Problem with Using cobertura-maven-plugin and aspectj-maven-plugin together in a project
I am having problem using cobertura and aspectj plugin together. My code coverage is incorrectly reported as 0% AspectJ is only used for unit testing, so project is configured to run test-compile only. Here is what i think is happening: - cobertura instruments the java class files (*.class) in target/generated-sources/cobertura - aspectj:test-compile is not picking up the class files generated (*.class) in the above step, it picks up the java source files (*.java) from src/main/java and src/main/test. I think ajc compiler needs -inpath option to weave the *.class files in target/generated-sources/cobertura directory but i couldn't find a configuration option for aspectj plugin to set this option. Any idea? Thanks, -Rakesh -- View this message in context: http://www.nabble.com/Problem-with-Using-cobertura-maven-plugin-and-aspectj-maven-plugin-together-in-a-project-tp22851108p22851108.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-surefire-plugin version 2.3.4 not reporting the @Ignore annotated testcases
Sorry, I made a mistake in the original post. We are using maven-surefire-plugin version 2.4.3. Thanks, -Rakesh Wayne Fay wrote: On Fri, Feb 6, 2009 at 12:48 PM, Rakesh Arora rakesh.ar...@nortel.com wrote: We are using junit 4.4 and maven-surefire-plugin version 2.3.4 http://jira.codehaus.org/browse/SUREFIRE-303 That JIRA indicates it is fixed in Surefire version 2.4, but by your own admission you are using 2.3.4. I would assume that is the problem. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- View this message in context: http://www.nabble.com/maven-surefire-plugin-version-2.3.4-not-reporting-the-%40Ignore-annotated-testcases-tp21880371p21914928.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven-surefire-plugin version 2.3.4 not reporting the @Ignore annotated testcases
We are using junit 4.4 and maven-surefire-plugin version 2.3.4 Some of out testcases are annotated with @Ignore but maven-surefire-plugin is not reporting them as skipped. Although these testcases are ignored during the build. Is their any specific configuration required to make maven-surefire-plugin to report them as skipped? I found this jira but it according to it this feature is now available: http://jira.codehaus.org/browse/SUREFIRE-303 Any idea? Thanks, -Rakesh
Maven plugin for creating a patch for the source files managed using subversion
Hi, Is there a maven plugin for creating a patch for the source files that are linked to subversion scm? I do see a plugin for applying the patch: http://maven.apache.org/plugins/maven-patch-plugin/index.html But can't find the one for creating one. Thanks, -Rakesh
RE: How to assembly a zip (using maven-asembly-plugin) with two artifacts that have the same groupId, artifactId and type but different version
Thanks Dan! This works. -Rakesh -Original Message- From: Dan Tran [mailto:dant...@gmail.com] Sent: Friday, January 09, 2009 1:17 AM To: Maven Users List Subject: Re: How to assembly a zip (using maven-asembly-plugin) with two artifacts that have the same groupId, artifactId and type but different version use maven-dependency-plugin to pull them down first, then have maven-assembly-plugin to take over -D On Thu, Jan 8, 2009 at 9:56 PM, Rakesh Arora rakesh.ar...@nortel.com wrote: I need to create a zip file that includes two versions of the same artifact. What is the best way to do that? Thanks, -Rakesh - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
How to assembly a zip (using maven-asembly-plugin) with two artifacts that have the same groupId, artifactId and type but different version
I need to create a zip file that includes two versions of the same artifact. What is the best way to do that? Thanks, -Rakesh
xdoclet:ejbdoclet error on windows2000
xdoclet:ejbdoclet goal fails to generate the deployment descriptor, home
interfaces etc. on my windows (Windows 2000) development environment. It
works fine on Unix. Also for few of my colleagues, it works fine on their
windows 2000.
Here is our maven.xml:
;--
project default=build xmlns:m=jelly:maven
goal name=code-generate
mkdir dir=${maven.build.dir}/log/
mkdir dir=${maven.build.dir}/generate/
echo message=Generating JVTSessionBean .../
java jar=${maven.repo.local}/saxon/jars/saxon-7.jar fork=true
output=${maven.build.dir}/log/jvtsession.log
arg path=${basedir}/../service.xml/
arg path=${basedir}/../../metamodel/jvtsession.xsl/
arg line=xsl-outdir=${maven.build.dir}/generate/
/java
!-- now add generated sources to maven compile set so maven knows to
compile them --
path id=gen.java.compile.src.set
location=${basedir}/target/generate/
m:addPath id=maven.compile.src.set refid=gen.java.compile.src.set/
/goal
preGoal name=java:compile
attainGoal name=code-generate/
attainGoal name=xdoclet:ejbdoclet/
/preGoal
postGoal name=cactus:cactifywar
attainGoal name=cactus:postcactifywar/
/postGoal
preGoal name=cactus:test
attainGoal name=cactus:pretest/
/preGoal
/project
;
Here is the error that i get:
;
java:compile:
code-generate:
[mkdir] Created dir:
M:\rakmoh.mainline_base_datamgmt_dev.win\oam_platform\b
ase_datamgmt\datasource\service\target\log
[mkdir] Created dir:
M:\rakmoh.mainline_base_datamgmt_dev.win\oam_platform\b
ase_datamgmt\datasource\service\target\generate
[echo] Generating JVTSessionBean ...
Tag library requested that is not present: 'maven' in plugin:
'maven-xdoclet-plu
gin-1.2.1'
Generating EJB deployment descriptor (ejb-jar.xml).
XJavaDoc Ignoring class
com.nortel.oam.impl.datasource.service.JVTDataSourceMode
lSessionBean in
M:\rakmoh.mainline_base_datamgmt_dev.win\oam_platform\base_datam
gmt\datasource\service\target\generate\com\nortel\oam\impl\datasource\servic
e\JV
TDataSourceModelSessionBean.java. It was generated (Tue Jun 22 16:17:23 EDT
2004
) after XJavaDoc's timestamp was reset (Tue Jun 22 16:17:17 EDT 2004)
Generating jboss.xml.
Generating jaws.xml.
xdoclet:ejbdoclet:
;--
Thanks,
-Rakesh
Problem using Maven jaxb plugin
I am getting the following error when using maven jaxb plugin to generate source code from the xsd files. Any idea? Note that I am trying to use this plgin with JAXB 1.0.2, since i couldn't find a way to download JAXB 1.0.0 from the sun site. Any idea how i can obtain JAXB 1.0.0? Thanks, -Rakesh ;- BUILD FAILED File.. D:\Profiles\rakmoh\.maven\plugins\maven-jaxb-plugin-1.0\plugin.jelly Element... xjc Line.. 34 Column 49 org/relaxng/datatype/ValidationContext com.werken.werkz.UnattainableGoalException: Unable to obtain goal [jaxb:generate ] -- D:\Profiles\rakmoh\.maven\plugins\maven-jaxb-plugin-1.0\plugin.jelly:34:49: xjc org/relaxng/datatype/ValidationContext at com.werken.werkz.Goal.fire(Goal.java:646) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java: 610) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:266) at org.apache.maven.cli.App.doMain(App.java:485) at org.apache.maven.cli.App.main(App.java:1214) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) org.apache.commons.jelly.JellyTagException: D:\Profiles\rakmoh\.maven\plugins\ma ven-jaxb-plugin-1.0\plugin.jelly:34:49: xjc org/relaxng/datatype/ValidationCon text at org.apache.commons.jelly.impl.TagScript.handleException(TagScript.jav a:702) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:296) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTa g.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.perfor mAction(MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java: 610) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:266) at org.apache.maven.cli.App.doMain(App.java:485) at org.apache.maven.cli.App.main(App.java:1214) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
