Discussion:
stacktrace from JarTask
Dieter Vrancken
2017-05-03 18:09:23 UTC
Permalink
Dear list,

I am trying to upgrade to Buildr 1.5.2 (running on JRuby 9.1.7.0, on
64-bit Arch Linux). Unfortunately, with this version, my build fails
during the package :jar task. This cause seems to be the POM-related
changes in 1.5.1 and 1.5.2. Below is partial output from the bundle exec
Buildr aborted!
NameError : undefined local variable or method `pom' for
#<Buildr::Packaging::Java::JarTask:0x1b065145>
Did you mean? p
com
/home/dieterv/.rbenv/versions/jruby-9.1.7.0/lib/ruby/gems/shared/gems/buildr-1.5.2-java/lib/buildr/java/packaging.rb:214:in
`block in initialize'
/home/dieterv/.rbenv/versions/jruby-9.1.7.0/lib/ruby/gems/shared/gems/rake-0.9.2.2/lib/rake/task.rb:205:in
`block in execute'
org/jruby/RubyArray.java:1733:in `each'
/home/dieterv/.rbenv/versions/jruby-9.1.7.0/lib/ruby/gems/shared/gems/rake-0.9.2.2/lib/rake/task.rb:200:in
`execute'
/home/dieterv/.rbenv/versions/jruby-9.1.7.0/lib/ruby/gems/shared/gems/buildr-1.5.2-java/lib/buildr/core/application.rb:661:in
`block in invoke_with_call_chain'
/home/dieterv/.rbenv/versions/jruby-9.1.7.0/lib/ruby/stdlib/monitor.rb:214:in
`mon_synchronize'
/home/dieterv/.rbenv/versions/jruby-9.1.7.0/lib/ruby/gems/shared/gems/buildr-1.5.2-java/lib/buildr/core/application.rb:647:in
`invoke_with_call_chain'
...
class JarTask < ZipTask
super
enhance do
pom.invoke rescue nil if pom && pom != self && classifier.nil?
end
end
My project does not have a .pom file, nor is it configured to generate a
custom pom. It looks to me like 'pom' simply isn't defined as a method
in this case.

Can this be fixed? As a workaround I'll just downgrade to 1.5.0 for now.
That one does work as expected.

Thanks,
Dieter
Peter Donald
2017-05-05 00:08:47 UTC
Permalink
Thanks for the heads up. We haven't this issue but I must admit that we
only use native ruby these days so it could have slipped past. I will try
and fix it tonight if I get the chance
Post by Dieter Vrancken
Dear list,
I am trying to upgrade to Buildr 1.5.2 (running on JRuby 9.1.7.0, on
64-bit Arch Linux). Unfortunately, with this version, my build fails during
the package :jar task. This cause seems to be the POM-related changes in
1.5.1 and 1.5.2. Below is partial output from the bundle exec buildr
Buildr aborted!
NameError : undefined local variable or method `pom' for
#<Buildr::Packaging::Java::JarTask:0x1b065145>
Did you mean? p
com
/home/dieterv/.rbenv/versions/jruby-9.1.7.0/lib/ruby/gems/sh
ared/gems/buildr-1.5.2-java/lib/buildr/java/packaging.rb:214:in `block
in initialize'
/home/dieterv/.rbenv/versions/jruby-9.1.7.0/lib/ruby/gems/sh
ared/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `block in execute'
org/jruby/RubyArray.java:1733:in `each'
/home/dieterv/.rbenv/versions/jruby-9.1.7.0/lib/ruby/gems/sh
ared/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `execute'
/home/dieterv/.rbenv/versions/jruby-9.1.7.0/lib/ruby/gems/sh
ared/gems/buildr-1.5.2-java/lib/buildr/core/application.rb:661:in `block
in invoke_with_call_chain'
/home/dieterv/.rbenv/versions/jruby-9.1.7.0/lib/ruby/stdlib/monitor.rb:214:in
`mon_synchronize'
/home/dieterv/.rbenv/versions/jruby-9.1.7.0/lib/ruby/gems/sh
ared/gems/buildr-1.5.2-java/lib/buildr/core/application.rb:647:in
`invoke_with_call_chain'
...
class JarTask < ZipTask
super
enhance do
pom.invoke rescue nil if pom && pom != self && classifier.nil?
end
end
My project does not have a .pom file, nor is it configured to generate a
custom pom. It looks to me like 'pom' simply isn't defined as a method in
this case.
Can this be fixed? As a workaround I'll just downgrade to 1.5.0 for now.
That one does work as expected.
Thanks,
Dieter
--
Cheers,

Peter Donald
Peter Donald
2017-05-06 11:11:09 UTC
Permalink
Hi,

Using rbenv to install jruby-9.1.7.0 and using Buildr 1.5.2 I was
unable to reproduce this error. I tried in three different projects.
Do you have a small example project that reproduces this error?
--
Cheers,

Peter Donald
Dieter Vrancken
2017-05-08 08:09:00 UTC
Permalink
Well that's just great :/ The interesting thing is that it does work as
expected with 1.5.0, without touching my buildfile. I will investigate
further and try to put something together in the coming days.

Thanks for looking into this,
Dieter
Post by Peter Donald
Hi,
Using rbenv to install jruby-9.1.7.0 and using Buildr 1.5.2 I was
unable to reproduce this error. I tried in three different projects.
Do you have a small example project that reproduces this error?
Peter Donald
2017-05-08 17:53:38 UTC
Permalink
I expect the problem is probably a particular addon or feature you are
using that we don't use in our projects. I just could not figure out
which one would cause this. A small example to reproduce it would make
the process a lot easier ;)

On Mon, May 8, 2017 at 6:09 PM, Dieter Vrancken
Post by Dieter Vrancken
Well that's just great :/ The interesting thing is that it does work as
expected with 1.5.0, without touching my buildfile. I will investigate
further and try to put something together in the coming days.
Thanks for looking into this,
Dieter
Post by Peter Donald
Hi,
Using rbenv to install jruby-9.1.7.0 and using Buildr 1.5.2 I was
unable to reproduce this error. I tried in three different projects.
Do you have a small example project that reproduces this error?
--
Cheers,

Peter Donald
Dieter Vrancken
2017-05-11 20:53:03 UTC
Permalink
So I finally looked into this and figured out what the problem was.

Turns out we have a custom extension to obfuscate the :jar package.
This custom extension tried to avoid registering the :jar package
as a project artefact as nothing is supposed to be using that jar.
It did this by directly invoking 'package_as_jar', rather than
using 'package :jar'. As a result the code at package.rb:175 never
gets executed for this :jar package, the pom method is never defined
and I get the exception at java/packaging.rb:214. IMO, the extension
should instead just use a classifier to indicate the purpose of this
jar.

For my benefit, would you mind explaining the intent of the line at
java/packaging.rb:214? It's obviously trying to invoke the pom method,
but what does that achieve? My project does not use a pom or even a
maven repo for dependencies...

Thanks again for your time,
Dieter
Post by Peter Donald
I expect the problem is probably a particular addon or feature you are
using that we don't use in our projects. I just could not figure out
which one would cause this. A small example to reproduce it would make
the process a lot easier ;)
On Mon, May 8, 2017 at 6:09 PM, Dieter Vrancken
Post by Dieter Vrancken
Well that's just great :/ The interesting thing is that it does work as
expected with 1.5.0, without touching my buildfile. I will investigate
further and try to put something together in the coming days.
Thanks for looking into this,
Dieter
Post by Peter Donald
Hi,
Using rbenv to install jruby-9.1.7.0 and using Buildr 1.5.2 I was
unable to reproduce this error. I tried in three different projects.
Do you have a small example project that reproduces this error?
Peter Donald
2017-05-14 21:19:57 UTC
Permalink
Hi,

On Fri, May 12, 2017 at 6:53 AM, Dieter Vrancken
Post by Dieter Vrancken
For my benefit, would you mind explaining the intent of the line at
java/packaging.rb:214? It's obviously trying to invoke the pom method,
but what does that achieve? My project does not use a pom or even a
maven repo for dependencies...
Hmm ... looking at the code, the intent seems to be to ensure that the
pom is built when the jar is built. This was not present in earlier
versions of buildr. It should be easy enough to avoid doing this if
the pom method is not defined so I will update the code to make it so.
I will look at making a release in the next short while to get it out
there.

I believe it is fixed in the commit

https://github.com/apache/buildr/commit/553f34846b4eb6b6a29249e0133e6ab463a4a80d
--
Cheers,

Peter Donald
Dieter Vrancken
2017-05-15 08:38:53 UTC
Permalink
Hi,
Post by Peter Donald
I believe it is fixed in the commit
https://github.com/apache/buildr/commit/553f34846b4eb6b6a29249e0133e6ab463a4a80d
that commit indeed avoids the exception.

Thanks a lot for the fast response,
Dieter

Loading...