Hi,
I have a setup where my JiBX schema and binding files are in one maven
project and some classes referenced by the bindings are in other peer-level
projects. This works great at dev time but at test, run and package time I
have some problems. Specifically, when the compile binding is executed with
the process-classes phase, the updates are not included in the jar files
generated for the other projects.
A simplified setup...
Parent
- SubJiBX (holds schema, binding files and other stuff)
- SubOther (holds data objects reference by the binding files)
Parent POM has SubJiBX and SubOther as modules. SubJiBX lists SubOther as
both a standard dependency and a module in the configuration of the plugin's
execution compile-binding definition. SubOther does not depend on SubJiBX
(and can't since that would be a circular dependency which is not allowed).
In the Parent directory run "mvn package". We need to do it here since
SubJiBX depends on SubOther and needs to be able to see a reference to it.
The generate-sources phase runs just fine (as long as the schema-codegen
schema directory configuration is prepended with ${basedir}) on all
projects. The compile phase runs just fine on all projects. The
process-classes phase runs just fine on all projects, and the classes
referenced in SubOther do get updated.
My problem is with the package phase. What is happening is that SubOther is
being packaged BEFORE the JiBX bind goal is run in SubJiBX. I have to
re-run "mvn package" for the first set of JiBX generated changes to be
included. The resulting JARs from the second mvn package seem to work ok,
but I don't get the warm and fuzzies.
Does anyone know how I can get the bind goal in SubJiBX to run before
SubOther is packaged so I only need to run the mvn command once? Moving
classes between the two modules is not an option.
Thanks for any insight!
Scott Dickerson
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
jibx-users mailing list
jibx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jibx-users
