As I indicated in my post, we need a gradual transition, and changing
the automated build part of it would be the last step rather than the
first step. We want to integrate maven into an existing nmake-based
process rather than change the entire automated build process first.
At some point down the road the goal would be to use something like
Hudson/Jenkins and CI, but we'll never get there if we have to redo
everything first.
On 03/31/2015 02:12 PM, [email protected] wrote:
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:[email protected]]
Sent: Tuesday, March 31, 2015 1:26 PM
To: [email protected]
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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
