You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@buildr.apache.org by "Hok Shun Poon (JIRA)" <ji...@apache.org> on 2012/06/07 20:42:23 UTC

[jira] [Created] (BUILDR-644) 'buildr eclipse' or 'buildr idea' tasks downloads artefacts multiple times.

Hok Shun Poon created BUILDR-644:
------------------------------------

             Summary: '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


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

        

[jira] [Commented] (BUILDR-644) Zip file extraction feature does not work.

Posted by "Alex Boisvert (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/BUILDR-644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291343#comment-13291343 ] 

Alex Boisvert commented on BUILDR-644:
--------------------------------------

That's right, no zip-file extraction occurs -- that misleading and a documentation bug (which I'll fix).

If you want to extract jars from a zip file, there are several ways to do it.

Here's one approach you may want to consider: https://github.com/aboisvert/revolute/blob/master/buildfile
                
> Zip file extraction feature does not work.
> ------------------------------------------
>
>                 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

        

[jira] [Updated] (BUILDR-644) Zip file extraction feature does not work.

Posted by "Hok Shun Poon (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/BUILDR-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hok Shun Poon updated BUILDR-644:
---------------------------------

    Summary: Zip file extraction feature does not work.  (was: 'buildr eclipse' or 'buildr idea' tasks downloads artefacts multiple times.)
    
> Zip file extraction feature does not work.
> ------------------------------------------
>
>                 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

        

[jira] [Commented] (BUILDR-644) 'buildr eclipse' or 'buildr idea' tasks downloads artefacts multiple times.

Posted by "Alex Boisvert (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/BUILDR-644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291253#comment-13291253 ] 

Alex Boisvert commented on BUILDR-644:
--------------------------------------

Neither the 'eclipse' nor the 'idea' tasks should re-download artifacts.

I created the following simplified buildfile and I cannot reproduce your issue.  I ran both "buildr compile" and "buildr eclipse" separately.

VERSION_NUMBER = "1.0.0"

repositories.remote << "http://repo1.maven.org/maven2"

LIBGDX = "com.badlogic.gdx:gdx:jar:0.9.4"
LIBGDX_OPENAL = "com.badlogic.gdx:gdx-openal:jar:0.9.4"

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"

define "buildr-eclipse-downlad" do
  project.version = VERSION_NUMBER
  project.group = "org.example"
  compile.with LIBGDX, LIBGDX_OPENAL
  package(:jar)
end

                
> '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

        

[jira] [Commented] (BUILDR-644) 'buildr eclipse' or 'buildr idea' tasks downloads artefacts multiple times.

Posted by "Hok Shun Poon (JIRA)" <ji...@apache.org>.
    [ 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

       

[jira] [Updated] (BUILDR-644) Zip file extraction feature does not work.

Posted by "Peter Donald (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/BUILDR-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Donald updated BUILDR-644:
--------------------------------

    Fix Version/s: 1.5
    
> Zip file extraction feature does not work.
> ------------------------------------------
>
>                 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
>             Fix For: 1.5
>
>   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
For more information on JIRA, see: http://www.atlassian.com/software/jira