archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olivier Lamy <ol...@apache.org>
Subject Re: About some refactoring
Date Sat, 16 Sep 2017 00:36:08 GMT
Hi
I apologise for the delayed response....

On 2 September 2017 at 18:06, Martin <martin_s@apache.org> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message