Skip to content

Implement ConcatFilesTask from Groovy to Java issues#34459 #37497

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

Merged
merged 10 commits into from
Mar 7, 2019

Conversation

akki
Copy link
Contributor

@akki akki commented Jan 15, 2019

Issue #34459

Facing one problem (added as comment), after which the implementation would be complete for review from my side.

@akki akki force-pushed the 34459-concatFilesGroovy branch from 695e6e7 to 800bdb3 Compare January 15, 2019 18:15
@akki akki force-pushed the 34459-concatFilesGroovy branch from 800bdb3 to af7f347 Compare January 15, 2019 18:16
@akki akki changed the title WIP: Implement ConcatFilesTask from Groovy to Java issues#34459 Implement ConcatFilesTask from Groovy to Java issues#34459 Jan 15, 2019
@akki
Copy link
Contributor Author

akki commented Jan 15, 2019

If this looks like a good enough implementation, I can start writing any tests that are required.

(And sorry for the force pushes, I forgot those are not allowed even in forks in Elasticsearch)

Copy link
Member

@rjernst rjernst left a comment

Choose a reason for hiding this comment

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

I have some requests

@colings86 colings86 added the :Delivery/Build Build or test infrastructure label Jan 16, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra


// To remove duplicate lines
LinkedHashSet<String> uniqueLines = new LinkedHashSet<>();
for (File f : getFiles()) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I am not sure if looping over a FileTree instance this way is correct.

@akki
Copy link
Contributor Author

akki commented Jan 20, 2019

@elasticmachine Test this please.

@rjernst Thanks for the review, I have incorporated your suggestions to the best of my understanding.

I ran ./gradlew check locally this time around 2 hours ago and it is still running. Is this the expected time it takes and is there any way to make it run faster?

@alpar-t
Copy link
Contributor

alpar-t commented Jan 21, 2019

@elasticmachine test this please
@akki you can do ./gradlew -p distribution check for this particular change. A full check does take more than 2 hours to run on powerful desktop machine. There's no way to make it faster, we're working on it.


@TaskAction
public void concatFiles() throws IOException {
final String encoding = "UTF-8";
Copy link
Contributor

Choose a reason for hiding this comment

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

Just use StandardCharsets.UTF_8, no need for a variable.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@atorok
There were multiple places where I had to mention the encoding type (UTF-8), hence I used it as a variable to keep it DRY.
Please let me know if it still makes more sense to you to remove the variable.

Copy link
Contributor

Choose a reason for hiding this comment

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

I do think it's better to use the StandardCharsets.UTF_8 constant to keep it dry rather than our own variable.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ahh, now I see your point. Fixed it, thanks! :)

Copy link
Contributor

@alpar-t alpar-t left a comment

Choose a reason for hiding this comment

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

Please also write tests for the task.

@akki
Copy link
Contributor Author

akki commented Jan 25, 2019

@atorok I have added the setter for target. Can you please help me test this.

I tried running ./gradlew -p distribution check and it worked well for me. But recently it started giving me the following errors (maybe because I tried running gradlew idea but I am not sure about that)

1: Task failed with an exception.
-----------
* Where:
Build file '/Users/adoshi/Work/repos/elasticsearch/benchmarks/build.gradle' line: 20

* What went wrong:
A problem occurred evaluating project ':benchmarks'.
> Failed to apply plugin [id 'elasticsearch.build']
   > A problem occurred starting process 'command '/bin/jrunscript''

2: Task failed with an exception.
-----------
* What went wrong:
A problem occurred configuring project ':benchmarks'.
> Must specify license and notice file for project :benchmarks

The same error is thrown when I run time ./gradlew test -Dtests.class="org.elasticsearch.gradle.ConcatFilesTaskTests" --scan. Do you clue why this might be happening and what I am doing wrong?

@akki
Copy link
Contributor Author

akki commented Jan 28, 2019

Fixed the above issue - seemed like a problem with the Java version and environment variables.
Having some problem with writing the tests (Java newbie here 😬) so might take some more time.

file.getParentFile().mkdirs();
file.createNewFile();
concatFilesTask.setTarget(file);
concatFilesTask.setFiles(new FileTree());
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This fails saying FileTree is abstract; cannot be instantiated.

Copy link
Contributor

Choose a reason for hiding this comment

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

That's right, you'll have to use the class as intended by Gradle projcet.fileTree in this case.
See: https://docs.gradle.org/current/javadoc/org/gradle/api/file/FileTree.html

for (File f : getFiles()) {
uniqueLines.addAll(Files.readAllLines(f.toPath(), Charset.forName(encoding)));
}
getFiles().getFiles().forEach(f -> uniqueLines.addAll(fileReadAllLines(f, encoding)));
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This fails with NullPointerException when setFiles is not used in the tests (I guess because the first getFiles() returns null?).

for (File f : getFiles()) {
uniqueLines.addAll(Files.readAllLines(f.toPath(), Charset.forName(encoding)));
}
getFiles().getFiles().forEach(f -> uniqueLines.addAll(fileReadAllLines(f, encoding)));
Copy link
Contributor Author

@akki akki Jan 29, 2019

Choose a reason for hiding this comment

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

Also, here Files.readAllLines raises the error unreported exception IOException; must be caught or declared to be thrown, even though the definition of concatFilesTask says throws IOException. Hence the need for creating an Exception-safe function fileReadAllLines.

@akki
Copy link
Contributor Author

akki commented Jan 29, 2019

Hi @atorok I tried to write the tests for this task but facing some problems using FileTree - I couldn't find any other test case similar to this task.
I would appreciate a lot if you could point me to any similar test cases or help me in any other way to write these. You can find my attempt in this commit (I've added a few comments to explain my problem).

@akki
Copy link
Contributor Author

akki commented Feb 7, 2019

Just wanted to check in once again on this PR to request if somebody has any suggestions for me on how I can go ahead with writing the test cases.
If not, is it possible for the admins to merge this PR in the current state?

@alpar-t
Copy link
Contributor

alpar-t commented Feb 7, 2019

Sorry to keep you waiting @akki I will look at this early next week.

@akki
Copy link
Contributor Author

akki commented Feb 7, 2019

I understand, appreciate the update on your availability. :)

@danielmitterdorfer
Copy link
Member

Note to reviewers: This PR will make #34476 obsolete. Please close #34476 accordingly when merging this PR.

@alpar-t
Copy link
Contributor

alpar-t commented Feb 13, 2019

@akki see here for file tree: https://docs.gradle.org/current/javadoc/org/gradle/api/file/FileTree.html you'll have to use the class as intended by Gradle. Specifically use project.fileTree

@akki
Copy link
Contributor Author

akki commented Feb 20, 2019

Thanks for the hint; I'll get back to this by next week.

@akki
Copy link
Contributor Author

akki commented Mar 2, 2019

Hi @atorok / all
I have added the tests as requested. Please have a look.
I did not run the whole test suite as it takes forever to run on my machine. I did run ./gradlew test -Dtests.class=org.elasticsearch.gradle.ConcatFilesTaskTests and ./gradlew -p distribution check - both of them passed for me.

Please let me know your thoughts.

@akki
Copy link
Contributor Author

akki commented Mar 2, 2019

@elasticmachine test this please

@alpar-t
Copy link
Contributor

alpar-t commented Mar 4, 2019

@elasticmachine test this please

  * Use standardcharset everywhere
  * Reshuffling of imports
  * Cosmetic changes
@akki
Copy link
Contributor Author

akki commented Mar 4, 2019

@atorok Thank you for the review. I have updated the PR to address your comments.
I also had a look at the build failures which seem to pointing to some problem with "git branch checkouts". Do you believe these are related to this PR and code changes? I digged in a bit but couldn't find any connection between the failing task and ConcatFilesTask.

@alpar-t
Copy link
Contributor

alpar-t commented Mar 6, 2019

@akki those failures are indeed not related to the changes, they are happening because the PR was created a long time ago and master got out of sync. I merged master in so @elasticmachine test this please.

@akki
Copy link
Contributor Author

akki commented Mar 6, 2019

@atorok Ahh, thank you. I did not realise that because GitHub told me This branch has no conflicts with the base branch.

@alpar-t alpar-t merged commit 8657e6e into elastic:master Mar 7, 2019
alpar-t pushed a commit that referenced this pull request Mar 7, 2019
@akki
Copy link
Contributor Author

akki commented Mar 7, 2019

@atorok Thanks for the approval. You might also want to close #34476 now as it is obsolete.

@akki akki deleted the 34459-concatFilesGroovy branch July 2, 2019 15:45
@mark-vieira mark-vieira added the Team:Delivery Meta label for Delivery team label Nov 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Delivery/Build Build or test infrastructure >non-issue Team:Delivery Meta label for Delivery team v7.2.0 v8.0.0-alpha1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants