Hi Andreas
I don't know if my practice is "best", but I certainly advise you to unpack to
the ${project.build.directory}, since
a) it's deleted during clear
b) you don't want to mess up your source directories, especially if you use SCM
And yes, you then need the buildhelper.
However, reading your message makes me wonder why you're unpacking a dependency
at all. I don't know your use case, but if you use the resources, you could
just load them from the classpath.
Best regards,
Eric
-----Ursprüngliche Nachricht-----
Von: Andreas Sewe [mailto:[email protected]]
Gesendet: Dienstag, 8. Juni 2010 10:55
An: Maven Users List
Betreff: Maven Best Pratices: Where to place generate re(sources)?
Hi all,
I have a project which uses dependency:unpack to grab Java sources as
well as some binary resources from a JAR. The Java sources thus
"generated" have then to be compiled, the binary resources must simply
wind up in the project's artifact.
At the moment, I unpack the Java sources into
${project.build.sourceDirectory} and the resources into
src/main/resources in the generate-sources and generate-resources
phases, respectively. This setup, however, has one disadvantage: neither
the source nor resource directories are cleaned when in the clean
lifecycle phase. But this is desirable for generated (re)sources. Of
course, I can configure the m-clean-p appropriately, but the less
configuration the better, right?
So, what are best practices to handle a situation like this? Should I
rather unpack the (re)sources to a directory somewhere below
${project.build.directory}? (This is what dependency:unpack does by
default, after all.) But this would require use of the buildhelper-m-p,
for otherwise the unpacked sources won't be picked up by the compiler. :-(
Any advice?
Andreas Sewe
---------------------------------------------------------------------
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]
