Resolving framework

[Antoine Toulme <an...@lunar-ocean.com>]

Guys, I am starting to work on a resolving framework that we would use with
Buildr.

I meant to start working with the wiki but for some reason I cannot access
it ? It looks like it is down.

I have pasted my thoughts there as a textile gist:
http://gist.github.com/362565

I am starting the work on a branch of my buildr fork on github. I will reuse
the work I did for buildr4osgi.

Please feel free to challenge the approach I'm taking. The intentions are
discussed in the first paragraph, and it cuts the chase down to the dirty
details right away.

Thanks,

Antoine

Re: Resolving framework

[Antoine Toulme <an...@lunar-ocean.com>]

Thanks for looking at the code Alex, let me try to answer your questions
below:

On Mon, Apr 12, 2010 at 02:49, Alex Boisvert <al...@gmail.com>wrote:

> I'm not clear on a few design aspects...
>
> Why are dependencies/projects located under the resolver?  Shouldn't the
> resolver be just an attribute instead of a structural element?
>
I want to give the opportunity for projects to have more than one resolver.
I also wanted the file to be easy to edit.
Using the current structure, it sounds easier to me. What structure would
you have in mind ? What do you mean by attribute ?

>
> Are only resolved transitive dependencies persisted in this file?  (Where)
> do you persist transitive dependencies that are used during the resolution
> process?  If they are not stored, then what's the difference between your
> proposal and artifact namespaces?
>
Yes, in the file you only store the outcome.
Each resolver will provide its own mechanism to specify the dependencies
used for resolution. For example, in OSGi, all you need is a MANIFEST.MF
file.
For poms, I would have the resolver extend the project or read the
package(:jar).pom. I don't know yet.

>
> Where do exclusions/overrides go?
>
The idea is that the file is free for the users to edit. Resolution happens
as part of the process of figuring dependencies. You can override anytime.
Do you think we need to filter more than that ?

>
> IMO, project dependencies should be kept in the buildfile.  Also, keep in
> mind it's currently possible for a project to depend only on a select few
> artifacts of another project.
>
Well, my experience with OSGi concurs with what you are telling me: when we
resolve all the dependencies transitively and add them all up for the
project, we get more than we need for compilation. But in my experience so
far I could not determine a minimum set. It also hasn't been the approach of
the OSGi world.
I don't see how to keep those dependencies in the Buildfile ?

>
> alex
>
>
> On Sun, Apr 11, 2010 at 12:31 AM, Antoine Toulme <an...@lunar-ocean.com>wrote:
>
>> Guys, I am starting to work on a resolving framework that we would use
>> with
>> Buildr.
>>
>> I meant to start working with the wiki but for some reason I cannot access
>> it ? It looks like it is down.
>>
>> I have pasted my thoughts there as a textile gist:
>> http://gist.github.com/362565
>>
>> I am starting the work on a branch of my buildr fork on github. I will
>> reuse
>> the work I did for buildr4osgi.
>>
>> Please feel free to challenge the approach I'm taking. The intentions are
>> discussed in the first paragraph, and it cuts the chase down to the dirty
>> details right away.
>>
>> Thanks,
>>
>> Antoine
>>
>
>

Re: Resolving framework

[Alex Boisvert <al...@gmail.com>]

I'm not clear on a few design aspects...

Why are dependencies/projects located under the resolver?  Shouldn't the
resolver be just an attribute instead of a structural element?

Are only resolved transitive dependencies persisted in this file?  (Where)
do you persist transitive dependencies that are used during the resolution
process?  If they are not stored, then what's the difference between your
proposal and artifact namespaces?

Where do exclusions/overrides go?

IMO, project dependencies should be kept in the buildfile.  Also, keep in
mind it's currently possible for a project to depend only on a select few
artifacts of another project.

alex

On Sun, Apr 11, 2010 at 12:31 AM, Antoine Toulme <an...@lunar-ocean.com>wrote:

> Guys, I am starting to work on a resolving framework that we would use with
> Buildr.
>
> I meant to start working with the wiki but for some reason I cannot access
> it ? It looks like it is down.
>
> I have pasted my thoughts there as a textile gist:
> http://gist.github.com/362565
>
> I am starting the work on a branch of my buildr fork on github. I will
> reuse
> the work I did for buildr4osgi.
>
> Please feel free to challenge the approach I'm taking. The intentions are
> discussed in the first paragraph, and it cuts the chase down to the dirty
> details right away.
>
> Thanks,
>
> Antoine
>

Re: Resolving framework

[Antoine Toulme <an...@lunar-ocean.com>]

First commit here<http://github.com/atoulme/buildr/commit/e5923752d84d8dd7199f2bc8dc58449c6da1ba58>covers
the bases on the file format, and sets an API for the resolution of
artifacts.

My next code run will cover coding the tasks for users to trigger resolving.

Antoine

On Sun, Apr 11, 2010 at 00:31, Antoine Toulme <an...@lunar-ocean.com>wrote:

> Guys, I am starting to work on a resolving framework that we would use with
> Buildr.
>
> I meant to start working with the wiki but for some reason I cannot access
> it ? It looks like it is down.
>
> I have pasted my thoughts there as a textile gist:
> http://gist.github.com/362565
>
> I am starting the work on a branch of my buildr fork on github. I will
> reuse the work I did for buildr4osgi.
>
> Please feel free to challenge the approach I'm taking. The intentions are
> discussed in the first paragraph, and it cuts the chase down to the dirty
> details right away.
>
> Thanks,
>
> Antoine
>
>
>