These are chat archives for jruby-gradle/jruby-gradle-plugin

21st
Sep 2015
R. Tyler Croy
@rtyler
Sep 21 2015 15:39
moin moin
Christian Meier
@mkristian
Sep 21 2015 15:46
moin
R. Tyler Croy
@rtyler
Sep 21 2015 15:58
@mkristian I started a branch of work to enable jem for the base plugin, not yet fully tested though
I'd love to add it to the nexus ruby tools too :)
@ysb33r somehow 0.4.0 still seems to be the most downloaded version of the plugin :(
Christian Meier
@mkristian
Sep 21 2015 16:04
@rtyler moving things from ruby to java is welcome on nexus-ruby-tools
R. Tyler Croy
@rtyler
Sep 21 2015 16:07
@mkristian is that nexus 2.11 branch okay to make pull requests for branch new features against?
Christian Meier
@mkristian
Sep 21 2015 16:11
yes, I take it from there to the internal branch.
R. Tyler Croy
@rtyler
Sep 21 2015 16:16
"open source" =_=
Christian Meier
@mkristian
Sep 21 2015 16:19
they are just restructuring their repos right now. but the nexus-ruby-tools is open source - EPL
Blane Dabney
@raelik
Sep 21 2015 16:28
FYI, I get this error when trying to turn defaultRepositories off and use the new rubygems() function: https://gist.github.com/raelik/32531ac0ae18cbac3959
spins up the jetty server just fine, but it isn't looking for jruby-complete and jruby-mains in the right place
Christian Meier
@mkristian
Sep 21 2015 16:29
right place ?
Blane Dabney
@raelik
Sep 21 2015 16:30
I'm guessing because I need to add maven back in?
yes, that's exactly what is was, disregard that
R. Tyler Croy
@rtyler
Sep 21 2015 16:31
raelik: yeah, you'll need a jcenter :)
is my blog post incorrect?
Blane Dabney
@raelik
Sep 21 2015 16:31
though you might wanna add that to the doc, that you'll need jcenter() or mavenCentral() in your repositories block
rtyler @rtyler nods
R. Tyler Croy
@rtyler
Sep 21 2015 16:31
will do, thanks
Blane Dabney
@raelik
Sep 21 2015 16:32
I should have realized that anyway
rtyler @rtyler pushes updates
Blane Dabney
@raelik
Sep 21 2015 16:35
Another thing I've noticed is that over repeated runs, the worker thread # is incrementing. Is that to be expected as long as the same instance of the gradle daemon is running?
(the jetty worker thread I should say)
R. Tyler Croy
@rtyler
Sep 21 2015 16:35
the embedded jetty doesn't run in the daemon process
I actually don't know how to get any behavior into the daemon
Blane Dabney
@raelik
Sep 21 2015 16:37
you sure it isn't somehow running in-process with the daemon's jvm? because there definitely seems to be some kind of state being maintained between ./gradlew runs
otherwise I wouldn't expect that thread # to increment like it is
Hmmm something was definitely going on there, because it reset when I killed my gradle daemon. That said, it isn't incrementing anymore
Might have had to do with that failure I had
R. Tyler Croy
@rtyler
Sep 21 2015 16:42
it's probably something to do with how the kernel keeps track of threads under the same parent pid
rtyler @rtyler isn't worried about it
Blane Dabney
@raelik
Sep 21 2015 16:43
yeah, I think you're right
it isn't behaving in a deterministic fashion
R. Tyler Croy
@rtyler
Sep 21 2015 17:30
@mkristian do you happen to know if bundle exec can operation purely with Gemfile.lcck?
Christian Meier
@mkristian
Sep 21 2015 17:57
no way I would say. a Gemfile with a set of valid gems installed works without running bundle install and generates a Gemfile.lock on the fly