Mailing-List: contact users-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Users List" <users@maven.apache.org>
Received-SPF: pass (athena.apache.org: domain of
 stephen.alan.connolly@gmail.com designates 74.125.82.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <551AE6A7.1080707@javactivity.org>
References: <551AE6A7.1080707@javactivity.org>
Date: Thu, 2 Apr 2015 08:30:43 +0100
Message-ID: 
 <CA+nPnMwQsi8Ajc-EYmYrjFwRsEZ-Yc9XW1r55Em9VCgBH73YKw@mail.gmail.com>
Subject: Re: Can Maven be used in an nmake environment with VPATH?
From: Stephen Connolly <stephen.alan.connolly@gmail.com>
To: Maven Users List <users@maven.apache.org>
Content-Type: multipart/alternative; boundary=089e013c637437790f0512b8cfe2

--089e013c637437790f0512b8cfe2
Content-Type: text/plain; charset=UTF-8

On 31 March 2015 at 19:25, Steve Cohen <scohen@javactivity.org> wrote:

> The problem is this.  Alcatel-Lucent nmake (and other versions of make
> such as GNU make) includes the concept of the VPATH, an environment
> variable containing a path (similar to PATH, etc.) along which to search
> for dependent source.  If a necessary file is not found along the first
> node of the path, the second is searched for it, then the third, etc. Only
> if the full VPATH is exhausted is the dependency not satisfied and the
> build fails.  Importantly, if the dependency IS satisfied, then nodes
> further down the path are not looked at for that dependency.
>
> There is a little tutorial here, explaining how this works:
> http://nmake.alcatel-lucent.com/tutorial/s10.html
>
> Needless to say, this is not the way Maven works, especially the compiler
> plugin, certainly not under default settings.  There is the sourcepath
> setting which invokes the -sourcepath switch on javac, which might be part
> of a solution.  There would then be a need for something that could
> translate the $VPATH envvar to a sourcepath which would need to dig down
> through several layers of a directory tree (at least they would be
> identical in each node -e.g. $NODE/$PROJECT/src/main/java) to produce a
> sourcepath.
>
>
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

--089e013c637437790f0512b8cfe2--