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.
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
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.
>> jboss-development mailing list