Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

nitirajrathore
Copy link
Contributor

This change

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

…lder so that current important files compile properly.
Copy link
Collaborator

@msokolov msokolov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

overall this LGTM. I like that we reorganized the java files into separate directories, teasing out those that are used by the "main" benchmarks from the other one-off tests that are not typically used, but I don't know if the word "legacy" is appropriate for those? Maybe "misc"?

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?

README.md Outdated
### Preparing the benchmark candidates

The benchmark compares a baseline version of Lucene to a patched one. Therefore we need two checkouts of Lucene, for example:
The benchmark compares a baseline version of Lucene to a patched one. Therefor we need two checkouts of Lucene, for example:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Therefore" is correct

Copy link
Collaborator

@zhaih zhaih left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the work! I'm still a bit want to move to full gradle instead of ant for several reasons:

  1. It makes IDE setup easier
  2. It is considered to be more "morden" (in exchange of speed maybe LOL) -- it is sometimes important, for example, one of my (newly graduated) colleague doesn't even know what is ant.
  3. Lucene uses gradle as well, so more or less we can suppose Lucene people all know gradle. (This probably is not a reason, but just want to say gradle shouldn't be considered a "hard to use" thing at all)

To me I think 1 is really important for letting new people participate in this repo, even it is most likely a one time thing but it set up a high mental barrier for people who are not that familiar with all those things.

I know @mikemccand is probably against that so just tagging him here :)

Comment on lines +71 to +110
### (Optional, for development) set up IntelliJ
You can open the project as usual in IntelliJ.

Select src/main folder as Source Root. `Right Click src/main --> Mark Directory As --> Source Root`

Select src/python folder as source Root. `Right Click src/python --> Mark Directory As --> Source Root`

For configuring the right jar files you will have to do the following.
The jars that you need are present in at 3 places.
1. Apache Lucene jars. Which are present in your ${lucene.checkout}/lucene folder.
2. Some jars will be downloaded by Ant-Ivy build system of this project into the `./libs` folder of this package.
3. Some jars are shipped with this project which are present in the `./lib` folder.

IntelliJ Idea does not automatically detect these jars in the classpath. So you will have to do following steps to
include them. Also, IntelliJ Idea by default do not recursively include all the jars in sub folders, so follow the below
instructions to enable recursive search in folder for both the above jar paths.

``
IntelliJ IDEA --> File --> Project Structure --> Modules --> luceneutil-root --> Dependencies --> +
--> Jars And Directories --> Select the path to ${lucene.checkout}/lucene --> Open --> Choose Roots (Unselect All) -->
OK --> Choose Categories of Selected Files --> Jar Directory --> OK --> Apply --> OK
``

After this you will have to update the file in .idea folder manually to enable 'recursive' jar discovery. Open your
project's `.iml` file and change the `<jarDirectory>` xml tag's recursive attribute to `true`
` vim $luceneutil.root/.idea/luceneutil.iml `

Change line like below from recursive="false" to recursive="true"
``` xml
<library>
...
<jarDirectory url="file://$MODULE_DIR$/../../lucene/lucene" recursive="false" />
</library>
```

This will make idea search jar files recursively in lucene project.
Alternatively, you can configure idea with the source code of Lucene as a library, by not doing "unselecting all" in the `Choose Roots` step above.

Repeat the same process for lib and libs folder in $luceneutil.root folder.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think gradle could help skip all those steps, altho it is admittedly the slowest build system but I really think an easy and fast IDE setup is very important, especially for newcomer.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree, IDEs understand Gradle much more than Ant. But I also felt that there is a learning curve for gradle, especiallly because of language dependence. Also, Although there is java toolkit support in Gradle now, but there can be some difficulties in supporting newer or custom JDK for testing. But such does not seem to be an issue with Ant as it does not come in between execution of code.
With this small initial setup we can work with both lucene classes or lucene jars. Moreover if all the lucene jars are put in one folder in its build then we don't need to manually add recursive in *.iml file.

@zhaih
Copy link
Collaborator

zhaih commented Dec 5, 2023

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
Copy link
Contributor Author

nitirajrathore commented Dec 5, 2023

@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
Copy link
Owner

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 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants