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 Wed, 01 Apr 2015 14:22:18 GMT
Previously I prematurely posted something to the list and then asked 
people to ignore it.  This is the completed version of that post. 
Please read and respond to it.

========================================================================

Okay, I am thinking that this could best be done by writing a custom 
plugin.  This plugin would walk down the VPATH, capturing the names of 
all the java files to be compiled, under each element in the VPATH, and 
pruning the list according to the VPATH logic:

In other words, given a VPATH of "
     vpath/patha:external/vpathb:external/vpathc
it would first find all the java files under
     vpath/patha/src/main/java
It would then scan
     vpath/external/vpathb
adding to the list only those java files not already in the list from 
the first iteration
and finally scan
     vpath/external/vpathc and add only those not already in the list
from the first two iterations, etc.

It would seem that I would need to somehow "extend" the Maven Compiler 
plugin by creating a custom Mojo (extending CompilerMojo) that would use 
a custom SourceInclusionScanner
to perform the selection that the VPATH logic demands.  Once this is 
done, I would want all the rest of the maven compiler plugin to be executed.

I have never created a plugin before.  How difficult, or doable, is it 
to "extend" a plugin in this way? Can someone point to an example where 
such an extension has been done?

Thanks.


On 03/31/2015 05:07 PM, Steve Cohen wrote:
> Thanks Kalle, but I don't think this meets the need either.
>
> Note
>> Importantly, if the dependency IS satisfied, then nodes
>> further down the path are not looked at for that dependency.
>
> This plugin simply provides a way to add additional source paths, but
> not with any logic governing their interrelation and use, which is
> required.
>
> Steve
>
> On 03/31/2015 03:03 PM, Kalle Korhonen wrote:
>> 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 <scohen@javactivity.org>
>> 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: 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