[
https://jira.codehaus.org/browse/MAVEN-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MAVEN-1665.
---------------------------------
Resolution: Won't Fix
Please refer to
https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
if you're wondering why this issue was closed out.
> Provide plugin that can simplify the task of populating an internal
> repository with the artifacts required for a project
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: MAVEN-1665
> URL: https://jira.codehaus.org/browse/MAVEN-1665
> Project: Maven 1
> Issue Type: Wish
> Reporter: John Sisson
> Priority: Minor
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
