Ok, that seemed to have resolved the POM-only problem (sort of, it's still a pain). However, it still refuses to generate an eclipse project file. I'm attaching (or trying anyway) a buildfile which does this for me. Basically, buildr just silently refuses to generate the metadata:
C:\Users\Daniel Spiewak\Development\workspace\TestApp>buildr eclipse (in C:/Users/Daniel Spiewak/Development/workspace/TestApp, development) Completed in 1.071s C:\Users\Daniel Spiewak\Development\workspace\TestApp> Daniel Spiewak wrote: > > Yeah, that's because my test case doesn't include the repo1 repository. > I'll try the artifact enhancer thingy. Thanks! > > Daniel > > > Assaf Arkin wrote: >> >> On Tue, Apr 29, 2008 at 11:31 PM, Daniel Spiewak <[EMAIL PROTECTED]> >> wrote: >> >>> >>> It's not that the POM is missing, it's that there's no JAR which >>> corresponds >>> to the POM. This is less often a case of broken deployment (though that >>> does happen) and more usually where a large project with complicated >>> dependencies tries to simplify their deployment by building a >>> "super-package" which depends upon everything below it. In short, it's >>> a >>> package which exists solely for the purpose of transitive dependencies. >>> In >>> my test case, the super-package is ``databinder-parent``. I don't >>> remember >>> what the artifact name is for the Hibernate super-package. >>> >>> Maybe I'm misunderstanding your notes in the troubleshooting doc, but it >>> looks like that just fixes the problems with missing POM. Is there any >>> way >>> to work around the non-JAR? (since it isn't really missing) >> >> >> Same thing, enhance the artifact to create a fake (empty) zip: >> >> artifact 'example:com:jar:1.0' do |task| >> mkpath File.dirname(task.to_s) >> Zip::ZipOutputStream.open task.to_s >> end >> >> >> When I run this test, I get an error like this: >> >> Failed to download org.apache.wicket:wicket:pom:1.3.2, tried the >> following >> repositories: >> http://databinder.net/repo/ >> >> Assaf >> >> >> >>> >>> Daniel >>> >>> >>> Assaf Arkin wrote: >>> > >>> > On Tue, Apr 29, 2008 at 8:48 PM, Daniel Spiewak <[EMAIL PROTECTED]> >>> > wrote: >>> > >>> >> https://issues.apache.org/jira/browse/BUILDR-63 >>> >> >>> >> Might want to hold off on that release. It seems that the bug with >>> >> POM-only >>> >> projects still hasn't been fixed. Since there are a large number of >>> >> projects (including Hibernate) which make use of this to aggregate >>> >> transitive dependencies, this really isn't something which can be >>> ignored >>> >> for 1.3 unless we're giving up on the idea of stable transitive >>> >> dependencies >>> >> in this release. >>> > >>> > >>> > I have some ideas on how to do transitive dependencies right, but >>> those >>> > will >>> > have to wait for after the 1.3. It's a pretty big deal and something >>> I'd >>> > like to see as the main focus for 1.4 (along with version matching and >>> > OSGi >>> > support). >>> > >>> > The transitive method is still marked as experimental, it's supposed >>> to >>> > carry us until we get real transitive support, so it should be fixed >>> but >>> > can't hold the release. >>> > >>> > The quick workaround until we get to test and fix it, is to fake the >>> > missing >>> > artifact/POM: >>> > >>> > >>> http://people.apache.org/~assaf/buildr/1.3.0/site/troubleshooting.html#missing_pom_breaks_transitive_dependencies >>> > >>> > Assaf >>> > >>> > >>> >> >>> >> >>> >> Daniel >>> >> >>> > >>> > >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/-RESULT---VOTE-%3A-Buildr-1.3-release-tp16944355p16976533.html >>> Sent from the Buildr - Dev mailing list archive at Nabble.com. >>> >>> >> >> >> -- >> CTO, Intalio >> http://www.intalio.com >> >> > > http://www.nabble.com/file/p16988713/buildfile buildfile -- View this message in context: http://www.nabble.com/-RESULT---VOTE-%3A-Buildr-1.3-release-tp16944355p16988713.html Sent from the Buildr - Dev mailing list archive at Nabble.com.
