Brush up selection and filters

farblos commented 5 months ago

OraclePatchDownloader.java:

Do not handle empty searches as errors or even warnings.
But do handle any other search errors as errors again.
Use Matcher.find instead of Matcher.matches to filter patch file names.
Support special-cased "-q ALL" selection criterion.
Implement various cosmetic changes.

README.md

Add section "Specifying Patch Platform and Other Selection Criteria".
Implement various cosmetic changes.

farblos commented 5 months ago

In the contrast to the previous "big" changes these are (hopefully) harmless and strictly backward-compatible, so I I'll take the freedom of merging and releasing this thing.

ojehle commented 5 months ago

Here I have a small problem with the last fixes from PR 16…

I have the situation, that it’s possible that a patch in my list not exist for the platform, so passing a list of patches stops downloading. This was the reason, I switched the error -> warn and after downloading all patches , checked if we have such an error and then exit , so downloading of all existing patches worked. Now the code exit, not downloading all other possible patches.

I prefer to revert to the searchErrorList logic..

What you think?

Regards Oliver

    // check for search errors.  For now only warn about
    // them, but throw an error after we have completed (or
    // not) downloading any remaining patches.
    Node error;
    if ((error = (Node)errorXPE.evaluate(result, XPC_NODE)) != null) {
        warn("Cannot process search error \"%s\"",
                 page, error.getTextContent().trim().replaceAll("\\s+", " "));
        searchErrorList.add(patch);
    } 

    // dump information on search errors and error out if there
        // were any
        if (searchErrorList.size() > 0) {
            warn();
            warn("Search errors occurred for the following patches:");
            for (String patch : searchErrorList)
                warn("  %s", patch);
            error("Cannot process previous search errors");
        }

On 31.05.2024, at 21:50, farblos @.***> wrote:

In the contrast to the previous "big" changes these are (hopefully) harmless and strictly backward-compatible, so I I'll take the freedom of merging and releasing this thing.

— Reply to this email directly, view it on GitHub https://github.com/ojehle/H35_OraclePatchDownloader/pull/16#issuecomment-2142889780, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANFNAQPBC3F7GEOJJS7E57LZFDH7FAVCNFSM6AAAAABITLU6D2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBSHA4DSNZYGA. You are receiving this because you are subscribed to this thread.

farblos commented 5 months ago

Hm, I thought this should continue to download even if some patch was missing - at least that was my intention as well.

More concretely, I get the following with release 1.1.1 downloaded from https://github.com/ojehle/H35_OraclePatchDownloader/releases/tag/v1.1.1:

[tmp]$ java -jar oraclePatchDownloader-1.1.1.jar -u "$MOS_USER" -p env:MOS_PASSWORD -d . -t 226P -r 1919 -x 12345678 -x 26749785
Processing search results for patch "12345678"...
Processing search results for patch "26749785"...
Patch file "p26749785_191900230418WINDBBP_Generic.zip" downloaded successfully.
Patch file "p26749785_1919000DBRU_Generic.zip" downloaded successfully.

SHA-256 checksums as provided by MOS:
ADCA6520F6C54AFCF32A4AF7B142A153427A411320C596B3F21D8C54D6EBA1FF  p26749785_191900230418WINDBBP_Generic.zip
34485B0D407C4483FE8067E2F91006C9F789B79562DD4411F3B124CB4C3BD52B  p26749785_1919000DBRU_Generic.zip

In other words, the non-existent patch 12345678 does not stop the downloader from downloading the other 2 patches.

What does the example look like for you? Or do you have some example that I can try to run?

ojehle commented 4 months ago

The download logic didn’t change, but you get an error when one of the patches is not found at the end. So if you use the tool in a shell script you can catch the “missing” patch …

Look my last commit,

On 04.06.2024, at 23:58, farblos @.***> wrote:

Hm, I thought this should continue to download even if some patch was missing - at least that was my intention as well.

More concretely, I get the following with release 1.1.1 downloaded from https://github.com/ojehle/H35_OraclePatchDownloader/releases/tag/v1.1.1:

[tmp]$ java -jar oraclePatchDownloader-1.1.1.jar -u "$MOS_USER" -p env:MOS_PASSWORD -d . -t 226P -r 1919 -x 12345678 -x 26749785 Processing search results for patch "12345678"... Processing search results for patch "26749785"... Patch file "p26749785_191900230418WINDBBP_Generic.zip" downloaded successfully. Patch file "p26749785_1919000DBRU_Generic.zip" downloaded successfully.

SHA-256 checksums as provided by MOS: ADCA6520F6C54AFCF32A4AF7B142A153427A411320C596B3F21D8C54D6EBA1FF p26749785_191900230418WINDBBP_Generic.zip 34485B0D407C4483FE8067E2F91006C9F789B79562DD4411F3B124CB4C3BD52B p26749785_1919000DBRU_Generic.zip In other words, the non-existent patch 12345678 does not stop the downloader from downloading the other 2 patches.

What does the example look like for you? Or do you have some example that I can try to run?

— Reply to this email directly, view it on GitHub https://github.com/ojehle/H35_OraclePatchDownloader/pull/16#issuecomment-2148482065, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANFNAQN57VMNEZX622EPSADZFY2CDAVCNFSM6AAAAABITLU6D2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBYGQ4DEMBWGU. You are receiving this because you commented.

farblos commented 4 months ago

To summarize:

My first approach was to error out immediately if a MOS search fails.
Then you changed that to a warning plus error in the end.
Then I changed to not error out at all if a MOS search fails.
Which you reverted to 2. again.

I understand your point that you want to more clearly get information on missing patches. Let's leave it as is, probably later we can add some option to control search error reporting.

ojehle / H35_OraclePatchDownloader

Brush up selection and filters #16