Thanks for your reply, Stephen. "On a hiding to nothing" - that's not an expression I'm familiar with, but I can guess it isn't a harbinger of good news. :-(
Actually, though, you're wrong about the VPATH being a substitute for Version Control (although it may have started that way). This use of VPATH is almost entirely directed at SUPPORTING the ancient Version Control system that the organization uses: For the developer we might have a 3-element vpath like: path-to-developer-workspace/path-to-version-controlled-code-revised-from-baseline/path-to-baselined-code whereas the automated build would just have the last two elements. If code has not been changed from the baseline, it will not be in path-to-version-controlled-code-revised-from-baseline, so vpath is necessary in this system to pull in baselined code. Typically the developer will run a command to pull down the latest code from version control whether baselined or not, so vpath is actually irrelevant to his use of the build process: nothing will not be in his node. But if should delete a file from his node, it will be picked up from the other nodes. (It follows from this that deleting files is a somewhat difficult process! but I digress). In any case, maintaining the existence of the current version control and build system is the main reason we need to maintain the VPATH. Anyway, in regard to your point about pom.xml, you are right, it would need to exist in the top node. But that would not be that hard to do. It seems that I would have to run some sort of preprocess that would resolve the vpath tree: 1) just pull down the code from all the nodes first, as the developer does. or 2) create some god-awful process to create a parallel directory of symbolic links under one tree that point to each source code file wherever it may be found. ==================================================================================== Stephen Connolly <[email protected]> wrote So I think you are on a hiding to nothing with regards to VPATH support. Let's take the use case where your VPATH=/tmp/n1:/tmp/n2 If I have /tmp/n2/pom.xml and /tmp/n2/src/main/java/com/lucent/Foo.java proper VPATH support would mean that I could do $ cd /tmp/n1 $ mkdir -p src/main/java/com/lucent $ cp /tmp/n2/src/main/java/com/lucent/Foo.java src/main/java/com/lucent/ and the the VPATH support would mean that in /tmp/n1 Maven would pick up the pom.xml as being from /tmp/n2 but to be used in /tmp/n1 It seems to me that VPATH was really a feature added to make working without a SCM possible. With a good SCM I would never need the VPATH feature at all. The best you could do is have VPATH support for non-pom.xml files but users will still need to propagate the pom.xml files to the "current" VPATH node --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
