On Tue, Feb 2, 2010 at 08:05, Alex Boisvert <[email protected]> wrote:
> On Mon, Feb 1, 2010 at 8:14 PM, Antoine Toulme <[email protected]>wrote: > >> I have given a bit of thought on the best way to do transitive >> dependencies. >> >> Actually, I wrote a Buildr plugin named buildr4osgi that resolves >> transitive >> dependencies for OSGi projects. >> >> I learnt a few lessons while playing with concepts and implementing it: >> >> 1. Resolving is a step in your build. >> You want your build to be reproducible. >> So one improvement with Maven is that your Buildr build should be always >> reproducible. You resolve once, and then always refer to the same >> artifacts. >> > > Yes, said differently I want to manage my dependencies explicitly -- not > have some sort of randomized process for resolving dependencies every time > the build is run. > > >> 2. There should be a file with your dependencies >> The dependencies should be resolved in a file next to your Buildfile. >> For Buildr4OSGi, we used a dependencies.yml with this format: >> >> project.id >> dependencies: >> ... >> projects: >> ... >> > > Agreed. Resolved dependencies should be persisted. > > 3. Projects may be dependencies too >> It's not because you use transitive dependencies that you cannot use the >> project next to you. You should give priority to projects sitting next to >> yours over dependencies while resolving. >> > > Yes, although I'm not sure what you mean by priority. When reusing a > project, I don't mind defaulting to its project's dependencies but I may > still want to override some. I think priority goes to locally defined > dependencies. > What happened while I was hacking is that I could refer to a dependency named core in the manifest, and the Eclipse instances I was browsing for those dependencies contained a core-2.1.0.0004.jar plugin that matched. However, next to my project, in the same buildfile, a project named core was also defined. The id of the project matches the dependency name, and will match the symbolic id when we package it as a OSGi bundle. By default, projects then have a higher priority than whatever else you can resolve. > > 4. Your dependencies should be available through a method, not implied. >> Never imply you are going to use the dependencies by default. You may also >> want to add additional dependencies. >> In Buildr4OSGi, we used the "dependencies" method, it gave something like >> this: >> >> compile.with dependencies, AXIS2, COMMONS >> > > I see this more as a preference than a requirement. Personally, I would > prefer to have nothing rather than a line that says only "compile.with > dependencies". > For OSGi it made sense to do that, because you had OSGi dependencies you could infer from the manifest, and jar dependencies that were to be packaged in the plugin. > > I would be ready to look into ivy4r and reuse it, or backport pieces of >> Buildr4OSGi into Buildr into something rock solid. >> > > Start hacking away! I'm currently looking into the bowels of Ivy to see > how we could reuse it for an interactive dependency management shell; > stemming from requirement #1 Ivy would only be used to resolve dependencies > at build-definition time and not (typically) used during build-time. > Ok good plan. I would like to start with the file definition. It needs to be very easy to apprehend. Here is the deal though: there may more than one way to resolve dependencies already. We can use more depths in the file: myproject: dependencies: osgi: foo bar maven: foobar projects: osgi: project2 maven: But that looks ridiculously complicated, for no good reasons. > > alex >
