Hi I apologise for the delayed response.... On 2 September 2017 at 18:06, Martin <[email protected]> wrote:
> Hi, > > after reading a lot of code and tickets the last days I would like to > propose some > refactoring changes: > > - One change and I think good to handle would be to switch from > java.io.File > to java.nio.Path for all the code. > Currently these are mixed (new code uses mostly Path) and leads to > confusion and needs always > conversions when accessing new code from old one and vice versa. > Good idea! > > The other one is more challenging but may be implemented step by step. > - After reading the code and https://issues.apache.org/ > jira/browse/MRM-1704 (and dependent tickets) I > think it would make sense to separate the code that is maven specific > from the archiva interfaces / main classes. > How? > - First, there is one thing I missed: Main interfaces for a managed and > remote repository > -> the classes used are beans from the repository-admin module > -> Maybe there are other beans from repository-admin used. I think > these should be extracted to interfaces too. > -> I would put them to the "archiva-repository-layer" module, or do > you think there is a separate module necessary? > - Separate other modules like archiva-indexer into archiva and maven > specific modules > -> I would create an -api module for these and move the archiva > specific part / interfaces to the api module > > Problems here: > - Can we start with a interface that represents the current > managed/remoterepository-Beans, or do we have to > find a more abstract one? (what other types of repositories may be > implemented in the future, and what do they need?) > maybe start only with the inferface (the idea is to have an easy to add repositories type in the future such docker, npm etc...) > - The maven repository model / indexes assume the content is stored in > the file system, do we need to keep this > more abstract, or make sure, that the already existing > RepositoryContent interfaces are used? Or will repositories always > have content / indexes in the filesystem? > we can assume different ways of storage. > - I'm not sure about the role/purpose of archiva-model and the code > generation. I do not know the history of this project, so > you may clarify this. Is code generation considered best practice > here and should be used more often? > Is it primarily used for configuration objects? > In the past, we were using some tooling based on modello / jpox so the code generation. I don't have any issue if we remove this code generation and use the beans from the source code (it's very legacy mode :-) ) > > Olivier, you created the ticket and maybe you can tell, what you had in > mind, or tell something about what is more historic and > what is best practice. > > So I'm for a pragmatic evolutionary approach. I will try to push small > commits and start with interfaces that mainly represent > what we already have. Consider my next commits to master as proposals. If > you think this goes into the wrong direction, tell me. > for sure :-) > > Greetings > > Martin > -- Olivier Lamy http://twitter.com/olamy | http://linkedin.com/in/olamy
