Re: [infinispan-dev] Uber jars - how do we want to use them

On Mon 2016-03-14 11:21, Sebastian Laskawiec wrote: > I took a look at Nexus download statistics and Infinispan Uberjars are > about 7% of our downloads (of course this calculation has been based on our > JBoss Nexus instance and we have no data from other mirrors). It's actually the opposite,

Re: [infinispan-dev] Uber jars - how do we want to use them

On Mon, Mar 14, 2016 at 12:21 PM, Sebastian Laskawiec wrote: > I took a look at Nexus download statistics and Infinispan Uberjars are about > 7% of our downloads (of course this calculation has been based on our JBoss > Nexus instance and we have no data from other mirrors).

Re: [infinispan-dev] Uber jars - how do we want to use them

To make a more practical proposal: give me a way to start a local, non transactional Cache which doesn't require any of: - JGroups - JBoss Marshalling - JTA API - Infinispan Commons If I don't have - for example - JGroups and am starting a clustered cache, I will see an exception "Enabling

Re: [infinispan-dev] Uber jars - how do we want to use them

Hi, uber jars were introduced as an answer to complaints such as "there are too many jars" but I still think this was the wrong answer.. too many issues so please stop this: it's not helping usability to understand which jars are needed, and it makes things worse with runtime errors not matching

Re: [infinispan-dev] Uber jars - how do we want to use them

-- Galder Zamarreño Infinispan, Red Hat > On 14 Mar 2016, at 08:42, Tristan Tarrant wrote: > > > > On 11/03/2016 18:20, Galder Zamarreño wrote: >> Are uber jars really that useful? From my own experience they often get > > The number of users who don't use a dependency

Re: [infinispan-dev] Uber jars - how do we want to use them

I took a look at Nexus download statistics and Infinispan Uberjars are about 7% of our downloads (of course this calculation has been based on our JBoss Nexus instance and we have no data from other mirrors). So, once we are clear how Uber Jars should work... let's take a look at one of the

Re: [infinispan-dev] Uber jars - how do we want to use them

On 11/03/2016 18:20, Galder Zamarreño wrote: > Are uber jars really that useful? From my own experience they often get The number of users who don't use a dependency management system (Maven, Ivy, Gradle) is quite a lot higher than you'd expect. Tristan -- Tristan Tarrant Infinispan Lead

Re: [infinispan-dev] Uber jars - how do we want to use them

Are uber jars really that useful? From my own experience they often get more in the way, e.g. clash of dependencies. We can fix our own clashes but once you have other modules creating uber jars users might get more of those clashes.Regardless of that, if we're continue with uber jars, it'd make

[infinispan-dev] Uber jars - how do we want to use them

Hey! Uber jars have been around for quite a while but some old problems are still biting our ankles. The biggest problem is JBoss Logging... But before diving into the technical discussion, I would like to clarify how do we treat Uber Jars and how other (let's call them "extra") modules should

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.

Re: [infinispan-dev] Uber jars testing

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

Re: [infinispan-dev] Uber jars testing

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

Re: [infinispan-dev] Uber jars testing

Sanne, we don't really care about the various JGroups protocols, we use a DISCARD protocol in some tests but it's always just above the transport. Instead, a lot of tests need to block just before/after a certain interceptor. I think there are also tests that we should have, but are missing,

Re: [infinispan-dev] Uber jars testing

+1 Galder for your abstraction, we might even need a DSL. An additional benefit would be that all "API functional tests" could be tested also in conditions such as running in a in a race with topology changes, instrumenting the timing of parallel code and network operations. As a DSL and using

Re: [infinispan-dev] Uber jars testing

-0.1 for Byteman - although generally I am a fan of Byteman, it seems to me that the rules are too fragile, since IDE does not give any hints like "hey, there's a test that inserts some logic to the place you're modifying". IMO, using Byteman regularly will end up with many tests silently

Re: [infinispan-dev] Uber jars testing

- Original Message - > Any plans for tests that are just slightly different for different > configurations? With inheritance, it's simple - you just override the > method. If you just run that test on a huge matrix of configurations, > you end up with having a method with a very

Re: [infinispan-dev] Uber jars testing

Yes I understand, and I also use Byteman only as last resort (sometimes it is). But while it might not be practical to maintain hundreds of tests using it and relying on specific internals - and in different ways - if you have a single general "test runner" which makes use of it you can limit the

Re: [infinispan-dev] Uber jars testing

I agree pretty much with everything below: * We overuse test overriding to run the same test with different configuration. I did that same mistake with the functional map API stuff :( * I'm in favour of testsuite restructuring, but I think we really need to start from scratch in a separate

Re: [infinispan-dev] Uber jars testing

Any plans for tests that are just slightly different for different configurations? With inheritance, it's simple - you just override the method. If you just run that test on a huge matrix of configurations, you end up with having a method with a very complicated switch for certain

Re: [infinispan-dev] Uber jars testing

Interesting subject. We also have many tests which (ab)use inheritance to re-test the same API semantics in slightly different configurations, like embedded/DIST and embedded/REPL, sometimes becoming an @Override mess. It would be far more useful to restructure the testsuite to have such tests in

[infinispan-dev] Uber jars testing

Hi all, we've been thinking for a while, how to test ISPN uber jars. The current status is that we actually don't have many tests in the testsuite, there are few tests in integrationtests/all-embedded-* modules that are basically copies of the actual tests in corresponding modules. We think

Re: [infinispan-dev] Uber jars testing

Hi Jiri, comments inline. On 2.9.2015 10:40, Jiri Holusa wrote: > Hi all, > > we've been thinking for a while, how to test ISPN uber jars. The current > status is that we actually don't have many tests in the testsuite, there are > few tests in integrationtests/all-embedded-* modules that are

Re: [infinispan-dev] Uber Jars

Sounds good to me. I do like the fact that the artifacts have a -all ending, it kinda signals that it’s an Uber jar. This might be handy for users who just look at the list of artifacts in the repository. Alternatively, we could have a group id that signals it, e.g. org.infinispan.all or

[infinispan-dev] Uber Jars

Dear all, on Thursday I issued a PR [1] to introduce Uber Jars, i.e. single jars which wrap our multitude of jars and some of the transitive dependencies, but it was (rightly) pointed out that we should have a little discussion here first. Firstly, I'm using the maven shade plugin which

Re: [infinispan-dev] Uber Jars

On Jun 3, 2014, at 8:53, Tristan Tarrant ttarr...@redhat.com wrote: Dear all, on Thursday I issued a PR [1] to introduce Uber Jars, i.e. single jars which wrap our multitude of jars and some of the transitive dependencies, but it was (rightly) pointed out that we should have a little

Re: [infinispan-dev] Uber Jars

On 3 June 2014 09:57, Mircea Markus mmar...@redhat.com wrote: On Jun 3, 2014, at 8:53, Tristan Tarrant ttarr...@redhat.com wrote: Dear all, on Thursday I issued a PR [1] to introduce Uber Jars, i.e. single jars which wrap our multitude of jars and some of the transitive dependencies, but it

Re: [infinispan-dev] Uber Jars

On 03/06/2014 11:35, Sanne Grinovero wrote: On 3 June 2014 09:57, Mircea Markus mmar...@redhat.com wrote: On Jun 3, 2014, at 8:53, Tristan Tarrant ttarr...@redhat.com wrote: Dear all, on Thursday I issued a PR [1] to introduce Uber Jars, i.e. single jars which wrap our multitude of jars and

Re: [infinispan-dev] Uber Jars

On Tue, Jun 3, 2014 at 1:30 PM, Tristan Tarrant ttarr...@redhat.com wrote: On 03/06/2014 11:35, Sanne Grinovero wrote: On 3 June 2014 09:57, Mircea Markus mmar...@redhat.com wrote: On Jun 3, 2014, at 8:53, Tristan Tarrant ttarr...@redhat.com wrote: Dear all, on Thursday I issued a PR

Re: [infinispan-dev] Uber Jars

On 03/06/2014 16:40, Dan Berindei wrote: On Tue, Jun 3, 2014 at 1:30 PM, Tristan Tarrant ttarr...@redhat.com mailto:ttarr...@redhat.com wrote: On 03/06/2014 11:35, Sanne Grinovero wrote: On 3 June 2014 09:57, Mircea Markus mmar...@redhat.com mailto:mmar...@redhat.com wrote: