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 <sco...@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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
