Le jeu. 8 août 2024 à 11:05, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :

> Hello Guillaume
>
> Le 2024-08-07 à 22 h 23, Guillaume Nodet a écrit :
>
> >   * ArtifactCoordinate are used to locate artifacts in a repository,
> >     it's basically a pointer to a file in maven repository
> >   * Artifact is the pointed artifact in the repository. They are
> >     created when *resolving* an ArtifactCoordinate which basically
> >     download the artifact in the local repository
> >   * DependencyCoordinate is used to express a dependency
> >   * Node is the main output of the *dependency collection* process,
> >     it's the graph of dependencies
> >   * Dependency is the output of the *collection* process, part of the
> >     graph computed from one or more DependencyCoordinate, it's an
> >     artifact + type + scope
> >
> It would be great to have this summary in the package-info Javadoc, and
> also the relevant parts in each interface Javadoc. I will try to do a PR
> next weekend for that.
>
>
> > when building the collected graph, the artifacts are not downloaded,
> > only the POMs are needed to build the graph. When will those
> > getModuleDescriptor() and getModuleName() methods be made available ?
> > I'd like to keep the objects immutable though.
> >
> I agree about immutability, but "immutable" does not necessarily mean
> "no deferred computation". The JDK has some examples of immutable
> objects that compute and cache their values when first requested (e.g.,
> `Path` itself, or `BigDecimal`, `Class`, etc.). Users still have the
> benefit of immutable objects, in the sense that they can share the same
> instance without the need for defensive copies and without the need to
> do synchronization themselves. So maybe a
> `Dependency.getModuleDescription()` method could load the module
> description when first needed, and `Dependency` still be considered
> immutable as long as no visible state changed. That method would
> potentially throw IOException, but again there is examples in the JDK of
> immutable objects throwing exceptions (e.g. File.getCanonicalPath()).
>
>
> > We could have a `ResolvedDependency` which would inherit from
> > `Dependency` and provide a `getPath()` method. Same for `Artifact`,
> > where we could define a `ResolvedArtifact`. Or maybe add a `Resolved`
> > interface with the`getPath` method, which could be implemented by both
> > ResolvedArtifact and ResolvedDependency.
> >
> That would work. But isn't `ResolvedDependency` the same as `Dependency`
> if we accept deferred computation, including for downloading the JAR file?


That would completely hide the download and means the object is not really
a data object anymore.  We’d have to keep pointers to the session, remote
repositories.
Deferring the module descriptor loading sounds reasonable, but I would not
defer the download which may fail for various reasons.
Also, we want downloads to happen in parallel, so deferring them would
break that.

>
>
>
> About `Dependency` as a specialization of `DependencyCoordinate`:
>
> > I find the outcome much less clear. The same kind of objects are used
> > for multiple things, and it's very confusing.
> >
> Alternatively we can keep the interfaces independent but nevertheless
> resolve the method collisions as below:
>
>   * In DependencyCoordinate, rename getVersion() as getVersionConstraint().


Yes, that one would be better.

>
>   * Choose a common name and return type for `isOptional()`.


That one is not doable imho.  DepedencyCoordinate and Dependency are not at
the same level.  One is a request and the other the result.  That’s why one
is a boolean primitive and the other a Boolean object which can carry 3
states. That’s the exact same problem with version and version constraint.
They are. Inflated in the resolver because they are stored as strings, but
this comes with confusion.


>
> It would allow an implementation class, if desired, to implement the two
> interfaces even if from user's eyes they are still two separated types.
> This strategy allows to implement the `toCoordinate()` method simply as
> `return this`, thus avoiding a copy operation and the possible
> information lost that come with it. Implementations are not forced to do
> that, it just become possible when convenient.


That’s still doable without the booleans.


>
>      Martin
>
>

Reply via email to