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.
For the alternate test sub module, would the right directory structure
be as7/testsuite/hibernate3?
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