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: [email protected]
For additional commands, e-mail: [email protected]
