On Tue, Mar 2, 2010 at 4:37 PM, Will Rogers <[email protected]> wrote:

> I'm using 'buildr/xmlbeans' and 'compile_xml_beans _(:source, :main,
> :xsd)' in my project definition.
>
> 1. I'm observing a similar problem to the one I reported yesterday
> with the resources task. I edited one of my files in src/main/xsd and
> ran "buildr package". Output:
>
> Building myproject
> Running XMLBeans schema compiler
> ←[34mredefining Project←[0m
> Time to build schema type system: 1.727 seconds
> Time to generate code: 12.038 seconds
> Compiling myproject into C:/blah/myproject/target/classes
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
> Packaging myproject
> Running integration tests...
> ←[32mCompleted in 1m2.352s←[0m
>
> NOTE: myproject.jar was NOT updated. I checked target/classes and
> verified that the XMLBeans were recompiled and have newer modified
> dates than the jar. Shouldn't that trigger the package task
> reassembling the jar? Can anyone verify this?
>
> 2. Adding a brand new file to src/main/xsd is not detected by the
> XMLBeans support at all. I did a "buildr clean package", copied a new
> XSD into src/main/xsd, and then did a "buildr package". Output:
>
> Building myproject
> Packaging myproject
> Running integration tests...
> ←[32mCompleted in 2.723s←[0m
>
> Schema generation did not run, compile did not run, and packaging did
> not run. The new file was ignored.
>

Now tracking #1 and #2 with:
https://issues.apache.org/jira/browse/BUILDR-393


> 3. In addon/buildr/xmlbeans.rb, the compile_xml_beans function calls
> 'compile.using(:javac).from(generated).with(*XMLBeans.requires)'.
> requires() is defined thus:
>
>  @requires ||= REQUIRES.artifacts.each(&:invoke).map(&:to_s)
>
> ...which resolves to filesystem paths, not artifact specs. This
> results in compile.dependencies containing two elements that are
> string filesystem paths instead of Artifact instances, which is
> screwing with some deployment scripting I am attempting. Removing the
> '.map(&:to_s)' from the end of that line makes requires() return
> artifact specs instead and everything works nicely. Does that seem
> like a reasonable change? I will file an enhancement ticket for this
> unless someone points out something wrong with it.
>

Fixed in trunk.

P.S. thanks for the excellent support thus far and sorry for
> continuing to poke the bear ;)
>

Keep 'em coming!  You uncovered important issues that should not have
existed this long.

alex

Reply via email to