Re: Quartz, next

2013-12-12 Thread AndyG
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

Re: Quartz, next

2013-12-12 Thread AndyG
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:

Re: Quartz, next

2013-12-11 Thread AndyG
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

Re: Quartz, next

2013-12-11 Thread AndyG
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

2013-12-11 Thread Romain Manni-Bucau
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

Re: Quartz, next

2013-12-11 Thread David Blevins
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

Re: Quartz, next

2013-12-10 Thread AndyG
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

Re: Quartz, next

2013-12-10 Thread Romain Manni-Bucau
+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:

Re: Quartz, next

2013-12-10 Thread Romain Manni-Bucau
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

Re: Quartz, next

2013-12-10 Thread David Blevins
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

Re: Quartz, next

2013-12-05 Thread Mark Struberg
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

Re: Quartz, next

2013-12-05 Thread Romain Manni-Bucau
: 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

Re: Quartz, next

2013-12-04 Thread Jean-Louis MONTEIRO
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

Re: Quartz, next

2013-12-04 Thread Romain Manni-Bucau
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

Re: Quartz, next

2013-12-04 Thread David Blevins
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

Re: Quartz, next

2013-12-03 Thread Romain Manni-Bucau
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