maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Cohen <stevec...@comcast.net>
Subject Re: Can Maven be used in an nmake environment with VPATH?
Date Tue, 31 Mar 2015 19:22:23 GMT
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, cody.a.fyler@wellsfargo.com 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:scohen@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-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
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message