[
https://issues.apache.org/jira/browse/IVY-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782499#action_12782499
]
Jon Schneider edited comment on IVY-1143 at 11/25/09 5:02 PM:
--------------------------------------------------------------
I am flexible on just about every point here...
Below is a sample Ivy settings file employing an index. Indexes are defined in
much the same way that caches are. I am of the opinion right now that there
should not be a default indexer like there is a default cache. The index
attribute is valid on RepositoryResolver subclasses (see note on publish hook).
{code:xml}
<ivysettings>
<settings defaultResolver="1"/>
<resolvers>
<filesystem name="1" index="index1">
<ivy
pattern="${ivy.settings.dir}/[organisation]/[module]/ivy-[revision].xml"/>
<artifact
pattern="${ivy.settings.dir}/[organisation]/[module]/[type]/[artifact]-[revision].[ext]"/>
</filesystem>
</resolvers>
<indexes>
<index name="index1" storageDir="${ivy.settings.dir}/.index"/>
</indexes>
</ivysettings>
{code}
h3. Index Writing
As discussed on ant-dev, the index-writing mechanism consists of two parts:
1. *A publish hook.* Right now the index manager is called at the end of the
publish(..) method on RepositoryResolver. I go back and forth on whether or
not this behavior should be allowed on the ChainResolver or not. If it was
allowed, the implementation would have to change so that the index manager
isn't called multiple times for the same artifact as the ChainResolver iterates
and delegates publishing to its children.
2. *Ant Index task.* The task is currently designed to operate against the
index defined on the default resolver. I think index and resolver attributes
would be beneficial to make it more flexible, but I'm not sure how to
accomplish it since I don't want the user forcing a resolver to use a
particular index that it wouldn't normally use through the publish hook. Maybe
just allowing for a resolver attribute is sufficient...
The index task works by attempting to list every jar in the repository based on
the resolver's artifact pattern. The indexer compares the jar location and
timestamp against the index and, if unique, opens the jar, lists .class files
and infers type names from file names. Jars deleted since the last index job
are deleted in the index and update jars are updated.
In order to associate a jar file with a particular ModuleRevisionId, the
indexer stores and recalls state information related to the substituted token
values as it expands the pattern. So, the indexer only functions against
repositories that have [organization], [module], [revision] tokens in their
artifact pattern. Perhaps someone could suggest an alternative approach.
was (Author: jkschneider):
I am flexible on just about every point here...
Below is a sample Ivy settings file employing an index. Indexes are defined in
much the same way that caches are. I am of the opinion right now that there
should not be a default indexer like there is a default cache. The index
attribute is valid on RepositoryResolver subclasses (see note on publish hook).
{code:xml}
<ivysettings>
<settings defaultResolver="1"/>
<resolvers>
<filesystem name="1" index="index1">
<ivy
pattern="${ivy.settings.dir}/[organisation]/[module]/ivy-[revision].xml"/>
<artifact
pattern="${ivy.settings.dir}/[organisation]/[module]/[type]/[artifact]-[revision].[ext]"/>
</filesystem>
</resolvers>
<indexes>
<index name="index1" storageDir="${ivy.settings.dir}/.index"/>
</indexes>
</ivysettings>
{code}
As discussed on ant-dev, the index-writing mechanism consists of two parts:
1. *A publish hook.* Right now the index manager is called at the end of the
publish(..) method on RepositoryResolver. I go back and forth on whether or
not this behavior should be allowed on the ChainResolver or not. If it was
allowed, the implementation would have to change so that the index manager
isn't called multiple times for the same artifact as the ChainResolver iterates
and delegates publishing to its children.
2. *Ant Index task.* The task is currently designed to operate against the
index defined on the default resolver. I think index and resolver attributes
would be beneficial to make it more flexible, but I'm not sure how to
accomplish it since I don't want the user forcing a resolver to use a
particular index that it wouldn't normally use through the publish hook. Maybe
just allowing for a resolver attribute is sufficient...
> Ivy Indexer
> -----------
>
> Key: IVY-1143
> URL: https://issues.apache.org/jira/browse/IVY-1143
> Project: Ivy
> Issue Type: New Feature
> Components: Ant, Core, Documentation
> Reporter: Jon Schneider
> Attachments: indexable-test-repository.zip, ivy-1143.patch
>
>
> Per the discussion on ant-dev.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
