Open jamiejackson opened 1 year ago
Yeah a logger would be cool, probably would offer some mild perf improvements over the many System.out.println
calls that are currently in there.
The shaded jar is because we add ourselves to the classpath, and probably the luceedebug.*
package won't conflict with anybody, but com.google.*
or whatever will. So we shade the dependencies; hence there is really only a shaded jar, no notion of a "slim build".
Ostensibly adding anything to the gradle dependencies as an implementation
dependency (as in, not a compile
dependency, and maybe there's other non-implementation dependency types too) should automagically get included/shaded as appropriate, and then Just Work at runtime.
Adding additional java files to any package other than coreinject
shouldn't offer any friction; adding java files to coreinject
will compile fine but then has a reasonable chance of running into classloader issues as it fights with OSGi at runtime. This sort of mimics Lucee's own architecture, in the difference between "loader" and "core" (hence the name coreinject).
Okay, that's what I thought the intention was, based on comments. However, the symptom I had seemed to point to the logging libs being stripped out, despite having had them specified as implementation
dependencies.
When I get a chance, I'm going to sanity-check that it's the shaded jar (not the slim jar) that ultimately gets placed in the build directory.
While troubleshooting, I wanted some extra logging in the Agent, so I thought I'd implement a logger. I was having trouble at integration time (missing classes) and I realized that the packaging process was stripping out the logging libraries.
I didn't spend a lot of time trying to figure out the gradle tasks, but I didn't grok the packaging tasks and how the shaded vs non-shaded jar placement was intended to work. (It kinda looked like the intention was to ultimately place the shaded jar, but maybe not?)
So two questions: