nadahar / external-maven-plugin Goto Github PK

What steps will reproduce the problem?
Use plugin with the following configuration
            <artifactItem>
              <groupId>com.github.voldemort</groupId>
              <artifactId>voldemort</artifactId>
              <version>0.90.1</version>
              <packaging>tar.gz</packaging>
              <downloadUrl>https//github.com/downloads/voldemort/voldemort/voldemort-0.90.1.tar.gz</downloadUrl>
              <extractFile>voldemort-0.90.1/dist/voldemort-0.90.1.jar</extractFile>
            </artifactItem>

What is the expected output? What do you see instead?
The plugin doesn't handle the HTTP status code 302 redirect and reports an 
invalid GZIP file.  It should handle the redirect transparently.

What version of the product are you using? On what operating system?
0.5

Please provide any additional information below.

The current checked in source will download a file from URL and install it as 
an artifact into the local M2 repository but the optional deployment of that 
artifact to a team M2 repository has not yet been implemented.

Currently working on adding support for this feature. 

Several artifactItems sharing the *same* downloadUrl (using different values 
for extractFile, of course) cause multiple downloads. This can be really 
annoying when extracting many small JARs from one very large archive. Thus, it 
would be nice if the maven-external-dependency-plugin could be smarter about 
this and hit each downloadUrl just once.

Currently, the maven-external-dependency-plugin is not marked @threadSafe; 
Maven 3 parallel builds thus issue a warning.

Hey, I made a patch to make possible unzip tar.gz files as well, it is not as 
efficient as the ZipFile, but it makes possible use a new set of compression 
formats.

Lemme know what you think about it.

VELO

Hi,

This is a very useful plugin, thank you :-)

Unfortunately we are using the plugin behind a proxy server which for reasons 
beyond out control makes downloads slow and frequently pause. As it is, the 
plugin times-out the connection before it has finished downloading.

We have checked out a copy of the code and fixed the problem locally by adding 
an Integer 'timeout' to the ArtifactItem and then using...

wagon.setTimeout(artifactItem.getTimeout());

...in the ResolveExternalDependencyMojo. This allows us to put  
<timeout>60000</timeout> within the relevant artifactItem element in the pom 
and then everything works nicely.

I attach the files we have amended in the hope that you can incorporate this 
(or something similar into the code base).

Many thanks
Rob

Currently, the maven-external-dependency-plugin is not overly smart about 
picking the right checksum algorithm straight-away; it always tries MD5 first 
and only if that fails does it try SHA1. Depending on the size of the external 
dependency, computing the ckecksum may take a few seconds, which could be saved 
if the plugin would apply the following heuristic:

  40 hex digits => 160 bit SHA-1 checksum
  otherwise => 128 bit MD5 checksum first, then 160 bit SHA-1 checksum

Alternatively, the plugin's goal would use two distinct parameters: md5checksum 
and sha1checksum, probably with checksum retained for compatibility.

maven-external-dependency-plugin-0.5-SNAPSHOT.pom is no longer available on the 
Sonatype OSS site:

https://oss.sonatype.org/content/groups/public/com/savage7/maven/plugins/maven-e
xternal-dependency-plugin/0.5-SNAPSHOT/

I'm trying to extract a jar from a zip file:

    <dependency>
        <groupId>de.innosystec</groupId>
        <artifactId>java-unrar</artifactId>
        <version>0.3</version>
    </dependency>

    <artifactItem>
        <groupId>de.innosystec</groupId>
        <artifactId>java-unrar</artifactId>
        <version>0.3</version>
        <packaging>jar</packaging>
        <downloadUrl>
            http://github.com/downloads/edmund-wagner/junrar/java-unrar-{version}.zip
        </downloadUrl>
        <install>true</install>
        <force>false</force>
        <extractFile>java-unrar/java-unrar-{version}.jar</extractFile>
        <checksum>530351609180152cff40fa1c79a28193185aba83</checksum>
    </artifactItem>

Whatever I place in the checksum, the build fails. If I use the checksum of the 
zip (530351609180152cff40fa1c79a28193185aba83), the resolve-external phase 
passes:

    [INFO] testing for SHA1 checksum on artifact: de.innosystec:java-unrar:0.3:jar
    [INFO] verification passed on SHA1 checksum for artifact: de.innosystec:java-unrar:0.3:jar

- but then validation fails for the jar in the install-external phase.

If I use the jar's SHA1 (bce51f76274c41ddac3ca8e99378ff2893108049), validation 
fails for the zip during the resolve-external phase.

If this is a bug (rather than a user error), perhaps an optional 
per-extracted-file checksum attribute could be added:

    <downloadUrl>http://www.example.com/foo.zip</downloadUrl>
    <checksum>123</checksum> <!-- for foo.zip -->
    <extractFile checksum="abc">bar.jar</extractFile> <!-- for bar.jar -->

maven-external-dependency-plugin 0.2-SNAPSHOT
Maven: 2.2.1
Java: 1.6.0_20
OS: Ubuntu 10.04

In order to prevent people from using the wrong artifact, would be nice to
have a checksum along with the url.

VELO

What steps will reproduce the problem?
1. Get yourself behind a proxy
2. Disable all other internet connections
3. try to download something with maven-external-dependency-plugin

What is the expected output? What do you see instead?
Expected: Download works, because my (http) proxy is configured in the 
settings.xml for maven.
Instead, i get a "Connection timed out" message.

What version of the product are you using? On what operating system?
Windows 7 x64, Plugin version 0.5-SONATYPE-r116

Please provide any additional information below.

Optimize the deploy-external goal to be a little more intelligent about only 
deploying files that it needs to.  The current implementation will deploy all 
external defined artifacts when the deploy-external goal is invoked.

Hey,

I did noticed you are using sonatype oss server to deploy releases, would be 
nice to promote this releases to maven central repository 
http://repo1.maven.org/maven2/

Right now it is only available at:
https://oss.sonatype.org/content/repositories/releases/


VELO

While running the plugin with Maven 2.2.1 I always run into NPE:


[INFO] [external-dependency:deploy-external {execution:
deploy-external-dependencies}]
[INFO] starting to deploy external dependencies to distribution repository
[INFO] resolving artifact in locale repository for deployment:
esi:common-content:12.2010.WEB10-SNAPSHOT:jar
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] null
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.NullPointerException
        at
org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.m
ergeMetadata(DefaultRepositoryMetadataManager.java:191)
        at
org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.r
esolve(DefaultRepositoryMetadataManager.java:166)
        at
org.apache.maven.artifact.transform.AbstractVersionTransformation.resolveVersion
(AbstractVersionTransformation.java:65)
        at
org.apache.maven.artifact.transform.SnapshotTransformation.transformForResolve(S
napshotTransformation.java:63)
        at
org.apache.maven.artifact.transform.DefaultArtifactTransformationManager.transfo
rmForResolve(DefaultArtifactTransformationManager.java:55)
        at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifa
ctResolver.java:145)
        at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifa
ctResolver.java:90)
        at
com.savage7.maven.plugin.dependency.DeployExternalDependencyMojo.execute(DeployE
xternalDependencyMojo.java:95)
        at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.ja
va:490)
        at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycl
eExecutor.java:694)
        at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(Def
aultLifecycleExecutor.java:556)
        at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycle
Executor.java:535)
        at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures
(DefaultLifecycleExecutor.java:387)
        at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultL
ifecycleExecutor.java:348)
        at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExec
utor.java:181)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
        at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.jav
a:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
        at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
        at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
        at org.codehaus.classworlds.Launcher.main(Launcher.java:376)

As it turns out, RemoteRepositories cannot be null, so I added the one from
current project settings.

Patch as attachment.

Attempt to resolve configured artifacts in remote repositories before 
downloading and installing one that may override a publicly hosted artifact.   

The maven-external-dependency-plugin does work with Maven 2.2, but fails
with 3.0-beta-1: It doesn't get a chance to resolve or install an external
dependency if it is declared as a project dependency under <dependencies>;
you get a MultipleArtifactsNotFoundException first.

Some projects are shipped as ZIP files, like GAE...

Would be awesome seeing it downloading it once
http://googleappengine.googlecode.com/files/appengine-java-sdk-1.3.0.zip
then unpacking and slicing it.

VELO

This is a bit wilder idea, but I think would be a nice add to your plugin,
specially if you really wanna follow that line of not screwing up the
artifacts already hosted on maven repo.

Let's say users put an entry to download an artifact.

And this artifact checksum is 'dcab88fc2a043c2479a6de676a2f8179e9ea2167' it
could be know ahead if user did inform this or calculated after the
artifact doesn't really matter.

Now, let's say user gave this artifact the following GAV
<groupId>org.apache.ant</groupId>
<artifactId>ant</artifactId>
<version>1.5</version>

But this checksum bellows to an artifact with a different GAV:
http://repository.sonatype.org/service/local/data_index?sha1=dcab88fc2a043c2479a
6de676a2f8179e9ea2167

I think you could use sonatype rest API to validate that.  And I would say
to fail the build if the artifact is already hosted on a know maven
repository.... specially if it's GAV doesn't match the repository GAV.


VELO

Some times I just wanna to extract a subdirectory of a zip into another zip.