On Sat, Nov 14, 2009 at 9:42 AM, Xavier Hanin <xavier.ha...@gmail.com>wrote:
> One thing I'm not sure to fully understand: it seems that you plan to store
> the index on the client (say the developer's box), according to your
> example
> with dir="${ivy.settings.dir}/index". But it also seems like every client
> will have the responsibility to maintain the index, is that right? Sound's
> strange, there's probably something I miss?
>
As a best practice recommendation, I would suggest that the index be stored
on the same box as the repository (of course, I think the index task and the
proxying resolver should allow for the index to be stored anywhere you
choose). I do not see any reason for there to be more than one index per
repository.
This single index should be as close to representative of the real-time
state of the repository as possible. In the case where repository artifacts
are added mainly through publish/deliver/install and these tasks are routed
through the indexing proxy, the index will always match the real-time state
of the repository. In the case where repository artifacts are added
manually by a repository administrator, the index will lack the types
defined in these artifacts until the administrator runs the index task.
Thus, the responsibility for maintaining the index belongs with the some
combination of the proxying resolver and the index task, their precise
relationship being defined by the use case.
All clients would then read from the same index. The Quick Search feature
only reads the index, it does not modify it.
On Sun, Nov 15, 2009 at 6:04 AM, Gilles Scokart <gscok...@gmail.com> wrote:
> I have already some code doing that. If you are interrested, you can find
> it at http://sourceforge.net/projects/deco-project/.
>
> For the moment it can just check the compile time dependencies. I would
> like to try to play further with it in order to check also runtime dep.
> The
> idea that I have is to write a kind of byte code interpreter that either
> simulate the execution of the simple java code, either fall back to real
> execution of some piece of code when it is too dynamic (with the help of
> some external configuration).
The compile time dependencies (Java types, not artifacts) are already
computed by Eclipse and made available via the "search engine" API. Again,
I haven't found a public facing interface to this yet, but I haven't looked
all that intensively. There may not be one. Runtime dependencies are very
tricky. I'll be interested in your thoughts on the byte code interpreter.
The only idea that has occurred to me is using the reports generated by
Clover.
Jon
