<sintel[m]>
headius: are you around ? need some chat on jruby-base vs. jruby-core !
<sintel[m]>
@h
<sintel[m]>
headius: me being mkristian
<headius[m]>
Oh hello!
<headius[m]>
I am here sintel
<headius[m]>
rdubya you can repro that? I have done some testing on 14 but I don't know that I've had that issue
<headius[m]>
It looks familiar but there's lots of things that can cause that
<sintel[m]>
headius: yesterday I looked what we have and what can be done to produce the same jruby-core as now and a new jruby-base jar. so one point I remembered why we shaded these asm classes that jruby code is picky regarding these dependencies.
<sintel[m]>
unsure about the me.qmx.jitescript which we also repackage under org.jruby. then we include explicitly jnr dependencies - unsure why we never repackaged them
<sintel[m]>
then we have the main jruby:jruby artifact which is just pom with jruby-code and jruby-stdlib as deps. from this artifact point of view it would be enough to just have jruby-core without shaded and the rest will be done by maven, gradle or ivy
<sintel[m]>
jruby-jars takes lib/jruby.jar and jruby-complete will shade everything as well. maybe could repackages some deps before and we just leave it as is.
<headius[m]>
sintel: ok so yes, I believe jruby-core includes nearly all dependencies, excluding a few optional things like BSF. ASM is relocated because it is a very common dependency and it's easy to start having things collide.
<headius[m]>
looks like that's only in the jars we publish to maven... from what I can tell only asm gets relocated in lib/jruby.jar
<headius[m]>
as for why we don't relocate anything else... I'm not sure I remember the reasons anymore
<sintel[m]>
right lib/jruby.jar only relocates ASM
<headius[m]>
if we started publishing a jruby-base jar it might make sense for core and complete to relocate everything else
<headius[m]>
since jruby-base + maven deps could be assembled by anyone, and usually would happen automatically with other packaging
<headius[m]>
so jruby-base is our stuff only, jruby-core is base + shaded and relocated dependencies, jruby-complete is core plus stdlib and in-jar dist stuff
<headius[m]>
jruby-core and lib/jruby.jar would really just be the same thing then I guess
<headius[m]>
I mean what is different about them right now?
<headius[m]>
module name
<headius[m]>
I guess
<sintel[m]>
if I would start this from scratch I just would publish jruby-core without shading anything and maybe attach a jruby-core-shaded. this are the usecases. if someone really needs jruby-core without jruby-stdlib s/he can use jruby-core-shaded, ....
<sintel[m]>
current difference between jruby-core and lib/jruby is the relocation of jitescript
<headius[m]>
yeah it's unfortunate that core is already a shaded one
<headius[m]>
I don't see that we can change that now though
<sintel[m]>
hmm. because people use it outside of maven, gradle or ivy ? any such tools are transparent regarding the dependencies of maven artifacts, i.e. this happens all the time that they transitive hull of an artifact cahnges
<headius[m]>
yeah it's the outside maven etc cases I would worry about
<sintel[m]>
can not argue against that :)
<headius[m]>
it's worth considering
<headius[m]>
so I guess you are thinking if we were willing to make this change, then jruby-core would just stop shading stuff and that would be jruby-base
<headius[m]>
without a name change
<sintel[m]>
well, this is where I am heading.
<headius[m]>
and jruby-lib would be a separate step that combines jruby-core with shaded deps, or else we just ship the deps and make a longer classpath
<headius[m]>
go on
<sintel[m]>
as it is nasty to get another artifact with the same dependencies. I played around yesterday and did not go far
<sintel[m]>
let's pick up your idea. rename /core to /base and produce a regular maven artifact. have a /core which depends base and shades everything.
<headius[m]>
sure
<headius[m]>
I don't want to toss too much on the fire but core could also be deprecated
<sintel[m]>
let's see how this goes.
<headius[m]>
it may not serve a purpose if we have base and a way to turn that into lib/jruby.jar
<headius[m]>
so it might move to maven/jruby-core
<headius[m]>
something along those lines
<sintel[m]>
as long it is not too hacky I am with you.
<headius[m]>
if you're fine prototyping something we can play with that seems like a good way forward
<sintel[m]>
ok - let me play with this. but I need to add another artifact to main `mvn install` without any profiles.
<sintel[m]>
yes, sure will make a PR for you guys to play
<headius[m]>
I think we should seriously consider relocating almost everything else in complete and core too, and I need to try putting all dep jars in lib and adding on classpath
<headius[m]>
that will be necessary once they are modularized
<sintel[m]>
yes totally agree with relocating everything in complete and core. will add this as well
<headius[m]>
we need to get off joda time
<sintel[m]>
anything else which should not be relocated ?
<headius[m]>
I don't think so
<headius[m]>
some things might be sensitive to path like jnr* and jcodings
<headius[m]>
I think they should be relocated but they may require fixes to work properly
xardion has joined #jruby
ur5us has joined #jruby
<headius[m]>
oy vey
<headius[m]>
I started a spike to move to java.time
<headius[m]>
we have a lot of code surrounding joda
<headius[m]>
I might have to back off on this and try some refactoring of Time and Date first