On Mon, 2015-08-10 at 12:56 +0200, Konrad Windszus wrote: > Hi Robert, > thanks for your comments on that. > > > On 10 Aug 2015, at 12:21, Robert Munteanu <[email protected]> > > wrote: > > > > On Fri, 2015-08-07 at 15:04 +0200, Konrad Windszus wrote: > > > Actually this does also affect sling-mocks IMHO (please compare > > > with > > > https://issues.apache.org/jira/browse/SLING-4932 < > > > https://issues.apache.org/jira/browse/SLING-4932>;). Therefore I > > > suggest to also do the embedding in sling-mocks ( > > > https://issues.apache.org/jira/browse/SLING-4934 < > > > https://issues.apache.org/jira/browse/SLING-4934>;). > > > Usually in our projects we have one big dependency management > > > section > > > reflecting the actual versions being running in Apache Felix > > > (i.e. > > > the runtime version). This may be newer versions than the ones > > > sling > > > -mocks is using. Unfortunately the dependency management does > > > also > > > affect the transitive dependencies of sling-mock at run-time > > > (i.e. > > > while executing the tests). > > > Anything speaks against embedding all transitive dependencies > > > there? > > > > I don't think there's a problem with embedding the dependencies > > here. > > > > Two questions related to your patch: > > > > 1. Is there a way to ensure that we embed the same versions? I > > think > > that if we use sling-mock and sling-mock-oak for instance, and they > > embed different versions we will get classpath clashes. Maybe we > > could > > set up some IT projects where this gets verified… > > > Yeah, very true. Especially if we would pass classes around being > embedded by both JARs like ResourceResolverFactory or SlingRepository > from ResourceResolverTypeAdapter. > Unfortunately I don’t have a very good idea on how to check that with > an IT. Probably at least the Sling API should never be embedded, as > that will for sure clash. > Do you have any idea, on how we could test that sufficiently?
Not really. It _might_ be enough to run the tests in the sling-mock -jackrabbit and sling-mock-oak tests, as those would pull in the sling -mock module. > > > 2. Why did you set createDependencyReducedPom = false? IIUC this > > means > > that some depending on sling-mock will pull in transitive > > dependencies > > in the classpath anyway. > > Yes, that is true. But when I enable that the dependency-reduced > -pom.xml is generated without the Apache License Header and therefore > the apache-rat-plugin does complain. > I could disable the check of the apache-rat-plugin but that would > mean, we would deploy a pom.xml without a Apache License Header to > Maven Central (and I am not sure this is allowed). > Also I didn’t have any problems with the transitive dependencies. > How did you solve that for sling-mock-oak? I guess I did not :-) But indeed this could be problematic when distributing the pom file ( both on Maven central and on dist.apache.org ). I noticed that I don't need a dependency-reduced-pom for Jackrabbit, since the embedded dependencies actually come from the org.apache.sling.commons.testing module. That's one possibility that we can consider. Alternatively we can look into altering the dependency -reduced-pom.xml to have a license header. Robert > > > > > Thanks, > > > > Robert > > > > > Konrad > > > > > > > On 11 Jun 2015, at 16:43, Stefan Seifert < > > > > [email protected]> > > > > wrote: > > > > > > > > hello robert. > > > > > > > > to clarify for the others, this does not affect the "primary > > > > mocks" > > > > jcr-mock and sling-mock, but only if you want to use one of the > > > > (more experimental) mocks with real repository underneath, > > > > namely > > > > sling-mock-jackrabbit and sling-mock-oak. for most usecases the > > > > resourcresolver-mock or jcr-mock will suffice and has not this > > > > problem. > > > > > > > > but if a real repository like oak or jackrabbit is required one > > > > hits the problem as described by robert. > > > > > > > > 1+2 are real no options, 3 is quite inconvenient and > > > > complicates > > > > code coverage checks a lot. > > > > > > > > yes, embedding the oak/jackrabbit dependencies in the sling > > > > -mock > > > > -jackrabbit/sling-mock-oak artifacts could be a good option. > > > > the > > > > only small drawback i see is the bloating of the JAR file. > > > > perhaps > > > > we should give it a try. > > > > > > > > stefan > > > > > > > > > -----Original Message----- > > > > > From: Robert Munteanu [mailto:[email protected]] > > > > > Sent: Wednesday, June 10, 2015 5:08 PM > > > > > To: Sling Dev > > > > > Subject: Sling JCR Mocks, testing dependencies and imported > > > > > ranges > > > > > > > > > > Hi, > > > > > > > > > > I'm starting to be very much convinced that the Sling Mocks > > > > > are > > > > > the > > > > > simplest way to add fast, repository and OSGi-enabled tests. > > > > > Since they > > > > > are executed out-of-container, they can live in the same > > > > > module > > > > > as the > > > > > code under test. > > > > > > > > > > One conflict that I found with this approach is that while > > > > > the > > > > > Sling > > > > > JCR mocks - namely JCR_JACKRABBIT and JCR_OAK - require > > > > > recent > > > > > versions > > > > > of jackrabbit ( api, commons ), while we typically aim to > > > > > keep > > > > > the > > > > > dependency versions as low as possible. One example is the > > > > > recent > > > > > change I added to the jcr.contentloader module [1], bumping > > > > > the > > > > > jackrabbit-api version from 2.2.0 to 2.10.1 (!). > > > > > > > > > > I have considered various approaches, but none of them looks > > > > > good. > > > > > > > > > > 1. Declaring two dependencies with different scopes - used to > > > > > work with > > > > > Maven 3, no longer works with Maven 2. > > > > > 2. Just live with the more strict import range - a bad idea > > > > > to > > > > > restrict > > > > > bundles from running on older versions just because the tests > > > > > need new > > > > > versions. > > > > > 3. Split the tests in a different module - defies the purpose > > > > > of > > > > > having > > > > > the tests live with the code under test > > > > > 4. Manually set the import-package versions in the pom.xml > > > > > file - > > > > > manual and error-prone > > > > > > > > > > Hm ... writing this email I just got the idea of the JCR > > > > > mocks > > > > > packaging all dependencies using the maven-shade-plugin [2] > > > > > so > > > > > that the > > > > > actual dependencies used for testing are not the ones used at > > > > > compile > > > > > time and implicitly not the ones used to calculate > > > > > dependencies. > > > > > > > > > > This means that for instance org.apache.sling.testing.sling > > > > > -mock > > > > > -oak > > > > > will embed all of oak and the dependendent jackrabbit apis. > > > > > > > > > > Thoughts? Alternatives? > > > > > > > > > > Thanks, > > > > > > > > > > Robert > > > > > > > > > > [1]: > > > > > http://svn.apache.org/viewvc?view=revision&revision=r1684450 > > > > > [2]: https://maven.apache.org/plugins/maven-shade-plugin/ > > > > > >
