kocmana / filerename Goto Github PK

It would be useful to define several file rename tasks to allow to merge two/n file naming patterns to one common pattern in one singular execution.
Picocli allows to repeat composite argument groups (Documentation) that could be used to implement this feature.

Command line arguments introduced by #4 and #5 as well as #3 are currently not covered by the documentation. The Readme needs hence to be updated.

Arguments:

-i "IMG_<<TS|yyyyMMdd_HHmmss>>.jpg" -o "<<TS|yyyyMMdd_HHmmss>>.jpg" -p ".\testfiles" -cp

File names matched:

.\testfiles\IMG_20210726_152901.jpg
.\testfiles\IMG_20210726_152902.jpg
.\testfiles\IMG_20210726_152902__01.jpg
.\testfiles\IMG_20210726_152909.jpg
.\testfiles\IMG_20210726_154326.jpg
.\testfiles\IMG_20210726_154330.jpg
.\testfiles\IMG_211946.jpg
.\testfiles\IMG_211948.jpg
.\testfiles\IMG_211951.jpg
.\testfiles\IMG_211954.jpg

Resulting Exception:

21:19:45:923 a.k.f.s.FileRenameTask [ForkJoinPool.commonPool-worker-1] ERROR - Could not finish task with arguments: CommandLineArguments[path=.\testfiles, recursive=false, inputTemplate=IMG_<<TS|yyyyMMdd_HHmmss>>.jpg, outputTemplate=<<TS|yyyyMMdd_HHmmss>>.jpg, dryRun=false, createCopy=true, collisionResolutionStrategy=FAIL]: Text '211946' could not be parsed at index 6

Currently the way examples are provided in the readme differ between the transformation rules.

A uniform approach should be used in a tabular form:
| inputPattern | outputPattern | input Filename | output Filename |

When providing multiple tasks, the command line parameters are becoming harder and harder to read. For such instances, providing job definitions via a xml/json file would be preferable.

In order to unify the current code base, Timestamp Transformation Rule should be refactored to extend AbstractTransformationRule

Currently, the project still uses the basic maven archetype. To build fat jars as required during package step this needs to be modified.

Currently the test asserts the order of the returned list of Transformation Rules. This is completely irrelevant to the functionality of the application and cause unexpected failing tests in the pipeline.

This test should assert class instances irrespective of the order in the list (one instance of X and one instance of Y are in the list)

Currently, file rename jobs will fail if the file can't be renamed due to an already existing file with the same name.
Users should be able to define a collision resolution strategy as command line argument for such cases.

Approach:
Add new command line argument -cr --collisionResolution with the arguments FAIL or ENUMERATE

While renaming may be the common goal, copying the files using the new filename may also be a worthwhile option.

Approach:
Add a -s --strategy option with the options COPY and RENAME (default)

Currently, there is no guidance on the impact of the abstract transformation rule methods and their contracts. This should be ammended by adding reasonable javadoc documentation.

Currently no licensing information is available. Licence information should be seleceted and made available based on https://choosealicense.com/

Currently, there is no guidance on the impact of the transformation rule methods and their contracts. This should be ammended by adding reasonable javadoc documentation.

Enumeration and Creation Date Rules require to have a wildcard template for input strings that identifies several files. This could be created as some sort of regex rule <<R|{regex-expression}>> or, probably easier from user perspective using common wildcards * ? as part of the filename.

• Example Approach 1:
  • -i "image<<R|[0-9]{8}>>.jpg -o "image<<CD>>.JPG"
  • This would also allow to shift parts of the filename between input and output filename
• Example Approach 2:
  • i "image*.jpg" -o "image<<CD>>.JPG"