Re: [infinispan-dev] Uber jars testing
How about changing the Log interfaces in the modules to not extend the
core Log interface, would that help?
About all the logging frameworks, I suspect log4J may be the only one
that we don't need in the uber jars - since it's always used through a
jboss-logging/commons-logging/slf4j facade.
Cheers
Dan
On Wed, Dec 16, 2015 at 2:31 PM, Sebastian Laskawiec
<slaskawi(a)redhat.com> wrote:
When I was adjusting Uber Jars content I hit the same problem a
couple of
times.
Currently we have almost all logging frameworks and facades in uber jars
(Log4J, SLF4J, commons-logging, JBoss Logging). So in my opinion we need a
long term solution to handle this (probably it would be better to discuss
that in a separate email thread).
How about *not* relocating JBoss Logging? Would it solve the problem?
Thanks
Sebastian
On Tue, Dec 15, 2015 at 3:38 PM, Jiri Holusa <jholusa(a)redhat.com> wrote:
>
> Hi,
>
> I'm reopening this thread, because I want to share some ideas we gone
> through the past weeks. Just as a remainder, we've been exploring a way how
> to run the whole Infinispan testsuite with uber jars, giving us a real
> confidence in uber jars.
>
> I've been experimenting with this a lot (actually only with one module -
> core) and I was able to run the testsuite with uber jars. However, there are
> some changes needed and the base cause is [1], please see Jakub's comment
> with detailed explanation. Long story short, the thing is that two instances
> of jboss-logging are present on classpath.
>
> So the process I went through is:
> 1) build ISPN with exclusion of jboss-logging from uber jars
> 2) change dependency in core/pom.xml from infinispan-commons to
> infinispan-embedded
> 3) run the testsuite of core
>
> The thing is that I have to remove the jboss-logging from uber jars
> because of [1] and hence I'm asking. Do you think that there is a
> possibility how to solve this issue? To be honest, I don't really see a way.
> Logically, the jboss-logging has to be in the uber jar, since this is its
> primary purpose (to reduce number of dependencies for user to add and
> Infinispan needs it) and it also has to be present in core/pom.xml because
> ISPN uses it extensively and without it, the core will not compile.
>
> Let me enhance the question. Do you think [1] could be somehow solved, so
> we wouldn't have to do this manual hack?
>
> Thanks,
> Jiri
>
> [1] https://issues.jboss.org/browse/ISPN-5193
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev