You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@buildr.apache.org by Will Rogers <wj...@gmail.com> on 2010/03/03 01:37:31 UTC
xmlbeans problems
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.
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.
-- Will
P.S. thanks for the excellent support thus far and sorry for
continuing to poke the bear ;)
Re: xmlbeans problems
Posted by Alex Boisvert <al...@gmail.com>.
I'm a bit in a rush right now ... can you file an issue and attach a simple
project illustrating #1 and #2? I'll look into them later today.
For #3, I agree with you and I'm happy to make the change. You can file a
separate issue for it.
thanks,
alex
On Tue, Mar 2, 2010 at 4:37 PM, Will Rogers <wj...@gmail.com> 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.
>
> 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.
>
>
> -- Will
>
> P.S. thanks for the excellent support thus far and sorry for
> continuing to poke the bear ;)
>
Re: xmlbeans problems
Posted by Alex Boisvert <al...@gmail.com>.
That's good to know. I haven't tested on either JRuby or Windows in some
time. I'll give it a shot asap. I only get 3 failing specs on Ubuntu + MRI
at the moment, all of which are known issues that should get fixed soon.
We won't be releasing 1.4.0 without first getting the specs under control
for both JRuby and Windows.
alex
On Wed, Mar 3, 2010 at 2:04 PM, Will Rogers <wj...@gmail.com> wrote:
> FYI I have...
>
> 79 specs failing on Windows 7 + java 1.6.0_18-b07 + jruby 1.4.0 + buildr
> r918501
> 13 specs failing on ubuntu 9.10 + java 1.6.0_15-b03 + jruby 1.4.0 +
> buildr r918501
>
> ...and one of the differences is Buildr::ZipTask 'should create new
> archive when updating' (fails on Windows). If I can be of any more
> help testing or verifying things on Windows, let me know.
>
>
> -- Will
>
Re: xmlbeans problems
Posted by Will Rogers <wj...@gmail.com>.
FYI I have...
79 specs failing on Windows 7 + java 1.6.0_18-b07 + jruby 1.4.0 + buildr r918501
13 specs failing on ubuntu 9.10 + java 1.6.0_15-b03 + jruby 1.4.0 +
buildr r918501
...and one of the differences is Buildr::ZipTask 'should create new
archive when updating' (fails on Windows). If I can be of any more
help testing or verifying things on Windows, let me know.
-- Will
Re: xmlbeans problems
Posted by Will Rogers <wj...@gmail.com>.
On Wed, Mar 3, 2010 at 10:08 AM, Alex Boisvert <al...@gmail.com> wrote:
> Now tracking #1 and #2 with:
> https://issues.apache.org/jira/browse/BUILDR-393
Thank you for following up on these. I was pretty much exhausted by
the time you got back to me last night, so I wasn't going to get to it
until just now. Glad I checked my e-mail first :)
I just updated BUILDR-393 with the steps that reproduce the reported
issues for me.
-- Will
Re: xmlbeans problems
Posted by Alex Boisvert <al...@gmail.com>.
On Tue, Mar 2, 2010 at 4:37 PM, Will Rogers <wj...@gmail.com> 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