[
http://jira.codehaus.org/browse/MRM-1025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=198788#action_198788
]
Brett Porter commented on MRM-1025:
-----------------------------------
the next step is to remove the ProjectModelToDatabaseConsumer as this is the
only remaining requirement for the second database scan.
The following relies on the project model directly:
- the dependency-graph module (in turn, used only by the DependencyTree tag in
the webapp, as it was not implemented for XMLRPC)
- DefaultRepositoryBrowsing (see below)
- DatabaseProjectModelResolver. This is primarily used in populating the model
itself, and the dependency graph. If the above usages are removed, this can be
removed.
The following utilise DefaultRepositoryBrowsing:
- "used by" in the webapp
- all tabs of the artifact page (ShowArtifactAction)
- the "shared model" on the artifact parent page
- to determine the artifact packaging in XMLRPC search (falls back to JAR -
this code should be improved)
- getDependencies in XMLRPC
The key step is to introduce a metadata content repository API that can be a
single touchpoint for the application, rather than the current situation of
spreading between the repository-layer and direct access to the database which
makes the availability of the model unreliable, is not easily extensible by
plugins, and causes the main need for slow pre-scanning.
I believe the next steps are to flesh out the new metadata content repository
api to support querying the above information. While it could be made to
continue to interface to the existing database using the same resolvers, I
believe it is valuable to simplify it using existing APIs and then revisit
functionality that might need to catch up. Therefore, it can have a dumb
implementation to start with (perhaps going back to reading the POM and
dependency tree on demand for most uses, and not implementing get used by
initially), and be improved later.
The API can be tested by migrating browse and xmlrpc to it, then removing the
dependency graph module and unprocessed database consumers, model code,
database scheduler and corresponding UI. If this is successful, other uses of
the database can be moved over (RSS, other browse and xmlrpc functionality, and
reporting) and the tree / used by made to work again. Following that, uses of
repository-layer and model can be moved over as well and deletion scanning
revisited.
> make the archiva database an optional part of the installation
> --------------------------------------------------------------
>
> Key: MRM-1025
> URL: http://jira.codehaus.org/browse/MRM-1025
> Project: Archiva
> Issue Type: Task
> Reporter: Brett Porter
> Assignee: Brett Porter
> Fix For: 1.3
>
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
