[jira] [Created] (MRM-1964) Refactor repository api

Discussion:

Martin Stockhammer (JIRA)

2017-11-01 14:56:00 UTC

Martin Stockhammer created MRM-1964:
---------------------------------------

Summary: Refactor repository api
Key: MRM-1964
URL: https://issues.apache.org/jira/browse/MRM-1964
Project: Archiva
Issue Type: Improvement
Reporter: Martin Stockhammer
Priority: Major

Currently, the repository access managed via the repository admin api and has several specifics in it that are highly dependent on the repository implementation.
At the time there is no way to provide another repository type without changing/duplicating code on a lot of different places.
Another issue, is that many modules are dependent on maven libraries.

Goal is to provide a central repository registry, that keeps track of repositories and delegates provider specific tasks to special repository providers.
Maven libraries should only be used in the repository provider implementations. All other modules should use the central repository api.

--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Martin Stockhammer (JIRA)

2017-11-01 14:57:00 UTC

Permalink

[ https://issues.apache.org/jira/browse/MRM-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Stockhammer reassigned MRM-1964:
---------------------------------------

Assignee: Martin Stockhammer

Post by Martin Stockhammer (JIRA)
Refactor repository api
-----------------------
Key: MRM-1964
URL: https://issues.apache.org/jira/browse/MRM-1964
Project: Archiva
Issue Type: Improvement
Reporter: Martin Stockhammer
Assignee: Martin Stockhammer
Priority: Major
Currently, the repository access managed via the repository admin api and has several specifics in it that are highly dependent on the repository implementation.
At the time there is no way to provide another repository type without changing/duplicating code on a lot of different places.
Another issue, is that many modules are dependent on maven libraries.
Goal is to provide a central repository registry, that keeps track of repositories and delegates provider specific tasks to special repository providers.
Maven libraries should only be used in the repository provider implementations. All other modules should use the central repository api.

--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Martin Stockhammer (JIRA)

2017-11-01 15:02:00 UTC

Permalink

[ https://issues.apache.org/jira/browse/MRM-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16234176#comment-16234176 ]

Martin Stockhammer commented on MRM-1964:
-----------------------------------------

Added repository registry and moved the repository admin implementation to the new API.
Changed the repository interfaces where applicable.

Next tasks:
* move the indexing part to the provider/registry.
* clarify the repositoryContent bean usages - it seems there are singleton beans used, but stored per repository id with direct references.
* move usage of repositoryContentFactory to repository registry

--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Martin Stockhammer (JIRA)

2017-11-01 15:38:00 UTC

Permalink

[ https://issues.apache.org/jira/browse/MRM-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16234230#comment-16234230 ]

Martin Stockhammer commented on MRM-1964:
-----------------------------------------

Proposal on the mailing list:

{quote}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{quote}

--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Martin Stockhammer (JIRA)

2017-12-12 18:10:00 UTC

Permalink

[ https://issues.apache.org/jira/browse/MRM-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Stockhammer updated MRM-1964:
------------------------------------
Fix Version/s: 3.0.0

Post by Martin Stockhammer (JIRA)
Refactor repository api
-----------------------
Key: MRM-1964
URL: https://issues.apache.org/jira/browse/MRM-1964
Project: Archiva
Issue Type: Improvement
Reporter: Martin Stockhammer
Assignee: Martin Stockhammer
Fix For: 3.0.0
Currently, the repository access managed via the repository admin api and has several specifics in it that are highly dependent on the repository implementation.
At the time there is no way to provide another repository type without changing/duplicating code on a lot of different places.
Another issue, is that many modules are dependent on maven libraries.
Goal is to provide a central repository registry, that keeps track of repositories and delegates provider specific tasks to special repository providers.
Maven libraries should only be used in the repository provider implementations. All other modules should use the central repository api.

--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Martin Stockhammer (JIRA)

2017-12-12 18:12:00 UTC

Permalink

[ https://issues.apache.org/jira/browse/MRM-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16287995#comment-16287995 ]

Martin Stockhammer commented on MRM-1964:
-----------------------------------------

Made some progress in changing the repository api. Next step is to split the indexer part to API and implementation specific implementations.

Post by Martin Stockhammer (JIRA)
Refactor repository api
-----------------------
Key: MRM-1964
URL: https://issues.apache.org/jira/browse/MRM-1964
Project: Archiva
Issue Type: Improvement
Reporter: Martin Stockhammer
Assignee: Martin Stockhammer
Fix For: 3.0.0
Currently, the repository access managed via the repository admin api and has several specifics in it that are highly dependent on the repository implementation.
At the time there is no way to provide another repository type without changing/duplicating code on a lot of different places.
Another issue, is that many modules are dependent on maven libraries.
Goal is to provide a central repository registry, that keeps track of repositories and delegates provider specific tasks to special repository providers.
Maven libraries should only be used in the repository provider implementations. All other modules should use the central repository api.

--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Martin Stockhammer (JIRA)

2018-04-17 20:04:00 UTC

Permalink

[ https://issues.apache.org/jira/browse/MRM-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16441418#comment-16441418 ]

Martin Stockhammer commented on MRM-1964:
-----------------------------------------

Still work in progress. RepositoryRegistry is mostly used in modules instead of RepositoryAdmin.

I'm separating the maven specific parts into their own modules

Post by Martin Stockhammer (JIRA)
Refactor repository api
-----------------------
Key: MRM-1964
URL: https://issues.apache.org/jira/browse/MRM-1964
Project: Archiva
Issue Type: Improvement
Reporter: Martin Stockhammer
Assignee: Martin Stockhammer
Priority: Major
Fix For: 3.0.0
Currently, the repository access managed via the repository admin api and has several specifics in it that are highly dependent on the repository implementation.
At the time there is no way to provide another repository type without changing/duplicating code on a lot of different places.
Another issue, is that many modules are dependent on maven libraries.
Goal is to provide a central repository registry, that keeps track of repositories and delegates provider specific tasks to special repository providers.
Maven libraries should only be used in the repository provider implementations. All other modules should use the central repository api.

--
This message was sent by Atlassian JIRA
(v7.6.3#76005)