Details
-
Type:
Bug
-
Status:
Resolved
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: JiBX 1.2.2
-
Fix Version/s: JiBX 1.2.3
-
Component/s: maven plugin
-
Labels:None
-
Environment:Windows XP, Java 1.6.0_20, Maven 3.0
Mac OS X 10.6, Java 1.6.0_22, Maven 2.2.1
-
Number of attachments :
Description
The problem is similar to JIBX-287, but I tested it with JiBX 1.2.2, and an unhandled Exception thrown.
Stacktrace
org.apache.maven.lifecycle.LifecycleExecutionException at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719) 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) Caused by: org.apache.maven.plugin.MojoExecutionException at org.jibx.maven.CompileBindingMojo.compile(CompileBindingMojo.java:224) at org.jibx.maven.CompileBindingMojo.execute(CompileBindingMojo.java:173) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) ... 17 more Caused by: java.lang.NullPointerException at org.jibx.binding.classes.ClassFile.<init>(ClassFile.java:242) at org.jibx.binding.classes.BoundClass.getInstance(BoundClass.java:411) at org.jibx.binding.classes.BoundClass.getInstance(BoundClass.java:443) at org.jibx.binding.def.ObjectBinding.<init>(ObjectBinding.java:294) at org.jibx.binding.def.BindingBuilder.unmarshalObjectBinding(BindingBuilder.java:1077) at org.jibx.binding.def.BindingBuilder.unmarshalMapping(BindingBuilder.java:1815) at org.jibx.binding.def.BindingBuilder.unmarshalMappings(BindingBuilder.java:1170) at org.jibx.binding.def.BindingBuilder.unmarshalBindingDefinition(BindingBuilder.java:2169) at org.jibx.binding.Utility.loadBinding(Utility.java:319) at org.jibx.binding.Utility.loadFileBinding(Utility.java:439) at org.jibx.binding.Compile.compile(Compile.java:217) at org.jibx.maven.CompileBindingMojo.compile(CompileBindingMojo.java:221) ... 20 more
The attached projects are the same as in JIBX-287, except the version of JiBX
Activity
Don Corley
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Assignee | Don Corley [ doncorley ] |
Don Corley
made changes -
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Resolution | Fixed [ 1 ] |
Adam,
Thank you so much for including these examples. It makes all the difference in trying to understand your question.
Remember, JiBX is such an elegant solution for XML binding because there are no messy extra classes or generated source code. JiBX actually changes the bytecode of your class so it can generate XML. This means that JiBX is run right after compilation and before (jar) packaging.
Typically, maven does the following in a JiBX binding project:
1. Compiles your source code into class files.
2. JiBX modifies the class files (bytecode) so they can generate the XML defined by your binding definition.
3. Packages the class files into a jar, etc.
In your example, just move the source files from the dsk-model project to the dsk-binding project, and JiBX runs flawlessly.
I can't think of a situation where you would want to do the binding in a different project than the source files since you would be changing the class files in another project.
Does this make sense?
Thanks,
Don