Current state

[madoar]

@qparis so basically I copied the whole org.phoenicis.tools.lnk package into this repository and renamed it to org.phoenicis.lnk.

In addition I did the following changes:

• remove the @Safe annotation from the LnkParser class
• remove the extends FilesManipulator inheritance from the LnkParser class
• remove the this.assertInDirectory(file); call from the LnkParser class
• add guava as a dependency and use Resources.getResource to access the test resources
• move the test resources from a subfolder directly to the resources folder
• some slight formatting changes

@qparis I think the Phoenicis code will need some changes to be compatible with the changed code base in this repository. Can you do these changes?

[qparis]

Why using guava?
In any case, could it be just a test dependency?

[madoar]

I've used guava in the tests to retrieve the test-resource files.
Using the Resources class from guava allows loading a resources class without worrying about path/package differences between the loading class and the loaded file.

[qparis]

But this behavior is correct, right? It avoid loading the wrong file

[madoar]

Which behavior do you mean?

Let me give a short example:
The Resources file allows it to comfortably load the file lnk-parser/src/test/resources/teenagent.lnk, while the file was previously located in lnk-parser/src/test/resources/org/phoenicis/lnk/teenagent.lnk for classloader reasons. Such a deep folder structure is not necessary anymore, thanks to the Resources class.

[qparis]

getClass().getResource("/file") should do the trick, right?

[madoar]

Yes it loads a file, but it requires that your file is located relative to the package path of the current class getClass(). This means that if the class referenced by getClass is located in package org.phoenicis.lnk the file file needs to be located in at path /org/phoenicis/lnk/file and not /file

[qparis]

Not if you start by /

[madoar]

If we can get the same behavior without changes to the resources folder and not much code overhead to load the resource files, then I'm absolutely fine with removing the dependency to guava.
In case we can't do this, it should be ok to change guava to be a testing dependency.

[qparis]

In any case, I don’t see any problem with keeping the package structure for local resources.
There are some shared resource between packages but there are not in majority

[madoar]

In my opinion it is more of a chore to search specific files in a resources folder with a deeply nested folder structure. Often resources files are used by multiple classes. Also the package names can be easily misleading when searching for a specific resource file. Therefore I wouldn't recommend it.

[madoar]

As an example for a really deep resources folder structure, which is confusing in my eyes, take a look at the one from the Phoenicis repository.

The first part of the path org/phoenicis/javafx adds no important information about the resources, because that is clear when looking at the project and repository itself.
themes is a good folder name in my opinion, but the other ones again don't contain any information about their folder content.

In my opinion shorter paths in the resources folder are often more on point and they make it easier to understand the content of the folders.

[qparis]

The drawback is that once the package is compiled, all resources (even those from dependencies) are mixed up and could potentially conflict.

Most of the IDEs will shorten the path when there is only one directory.

I wouldn’t recommend at all going out of our namespace for these two reasons.

I think a reasonable approach would be to differentiate shared and local resources. Shared resource could go into /namespace/shared and others would follow the name of the packages

Theme could have its own namespace

[madoar]

The mixing of the compiled source code and the resources should not be a problem, because the source code still retains its prefix, i.e. org.phoenicis, which the resources wouldn't have according to my suggestion.

About the IDE:
I agree that most IDEs, and even github, are able to shorten path names. The issue is, that the resources folder commonly doesn't contain source code. Therefore I wouldn't say that every user uses an IDE to open and work with the resources folder.

For example, let's assume you want to modify a theme for Phoenicis, or add a new theme. To do this you don't require Java knowledge and most likely you won't have an IDE installed. In this case you simply use your file browser, for which a deeply nested folder structure is quite annoying.

I suggest we move the Phoenicis resources folder discussion to the dedicated issue PhoenicisOrg/phoenicis#1616, so that we don't get off-topic here.