I suspect what Romain is pointing out is we already have things like openejb-derby, openejb-hsql and openejb-cxf. No way at this point to use "openejb-cxf" to imply a shaded or patched version of CXF without it conflicting with the existing openejb-cxf module where the CXF integration code lives.
As far as where the shaded project lives, I'm cool with whatever as long as it doesn't: - break Intellij so we can still compile with a plain Intellij import and not having to go through any magic to compile/run - break the maven-assembly-plugin and pull the binaries twice - require us to ping/pong the shaded module in and out of the build We used to have the shaded javaee-api jar in the build, but we only pulled it in when one of the jars needed to be patched. The result was we were randomly adding it and then on those releases we'd need to remember to kill it afterwards and it actually made the release process way harder -- one person adding something to the build that some other person would have to remember to clean up. No fun. In or out, I'm fine with either as long as we stick to it. -David On Dec 10, 2013, at 10:15 AM, Romain Manni-Bucau <[email protected]> wrote: > Exactly why i would like to avoid it, ls quartz*. That's what is expected > (from me at least). This is smoother to compare with released versions IMO > Le 10 déc. 2013 17:43, "AndyG" <[email protected]> a écrit : > >> The name 'openejb-quartz-shade' just keeps it nice in a directory listing >> (i.e. All openejb jars together) >> >> >> >> -- >> View this message in context: >> http://openejb.979440.n4.nabble.com/Quartz-next-tp4666498p4666656.html >> Sent from the OpenEJB Dev mailing list archive at Nabble.com. >>
