You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

I'm writing here some thoughts about the refactoring for version 3.0


Main Goals

  • Remove dependencies to 'maven' packages in central modules
    • Maven should be just a implementation of a specific type of repository. Maven specifics should not be part of central APIs
  • Provide central generic API for repository handling, with implementations in separate modules.
    • Start with maven as implementation
    • Try to abstract the concepts
  • Try to reduce/remove redundant APIs
    • E.g. there are different ways to access the physical files of a repository → MetaData, Repository implementation, Repository API
  • Improve performance
    • Find pain points
  • Upgrade  the used libraries / dependencies
    • Use newer maven libraries and API
    • Update selenium web tests
    • Update versions of all maven plugins used
    • Get rid of maven plugins that are not used
  • Modernize the techniques libraries used for Web UI
  • Rename packages to mirror the main architecture
    • Unique naming for maven specific packages → bundle them under one tree
    • plugins folder : Does it make sense? What is a plugin exactly?
  • Update documentation
  • Remove functionality that is not needed and/or not used


Specifics / Things to consider

Central Repository API

  • We use the new RepositoryRegistry as entry point for repository usage
    • This is a singleton spring bean
    • Should have not much dependencies to other modules - helps avoid dependency cycles
  • Change ArchivaAdministration usage to RepositoryRegistry where possible

Metadata Repository

I'm not sure about the complete intended role of the metadata-repository-api project.

  • As I know repository metadata was introduced to allow to store arbitrary
    information to artifacts / paths in repositories that cannot be stored by the normal repository technique (e.g. maven pom files).
  • Metadata is also used for fast access to artifact information and to implement search functionality.

I think the MetadataRepository has API that is redundant and should be migrated to a central API:

  • The storage API should not be part of the metadata repository → Try to merge with the central API (RepositoryRegistry)
  • Not sure about the resolver API and the difference to the direct repository access → More investigation needed
  • We have redundant information: In the metadata storage and in the artifacts / paths of the artifacts
    • When do we access which type of information? Are there patterns?
    • Is it possible to unify the access to the information? What about changes / updates?


The RepositorySession is a real performance killer as it is implemented at the time. Session creation (especially for JCR) are really heavyweight methods,
but are used in many parts of archiva, even in audit log listeners.

  • Think about the session concept - does it make sense? What does a session mean in the underlying storage?
  • Better one session per user? - But what is with scheduled tasks?
  • Session Caching?



  • No labels