ddanielr commented on PR #6121: URL: https://github.com/apache/accumulo/pull/6121#issuecomment-3891821352
> @dlmarion wrote: > > > @ctubbsii - with this change the LocalCachingClassloader can declare it's own UsageGroup for its KeywordExecutables for 4.0. For example, if the UsageGroup is `ccl`, then the commands could be `./accumulo ccl init` and `./accumulo ccl create-manifest`. > > Given that the classloader is intended to work across 2.1 and 4.0, it might be hard to make use of the changes here. Maybe it might make sense to put some of this KeywordExecutable+JCommander stuff in a separate library, that both 2.1 and 4.0 could leverage, though 2.1 might leverage it in a different way, so it doesn't break all the existing 2.1 commands. Moving this into a separate library is a nice long-term goal and it might also make sense to add the KeywordExecutable interface to public API at that time. However, that seems like a major task for minimal immediate gain. I can only think of the upgrade utility potentially using this common cli library due to it's need for cross-version support, but it's currently coupled with the accumulo source code. The simplest solution would be adding a 2.1 branch to accumulo-classloaders. This would allow the cli utilities to work while following the same structure as the accumulo-testing repo. I understand that the caching classloader is currently designed to work across multiple accumulo versions but unless we state otherwise, the repo will most likely diverge to support various accumulo versions in the future. If that is a non-starter then an alternate solution would be decoupling the cli utility part of the classloader into separate modules that require different accumulo versions. I'm not a huge fan of this solution as it seems more complicated than managing a separate branch, but I'm open to discussions. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
