Have you looked into using Jenkins or Hudson to automate those builds? You can set up custom environment variables, different jvms, etc. etc. It can run any number of utilities via shell scripts, Maven, Ant, Gradle, etc. etc.
That might be a more fruitful place to start. Cody Fyler Lending Grid Build Team G=Lending Grid Builds (515) – 441 - 0814 -----Original Message----- From: Steve Cohen [mailto:sco...@javactivity.org] Sent: Tuesday, March 31, 2015 1:26 PM To: users@maven.apache.org Subject: Can Maven be used in an nmake environment with VPATH? I work for an organization which uses an SCM/Build process based on the following: SCM: a ancient legacy horror of a system Build: Alcatel-Lucent nmake With this system the organization maintains a large suite of applications. The system is monstrously inflexible and a pain to work with. They do manage to have an automated build process with it, but no continuous integration. A large proportion of the actual code built by this system is java. Deployment is onto various servers using versions of containers such as weblogic, or sometimes standalone. This requires old JVMs, a few of which are as old as JDK-1.3, and none use a version of java that is still supported by Oracle (>=1.7). Deployment is done through RPMs and in some cases Solaris packaging. As you might imagine, change, in such an organization is difficult. The main impediment to change is the accreted base of thousands of makefiles that have been created over the years. But a few intrepid (or maybe foolhardy) souls are thinking of trying. We'd like to use maven to handle the java portion of this process. Its dependency management features would be worth the effort if we could get them. Since replacing the whole system is not in scope, the idea is to use maven to handle the java compilation, archiving into jars, wars, ears, etc., while leaving the packaging, deployment, source control systems as they are. Alcatel-Lucent nmake would invoke maven as it now invokes javac, jar, etc. If we can get this far, future upgrading of other portions of the system may come into play, but not in step 1. Such a transition will happen gradually or not at all. 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. I don't think this will work because if I turn on the verbose debug output, I see that maven is putting a path to each source file on the javac command line, and am guessing maven is not going to do this looking over each node of the VPATH. Another option would be to pull the source from the various vpath nodes in reverse order and then use maven in a more normal way. But I imagine that this would have negative performance consequences. Has anyone on this list ever tried anything like this? Or is this too big a hill to even contemplate climbing? --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
