You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by "Brett Porter (JIRA)" <ji...@codehaus.org> on 2005/05/16 07:35:35 UTC
[jira] Closed: (MAVEN-568) Mechanism for installing non-downloadable artifacts
[ http://jira.codehaus.org/browse/MAVEN-568?page=all ]
Brett Porter closed MAVEN-568:
------------------------------
Resolution: Won't Fix
as much fun as it was to see goals "maven sucks" and "maven blows", the solution in Maven 2.0 works and this, to me, seems to require as much effort as copying files to the local repo.
> Mechanism for installing non-downloadable artifacts
> ---------------------------------------------------
>
> Key: MAVEN-568
> URL: http://jira.codehaus.org/browse/MAVEN-568
> Project: maven
> Type: Improvement
> Reporter: Brian Ewins
> Attachments: sucks.zip
>
>
> Many artifacts maven users need are not downloadable, or are not redistributable from their original download location - e.g. many Sun jars, Oracle drivers, etc. We need a mechanism which makes it easy for users to install such jars in the same place 'globally' so that people can share project.xmls - i.e. if my project.xml mentions ejb-2.1.jar then I can rely on you having installed it to the same name in your repository.
> Attached is a work-in-progress plugin which addresses this need. It uses md5 checksums as unique file identifiers, given an xml file containing the usual dependency information along with the checksums, it can scan a directory, recognize files to install, and install them in the correct place in the repository.
> In order to make it easier to use, and to help bootstrap the system, it can also scan the directory and create the xml file it needs from the files it finds there, guessing the dependency information that would be needed. This covers two scenarios: scanning a local repository to create an accurate descriptor for whats in there, and scanning a directory of some unknown jars, to create a descriptor you can edit (eg to correct version info, group ids, etc)
> To build, unzip to plugins-build, creating the 'sucks' directory. cd to the directory and do 'maven plugin:install'. Now you can do 'maven blows' to create a 'sucks.xml' file from your local repo. Now try 'maven sucks', and it should recognize the plugin jar you just created. Take a look at the sucks.xml file. The plugin.jelly currently prevents you from installing anything by accident, take a look.
> Todo: make the code more testable, and write a ton of tests; write some documentation; write sucks.xml in a more sensible order (by groupid, artifactid, version); deal with SNAPSHOTS (they shouldn't be stored in the map); get this to work in directories with no project.xml (currently needed for maven.repo.local - I get an NPE in non-project directories). Suggestions on fixing that last one would be much appreciated.
> Anyway, here's the first draft so people can take potshots.
--
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