-
Notifications
You must be signed in to change notification settings - Fork 5.7k
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
8281104: jar --create should create missing parent directories #7327
8281104: jar --create should create missing parent directories #7327
Conversation
👋 Welcome back cstein! A progress list of the required criteria for merging this PR into |
Webrevs
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for taking this on. Overall looks good.
A few comments below.
Also, we should update jar.properties to indicate that the directory path will be created as needed in the help section for jar.
Best,
Lance
import java.util.spi.ToolProvider; | ||
import java.util.stream.Stream; | ||
|
||
public class CreateMissingParentDirectories { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Understand why you used went this route for the test given some of the older tests use this framework. I might have gone the route of using TestNG as the newer tests (such as in MultiRelease) use it.
Path parent = target.getParent(); | ||
if (parent != null) { | ||
Files.createDirectories(parent); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be good to move the creation after validating the arguments as this would fail after creating the temp zip file. Be good to do via another PR
} | ||
|
||
private static void doHappyPathTest(Path jar, Path entry) throws Throwable { | ||
String[] jarArgs = new String[]{"cf", jar.toString(), entry.toString()}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might consider also using --create --file in addition to "cf" in a run for an extra sanity check
Thanks for the review, Lance. I didn't change order of creation, validation, and movement of the temporary JAR file in order to keep existing behaviour consistent. A reason to use the main-based testing approach was also the ability to run the test via JEP 330:
That's a good point. Where would we put that information?
|
I do think we are better served with the validation check earlier on. In the case of a failure, we do not make the tmp file name known so it could be easy to miss. I think it makes sense to report the issue before erring out after creating the jar.. If the behavior stays as is, it would be best to document that the tmp file would still be there. Let's see what others think. Either way we can accomplish the additional change if we reach consensus via a separate PR.
For me personally, I would not use that means to run the tests as typically would from an IDE. Plus there is a benefit of leveraging the test framework in TestNG. I totally understand everyone has a personal preference. A discussion for another day I guess ;-).
I think this would be the appropriate place for documenting the behavior.
Also we will need to update the MD file which represents the jar man page via a separate PR. |
Like this?
Perhaps, only adding it to
Yes. Will create PR for this. |
I think just having the verbiage when creating the jar should suffice as if we were updating it, the path would need to exist already.
Great, thank you. Have a good weekend! |
Should I also extend this "usage.compat" help message block? When and where is it displayed? 🤔 jdk/src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties Lines 167 to 173 in 48523b0
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The current changes look good overall
@sormuras This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 55 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@LanceAndersen) but any other Committer may sponsor as well. ➡️ To flag this PR as ready for integration with the above commit message, type |
I guess that makes sense. Not sure how often anyone looks at this but good for consistency. |
/integrate |
/label remove compiler |
@vicente-romero-oracle |
/sponsor |
Going to push as commit 92f4f40.
Your commit was automatically rebased without conflicts. |
@LanceAndersen @sormuras Pushed as commit 92f4f40. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Calling
jar --create --file a/b/foo.jar INPUT-FILES
should create missing parent directories (herea/b
) on the default file system before storing the JAR file (herefoo.jar
) in the destination directory.Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/7327/head:pull/7327
$ git checkout pull/7327
Update a local copy of the PR:
$ git checkout pull/7327
$ git pull https://git.openjdk.java.net/jdk pull/7327/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 7327
View PR using the GUI difftool:
$ git pr show -t 7327
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/7327.diff