[prev in list] [next in list] [prev in thread] [next in thread] 

List:       maven-user
Subject:    Re: Can Maven be used in an nmake environment with VPATH?
From:       Steve Cohen <stevecoh1 () comcast ! net>
Date:       2015-04-02 23:14:27
Message-ID: 551DCD53.4080709 () comcast ! net
[Download RAW message or body]

In any case Stephen Connolly has provided the final nail in the coffin 
for this idea.  At the end of the day, there is no GOOD way to do this 
that would be worth the effort.

Switching over to a modern version control system (without VPATH) and 
Maven will need to be done together, and be for new work.  Old 
applications will need to be ported.  There's no way around it.

Thanks to everyone for trying.

Steve Cohen

On 04/02/2015 10:35 AM, scohen@JAVACTIVITY.ORG wrote:
> 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 <stephen.alan.connolly@gmail.com> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]