[jboss-dev] fix AS trunk testing on windows

[Alexey Loubyansky]

What I have at this point is a hack, which is create 
testsuiteclasspath.jar in the maven repo (I found it easier to generate 
paths relative to the maven repo root dir for the manifest Class-Path) 
which is not a good choice.

<manifestclasspath property="manifest.classpath" 
jarfile="${user.home}/.m2/repository/testsuiteclasspath.jar">
   <classpath>
     <pathelement location="${build.classes}"/>
     <pathelement location="${build.resources}"/>
     <pathelement location="${build.resources}/security"/>
     <path refid="tests.classpath"/>
   </classpath>
</manifestclasspath>


I guess the testsuite dir would be better? But then the trick is to 
generate the paths (just changing the jarfile value won't work, of course).

On 3/4/2010 11:30 PM, Jason T. Greene wrote:
> Ok, yeah the reason this has only started blowing up recently is that
> now all thirdparty jars are referenced from the maven repo, which
> defaults to the users home directory. This is a really long path, and
> asking users to relocate their repo is just not reasonable.
>
> So yeah I think your fix is the only real solution. All of the junit
> targets should generate a temp jar that contains the classpath and refer
> to it instead.
>
> If you have this already, can you just commit it?
>
> Jason T. Greene wrote:
>> I'll look into this.
>>
>> Alexey Loubyansky wrote:
>>> It currently isn't working (e.g. one-test target) since the classpath is
>>> too long. To work around the issue, a manifest-only jar has to be
>>> created which would reference all the jars and dirs. Can we fix testing
>>> this way?
>>> This is what I am doing on my laptop at the moment.
>>>
>>> Thanks,
>>> Alexey
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
>>
>
>