You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@buildr.apache.org by Daniel Spiewak <dj...@gmail.com> on 2008/04/11 21:57:37 UTC
POM-Only Transitive Dependencies
It's a fairly common pattern in Maven2 for complex projects to release their
artifacts as separate modules, often with one (or more) "super-modules"
which act as transitive dependency aggregators. For example,
Databinder<http://databinder.net>(though I have read that Hibernate
does the same thing for certain
dependency paths). There is an apparently known
bug<https://issues.apache.org/jira/browse/BUILDR-9>in Buildr where it
attempts to download a JAR for
*every* dependency in the chain, including those for which no JAR exists.
An experimental patch was attached to the BUILDR-9 issue which supposedly
fixes the problem, but I applied the patch and installed Buildr from the SVN
and it still seems to be an issue. This seems like a simple thing to fix
(as the patch demonstrates), but I obviously don't know enough about the
architecture to do it. Also, Gem development is painful on Windows. :-S
Are there any plans to fix this in the near future? All of the issues I've
seen related to it seem to be conspicuously silent in terms of developer
feedback. What's the official word?
Daniel
Re: POM-Only Transitive Dependencies
Posted by Daniel Spiewak <dj...@gmail.com>.
What about creating a stub pom that has practically nothing in it and
doesn't correspond to any JAR? It's not really broken dependencies, just a
POM that exists solely for the purpose of triggering transient dependencies
to other artifacts. I don't think this is an issue with the transitive
functionality, but rather an assumption made by the JAR resolution.
Obviously I could be totally off base on that (knowing almost nothing about
the code), but from what I've seen, that seems to be more the case. I would
be willing to write up an RSpec for this, except for the fact that I a)
don't know RSpec, and b) don't know maven. :-) Anyway, aside from those
two limitations I'd love to help out!
Daniel
On Fri, Apr 11, 2008 at 9:11 PM, Assaf Arkin <ar...@intalio.com> wrote:
> On Fri, Apr 11, 2008 at 6:41 PM, Daniel Spiewak <dj...@gmail.com>
> wrote:
>
> > repositories.remote << 'http://databinder.net/repo/'
> > repositories.remote << 'http://download.java.net/maven/2/'
> > repositories.remote << 'http://repo1.maven.org/maven2/'
> >
> > define 'TestProject' do
> > project.version = '0.1'
> >
> > compile.with transitive('net.databinder:databinder-app-ao:1.2-alpha1')
> >
> > package :jar
> > end
> >
> > If you run that, Buildr eventually complains and gives up when it tries
> to
> > download *databinder-parent-1.2-alpha1.jar *(I think that's the file
> > anyway). It's 100% repeatable for me.
>
>
> The problem is we can't put this in the test suite. We need the tests to
> run quickly and not depend on a public repository, that way we can run
> them
> often. I typically run the full test suite several time before making a
> commit. Here's what my history file looks like:
>
> ~/work/buildr $ history|awk '{print $2}'|sort|uniq -c|sort -rn|head
> 232 spec
> 50 rake
> 32 sudo
> 29 git
> 19 svn
> 19 cd
> 18 gem
> 17 ls
> 9 irb
> 8 vim
>
> To get a failing test we need to mock the repository with broken
> dependencies. Unfortunately, bugs like this take longer to test than to
> fix, but it will be done.
>
> Assaf
>
>
> >
> >
> > Daniel
> >
> >
>
Re: POM-Only Transitive Dependencies
Posted by Assaf Arkin <ar...@intalio.com>.
On Fri, Apr 11, 2008 at 6:41 PM, Daniel Spiewak <dj...@gmail.com> wrote:
> repositories.remote << 'http://databinder.net/repo/'
> repositories.remote << 'http://download.java.net/maven/2/'
> repositories.remote << 'http://repo1.maven.org/maven2/'
>
> define 'TestProject' do
> project.version = '0.1'
>
> compile.with transitive('net.databinder:databinder-app-ao:1.2-alpha1')
>
> package :jar
> end
>
> If you run that, Buildr eventually complains and gives up when it tries to
> download *databinder-parent-1.2-alpha1.jar *(I think that's the file
> anyway). It's 100% repeatable for me.
The problem is we can't put this in the test suite. We need the tests to
run quickly and not depend on a public repository, that way we can run them
often. I typically run the full test suite several time before making a
commit. Here's what my history file looks like:
~/work/buildr $ history|awk '{print $2}'|sort|uniq -c|sort -rn|head
232 spec
50 rake
32 sudo
29 git
19 svn
19 cd
18 gem
17 ls
9 irb
8 vim
To get a failing test we need to mock the repository with broken
dependencies. Unfortunately, bugs like this take longer to test than to
fix, but it will be done.
Assaf
>
>
> Daniel
>
>
Re: POM-Only Transitive Dependencies
Posted by Daniel Spiewak <dj...@gmail.com>.
repositories.remote << 'http://databinder.net/repo/'
repositories.remote << 'http://download.java.net/maven/2/'
repositories.remote << 'http://repo1.maven.org/maven2/'
define 'TestProject' do
project.version = '0.1'
compile.with transitive('net.databinder:databinder-app-ao:1.2-alpha1')
package :jar
end
If you run that, Buildr eventually complains and gives up when it tries to
download *databinder-parent-1.2-alpha1.jar *(I think that's the file
anyway). It's 100% repeatable for me.
Daniel
On Fri, Apr 11, 2008 at 8:35 PM, Assaf Arkin <ar...@intalio.com> wrote:
> On Fri, Apr 11, 2008 at 12:57 PM, Daniel Spiewak <dj...@gmail.com>
> wrote:
>
> > It's a fairly common pattern in Maven2 for complex projects to release
> > their
> > artifacts as separate modules, often with one (or more) "super-modules"
> > which act as transitive dependency aggregators. For example,
> > Databinder<http://databinder.net>(though I have read that Hibernate
> > does the same thing for certain
> > dependency paths). There is an apparently known
> > bug<https://issues.apache.org/jira/browse/BUILDR-9>in Buildr where it
> > attempts to download a JAR for
> > *every* dependency in the chain, including those for which no JAR
> exists.
> >
> > An experimental patch was attached to the BUILDR-9 issue which
> supposedly
> > fixes the problem, but I applied the patch and installed Buildr from the
> > SVN
> > and it still seems to be an issue. This seems like a simple thing to
> fix
> > (as the patch demonstrates), but I obviously don't know enough about the
> > architecture to do it.
>
>
> The trick is to actually write a test case to verify that the patch works,
> and we don't accidentally break it when we change how POM.load works,
> which
> was required for other bugs. We'll get it closed before 1.3.
>
>
>
> > Also, Gem development is painful on Windows. :-S
> > Are there any plans to fix this in the near future? All of the issues
> > I've
> > seen related to it seem to be conspicuously silent in terms of developer
> > feedback. What's the official word?
>
>
> We just entered "get it stable for a 1.3 release" stage, so no more big
> changes to trunk. Anything specific you're seeing?
>
> Assaf
>
>
> >
> >
> > Daniel
> >
>
Re: POM-Only Transitive Dependencies
Posted by Assaf Arkin <ar...@intalio.com>.
On Fri, Apr 11, 2008 at 12:57 PM, Daniel Spiewak <dj...@gmail.com>
wrote:
> It's a fairly common pattern in Maven2 for complex projects to release
> their
> artifacts as separate modules, often with one (or more) "super-modules"
> which act as transitive dependency aggregators. For example,
> Databinder<http://databinder.net>(though I have read that Hibernate
> does the same thing for certain
> dependency paths). There is an apparently known
> bug<https://issues.apache.org/jira/browse/BUILDR-9>in Buildr where it
> attempts to download a JAR for
> *every* dependency in the chain, including those for which no JAR exists.
>
> An experimental patch was attached to the BUILDR-9 issue which supposedly
> fixes the problem, but I applied the patch and installed Buildr from the
> SVN
> and it still seems to be an issue. This seems like a simple thing to fix
> (as the patch demonstrates), but I obviously don't know enough about the
> architecture to do it.
The trick is to actually write a test case to verify that the patch works,
and we don't accidentally break it when we change how POM.load works, which
was required for other bugs. We'll get it closed before 1.3.
> Also, Gem development is painful on Windows. :-S
> Are there any plans to fix this in the near future? All of the issues
> I've
> seen related to it seem to be conspicuously silent in terms of developer
> feedback. What's the official word?
We just entered "get it stable for a 1.3 release" stage, so no more big
changes to trunk. Anything specific you're seeing?
Assaf
>
>
> Daniel
>