You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by "John Sisson (JIRA)" <ji...@codehaus.org> on 2005/08/15 02:01:57 UTC

[jira] Created: (MAVEN-1665) Provide plugin that can simplify the task of populating an internal repository with the artifacts required for a project

Provide plugin that can simplify the task of populating an internal repository with the artifacts required for a project
------------------------------------------------------------------------------------------------------------------------

         Key: MAVEN-1665
         URL: http://jira.codehaus.org/browse/MAVEN-1665
     Project: Maven
        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 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


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org