On 7/5/07, Tjeerd Verhagen <[EMAIL PROTECTED]> wrote:
Hi,
yes, I've red the Wiki page a new it already. But still these classes and
the Wiki do not form a good understanding for me... Sorry.
No problem, the design doc is very poor, but we are here to explain :-)
Maybe I should
also spit into it deeper. Below a few word about what I understand and
where
it's still foggy for me. And some thoughs I have while reading these
classes. Please write them as my thoughs, it's not said that I dissagray
with the implementation, it more what I would expect from what I know yet
about the framework and for my experience with coding untill now.
Mmm, ok, I understand that these classes represent some 'identifier'.
What I guess:
- These identifiers are used in creating a dependency graph?
Or (also) somewhere else?
They are used mainly to create a dependency graph, but can also be used to
represent metadata about a single module, or metadata about a bunch of
modules in a repository.
What I not understand
- A module contains an organistation and module-name.
Which can be for example 'apache' and 'commons-lang'.
Why is there a ModuleRevisionId?
For my understanding only Artifact would have a version (RevisionId).
No, in Ivy a module can have a version. A module can declare to publish
several artifcacts, in which case all of them will have the version: the
module version.
- Why do Id classes have a generic attribute container with them
(XxxRevisionId extend UnmodifiableExtendableItem).
It's used to implement extra attributes, which allow any user to use
attributes which are not defined in Ivy.
- For me it also doesn't make sence to extend from this class. I think
it would be better to delegate to an instance of that class. This
keeps
the design mutch cleaner. (In UML design terminology, there also the
rule
that a parent/child relation should also be a 'is a'.
Class Rabbit extends class Animal (Rabbit is an Animal).
For as for as I see this doesn't make since for the
XxxRevisionId extend UnmodifiableExtendableItem.
But maybe I'm totaly wrong here....
Or maybe there are some other very good reason(s) what it's solved
this
way.
I think there is a 'is a' relationship between those classes.
ModuleRevisionID is an extendable item which can't be modified once it has
been constructed (the name should better be ImmutableExtendableItem BTW). Do
you see anything wrong with that?
- Would it not be nice to create a small piece of xml for the encoded id's?
Something like:
<module org="apache" name="commons-lang" />
Or with attibutes:
<module org="apache" name="commons-lang">
<attrubte name="" value="" />
<module />
- creating the encoded part is simple
- decoding could be done by own code, or by a xml parser.
- making the encoding / decoding plugable, would make it easy to
switch
between
own (fast) implementation and parser implemenation.
Indeed, it could make sense, but maybe people would be lost between the XML
representation in an Ivy file and the encoded representation. What would
really help IMO is a standard way to write a module id, a module revision
id, an artifact, a dependency, and so on, in plain text. At the moment there
is something implemented in the toString, but the choice are not very good,
and people (including me) do not use these representations when talking
about modules in the mailing list. The problem is that in Ivy there is no
restriction in the characters used in a module name, organization or
revision. So we can't choose a special character as delimiter. It's really a
problem, because I would prefer something like org.apache.ivy;ivy;2.0.0-alpha2
to describe a module revision id, rather than [org.apache.ivy | ivy |
2.0.0-alpha2] as we use ATM.
Xavier
Regards, Tjeerd
On 7/4/07, Xavier Hanin <[EMAIL PROTECTED]> wrote:
>
> On 7/3/07, Tjeerd Verhagen <[EMAIL PROTECTED]> wrote:
> >
> > Hello,
> >
> > after looking into the following classes:
> >
> > - ArtifactId
> > - ArtifactRevisionId
> > - ModuleId
> > - ModuleRevisionId
> >
> > What I understand from the classes:
> > The Module is needed for all module specific stuff, organisation and
> > module
> > name.
> > An Artifact represents the created product in the form of a xxx.jar /
> > xxx-src.zip or so.
> > An ArtifactRevision represent a release / version of a Artifact.
> >
> > Questions:
> > What I don't get here is why every class-name contains Id at the end?
> > Why is there ModuleRevision?
> >
> > Probably I'm making some incorrect observations by reading the code...
A
> > few
> > words explaining these base classes would be appreciated!
>
>
> First I don't know if you've had a look at this:
> http://wiki.apache.org/ivy/IvyDataModel
>
> It gives basic explanation about these classes.
>
> For the Id at the end, it's because those classes represents only
> identifiers, and not the model content. For instance a ModuleRevisionId
is
> part of the description of a dependency of a module upon another module.
> In
> this dependency description, only the identifier of the dependency
module
> with revision is used, the whole content of the metadata associated with
> it
> (a ModuleDescriptor) is not known yet.
>
> Does it help your understanding?
>
> Xavier
>
> Thx, Tjeerd
> >
>
>
>
> --
> Xavier Hanin - Independent Java Consultant
> http://xhab.blogspot.com/
> http://incubator.apache.org/ivy/
> http://www.xoocode.org/
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://incubator.apache.org/ivy/
http://www.xoocode.org/
