About some refactoring

[Martin <ma...@apache.org>]

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.

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?)
  - 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?
  - 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? 

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.

Greetings

Martin

Re: About some refactoring

[Olivier Lamy <ol...@apache.org>]

Hi
I apologise for the delayed response....

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