ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrien Lecharpentier <adrien.lecharpent...@gmail.com>
Subject Re: Creation of a new ivy resolver
Date Tue, 07 Aug 2012 13:05:41 GMT
Thank you for your time, I've answered in your mail.

-- Adrien

2012/8/7 Nicolas Lalevée <nicolas.lalevee@hibnet.org>

> I have looked at you patch more closely, and there are indeed some strange
> things. I don't understand why the parsing of a cudf file have to depend on
> the resolve context.


In fact, the resolving is done on server-side for CUDF. That's why we use
the resolve context to be able to ask the resolution for each specific
configuration.


> It means that this file format is not describing dependencies
> independently of a resolve. This format could not be used to describe the
> dependencies of a project in development ? It should only be used to
> describe transitive dependencies ?
>

We want to use this format to be able to generate resolution Q&A so that
client side doesn't have to care about conflicts.


> For instance the configurations declared for a parsed module are computed
> from the "root" ones.


We are working to modify that to be able to send all the dependencies set
in a configuration to have the list of all dependencies needed for the
configuration (1st-level and transitive deps).


> I understand the notion of configuration might not exist for cudf files.
> But then just choose the "default" configuration for instance. Then it is
> up to the root ivy file, if it is xml, to properly reference the "default"
> configuration implicitly declared in a cudf file.
>

We want to make one resolution question for each configuration of ivy file.


> And about the conflict resolution, it should be independent of the format
> of the module descriptor. Why and how the cudf format is enforcing it ?
>

Resolution is done on server side. The "list" of dependencies the client
gets is conflict-less.


> I think that what you should focus on is the mapping between the cudf
> format and the Ivy "ModuleDescriptor" model. AFAI, the cudf format has less
> features than Ivy does, so once you have done that, it will plug nicely
> into Ivy.

Look at how the OSGi support was implemented. First the mapping :
> http://ant.apache.org/ivy/history/latest-milestone/osgi/osgi-mapping.html(at some point
it will be really great the you write a such doc about the
> cudf format). Then, as the OSGi model has features Ivy doesn't have, I had
> to work around it by writing a resolver. But I don't think you need to for
> cudf.
>
> But I probably not know the cudf format as well as you do. Please correct
> me if I'm wrong.
>
> Nicolas
>
> Le 7 août 2012 à 11:33, Adrien Lecharpentier a écrit :
>
> > Hello,
> >
> > some updates on this question.
> > We've notice that the resolver is called at each dependency fetched. The
> > problem with that is the list of dependencies returned in the cudf
> > file/output is already conflict-less.
> >
> > That was on of the reason why we implement a resolver at first.
> >
> > Any thought about this?
> >
> > Thanks!
> >
> > --
> > Adrien Lecharpentier
> >
> >
> > 2012/5/25 Nicolas Lalevée <nicolas.lalevee@hibnet.org>
> >
> >> Hi Adrien,
> >>
> >> I just saw your patch in IVY-1352. So you found out that jira is the way
> >> to go, cool :)
> >>
> >> About the submission, given the size of the patch, when uploading your
> >> patch, you should check the button "Grant license to ASF for inclusion
> in
> >> ASF works". You should also remove the copyright notices in the header
> of
> >> the files. So it would clear the legal work.
> >>
> >> About the technical details, we'll discuss it in the jira issue.
> >>
> >> cheers,
> >> Nicolas
> >>
> >> Le 24 mai 2012 à 10:19, Adrien Lecharpentier a écrit :
> >>
> >>> Hello,
> >>>
> >>> I create a new resolver in Ivy and would like to integrate it into the
> >>> official source code repository.
> >>>
> >>> This new resolver is using a CUDF format to describe the dependencies
> of
> >> a
> >>> module. This description file is generated by a server. The aim is to
> >> have
> >>> a server side dependency resolution, the client site is onyl about to
> >>> download the description file, parse it and use information it
> contains.
> >>>
> >>> I used a fork of the github repository, work on a separate branch but I
> >>> integrate the changes you've done on trunk. How can I proceed to give
> you
> >>> the source code ?
> >>>
> >>> Thanks,
> >>>
> >>> --
> >>> Adrien Lecharpentier
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> >> For additional commands, e-mail: dev-help@ant.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>


-- 

--
Adrien Lecharpentier

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message