Compiling with ant. Moved non compilable outdated files to /legacy

[nitirajrathore]

This change

1. removes the Gradle and maven build systems
2. Adds the ant + Ivy build system
3. moves uncompilable files to /legacy folder.

[zhaih]

I'm curious what the "out of box" experience is for users with this change. What happens if I check out a fresh working folder and run python src/python/setup.py and then python src/python/localrun.py -- will python code run this ant/ivy build? Or ... does it still use its own internal build system?

I think it will still use "Mike build"? Because that build is written in competition.py and directly using javac command, without changing the python code I don't think the behavior will be changed.

[nitirajrathore]

@msokolov : As I have not updated any classes or files and Ant does not come in way of execution, all the exiting practices and commands should work like before. To test I checked out the this PR in a new folder and ran the following commands which worked correctly.

python src/python/setup.py -download
lzma -d enwiki-20120502-lines-1k-fixed-utf8-with-random-label.txt.lzma
ln -s ~/mywork/lucene/lucene lucene_baseline
ln -s ~/mywork/lucene/lucene lucene_candidate
python src/python/localrun.py -source wikimedium10k

May be one by one we can make the 'Mike build' to merge with Ant system ( shouldn't be difficult but preferable separate PR ).

Currently I have renamed the existing build.xml to data-build.xml and "imported" it into the build.xml. So even the existing build commands like 'ant build' and 'ant vectors300-tasks' work as is. Now we can update the lucene.checkout in the build.properties file. Later, if we like we can remove the 'build' task in data-build.xml and just use the default 'compile' task in build.xml. I did not change all that right now so as not to affect any existing processes.

[mikemccand]

I'm having trouble evaluating the two options here :)

I do agree, simplifying the onboarding of new devs using IDEs that are NOT emacs, heh, is important.

Can someone compare the onboarding process of Gradle (as is now in luceneutil, but also as it could be if we further improved it) with ant?

I agree that modifying the benchy runner to also use this new build tooling can/should come later. It's somewhat complex since a single benchy may need to compile against different Lucene clones (baseline and competitor), possibly using different JDKs each time as well. Sometimes the Lucene level changes being tested require code changes to luceneutil sources as well, making things extra hairy :)