18:27 <@Elvanor> As for Groovy, all the deps are now done, there is still a problem related to jarjar though. 18:27 <@Elvanor> Upstream Groovy jar is done using jarjar probably to prevent class loader conflicts 18:28 <@Elvanor> Ours is not done like that but I am almost sure that this can cause some problems. So what is our policy on that, should we jarjar some packages or not? Is there any support in terms of eclass ? 18:30 <@Elvanor> Betelgeuse, fordfrog: ^ 18:31 <@fordfrog> i'm not eclass guru here and i do not know about any solution for this 18:31 <@fordfrog> except using bundled stuff 18:35 <@Betelgeuse> Elvanor: We don't use jarjar but the system classes 18:35 <@Betelgeuse> Elvanor: Adding new ant-* pkgs is not a problem 18:35 <@Elvanor> System classes? 18:35 <@Betelgeuse> Elvanor: System installed copies of .class files 18:35 <@Elvanor> Well the problem here is not with system classes 18:36 <@Elvanor> I think it's pulling some versions of asm jars conflicting with other packages 18:36 <@Elvanor> this kind of problems 18:39 <@Betelgeuse> yeah we pretty much ignore that one 18:39 <@Betelgeuse> as no user has hit that one yet 18:39 <@Betelgeuse> JDK 7 and jigsaw can eventually be used to solve it 18:40 <@Elvanor> jigsaw ? 18:40 <@Elvanor> let me google that 18:41 <@Betelgeuse> Elvanor: just go through the openjdk page 18:42 <@Betelgeuse> We should add a walker check to the eclass 18:42 <@Betelgeuse> It's quite easy to do 18:42 <@Betelgeuse> Walk the to be installed package.env to make sure it doesn't pull in multiple slots 18:42 <@Betelgeuse> Sometimes this is valid of course 18:42 <@Betelgeuse> if they have changed the pkg name space 18:43 <@Betelgeuse> Can add new instructions to package.envs to silence those cases (for example antlr comes to mind)
