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 13:45:15 GMT
Please disregard my previous message.  I inadvertently pressed "send" 
before it was finished.  Sorry.

On 04/01/2015 08:43 AM, Steve Cohen wrote:
> On 03/31/2015 05:07 PM, Steve Cohen wrote:
> Okay, I am thinking that this could be best 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.
>
> This list would then be passed to javac
>
> My question is whether there is a hook
>> 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
>
>
>


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


Mime
View raw message