Which rspec error should be attacked first?

[Niklaus Giger]

Hi Antoine

I would appreciate if you could give me a hint on which rspecs errors to
attack first. I attach also a full log of a recent rspec run.

Here are my observations. There is one error coming from using Ruby 1.9 (see
below).

The following spec files have no errors.

spec/osgi/version_spec.rb OK
spec/osgi/packaging_sources_spec.rb OK
spec/osgi/bundle_package_spec.rb OK
spec/osgi/container_spec.rb OK
spec/osgi/dependencies_spec.rb OK
spec/osgi/execution_environment_spec.rb OK
spec/osgi/resolving_strategies_spec.rb OK
spec/osgi/registry_spec.rb 1 Simple Patch, Ruby 1.9 issue

spec/osgi/library_extension_spec.rb 13 examples, 3 failures, 1 pending
spec/osgi/bundle_spec.rb 13 examples, 6 failures
spec/osgi/packaging_spec.rb 23 examples, 13 failures, 1 pending
spec/osgi/project_extension_spec.rb 30 examples, 19 failures, 2 pending
spec/eclipse/feature_spec.rb 15 examples, 6 failures
spec/eclipse/p2_spec.rb 1 examples, 1 failure
spec/eclipse/site_spec.rb 2 examples. 2 failures

Remarks:
spec/osgi/bundle_spec.rb has quite a few error like this:
undefined method `with' for #<Buildr::Bnd::BundleTask:0x7f4e8149dd70>

There are 9 failures like this containing "/target/root/resources not created"

Can you also have a quick look, whether this patch is okay
https://github.com/ngiger/buildr4osgi/commit/7cb7f708fa71f96e8e692b706c8dca5c0349f364
to fix an error as ruby 1.9 raises a different error as 1.8? Or should I use a
different approch? If it is okay I will push it to you main repository.

Please let me know, if you think one of my commits is questionable.

Best regard and thanks in advance for your help.

Niklaus

[Antoine Toulme]

Hi Niklaus,

this should help a bit:

spec/osgi/library_extension_spec.rb 13 examples, 3 failures, 1 pending

That one is low priority, it is used to generate a library (see doc here: https://github.com/atoulme/buildr4osgi/blob/gh-pages/osgi.textile)

spec/osgi/bundle_spec.rb 13 examples, 6 failures

spec/osgi/packaging_spec.rb 23 examples, 13 failures, 1 pending

spec/osgi/project_extension_spec.rb 30 examples, 19 failures, 2 pending

This is high priority.

spec/eclipse/feature_spec.rb 15 examples, 6 failures

This is Eclipse specific stuff.

spec/eclipse/p2_spec.rb 1 examples, 1 failure

This is probably outdated.

spec/eclipse/site_spec.rb 2 examples. 2 failures

There's no notion of update site anymore. That can be just plainly removed.

There are 9 failures like this containing "/target/root/resources not created"

This is something I remember stumbling upon a long time ago, it might be tied to how Buildr is setup for testing. Recreating the folder prior to testing was helping. I think the tests ran ok the second time around.

I think your patch is fine, please feel free to merge it in. If you want, you can open pull requests so I can review and merge them.

Attachments:

- spec_ruby_1_8_7.log

[Niklaus Giger]

Hi Antoine

Thanks for your clarification

> Hi Niklaus,
>
> this should help a bit:
>

<..>

> > There are 9 failures like this containing "/target/root/resources not
> > created"
>
> This is something I remember stumbling upon a long time ago, it might be
> tied to how Buildr is setup for testing. Recreating the folder prior to
> testing was helping. I think the tests ran ok the second time around.
>

I stumbled over this bug in my project where I just add a special rule to
create the directory anyhow.

With the following patch in the buildr subdirectory, all the 9 failures
vanish.
> diff --git a/lib/buildr/packaging/ziptask.rb
> b/lib/buildr/packaging/ziptask.rb index 19ea8b8..150c961 100644
> --- a/lib/buildr/packaging/ziptask.rb
> +++ b/lib/buildr/packaging/ziptask.rb
> @@ -78,7 +78,7 @@ module Buildr
>
> while data = is.read(4096)
>
> zip << data
>
> end
>
> - end
> + end if File.exists?(content.to_s)
>
> end
>
> end
>
> end
But the fix is wrong in my eyes, as one should not ask to pack non existiting
files! But I will leave it for the time being, like this in order to attack
higher priority items. But something inside buildr4osgi is causing this bug.

Best regards

Niklaus

[Antoine Toulme]

Sure, that makes sense for now.