Re: [jboss-dev] fix AS trunk testing on windows
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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>
>