Closed j256 closed 1 month ago
We will probably not change the directory structure just because someone is not able to use the github search
Yeah I get it. Just understand that I've never had to use search before because every other repo is browsable. Yeah so I guess maybe I suck. But maybe .......
I just spent a good amount of time trying to figure out where the ClassFileReader class was. Google and top level github searches were not helpful but luckily a file search in the eclipse.jdt.core repo located the file. Better pointers from the archived directories from gitlab.eclipse.org would have also saved time.
The fact that the repo is not a hierarchy and that packages such as
org.eclipse.jdt.internal.compiler.classfmt
is in theorg.eclipse.jdt.core.compiler.batch
directory which sure looks like a package to me seems to me to border on deliberate obfuscation.I'm sure you are stuck with this mess but I would suggest to not use a java package style for the subdirs. I guess you can't do a full tree but something like
org.eclipse.jdt-core-compile-batch
or maybe a top directory of org.eclipse.jdt and thencore-compile-batch
subdirectory? Maybe have a full tree with README.md links to the appropriate locations of the code would also help developers who don't know the repo intimately -- which means the rest of the world.Thanks.