9 a.m.
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
11 a.m.
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
--
Jason T. Greene
JBoss, a division of Red Hat
4:30 p.m.
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
--
Jason T. Greene
JBoss, a division of Red Hat
5:11 p.m.
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
>
>
7:24 a.m.
I couldn't find a way to convert all the paths to relative paths using
purely build.xml. So, I wrote a small Java class that does the
conversion and which is called from ant.
Now, it generates a testsclasspath.jar in testsuite and the test targets
work.
The problem with this is that if there is no relative path from
testsuite to the local maven repository it won't work (e.g. they are on
different hard drives).
Any other ideas to fix it?
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
>
>
5362
days inactive
5403
days old
jboss-development@lists.jboss.org
4 comments
2 participants
participants (2)
-
Alexey Loubyansky -
Jason T. Greene