[
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 4:52 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}
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...
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 IndexManager 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.
