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. 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". 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. alex
