[
https://issues.apache.org/jira/browse/BUILDR-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Assaf Arkin closed BUILDR-58.
-----------------------------
Resolution: Invalid
The only problem I could find with this case is not being able to download POM
for DBPOOL. But if the source doesn't include any POM (or transitive
information), why apply the transitive function to it?
This will work:
compile.with transitive(DATABINDER_AO, HSQLDB, SL4J_JDK, JETTY), DBPOOL,
> Transitive Dependency Resolution Fails on Edge Cases
> ----------------------------------------------------
>
> Key: BUILDR-58
> URL: https://issues.apache.org/jira/browse/BUILDR-58
> Project: Buildr
> Issue Type: Bug
> Components: Dependency management
> Affects Versions: 1.2.10
> Environment: Windows Vista
> ruby 1.8.6 (2007-03-13 patchlevel 0) [i386-mswin32]
> Reporter: Daniel Spiewak
> Priority: Critical
>
> It looks like transitive dependency resolution fails when the dependencies
> include one of the two following cases (may be more, this is what I've seen):
> * Non-maven artifact (download artifact(BLAH))
> * Maven artifact with only POM (no JAR)
> Reproduce with the following buildfile:
> -------
> DATABINDER_AO = 'net.databinder:databinder-app-ao:jar:1.2-alpha1'
> HSQLDB = 'hsqldb:hsqldb:jar:1.8.0.7'
> SL4J_JDK = 'org.slf4j:slf4j-jdk14:jar:1.4.2'
> JETTY = group('jetty','jetty-util','jetty-ajp', 'servlet-api-2.5', :under =>
> 'org.mortbay.jetty', :version => '6.1.7')
> DBPOOL_VERS = '4.8.3'
> DBPOOL = "snaq.db.dbpool:dbpool:jar:#{DBPOOL_VERS}"
> download artifact(DBPOOL) =>
> "http://homepages.nildram.co.uk/~slink/java/DBPool/DBPool_v#{DBPOOL_VERS}.jar";
> repositories.remote << 'http://repo1.maven.org/maven2'
> repositories.remote << 'http://databinder.net/repo'
> repositories.remote << 'http://download.java.net/maven/2'
> define 'FreakyWiki' do
> project.version = '0.1'
> package :jar
>
> compile.with transitive(DATABINDER_AO, HSQLDB, \
> DBPOOL, \
> SL4J_JDK, JETTY)
> end
> --------
> To reproduce the second case, comment out the DBPOOL dependency. I can
> attach traces if you like, but this description is already pretty long.
> Marking as "Critical" because it's extremely important to what I'm doing with
> Buildr. Obviously things work fine if I just resolve all of the dependencies
> myself, but that throws a bit of a wrench into the works for my use-case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
