On Mon, Jul 11, 2011 at 10:02 AM, Simone Tripodi <simonetrip...@apache.org> wrote: > Hi Matt, > it sounds indeed reasonable, thanks for your feedbacks! > Moreover what is you are suggesting is what we did in BVAL...
Yes, exactly like bval... :) > Do you see any risk on splitting current Discovery project structure > in multi module? I honestly am not that familiar with [discovery] per se. I have wondered if it is still relevant in a Java 6 environment with java.util.ServiceLoader making convenient the exploration of service impls provided by META-INF/services/* resources. I realize [discovery] uses other mechanisms as well, but do they continue to be necessary? Matt > Many thanks in advance, have a nice day! > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Mon, Jul 11, 2011 at 4:54 PM, Matt Benson <gudnabr...@gmail.com> wrote: >> On Mon, Jul 11, 2011 at 9:28 AM, Simone Tripodi >> <simonetrip...@apache.org> wrote: >>> Hi all guys, >>> lately in my projects I've been frequently repeating the pattern >>> described in [1], so, to avoid useless c'n'p I would propose to >>> provide an already compiled module that makes easier the Google Guice >>> integration with Discovery. >>> Google Guice could be provided as a 'optional' or 'provided' >>> dependency, since it wouldn't be part of the core functionalities. >>> WDYT? Do you see any problem if I add such class? >>> Thanks in advance for any feedback, have a nice day! >>> Simo >>> >> >> FWIW, my personal preference for integration with non-ASF code would >> be the admittedly cumbersome multi-module project approach. >> >> Matt >> >>> [1] http://s.apache.org/Nai >>> >>> http://people.apache.org/~simonetripodi/ >>> http://www.99soft.org/ >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
