Hi, I'd like to hack together a unit test that packages a 3.6.x version of Hibernate and references a class that only lives in 3.6.x (not in Hibernate 4.0). Is there anything built directly into Arquillian for obtaining a test jar from an external repo? I assume not but wanted to ask anyway. :) Just looking for the simplest way to handle this test. Thanks, Scott _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

There is a Maven extension to ShrinkWrap, see usage: https://github.com/shrinkwrap/shrinkwrap/blob/master/extension-resolver/i... -aslak- ----- Original Message ----- > You want to use MavenDependencyResolver, I can't find an example right > now, but I know Aslak has one. > > On 28 Jun 2011, at 14:52, Scott Marlow wrote: > >> Hi, >> >> I'd like to hack together a unit test that packages a 3.6.x version >> of >> Hibernate and references a class that only lives in 3.6.x (not in >> Hibernate 4.0). >> >> Is there anything built directly into Arquillian for obtaining a >> test >> jar from an external repo? I assume not but wanted to ask anyway. :) >> >> Just looking for the simplest way to handle this test. >> >> Thanks, >> Scott >> >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

I was writing a similar testcase sometime back which required a jar to be added to the deployment. But I wasn't too sure if it was a good idea to use the Maven resolver within the testcase. I haven't looked into how it's implemented, but trying to resolve via maven during each test run would probably slow down things a bit, isn't it? On Thursday 14 July 2011 08:17 PM, Scott Marlow wrote: > Can someone help bring in the Maven extension to ShrinkWrap in AS7.1 > testsuite? I wanted to ask, before trying to hack it on my own. I > think this would help us create better and more complete tests.

That scenario is possible with any maven artefact that the built relies on. AFAIK the ShrinkWrap maven resolver will use the version cached in the local repository, so it is no different to any other maven dependency.

Stuart On 15/07/2011, at 4:16 AM, Jesper Pedersen wrote: > On Thursday, July 14, 2011 02:09:40 PM Jaikiran Pai wrote: >> I was writing a similar testcase sometime back which required a jar to >> be added to the deployment. But I wasn't too sure if it was a good idea >> to use the Maven resolver within the testcase. I haven't looked into how >> it's implemented, but trying to resolve via maven during each test run >> would probably slow down things a bit, isn't it?

>> >> On Thursday 14 July 2011 08:17 PM, Scott Marlow wrote: >>> Can someone help bring in the Maven extension to ShrinkWrap in AS7.1 >>> testsuite? I wanted to ask, before trying to hack it on my own. I >>> think this would help us create better and more complete tests. > > Please, no. > > I see this: > > #1 Code gets committed > #2 You/Jenkins update

> #3 Nexus repo is down/can't be resolved/can't be accessed/...

> #4 ¤%"%#¤%"¤&"!%"!#¤%!"#! > > and having a Maven resolver running in the testsuite is just asking for > trouble. > > Just add the needed .jar's to the testsuite/ - we already have examples of > this. > > Best regards, > Jesper > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

Hi All, see comments inline. Karel On Fri, 2011-07-15 at 01:19 -0400, Scott Marlow wrote: > We already include org.hibernate:hibernate-core:jar:4.0.0.Beta1 and I > want to test against org.hibernate:hibernate-core:jar:3.6.4.Final. > > It is possible that the org.hibernate:hibernate-core:jar:3.6.4.Final > artifact will not be in the local maven repo, when the unit test starts. > If the ShrinkWrap maven resolver would download it into the local > maven cache, we should get good enough performance (similar to if the > artifact was downloaded during the build). > MavenDependencyResolver will act exactly that way, if the local repository contains the artifact, it will be fetched from there, if not remote repositories will be touched.

On 07/15/2011 08:50 AM, Karel Piwko wrote: > Hi All, > > see comments inline. > > Karel > > On Fri, 2011-07-15 at 01:19 -0400, Scott Marlow wrote: >> We already include org.hibernate:hibernate-core:jar:4.0.0.Beta1 and I >> want to test against org.hibernate:hibernate-core:jar:3.6.4.Final. >> >> It is possible that the org.hibernate:hibernate-core:jar:3.6.4.Final >> artifact will not be in the local maven repo, when the unit test starts. >> If the ShrinkWrap maven resolver would download it into the local >> maven cache, we should get good enough performance (similar to if the >> artifact was downloaded during the build). >> > MavenDependencyResolver will act exactly that way, if the local > repository contains the artifact, it will be fetched from there, if not > remote repositories will be touched. I tried calling "DependencyResolvers.use(MavenDependencyResolver.class).artifact("org.hibernate:hibernate-core:3.6.5.Final").resolveAs(GenericArchive.class)" from an existing AS7 testsuite test but got a CNFE on class org.sonatype.aether.resolution.ArtifactResolutionException. as7/tools/maven/lib/aether-api-1.9.jar seems to have this class. Which pom.xml do I need to update for ShrinkWrap to have access to aester api? Thanks, Scott

Hi Karel, Thanks for the answer. I noticed that the [1] link is not valid. Does that reflect a different solution taking place perhaps? Or should I not read into that? ;) Do you have a new link that I should take the dependencies from? Also, which AS7 project/module should have its dependencies updated, to work around this (the as7/testsuite project?). Scott On 07/26/2011 09:12 AM, Karel Piwko wrote: > Hi Scott, > > this is likely caused by too strict exclusions in jboss-as-parent. As a > workaround, you have to enumerate all dependencies from [1] directly in > the project/module where you want to use the resolver. > > This was caused by https://issues.jboss.org/browse/AS7-954, I filed > https://issues.jboss.org/browse/AS7-1403 to track the problem. > > Karel > > [1] > https://github.com/shrinkwrap/shrinkwrap/blob/master/extension-resolver/i... > > On Mon, 2011-07-25 at 15:51 -0400, Scott Marlow wrote: >> On 07/15/2011 08:50 AM, Karel Piwko wrote: >>> Hi All, >>> >>> see comments inline. >>> >>> Karel >>> >>> On Fri, 2011-07-15 at 01:19 -0400, Scott Marlow wrote: >>>> We already include org.hibernate:hibernate-core:jar:4.0.0.Beta1 and I >>>> want to test against org.hibernate:hibernate-core:jar:3.6.4.Final. >>>> >>>> It is possible that the org.hibernate:hibernate-core:jar:3.6.4.Final >>>> artifact will not be in the local maven repo, when the unit test starts. >>>> If the ShrinkWrap maven resolver would download it into the local >>>> maven cache, we should get good enough performance (similar to if the >>>> artifact was downloaded during the build). >>>> >>> MavenDependencyResolver will act exactly that way, if the local >>> repository contains the artifact, it will be fetched from there, if not >>> remote repositories will be touched. >> >> I tried calling >> "DependencyResolvers.use(MavenDependencyResolver.class).artifact("org.hibernate:hibernate-core:3.6.5.Final").resolveAs(GenericArchive.class)" >> from an existing AS7 testsuite test but got a CNFE on class >> org.sonatype.aether.resolution.ArtifactResolutionException. >> >> as7/tools/maven/lib/aether-api-1.9.jar seems to have this class. Which >> pom.xml do I need to update for ShrinkWrap to have access to aester api? >> >> Thanks, >> Scott > >

It's not too strict it's explicit which is exactly what we want. History has shown us that transitive deps do more harm than good. My big worry about this resolver is that it is going to pull down conflicts. We definitely want to isolate this kind of thing. Another perhaps better approach would be to just add the hib3 deps to a special test sub module using a test scope.

Sent from my iPad On Jul 26, 2011, at 8:13 AM, Karel Piwko<kpiwko(a)redhat.com> wrote: > Hi Scott, > > this is likely caused by too strict exclusions in jboss-as-parent. As a > workaround, you have to enumerate all dependencies from [1] directly in > the project/module where you want to use the resolver. > > This was caused by https://issues.jboss.org/browse/AS7-954, I filed > https://issues.jboss.org/browse/AS7-1403 to track the problem. > > Karel > > [1] > https://github.com/shrinkwrap/shrinkwrap/blob/master/extension-resolver/i... > > On Mon, 2011-07-25 at 15:51 -0400, Scott Marlow wrote: >> On 07/15/2011 08:50 AM, Karel Piwko wrote: >>> Hi All, >>> >>> see comments inline. >>> >>> Karel >>> >>> On Fri, 2011-07-15 at 01:19 -0400, Scott Marlow wrote: >>>> We already include org.hibernate:hibernate-core:jar:4.0.0.Beta1 and I >>>> want to test against org.hibernate:hibernate-core:jar:3.6.4.Final. >>>> >>>> It is possible that the org.hibernate:hibernate-core:jar:3.6.4.Final >>>> artifact will not be in the local maven repo, when the unit test starts. >>>> If the ShrinkWrap maven resolver would download it into the local >>>> maven cache, we should get good enough performance (similar to if the >>>> artifact was downloaded during the build). >>>> >>> MavenDependencyResolver will act exactly that way, if the local >>> repository contains the artifact, it will be fetched from there, if not >>> remote repositories will be touched. >> >> I tried calling >> "DependencyResolvers.use(MavenDependencyResolver.class).artifact("org.hibernate:hibernate-core:3.6.5.Final").resolveAs(GenericArchive.class)" >> from an existing AS7 testsuite test but got a CNFE on class >> org.sonatype.aether.resolution.ArtifactResolutionException. >> >> as7/tools/maven/lib/aether-api-1.9.jar seems to have this class. Which >> pom.xml do I need to update for ShrinkWrap to have access to aester api? >> >> Thanks, >> Scott > > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

It's not too strict it's explicit which is exactly what we want. History has shown us that transitive deps do more harm than good. My big worry about this resolver is that it is going to pull down conflicts. We definitely want to isolate this kind of thing. Another perhaps better approach would be to just add the hib3 deps to a special test sub module using a test scope. Sent from my iPad On Jul 26, 2011, at 8:13 AM, Karel Piwko <kpiwko(a)redhat.com&gt; wrote: > Hi Scott, > > this is likely caused by too strict exclusions in jboss-as-parent. As a > workaround, you have to enumerate all dependencies from [1] directly in > the project/module where you want to use the resolver. > > This was caused by https://issues.jboss.org/browse/AS7-954, I filed > https://issues.jboss.org/browse/AS7-1403 to track the problem. > > Karel > > [1] > https://github.com/shrinkwrap/shrinkwrap/blob/master/extension-resolver/i... > > On Mon, 2011-07-25 at 15:51 -0400, Scott Marlow wrote: >> On 07/15/2011 08:50 AM, Karel Piwko wrote: >>> Hi All, >>> >>> see comments inline. >>> >>> Karel >>> >>> On Fri, 2011-07-15 at 01:19 -0400, Scott Marlow wrote: >>>> We already include org.hibernate:hibernate-core:jar:4.0.0.Beta1 and I >>>> want to test against org.hibernate:hibernate-core:jar:3.6.4.Final. >>>> >>>> It is possible that the org.hibernate:hibernate-core:jar:3.6.4.Final >>>> artifact will not be in the local maven repo, when the unit test starts. >>>> If the ShrinkWrap maven resolver would download it into the local >>>> maven cache, we should get good enough performance (similar to if the >>>> artifact was downloaded during the build). >>>> >>> MavenDependencyResolver will act exactly that way, if the local >>> repository contains the artifact, it will be fetched from there, if not >>> remote repositories will be touched. >> >> I tried calling >> "DependencyResolvers.use(MavenDependencyResolver.class).artifact("org.hibernate:hibernate-core:3.6.5.Final").resolveAs(GenericArchive.class)" >> from an existing AS7 testsuite test but got a CNFE on class >> org.sonatype.aether.resolution.ArtifactResolutionException. >> >> as7/tools/maven/lib/aether-api-1.9.jar seems to have this class. Which >> pom.xml do I need to update for ShrinkWrap to have access to aester api? >> >> Thanks, >> Scott > > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev