Re: Quartz, next
I see what you mean now - As shade only works at the 'package' phase there is no way round this other than to use your approach - An external project dependency. Dammit Andy -- View this message in context: http://openejb.979440.n4.nabble.com/Quartz-next-tp4666498p4666717.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: Quartz, next
You need to enable the 'main' profile in the maven projects view, then the whole world comes in to say hello (takes a while even on a fast machine). Also enable automatic imports in the intellij maven settings. Andy. -- View this message in context: http://openejb.979440.n4.nabble.com/Quartz-next-tp4666498p4666718.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: Quartz, next
So how would we feel with 'openejb-shade-[quartz]' ? And eventually bring all shade jars in line with that naming? I'm happy to do the maven stuff either way. Andy -- View this message in context: http://openejb.979440.n4.nabble.com/Quartz-next-tp4666498p486.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: Quartz, next
I agree. Just checked in for a build something that works for me - We can rename stuff later. Andy. -- View this message in context: http://openejb.979440.n4.nabble.com/Quartz-next-tp4666498p488.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: Quartz, next
Hmm I have not enough time to say no but till try to justify my opinion (i like product-openejb-shade (or shaded)) It really makes diff easy and if product and shade are together by mistake in assemblies you see it quickly sorting by name. Last point for libraries which were not shaded in previous versions it lets the artifact at the same place which makes the transition smoother and avoids issues in pom, assembly.xml, exclusions Now technically all works ;) Le 11 déc. 2013 10:54, AndyG andy.gumbre...@orprovision.com a écrit : I agree. Just checked in for a build something that works for me - We can rename stuff later. Andy. -- View this message in context: http://openejb.979440.n4.nabble.com/Quartz-next-tp4666498p488.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: Quartz, next
On Dec 10, 2013, at 2:40 PM, David Blevins david.blev...@gmail.com wrote: 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 Looks like the trunk/shade/quartz/ setup is no different than the former trunk/deps/ setup. Breaks the IDE so you can't compile or run tests. -David
Re: Quartz, next
Damn, was too late checking this in. The only issue with quartz-openejb-shade was trying to use the quartz version rather than 'omitting' the version so that it resolves to the parent project version (i.e. 4.6.1-SNAPSHOT) - This is how it should be, as we really want to keep control of the shade at build time when we deploy to either a snapshot or release repo. Moving it out of the project completely is IMHO not the way to go as it complicates the build/deploy and release even more. Andy. -- View this message in context: http://openejb.979440.n4.nabble.com/Quartz-next-tp4666498p449.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: Quartz, next
+1 to keep it in the build (in old deps) however on the renaming I think keeping the shade starting with quartz makes it more obvious. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2013/12/10 AndyG andy.gumbre...@orprovision.com: And renaming to openejb-quartz-shade would make sense i.e. produce openejb-quartz-shade-4.6.1-SNAPSHOT.jar -- View this message in context: http://openejb.979440.n4.nabble.com/Quartz-next-tp4666498p451.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: Quartz, next
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 andy.gumbre...@orprovision.com 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-tp4666498p456.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: Quartz, next
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 rmannibu...@gmail.com 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 andy.gumbre...@orprovision.com 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-tp4666498p456.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: Quartz, next
+1 for shading. Always good to prevent classpath clashes without having to provide expensive ClassLoader tricks. The only obstacle is if there is some configuration which needs to be read from a file with a fixed name. LieGrue, strub From: David Blevins david.blev...@gmail.com To: dev@tomee.apache.org Sent: Thursday, 5 December 2013, 2:38 Subject: Re: Quartz, next Trying the shaded approach would certainly be interesting. There's a lot of merit to it if we can work through the obvious issues and test the heck out of it. -David On Dec 3, 2013, at 12:57 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: Ps: forgot another solutuon: shade quartz in org.apache.openejb.quartz Le 2 déc. 2013 22:23, Romain Manni-Bucau rmannibu...@gmail.com a écrit : Hi How do we handle quartz for next releases? It is very often a pain I propose: 1) if in openejb loader use this one 2) if not look for it in tomee/quartz/*.jar and create a loader with it Tomee would use 2 by default Wdyt?
Re: Quartz, next
hopefully it should work now. I didnt check tomee only provides quartz shade but our quartz ra tests are passing (if any volonteer...) Note: I kept org.quartz config in EjbTimerServiceImpl but we should replace it by org.apache.openejb.quartz.* (here again if any volonteer ;). Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2013/12/5 Mark Struberg strub...@yahoo.de: +1 for shading. Always good to prevent classpath clashes without having to provide expensive ClassLoader tricks. The only obstacle is if there is some configuration which needs to be read from a file with a fixed name. LieGrue, strub From: David Blevins david.blev...@gmail.com To: dev@tomee.apache.org Sent: Thursday, 5 December 2013, 2:38 Subject: Re: Quartz, next Trying the shaded approach would certainly be interesting. There's a lot of merit to it if we can work through the obvious issues and test the heck out of it. -David On Dec 3, 2013, at 12:57 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: Ps: forgot another solutuon: shade quartz in org.apache.openejb.quartz Le 2 déc. 2013 22:23, Romain Manni-Bucau rmannibu...@gmail.com a écrit : Hi How do we handle quartz for next releases? It is very often a pain I propose: 1) if in openejb loader use this one 2) if not look for it in tomee/quartz/*.jar and create a loader with it Tomee would use 2 by default Wdyt?
Re: Quartz, next
But, the main objective of shading is to let users embed their own Quartz if I understood without interfering with TomEE internals. So if they embed it, where is the issue? They gonna be able to extend/implement whatever they want to. JLouis 2013/12/3 Romain Manni-Bucau rmannibu...@gmail.com quartz api (interfaces/abstract classes) are sometimes used by users. If we shade we can't use default impl. Not blocking for me, was mainly a warning Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2013/12/3 Jean-Louis MONTEIRO jeano...@gmail.com: Did not get time to dig into, was just my first feeling. Could you elaborate a bit more? Not sure I understood the extension issue? JLouis 2013/12/3 Romain Manni-Bucau rmannibu...@gmail.com The 3rd ;). The issue is we loose all quartz extensions then Le 3 déc. 2013 10:10, Jean-Louis MONTEIRO jeano...@gmail.com a écrit : Maybe the second (shaded) one is easier to manage at first glance. So that is my preferred solution 2013/12/3 Romain Manni-Bucau rmannibu...@gmail.com Ps: forgot another solutuon: shade quartz in org.apache.openejb.quartz Le 2 déc. 2013 22:23, Romain Manni-Bucau rmannibu...@gmail.com a écrit : Hi How do we handle quartz for next releases? It is very often a pain I propose: 1) if in openejb loader use this one 2) if not look for it in tomee/quartz/*.jar and create a loader with it Tomee would use 2 by default Wdyt? -- Jean-Louis -- Jean-Louis -- Jean-Louis
Re: Quartz, next
But no more the tomee one without copying code. (once again not blocking) Le 4 déc. 2013 09:35, Jean-Louis MONTEIRO jeano...@gmail.com a écrit : But, the main objective of shading is to let users embed their own Quartz if I understood without interfering with TomEE internals. So if they embed it, where is the issue? They gonna be able to extend/implement whatever they want to. JLouis 2013/12/3 Romain Manni-Bucau rmannibu...@gmail.com quartz api (interfaces/abstract classes) are sometimes used by users. If we shade we can't use default impl. Not blocking for me, was mainly a warning Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2013/12/3 Jean-Louis MONTEIRO jeano...@gmail.com: Did not get time to dig into, was just my first feeling. Could you elaborate a bit more? Not sure I understood the extension issue? JLouis 2013/12/3 Romain Manni-Bucau rmannibu...@gmail.com The 3rd ;). The issue is we loose all quartz extensions then Le 3 déc. 2013 10:10, Jean-Louis MONTEIRO jeano...@gmail.com a écrit : Maybe the second (shaded) one is easier to manage at first glance. So that is my preferred solution 2013/12/3 Romain Manni-Bucau rmannibu...@gmail.com Ps: forgot another solutuon: shade quartz in org.apache.openejb.quartz Le 2 déc. 2013 22:23, Romain Manni-Bucau rmannibu...@gmail.com a écrit : Hi How do we handle quartz for next releases? It is very often a pain I propose: 1) if in openejb loader use this one 2) if not look for it in tomee/quartz/*.jar and create a loader with it Tomee would use 2 by default Wdyt? -- Jean-Louis -- Jean-Louis -- Jean-Louis
Re: Quartz, next
Trying the shaded approach would certainly be interesting. There's a lot of merit to it if we can work through the obvious issues and test the heck out of it. -David On Dec 3, 2013, at 12:57 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: Ps: forgot another solutuon: shade quartz in org.apache.openejb.quartz Le 2 déc. 2013 22:23, Romain Manni-Bucau rmannibu...@gmail.com a écrit : Hi How do we handle quartz for next releases? It is very often a pain I propose: 1) if in openejb loader use this one 2) if not look for it in tomee/quartz/*.jar and create a loader with it Tomee would use 2 by default Wdyt?
Re: Quartz, next
Ps: forgot another solutuon: shade quartz in org.apache.openejb.quartz Le 2 déc. 2013 22:23, Romain Manni-Bucau rmannibu...@gmail.com a écrit : Hi How do we handle quartz for next releases? It is very often a pain I propose: 1) if in openejb loader use this one 2) if not look for it in tomee/quartz/*.jar and create a loader with it Tomee would use 2 by default Wdyt?
