ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jon Schneider (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (IVY-1143) Ivy Indexer
Date Wed, 25 Nov 2009 17:03:39 GMT

    [ 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.


Mime
View raw message