maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From james northrup <northrup.ja...@gmail.com>
Subject Re: Can Maven be used in an nmake environment with VPATH?
Date Sat, 04 Apr 2015 14:14:38 GMT
teraform-mvn at https://code.google.com/p/teraform-mvn/ produces poms from
netbeans projects and/or anything with src/*.java and lib/*.jar as maven
reactor builds + does some hueristics to locate existing libraries as
dependencies, and just subsumes the rest of the jars in lib/ as a private
local maven repo.

the conversion only works against maven 2.1, for the brave, however you can
use later edictions of maven on the produced poms.

reorganizing the java source and relaxing the testing requirements can get
you clear of many large java projects in a  relatively short time.

On Thu, Apr 2, 2015 at 4:15 PM Steve Cohen <stevecoh1@comcast.net> wrote:

> 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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message