Resolution: Won't Fix
Affects Version/s: None
Fix Version/s: None
Number of attachments :
Currently if a corporate Maven installation is set up with an internal repository and wants their developers to only use the internal repository (not remote repositories such as ibiblio) they have to manually place the files needed for a project into the repository. They may have their internal repository stored in a source control system, with restricted update access.
The corporation may use some artifacts from open source projects and others from an ISV, where the ISV has their own remote repository and their code may not be open source, so therefore the source code may not be available and the corporate user can't build the ISV's code from the source and deploy to their internal repository.
The corporation may not be keen on maven-proxy since an end user doing a build causes artifacts from the remote repository to the downloaded and placed in maven-proxy's cache and does not allow a corporation to review and control of what is being used by their developers (and what may end up running on their machines containing sensitive information). They may want to review the artifacts used for legal, risk management, licensing reasons.
The corporation could have an employee who has the role of reviewing the artifacts required by corporation's developers and if ok, updating the internal repository with the artifacts. Only that employee has update access to the internal repository and they may use a machine that has Internet access to remote repositories ibiblio etc (other development machines or servers may not have general internet access for security reasons).
The tool needed should not just work on a single artifact; it should be able to work with a POM to get all the required artifacts.
The employee who has update access to the internal repository would probably want to be able to point to a POM and be able to get a list of its dependencies, the remote repository location and associated license info so they can decide whether to go ahead with importing the artifacts into their internal repository. It would be helpful if the tool can exclude displaying artifacts/dependencies they already have in their internal repository.
A related idea...
It may also be useful if there was a tool that could build a zipped repository of the artifacts required by a project, so that could be included with the project's software on an installation CD. The tool would then be used by the person installing the software to read the zipped repository and load it into their internal repository (with the opportunity to review what is being placed in their internal repository). This may also be useful for ISVs that don't want to place their artifacts on an Internet accessible repository and want to only ship them on CD because they have more control over who has access to the software.