It's not obvious to me how manifestclasspath helps, here, but as for the use
case ...
I'd like to transform a "local" Junit test command (under Netbeans) so that I
can run a test, without Netbeans, on another machine. Specifically, I'd like to
effectively execute the following command, generated by Netbeans:
Execute:Java13CommandLauncher: Executing '/files/jdk1.6.0/jre/bin/java'
with arguments:
'-classpath'
'<path1>/<jar1>.jar:
<path2>/<jar2>.jar:
<path3>/classes:
<netbeansPath>/modules/ext/junit-3.8.1.jar:
<netbeansPath>/ant/lib/ant-launcher.jar:
<netbeansPath>/ant/lib/ant.jar:
<netbeansPath>/ant/lib/ant-junit.jar'
'org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner'
'<packageName>.<testName>'
'filtertrace=true'
'haltOnError=false'
'haltOnFailure=false'
'showoutput=true'
'formatter=org.apache.tools.ant.taskdefs.optional.junit.BriefJUnitResultFormatter'
on another host (testHost) without Netbeans (but with Java, of course).
Therefore, I'd like to recreate the test environment on testHost by essentially
zipping up all the components of the JUnit classpath (above) and then re-parent
them under a common root so that I can reconstruct the command line on
testHost. For example, assuming I can un/zip and re-parent the required
jar/class files on testHost, I should then be able to run the following command
line:
'/files/jdk1.6.0/jre/bin/java'
'-classpath'
'<newRoot>/<path1>/<jar1>.jar:
<newRoot>/<path2>/<jar2>.jar:
<newRoot>/<path3>/classes:
<newRoot>/<netbeansPath>/modules/ext/junit-3.8.1.jar:
<newRoot>/<netbeansPath>/ant/lib/ant-launcher.jar:
<newRoot>/<netbeansPath>/ant/lib/ant.jar:
<newRoot>/<netbeansPath>/ant/lib/ant-junit.jar'
'org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner'
'<packageName>.<testName>'
'filtertrace=true'
'haltOnError=false'
'haltOnFailure=false'
'showoutput=true'
'formatter=org.apache.tools.ant.taskdefs.optional.junit.BriefJUnitResultFormatter'
So, ideally, what I want is the ability to:
- zip up the individual components of the ${run.test.classpath} property under
NetBeans (jars and class directories) under a new "root" directory
- modify the the ${run.test.classpath} to pre-pend the new "root" to the path
elements
- generate a script/file with the command line to run
Make sense?
----- Original Message ----
From: Dominique Devienne <[EMAIL PROTECTED]>
To: Ant Users List <user@ant.apache.org>
Sent: Wednesday, October 17, 2007 9:32:25 AM
Subject: Re: Re-parenting classpath
On 10/16/07, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Hopefully, someone can point me in the right direction. What I'd like
to do is re-parent the elements of a classpath entry in an Ant build
script (from netbeans). For example, given classpath property like:
>
> Setting project property: run.test.classpath ->
>
../lib/a.jar:../lib/dir1/b.jar:../lib/dir2/c.jar:build/classes:build/test/classes
>
> I'd like to zip up the classpath components from their current
locations, but then re-parent them within the zip file so that they get
extracted to the following layout:
>
> a.jar
> b.jar
> c.jar
> classes
>
> The jar file names should be unique, so I'm not too worried about
name clashes with the jar files. Being new to Ant I don't see an easy way
to get this done with the existing Ant tasks (pathconvert, basename,
zip, etc.). So, I'm hoping someone can tell if it can be done (and how)
or if there's some custom Ant task that already handles this
functionality.
<manifestclasspath> can do that, indirectly. You're not saying why the
re-parenting, but the only use-case I know of is having a in-manifest
relative CP in a jar, which is the purpose of this task. You only get
a string out of it though, which may not be what you need. Hard to say
though given your post. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
