[jboss-as7-dev] Help adding a native Hibernate 3.x unit test

[Karel Piwko]

Hi Jason,

I had a quite long discussion with productization guys and I think I
really understand the problems with transitive deps now and I do see the
reason of the explicit enumeration.

Maybe I haven't use the correct wording in JIRA, say it this way:

Nobody said that there is a requirement to flatten transitive
dependencies and be explicit for Resolver. No tests using the Resolver
were present at the time the change was done.

As the result, jboss-as-parent contains a definition of the Resolver in
such state it can be never used. If we'd had some tests using Resolver
before, the list of explicit dependencies would have been longer unless
you wanted to delete those tests.

And quite important note:

Resolver does not modify the build classpath anyhow. It's purpose is to
get an artifact available in a (Maven) repository. The most common usage
is to package that artifact as a part of ShrinkWrap created archive,
e.g. to put it into WEB-INF/lib directory and so it becomes available
during tests on server side.

Karel


On Tue, 2011-07-26 at 10:11 -0400, Jason Greene wrote:
> 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 at 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/impl-maven/pom.xml
> > 
> > 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev