I'm sorry ,maybe its just because I'm pre-coffee, but I don't really
understand what you are referring to.
process-[test-]resources copies with targetPath to
target/[test-]classes, which is added to the classpath. So it should all
be correct.
I assume you are talking about modifying the manifest Class-Path: entry
in the JAR plugin, which you can do either by:
a) filtering the manifest (this is already possible using normal
filters, it has nothing to do with the JAR plugin)
b) using ${project.*} variables or others in the manifest elements on
the jar plugin configuration.
- Brett
On 3/08/2006 12:04 AM, David J. M. Karlsen wrote:
Hi list!
We have resource scoping today with the //build/resources and
//build/testresources elements - this is OK for stuff that's supposed to
end up in the archived artifact.
(yes - I am aware that a different targetPath may be specified - but
these directories won't be added to the surefire classpath when
executing the tests).
Very often one wants to have some other resources (typically
configuration) added to the classpath when running tests / execution in
a procution environment.
What do you guys think is the most appropiate approach to this?
1. automatically add [test]resources with a targetPath element to the
surefire classpath?
2. add filtering to the jar plugin?
3. Add ability to append to surefire's classpath manually (See
http://jira.codehaus.org/browse/MSUREFIRE-153).
It could also be solved by adding the targetPaths to the manifest's
classpath entries - but solving it this way will require the
resource/config directory to have the same name in all environments.
WDYT?
Regards,
David
--
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
