[
https://issues.apache.org/jira/browse/BUILDR-644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291330#comment-13291330
]
Hok Shun Poon commented on BUILDR-644:
--------------------------------------
Okay, this is quite strange. Using your simplified script, I couldn't reproduce
it — so we agree there. I suspect compilation worked due to my earlier attempts
at installing libgdx. I have since purged my local repository of that set of
libraries.
What I have uncovered is actually a different issue altogether. It has to do
with the extraction behaviour actually. If you'll forgive me, I want to take
the liberty of changing the description of the bug to something entirely
different.
I find the zip-download-extract-publish feature as described on page 10 of the
documentation very handy. The DBPOOL example has a couple of typos and is
outdated since the time of writing, however.
Basically, I tried to observe the zip being downloaded, extracted, the JAR
published locally by making this small test buildfile in an otherwise blank
project.
== Reproduction ==
Use this buildfile
```
DBPOOL = 'net.snaq:dbpool:jar:5.0'
download artifact(DBPOOL) => 'http://www.snaq.net/java/DBPool/DBPool-5.0.zip'
define 'killer-app' do
project.version = '0.1.0'
compile.with DBPOOL
package :jar
end
```
and run 'buildr'.
Observe the content of the .jar published onto the local repository.
== Observations ==
After the build run I see, in my Maven repository
'~/.m2/repository/net/snaq/dbpool/5.0/dbpool-0.5.jar'.
However, this JAR file is _not what it looks like_ it is.
In actual fact, this JAR file is _not_ the JAR file we were expecting at all.
It's actually just the downloaded zip archive renamed into '.jar'.
This is easily verifiable: if you unzip
'~/.m2/repository/net/snaq/dbpool/5.0/dbpool-0.5.jar' you will find inside the
directory structure of the zip file, which of course includes the
'DBPool-5.0.jar' we wanted.
In short, I'm not convinced any zip-file extraction occurs as it says on the
documentation.
> 'buildr eclipse' or 'buildr idea' tasks downloads artefacts multiple times.
> ---------------------------------------------------------------------------
>
> Key: BUILDR-644
> URL: https://issues.apache.org/jira/browse/BUILDR-644
> Project: Buildr
> Issue Type: Bug
> Components: Dependency management
> Affects Versions: 1.4.7
> Environment: Ruby Version: ruby 1.8.7 (2010-01-10 patchlevel 249)
> [universal-darwin10.0]
> Java Version: java version "1.6.0_31"
> Java(TM) SE Runtime Environment (build 1.6.0_31-b04-415-10M3635)
> Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01-415, mixed mode)
> Reporter: Hok Shun Poon
> Priority: Minor
> Labels: dependencies, download, eclipse, extract, intellij, zip
> Original Estimate: 12h
> Remaining Estimate: 12h
>
> I would like to use the Buildr auto-extract + cache into local repository
> functionality with a rather funny setup.
> I'm using a library called libgdx, Android / HTML5 game library
> (http://libgdx.googlecode.com/files/libgdx-0.9.4.zip). This library is not on
> Maven Central, but is distributed as a zip containing 9 .jars on the top
> level of the zip hierarchy.
> A selection of these JARs are required to build my project successfully.
> Thus, I ensure that I declare the JARs as constants and tell Buildr that they
> can be found in the libgdx-0.9.4.zip URL:
> ```
> LIBGDX = "com.badlogic.gdx:gdx:jar:0.9.4"
> LIBGDX_OPENAL = "com.badlogic.gdx:gdx-openal:jar:0.9.4"
> ... (7 more)
> download artifact(LIBGDX) =>
> "http://libgdx.googlecode.com/files/libgdx-0.9.4.zip";
> download artifact(LIBGDX_OPENAL) =>
> "http://libgdx.googlecode.com/files/libgdx-0.9.4.zip";
> ... (7 more)
> ```
> Project declarations are as standard. For the sakes of illustration, try:
> ```
> ...
> compile.with LIBGDX, LIBGDX_OPENAL
> ...
> ```
> `buildr compile` succeeds in a short time, downloading the zip if it wasn't
> found, extracting, and publishing the named JARs into the local repository.
> The next time this is invoked, the local repository is inspected and are
> found, so no zip download is initiated. This is perfect behaviour.
> `buildr eclipse` and `buildr idea` however seem to totally ignore the local
> repository and just goes to download the listed artefacts in the sequence
> specified. This is disastrous for the build especially when all of the
> 'download artefact' directives point to the exact same 26MB zip!
> Please ensure commands that trigger a zip download inspects the local
> repository first!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
