Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
Today I can say that I am so happy, (although there are some bad news) and it is because the CI approach used for integrating latest pushed changes of Asciidoctor gem into Asciidoctor Java Integration, works so well because it has detected a problem. The bad news are that I don't know exactly where is the problem, and before starting with git bisect I would like to know if you have a quick answer why.
Basically you can see the problem here: 11 days ago I run it the last time a full integration between gem and java with latest Asciidoctor gem (https://travis-ci.org/asciidoctor/asciidoctor-java-integration/builds/8251591), today I have run it again, but without any modification on Java code (see git hash tag), but the build has failed with the error: org.jruby.exceptions.RaiseException: (LoadError) no such file to load -- asciidoctor at org.jruby.RubyKernel.require(org/jruby/RubyKernel.java:1054) at RUBY.require(jar:file:/opt/repo/org/jruby/jruby-complete/1.7.4/jruby-complete-1.7.4.jar!/META-INF/jruby.home/lib/ruby/shared/rubygems/custom_require.rb:36) So it seems like asciidoctor module is no longer available but at the same time this seems impossible, so any idea of which issue could be modified Asciidoctor gem in the way that cannot be loaded by JRuby? If there is nothing, then I will start with git bisect. |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
Administrator
|
Alex, First, great news! Continuous integration FTW! I did a brief exploration on my box (since I wanted to become familiar with the CI build anyway) and what I noticed is that this is an issue with the setup script. I recently changed the Asciidoctor version from 0.1.4.pre to 0.1.4.preview.1 [1]. That seems to be causing a problem with how JRuby resolves the gem under target/classes.
To be honest, I'm not sure I understand how it worked before. Instead of trying to overlay Asciidoctor HEAD onto version 0.1.3 to trick JRuby into using the right code base, I think the script should be installing the unreleased version of Asciidoctor into the local Maven repository and then building against a real gem. This is not only simpler, but it also makes the results more accurate.
I've put together a pull request that switches to this strategy. It's necessary to install the gem outside of the Maven lifecycle because, well, Maven just isn't that smart. Thus, Travis will invoke a shell script instead of mvn directly.
-Dan
Btw, I noticed that you are only running CI against the unreleased version of Asciidoctor. I think you should include building against the current released version in the build matrix. Travis supports running multiple builds (or you could just run mvn twice inside the test-asciidoctor-master.sh).
On Mon, Jul 1, 2013 at 1:16 PM, asotobu [via Asciidoctor :: Discussion] <[hidden email]> wrote: Today I can say that I am so happy, (although there are some bad news) and it is because the CI approach used for integrating latest pushed changes of Asciidoctor gem into Asciidoctor Java Integration, works so well because it has detected a problem. The bad news are that I don't know exactly where is the problem, and before starting with git bisect I would like to know if you have a quick answer why. ... [show rest of quote] Dan Allen | http://google.com/profiles/dan.j.allen |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
First of all thank you so much for improving that part of code.
The irony of the fate is that my first idea was to install the gem using Maven (not as worked as your solution but using same approach), but after talking with Jason, I thought I could also do that by installing gems directly to target directory (which of course I was wrong as we have seen), so no two executions of Maven were required, and it was "easier" to be integrated with development phase, and because at that time it worked I left as is. But yes obviously my approach was wrong, now it works pretty well so I am so happy. Thank you very much. Alex. |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
Administrator
|
On Mon, Jul 1, 2013 at 11:52 PM, asotobu [via Asciidoctor :: Discussion] <[hidden email]> wrote: But yes obviously my approach was wrong, now it works pretty well so I am so happy. I couldn't have implemented the changes I made without building on the great work you and Jason did in the first iteration. I could see the intent and another idea just popped into my head. Yeah OSS!
I'd actually conclude that Maven is just a pain in the side and thus it's more pragmatic to implement it using Maven as a helper rather than the primary controller. A single execution would be much easier with a tool like Gradle, which is one of the main reasons I think that I think Gradle will eventually win over ;) |
Free forum by Nabble | Edit this page |