see comments inline.
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.
If you want to make it super fast, you can enforce it to work in offline
If you want to ensure it won't pollute your build repository, you can
point it to completely different local repository.
If its easy, clean, fast to use the ShrinkWrap maven resolver, That
sounds like the best solution (rather than having multiple versions of
the same artifact in the build).
The biggest advantage w.r.t. using jar stored in filesystem is that it
can resolve transitive dependencies if you want it to do so.
On 07/14/2011 06:59 PM, Stuart Douglas wrote:
> 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.
That sounds encouraging for what I want to do...
> 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
>>> it's implemented, but trying to resolve via maven during each test run
>>> would probably slow down things a bit, isn't it?
I don't know the ShrinkWrap internals either. It really depends on the
implementation and whether it uses the local maven repo.
MavenDependencyResolver is using Aether, which is a repository
abstraction used in Maven as well. Yes, it does use a local repository
and it is able to recycle most of the configuration either in
settings.xml or pom.xml.
>>> 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
I'm not sure what you mean by #2.
>> #3 Nexus repo is down/can't be resolved/can't be accessed/...
If the repo is down, we won't make it to run the AS7 testsuite. We will
fail during the build (unless we aren't clearing the local maven repo
and we might then get lucky for the test case also).
>> #4 ¤%"%#¤%"¤&"!%"!#¤%!"#!
>> and having a Maven resolver running in the testsuite is just asking for
>> Just add the needed .jar's to the testsuite/ - we already have examples of
>> Best regards,
>> jboss-as7-dev mailing list
> jboss-as7-dev mailing list
jboss-as7-dev mailing list