build-helper-maven-plugin allows you to add multiple sourcepaths to the build, which could be part of the answer. I've never attempted scripting the sourcepaths in but might be possible. In any case, I've done something similar in the past in an ancient c+java monolithic make build environment paired with ClearCase. Good times. Anyway, our solution was to introduce a Maven repo manager (Nexus in our case) and start modularizing, packaging up and versioning the Java parts properly. If you can use a repo manager, it's much easier to write custom Maven builds to deal with pre-built dependencies than try to add a Maven build on top of a non-standard, convoluted directory hierarchy. Of the 4+h build times where only 1-2% of the codebase would ever change, we got down to ~1h builds, with most of it spent on the C compilation and only a few minutes on the Java side. If there's any good side dealing with legacy envrionments, it's that a large part of the codebase is usually stable and really doesn't have to be compiled over and over again for every build.
Kalle On Tue, Mar 31, 2015 at 11:25 AM, Steve Cohen <[email protected]> wrote: > 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] > >
