A work in progress...
Introduction
This document is intended for first-time reviewers and of Apache Taverna, particularly those reviewers who could benefit from desire additional information about the Apache software release process or specific tools needed to accomplish the review. See also review process and tools used. It assumes you have already read How to Review a Release and Vote.
General getting-started information
Requirements:
- Maven
- Java
- Command line interface (e.g., GitBash (Windows), PowerShell (Windows), and UNIX Terminal)
- GPG - for verifying PGP key signatures (See download page for Windows and other OS verions. See more information.)
Additional (optional) tools:
- MD5 and SHA Checksum Utility
- Online Difference Checker (for text files)
Verify your environment
Verify you have the correct versions of the following software. The versions must match the requirements in the module download instructions.
...
Contents
- Getting Started
- Verify Your Environment
- Download the Release Candidate
- BEFORE You Unzip the Release Candidate
- AFTER You Unzip the Release Candidate But BEFORE You Build
- Build
- AFTER the (Successful) Build
- Tips
- Definitions
...
Anchor | ||||
---|---|---|---|---|
|
First read How to Review a Release and Vote.
In addition to the prerequisites listed in the README file, you will also need:
- A command line interface (e.g., UNIX Terminal, GitBash (Windows), or PowerShell (Windows).
- Maven
- Java
- GPG - for verifying PGP key signatures
mvn -- version
java – version
Download the release candidate
- Create a temporary directory for the release candidate.
- Open the VOTE email, and click the release candidate link. This will open a web page with four additional links: .zip (the release candidate), .asc (the signature file), .md5 (the md5 hash file), and .sha1 (the sha1 hash file).
- Click on each of the four links and download the files to your computer. (You may need to save a file from the browser to text. Make sure the browser does not append ".txt" to the file.)
Alternatively, you can use wget to download the release candidate. (See Apache Stratos 3.0.0 Test Procedure.)
BEFORE you unzip the release candidate
1a Check that Checksums are valid
There are three sources of checksums: (1) the VOTE email, (2) the release candidate .zip file, and (3) the checksum files (.md5 and .sha1) downloaded at the same time as the release candidate.
You can verify the checksums using a command line interface or a utility. Both methods are described below.
Command line interface
To generate checksums, navigate to the directory containing the .zip file and run the CertUtil command. The default gives you the SHA1 checksum. Append SHA512 and MD5, as shown below, to generate those checksums. Is the intent to make sure that the checksums from all 3 sources are identical?
CertUtil -hashfile 'apache-taverna-parent-2-incubating-source-release.zip'
CertUtil -hashfile 'apache-taverna-parent-2-incubating-source-release.zip' SHA512
CertUtil -hashfile 'apache-taverna-parent-2-incubating-source-release.zip' MD5
What's the best way to compare the checksums from the email and the .md5 and .sha1 files?
MD5 and SHA Checksum Utility
When you double-click the .exe, a window opens (see below). Browse to the release candidate .zip file, and the checksums will be displayed. (Use the checkboxes to choose which checksums you want to see.) You can copy individual checksums, or use the Copy All button. At the bottom of the window, you can paste a checksum (e.g., either from the VOTE email or from the downloaded .md5 or .sha1 files) and the utility will verify the hash is the same as that from the .zip file.
1b Check that the PGP signature is valid
Each software artifact is signed using a PGP (Pretty Good Privacy) key. It is important to verify the key in copy of software you downloaded matches the key originally used to sign the software artifacdt.
You can verify the signatures using a command line interface or other software program (Kleopatra). Both methods are described below
Command line interface
- Download the Taverna key file from https://dist.apache.org/repos/dist/release/incubator/taverna/KEYS. (On Windows this can be done by typing Ctrl-S in the browser window and saving the file as keys.txt.)
Import the key file into GPG:
gpg --import keys.txt
AFTER you unzip the release candidate, but BEFORE you build
2 Check the commit ID matches the VOTE email
The idea here is to check that the commit ID in the downloaded file matches that in the VOTE email. You will use a command line terminal for at least some of these steps.
Approach 1 (clone the git repository, checkout the commit id, and compare to release candidate)
This approach uses Git commands to compare the downloaded release candidate to a cloned git repository. You will clone one copy and unzip the other copy in such a way that will "trick" Git into thinking you are comparing two versions that you have edited. (I'm missing part of the picture here. What is the end configuration you want before you use git status to compare files?)
- Make a new directory and change to that directory (e.g., mkdir 1 ; cd 1)
- Git clone that-repository (which repository?? from where??)
- Checkout the commit id from the repository you just created: git checkout <commit_id>
- rm -rf* (remove a directory? I don't understand this step.)
- Unzip the release candidate (e.g., apache-taverna-parent-2-incubating-source-release.zip) (into the same directory?)
- mv apache-taverna-"/*. (one level up) (Move the release candidate up one level? Because it zips into a new folder?)
- git status
Git will then check the checksums of every file and let you know what has "changed."
If there are NO CHANGES, then the commit ID in the VOTE email matches the release candidate.
Approach 2 (download git commit from GitHub and compare to release candidate)
This approach uses the commit id from the VOTE email to download that commit from GitHub, which is then compared to the release candidate using the diff command.
- Search for the git commit corresponding to the email by browsing for it on GitHub. Use a URL that follows this pattern: https://github.com/apache/incubator-taverna-language/tree/<hash>, where <hash> is the commit has you want to download.
- Click "Download Zip" and save the file to your computer.
- Make a new directory, change to the new directory, and unzip the GitHub file to the new folder. (e.g., mkdir 1 ; cd 1 ; unzip <filename>.zip)
- Move up a directory (cd .. ) and make a second new directory (e.g., mkdir 2)
- Change to the second new directory (e.g., cd 2) and unzip the release candidate (e.g., unzip release-candidate.zip)
- Move up one directory. When you do a directory listing (ls) you should see both of your new directories listed.
- Compare all files in the two new directories using the diff command:
- Linix: diff -uR 1 2
- Windows, GitBash: diff -r 1 2 (Windows CMD command line try FC)
The files that differ will be shown. If you do this after you build, make sure you don't have any target folders before diff-ing. (Run mvn clean to be sure.)
Again, if there are NO DIFFERENCES, then the commit ID in the VOTE email matches the release candidate.
3a Check the incubator disclaimer (INCUBATOR PROJECTS ONLY)
All Podlings must include a disclaimer indicating they are in incubation. To check a Taverna release candidate, open the DISCLAIMER file (in the top level release candidate folder) and verify the text matches the following:
Apache Taverna is an effort undergoing incubation at the Apache Software
Foundation (ASF), sponsored by the Apache Incubator PMC.
Incubation is required of all newly accepted projects until a further review
indicates that the infrastructure, communications, and decision making process
have stabilized in a manner consistent with other successful ASF projects.
While incubation status is not necessarily a reflection of the completeness
or stability of the code, it does indicate that the project has yet to be
fully endorsed by the ASF.
You can use a text editor (e.g., Notepad++) or an integrated development environment (IDE), such as Eclipse, to open the DISCLAIMER files.
3b Check the file names include "incubating"
Check the unzipped release candidate to ensure the top-level distribution folder contains the word "incubating" (Is this all that can be checked before building? See 11 below.)
4 Check the top-level LICENSE and NOTICE files
LICENSE file
Check the text of the LICENSE file in the top-level release candidate folder, and ensure the Apache License matches the text of the required Apache License.
If additional, third-party licenses are listed below the required Apache License, ensure the licenses are allowed in Apache Software Foundation projects. (See also item 9, Check the dependencies - Review binary licenses.)
NOTICE file
Check the text of the NOTICE file in the top-level release candidate folder, and ensure it matches the following:
Apache Taverna Language
Copyright 2014-2016 The Apache Software Foundation
This product includes software developed at
The Apache Software Foundation (http://www.apache.org/).
Portions of this software were originally based on the following:
- Copyright 2010-2014 University of Manchester, UK
These have been licensed to the Apache Software Foundation under a software grant.
5 Check the source file headers
How does a reviewer know if a source file has been submitted directly to the ASF?
Code developed at the ASF
The ASF Source Headers web page details how to handle source file headers for code developed at the ASF. In short, the copyright must be removed (see requirements) and files should have the ASF license header text added to the header.
Specifically, check that each file has the ASF license header text and no copyright.
Third-party files
Files used by the project, but not submitted by their owners directly to the ASF, are treated differently. Copyright notices stay in the header, and associated licenses must be part of the distribution.
Specifically, check that each file has a license and that the license is allowed.
6 Check the provenance
TO DO What exactly is this, how does it differ from licensing, and how do you accomplish it?
7 Check that the source code does not include any binaries
Before building, the downloaded zip folder should contain no unexpected binary artifacts. For example, there should be no *.jar files.
There may be some "expected" binary files, such as pictures and test workflows. These should be declared in NOTICE/LICENSE if they came from third-parties, e.g., if use use a Creative Commons-licensed JPEG.
- . (See download page for Windows and other OS versions. See also Apache verification information and GPG Windows information.)
You may find the following tools useful.
- MD5 and SHA Checksum Utility
- Online Difference Checker (for text files)
...
Anchor | ||||
---|---|---|---|---|
|
Use the command line interface to verify you have the correct versions of Maven and Java as stated in the README file. Use the following commands to check Maven (mvn) and Java versions.
mvn --version
java --version
...
Anchor | ||||
---|---|---|---|---|
|
- Create a temporary directory for the release candidate. (Windows users may want to use a high level directory (e.g., C:/src) to avoid errors caused by long path names.)
- Open the VOTE email, and click the release candidate link. This will open a web page with four additional links: .zip (the release candidate),.asc (the signature file), .md5 (the md5 hash file), and .sha1 (the sha1 hash file). (See sections 1a and 1b below for information about signature and hash files.)
- Download the files to your computer by clicking on each of the four links and saving the files to your computer. (You may need to use Ctrl-S to save a text file from the browser to text. Make sure the browser does not append ".txt" to the file.)
Alternatively, you can use wget to download the release candidate. (See Apache Stratos 3.0.0 Test Procedure.)
...
Anchor | ||||
---|---|---|---|---|
|
1a. Check that Checksums are valid
There are three sources of checksums:
- The VOTE email,
- The release candidate .zip file, and
- The checksum files (.md5 and .sha1), downloaded at the same time as the release candidate.
All three checksums should be identical.
There are two steps: generate and verify. You can use a command line interface or a utility. Both methods are described below.
Check using the command line interface
GENERATE. To generate checksums, navigate to the directory containing the .zip file and run the CertUtil command. Append SHA512 and MD5, as shown below, to generate those checksums. (The default gives you the SHA1 checksum.)
CertUtil -hashfile 'apache-taverna-parent-2-incubating-source-release.zip'
CertUtil -hashfile 'apache-taverna-parent-2-incubating-source-release.zip' SHA512
CertUtil -hashfile 'apache-taverna-parent-2-incubating-source-release.zip' MD5
VERIFY. To verify, visually compare the checksums with those listed in the VOTE email, or use an online difference checker.
Check using the MD5 and SHA Checksum Utility
GENERATE. Follow the steps below.
- Open the MD5 and SHA Checksum Utility (double-click the .exe), a window opens (see below).
- Browse to the release candidate .zip file, and the checksums will be displayed. (Use the checkboxes to choose which checksums you want to see.)
- You can copy individual checksums, or use the Copy All button.
VERIFY. You can visually compare the checksums or use an online difference checker. The utiility also allows you to paste a checksum (e.g., either from the VOTE email or from the downloaded .md5 or .sha1 files) into the Hash input box, and the utility will compare it with the value from the .zip file.
1b. Check that the PGP signature is valid
Each software artifact is signed using a PGP (Pretty Good Privacy) key. Verifying the downloaded key matches the original key is a critical step.
You can verify the signatures using a command line interface. See https://httpd.apache.org/dev/verification.html for some general verification info.
Command line interface
- Download the Taverna key file from https://dist.apache.org/repos/dist/release/incubator/taverna/KEYS. (On Windows this can be done by typing Ctrl-S in the browser window and saving the file as keys.txt.)
- Import the key file into GPG:
gpg --import keys.txt
- Download the .asc file. (Save this file in the same folder as keys.txt.)
- Verify the .asc file matches the zipped release candidate by using the gpg command with the --verify option followed by the .asc filename and the .zip filename.
gpg --verify 'apache-taverna-...-source-release.zip.asc' 'apache-taverna-...-source-release.zip'
...
Anchor | ||||
---|---|---|---|---|
|
2. Check the commit ID matches the VOTE email
The idea here is to check that the commit ID in the downloaded file matches that in the VOTE email. You will use a command line interface for at least some of these steps.
Approach 1 (clone the git repository, checkout the commit id, and compare to release candidate)
This approach uses Git commands to compare the downloaded release candidate to a cloned git repository. You will clone one copy and unzip the other copy in such a way that will "trick" Git into thinking you are comparing two versions that you have edited.
- Make a new directory and change to that directory (e.g., mkdir 1 ; cd 1)
- Git clone that-repository
- Checkout the commit id from the repository you just created: git checkout <commit_id>
- rm -rf*
- Unzip the release candidate (e.g., apache-taverna-parent-2-incubating-source-release.zip)
- mv apache-taverna-"/*. (one level up)
- git status
Git will then review the checksums of every file and let you know what has "changed."
If there are NO CHANGES, then the commit ID in the VOTE email matches the release candidate.
Approach 2 (download git commit from GitHub and compare to release candidate)
This approach uses the commit id from the VOTE email to download that commit from GitHub, which is then compared to the release candidate using the diff command.
- Search for the git commit corresponding to the email by browsing for it on GitHub. Use a URL that follows this pattern: https://github.com/apache/incubator-taverna-language/commit/<hash>, where <hash> is the commit hash you want to download.
- Click "Download Zip" and save the file to your computer.
- Make a new directory, change to the new directory
- Unzip the GitHub file to the new folder. (e.g., mkdir 1 ; cd 1 ; unzip <filename>.zip)
- Move up a directory level (cd .. )
- Make a second new directory (e.g., mkdir 2)
- Change to the second new directory (e.g., cd 2)
- Unzip the release candidate (e.g., unzip release-candidate.zip)
- Move up one directory level. (When you do a directory listing you should see both new directories listed.)
- Compare all files in the two new directories using the diff command:
- Linix: diff -uR 1 2
- Windows, GitBash: diff -r 1 2 (Windows CMD command line try FC)
The files that differ will be shown. If you do this after you build, make sure you don't have any target folders before diff-ing. (Run mvn clean to be sure.)
Again, if there are NO DIFFERENCES, then the commit ID in the VOTE email matches the release candidate.
3a. Check the incubator disclaimer (INCUBATOR PROJECTS ONLY)
All Podlings must include a disclaimer indicating they are in incubation. To check a Taverna release candidate, open the DISCLAIMER file (in the top level release candidate folder) and verify the text matches what is shown below. You can use a text editor (e.g., Notepad++) or an integrated development environment (IDE), such as Eclipse, to open the DISCLAIMER files.
Apache Taverna is an effort undergoing incubation at the Apache Software
Foundation (ASF), sponsored by the Apache Incubator PMC.
Incubation is required of all newly accepted projects until a further review
indicates that the infrastructure, communications, and decision making process
have stabilized in a manner consistent with other successful ASF projects.
While incubation status is not necessarily a reflection of the completeness
or stability of the code, it does indicate that the project has yet to be
fully endorsed by the ASF.
3b. Check that file names include "incubating"
Check the unzipped release candidate to ensure the top-level distribution folder contains the word "incubating" (Is this all that can be checked before building? See 11 below.)
4. Check the top-level LICENSE and NOTICE files
LICENSE file
Check the text of the LICENSE file in the top-level release candidate folder, and ensure the Apache License matches the text of the required Apache License. The LICENSE file may also include details of additional licenses.
If additional, third-party licenses are listed below the required Apache License, ensure the licenses are allowed in Apache Software Foundation projects. (See also item 9, Check the dependencies - Review binary licenses.)
NOTICE file
Check the text of the NOTICE file in the top-level release candidate folder, and ensure it matches the text below.
Apache Taverna Language
Copyright 2014-2016 The Apache Software Foundation
This product includes software developed at
The Apache Software Foundation (http://www.apache.org/).
Portions of this software were originally based on the following:
- Copyright 2010-2014 University of Manchester, UK
These have been licensed to the Apache Software Foundation under a software grant.
5. Check the source file headers
Code developed at the ASF
Check that each file has the ASF license header text and no copyright. The ASF Source Headers web page details how to handle source file headers for code developed at the ASF. In short, the copyright must be removed (see requirements) and files should have the ASF license header text added to the header.
Third-party files
Check that each file has a license and that the license is allowed. Files used by the project, but not submitted by their owners directly to the ASF, are treated differently. Copyright notices stay in the header, and associated licenses must be part of the distribution.
6. Check the provenance
TO DO
7. Check that the source code does not include any binaries
Before building, the downloaded zip folder should contain no unexpected binary artifacts. For example, there should be no *.jar files.
There may be some "expected" binary files, such as pictures and test workflows. If these come from third-parties (e.g., a Creative Commons-licensed JPEG), they should be declared in NOTICE/LICENSE.
Anchor | ||||
---|---|---|---|---|
|
8. Build the release candidate(s) from source
Run mvn clean install
- Successfully complete the verification steps above.
- Use a command line interface and navigate to the folder containing the unzipped release candidate files.
- Execute the command below, which will build the release candidate and save the output to two text files. (The text file names can be anything.) This command will run several Maven goals, including automated tests. Do not skip the automated build tests.
mvn clean install > console.txt 2> err.txt
Review build completion status
BUILD FAILURE: At the completion of the mvn clean install process, if the message is "BUILD FAILURE," review both text files. Report the failure, along with any warning and error messages, on the release candidate's DISCUSS thread.
BUILD SUCCESS: If the completion message is "BUILD SUCCESS," review both text files. Report the success, along with any warning messages, on the release candidate's DISCUSS thread.
Anchor | ||||
---|---|---|---|---|
|
9. Check the dependencies
Checking dependencies:
- Make sure dependencies are used and declared properly. (Use mvn dependency:analyze and look for warnings or errors.)
- Determine if there are any mismatches between resolved dependencies and the dependencyManagement section. (Use mvn dependency:analyze-dep-mgt and look for warnings or errors.)
- Generate a list of licenses for each third-party dependency and check the licenses to make sure they meet Apache licensing requirements. (See Review Binary License below.)
- You can create a list of dependencies by module using mvn dependency:list and generate a dependency tree to troubleshoot conflicts using mvn dependency:tree.
Review Binary Licenses.
Create a list of third-party dependencies using the license:aggregate-add-third-party plugin and review the dependency licenses.)
- In a command line interface, change to the top level directory of the distribution (e.g., apache-taverna-language-<version>-incubator).
- Run the following Maven command: mvn license:aggregate-add-third-party. (On Windows, to save the output to a file, add > filename.txt to the end of the command.)
- This command will create THIRD-PARTY.txt files in each target folder (in the generated-sources/license subfolder).
- Review the THIRD-PARTY.txt files for unknown or disallowed licenses. Note: some unknown licenses have been determined to be allowed.) One method is shown below.
cat target/generated-sources/license/THIRD-PARTY.txt | sort
10. Verify the build produces the binaries
Quick check: browse the target folders and make sure there are not any extra folders. (For example, if we are voting on taverna-language there should not be any taverna-engine folders.)
Deeper check: ensure your target folders contains all the same *.jar files as those in TBR.
At least one person should check that all staged JARs are the same as those built from the downloaded release candidate. (One approach is to do a recursive wget of the repository , and then compare the result of "find . -name '*jar'" in the wget-tree with */*/target/*.jar. See StackOverflow response.)
NOTE: Binary releases are considered "convenience only" and are not crucial for the vote: The source release is what everything else should be made from. However, in practical terms most people download the binaries from the Maven repository, so it is important this is checked at least once.
11. Verify all the *.jar files include the word "incubating"
Visually inspect all the *.jar files include the word "incubating" by opening all the /target folders.
Anchor tips tips
Tips
tips | |
tips |
How to check LICENSE, NOTICE, DISCLAIMER, and similar files?
- Command line: Navigate to directory containing the file and use cat command to print contents to console (Example: cat LICENSE)
- Text Editor/IDE: Use a text editor (e.g., Notepad++) or an integrated development environment (IDE), such as Eclipse, to open the LICENSE, NOTICE, DISCLAIMER, and similar files.
How to capture the output of a command line interface command?
- In a command line interface, send the console output and error messages to a text file:
- GitBash example: mvn clean install > Console.txt 2> Err.txt
DefinitionsAnchor definitions definitions - binary files: Created during mvn clean install, located in target folders. Includes pictures, ZIP files, and JAR files.
- dependency: "A dependency is a file that something you are trying to install requires." [AskUbuntu]
- distribution: A distribution is all of the files (not including dependencies) that are needed to run an application.
- license: Terms and conditions for use of source code. For example, *Licensed under a Creative Commons Attribution 3.0 license.*
- notice: Copyright notice. For example, *Copyright (c) 2012-2015 University of Manchester.*
- provenance: "[A] record that describes the people, institutions, entities, and activities involved in producing, influencing, or delivering a piece of data or a thing." (Schreiber, 2013)
- source artifact: ".. 'things' ... produced by people involved in the process. Examples [are] design documents, data models, workflow diagrams, test matrices and plans, setup scripts. ... [A]ny thing that is created could be an artifact." [Programmers StackExchange]
- source files: Files downloaded from the VOTE email. Includes *.java and *xsd.
References:
Schreiber, Andreas. (2013) "Increasing software quality using the provenance of software development processes," in ESA Software Product Assurance Workshop 2013, 12-13 June 2013, Noordwijk, Niederlande. [link]
- In a command line interface, send the console output and error messages to a text file:
Build
8 Build the release candidate(s) from source
Run mvn clean install
After successfully completing the verification steps above, use a command line interface and navigate to the folder containing the unzipped release candidate files. Execute the following command, which will build the release candidate and save the output to two text files:
run mvn clean install > console.txt 2> err.txt
(The text file names can be anything.) This command will run several Maven goals, including automated tests. Do not skip the automated build tests.
Review build completion status
BUILD FAILURE: At the completion of the mvn clean install process, if the message is "BUILD FAILURE," review both text files. Report the failure, along with any warning and error messages, on the release candidate's DISCUSS thread.
BUILD SUCCESS: If the completion message is "BUILD SUCCESS," review both text files. Report the success, along with any warning messages, on the release candidate's DISCUSS thread.
AFTER the (successful) build
9 Check the dependencies
Checking dependencies:
- Make sure dependencies are used and declared properly. (Use mvn dependency:analyze and look for warnings or errors.)
- Determine if there are any mismatches between resolved dependencies and the dependencyManagement section. (Use mvn dependency:analyze-dep-mgt and look for warnings or errors.)
- Generate a list of licenses for each third-party dependency and check the licenses to make sure they meet Apache licensing requirements. (See Review Binary License below.)
- You can create a list of dependencies by module using mvn dependency:list and generate a dependency tree to troubleshoot conflicts using mvn dependency:tree.
Review Binary Licenses. Create a list of third-party dependencies using the license:aggregate-add-third-party plugin and review the dependency licenses.)
- In a command line interface, change to the top level directory of the distribution (e.g., apache-taverna-language-<version>-incubator).
- Run the following Maven command: mvn license:aggregate-add-third-party. (On Windows, to save the output to a file, add > filename.txt to the end of the command.)
- This command will create THIRD-PARTY.txt files in each target folder (in the generated-sources/license subfolder).
- Review the THIRD-PARTY.txt files for unknown or disallowed licenses. Note: some unknown licenses have been determined to be allowed.)
- One way to do this: cat target/generated-sources/license/THIRD-PARTY.txt | sort
10 Verify the build produces the binaries
Quick check: browse the target folders and make sure there are not any extra folders. (For example, if we are voting on taverna-language there should not be any taverna-engine folders.)
Deeper check: ensure your target folders contains all the same *.jar files as those in the git repo? in the Maven repository? (Example link?)
At least one person should check that all staged JARs are the same as those built from the downloaded release candidate. (One approach is to do a recursive wget of the repository , and then compare the result of "find . -name '*jar'" in the wget-tree with */*/target/*.jar. See StackOverflow response.)
NOTE: Binary releases are considered "convenience only" and are not crucial for the vote: The source release is what everything else should be made from. However, in practical terms most people download the binaries from the Maven repository, so it is important this is checked at least once.
11 Verify all the *.jar files include the word "incubating"
Visually inspect all the *.jar files include the word "incubating" by opening all the /target folders. Is there an easier way to do this?
Are other files supposed to be labeled as well, or is it only the *.jar files?
Tips
How to check LICENSE, NOTICE, DISCLAIMER, and similar files?
- Command line: Navigate to directory containing the file and use cat command to print contents to console (Example: cat LICENSE)
- Text Editor/IDE: Use a text editor (e.g., Notepad++) or an integrated development environment (IDE), such as Eclipse, to open the LICENSE, NOTICE, DISCLAIMER, and similar files.
How to capture the output of a command line interface command?
- In a command line interface, send the console output and error messages to a text file:
- GitBash example: mvn clean install > Console.txt 2> Err.txt
- In a command line interface, send the console output and error messages to a text file:
- tbd