[jboss-dev] fix AS trunk testing on windows
Alexey Loubyansky
alexey.loubyansky at redhat.com
Thu Mar 4 18:11:33 EST 2010
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
>>
>>
>
>
More information about the jboss-development
mailing list