<headius[m]>
basically someone requesting a "jruby-slim" maven artifact that shades *nothing*
<headius[m]>
fidothe: that is definitely a tricky use case... it must be using reflection to construct instances of that class?
<headius[m]>
I have never used a custom entity resolver...do you have a link to some example Java code?
<enebo[m]>
headius: I guess I don't care so long as it is maven only but with that said we should not make it have an appealing name
<enebo[m]>
slim I believe someone will think is down to the metal or something :)
<headius[m]>
jruby-without-all-the-other-crap
<enebo[m]>
jruby-incomplete
<headius[m]>
I don't think we have a jruby-base artifact
<headius[m]>
hahah
<enebo[m]>
actually I am happy with incomplete even though I meant it as a joke
<enebo[m]>
-base probably is fine but I will not answer support questions if someone asks why it doesn't work
<enebo[m]>
Hmm does jython separate?
<headius[m]>
well this isn't an artifact that would be basically broken...it would just depend on jnr-ffi and stuff via maven deps
<headius[m]>
rather than shading them in
<enebo[m]>
They obviously do or this person would not be where they are at
<enebo[m]>
yeah that's true
<enebo[m]>
you would just maven build your java project or whatever
<headius[m]>
open question whether we would unshade ASM but I think the goal here is to get a bare bones jar that's just jruby
<headius[m]>
right
<headius[m]>
so you'd depend on jruby-base and it would effectively do what jruby-core does with external deps
<headius[m]>
jruby-core would really just repackage jruby-base with some shaded deps
<enebo[m]>
ah they do use slim
<enebo[m]>
meh on slim I think I would rather go with base than that
<headius[m]>
so you have base, core = base + deps, complete = core + stdlib
<enebo[m]>
yeah or even just consider non-base name and then have it be its own thing
<enebo[m]>
but it does not really matter since we will always be releasing these in lock step
<enebo[m]>
my only concern with slicing up deps more is IDE supoprt
<enebo[m]>
right now I tend to load core to speed up loading the project
<headius[m]>
non-base name?
<headius[m]>
ah yeah core is a little weird wrt local dev
<enebo[m]>
I just mean it is some special thing which is not in some more complicated dep chain
<enebo[m]>
If we have dep of base but need core to run anything as a dev I guess I just load jruby and accept it will index everything in there
<headius[m]>
oh right I didn't mean those + would be explicit deps
<headius[m]>
core would shade base plus deps
<headius[m]>
it would not have a dependency on base
<enebo[m]>
Or perhaps we can get idea to not look at gems
<enebo[m]>
ok cool
<headius[m]>
so I think for maven purposes, core might have a submodule base that we also publish... we're basically building base right now but then we go straight to shading
<headius[m]>
there is another part of this discussion though... Java modules and shading will be a problem in the future
<headius[m]>
I've contemplated having lib/jruby.jar actually be a base jar plus the other dependency jars as from maven
<headius[m]>
that would allow us to set lib as a module dir and modularize everything
<headius[m]>
I thought that's what this person was working on but they seem to just want a slim jar
<headius[m]>
I have thought a few times that it's weird to have core/ do this repackaging for lib/jruby.jar but I think that was just simplest when we were migrating to maven
<headius[m]>
we can move forward with a base artifact without addressing these other changes though
<enebo[m]>
I believe we can change core to be properly modularized in the future and just use a significant version perhaps
<enebo[m]>
but even if we didn't use a significant version it would still likely work non-modularized when we do break it up
<enebo[m]>
and then slim/base/whatever it is called would I guess just be the same as core
subbu|lunch is now known as subbu
<headius[m]>
if we add base then maven users of JRuby should be able to modularize fine
<headius[m]>
for dist, though, I'm thinking lib would change from holding a jruby-core jar to holding a jruby-base jar plus all the other dependencies as jars
<headius[m]>
and then launcher just sets those into classpath or module path
<headius[m]>
so core wouldn't go away but it would not be used in the dist
lopex[m] has joined #jruby
<enebo[m]>
ok makes sense
SarahStep has joined #jruby
SarahStep has quit [Client Quit]
ur5us has joined #jruby
<headius[m]>
enebo: following up on the Time.now bug we chatted about...
<headius[m]>
this is obviously primitive, just looking for a library name of "DEFAULT" to use a hardcoded value for RTLD_DEFAULT as the library handle, but then the cascading behavior of jnr-ffi symbol searching "just works"
<headius[m]>
so I'm not married to this mechanism but it works