On 1/10/07, Stephane Bailliez <[EMAIL PROTECTED]> wrote:

Xavier Hanin wrote:
> I don't have much time now, so I'll just give a couple of explanations,
> excuse me if I'm not clear.
> - a ModuleId identifies a module, with no revision information
> - a ModuleRevisionId identifies a revision of a module (which is itself
> identified by a ModuleId)
> - an ArtifactId identifies an Artifact of a module, in no particular
> revision
> - an ArtifactRevisionId identifies an Artifact of a module in a
> particular
> revision

Why is there a need to to have those xxxxRevisionId rather than having a
version having a revision or not ?
(A revision seems like a much more complex object than a pure string)


Because I think that the semantic is different. Take a method which accepts
a ModuleId as argument, you wouldn't know that it doesn't deal with revision
if it was only the value or revision which was used to distinguish the two.
But if most people think it would be easier to understand with less classes,
I can understand.

- an Artifact represents an artifact of a particular revision of a
> module,
> and is thus identified by an ArtifactRevisionId. It provides methods
> to ease
> access to data stored in the ArtifactRevisionId, such as
> getModuleRevisionId, getName, getType, and so on. It basically
> corresponds
> to the artifacts elements in the publication section of an Ivy file,
> it thus
> offers configurations info for example.
> - a DefaultArtifact is one particular implementation of the Artifact
> interface
> - ArtifactInfo is an interface mainly used for LatestStrategy methods,
to
> determine the latest revision among several ones.
Why is that ? Why is an artifact itself not enough to work on ?


An Artifact is too much... You don't need all information of an Artifact in
a LatestStrategy. And sometime you don't have all this information at the
time you use the latest strategy.


>
> - ArtifactOrigin is used to store the original location of an Artifact

Same here, should this actually be part of the artifact information itself
?


Why not
- Xavier


> I hope this clears things a bit.
Thanks.

I'll have to lay that down on paper and follow sequences because I have
a hard time understanding the relation between objects and workflows.

Reply via email to