maven/NOTES.txt

[marvin] Marvin NOTES
Date: Friday 09:33:59 pm
From: Michal Maczka <mmaczka@interia.pl>
To: marvin@lists.codehaus.org
Reply to: marvin@lists.codehaus.org

Some notes which can help you get familiar with Marvin code:

My work for Marvin is gathered mostly in two components:

wagon
maven-artifact

First remark: The best way to see how maven2 works is to try to run
/debug tests of compiler module (plugin).
There entire scope of code which works is used there.


I will try to introduce them very briefly:

Wagon
------------------
This component is supposed to be a transfer layer for artifacts.

In other words Wagon provides a facility of downloading/uploading files
in unified manner over various different protocols.

I tried to keep it simple - but I am not quite happy with the shape of
API but I don't find much better alternative at the moment.



Maven-Artifact
-------------------
At the moment it mostly mimics the behavior of Dependency Resolving
Mechanism of the core of old maven

a) Mapping of dependencies to artifacts
b) Artifact downloading

The code is rather straightforward decomposition of old code +
refactoring to components.
I think that such decomposition is the only way to have "testable code".
But I think also that the notion of components is bit overused in this code.


There are two packages which are not used at all in the current code:
a) org.apache.maven.artifact.verify
b) package org.apache.maven.artifact.handlers;

First one just wasn't used yet but I think it will be quite easy to find
a place when it should be plugged.

The key concept of this package is to "check/verify" artifact when it is
downloaded.

I am downloading md5 checksum file along with any artifact. Question is:
Checksum checking is the only checking we are going to perform

or we can imagine different type of artifact verifications (e.g. if
service contains meta data required to run inside container)

Artifact Handlers (org.apache.maven.artifact.handlers) - It's an attempt
to allow arbitrary processing of dependency of given type.
Say dependency we have dependecy of type "plugin" "loom component"
"service" etc. Such dependency can be processed in the "special way"
(whatever it means).
The semantics of this processing in not defined at all. I just put some
pretty dumb code which is based on idea of decorators which resables
ServletFilters
The main problem of this code is: Maven2 will be running inside
container. So project can be loaded, cached inside of container etc..
<EFBFBD>From the other hand it is useful to do "maven clean" without checking
if some dependencies are missing (lazy resolving of dependencies).
Surly those two design goals are not going well together.


There is one fundamental change there: Repository Layout Service
(package org.apache.maven.artifact.layout) Computation of repository -
root relative paths for dependecies is a function of

- type

- groupId

- artifactId

- version

This component is the only place in maven which knows how to build paths
from dependencies.

In future version of maven (AFAIK :) ) groupId like "foo.boo.goo" will
be mapped to /foo/boo/goo (3 directories)

There are more complex examples included (like always - see the test
cases) e.g. native libraries. (*.so *.dll)

This component + Artifact Handlers can be used for implementing "group
dependencies facility"

So basically this component decides about strategy how paths for
dependecies in maven are computed.


---------------------------------


As I said yesterday - I did not put too many comments to the code hoping
that code is very unstable from the point of view what will stay/what
will disapper, but I hope it's fairly comprehensible.

I don't mind if even a single line of my code won't be included in
maven2. Just smash my bad ideas!

At the moment

there are few fundamental open points:

We have POM - Project Object Model.

It will be nice to have ROM - Repository Object Model.

At the moment I am using some interfaces from Wagon to represent ROM. I
what I did is simple and this is definitely not a masterpiece.

The problem is: maven-model + maven-project modules contains definition
of POM.

The POM has references to ROM and Artifacts

The question is how connect ROM and POM + Artifacts together and not to
have circular dependencies between modules.

(I bet Artifact Interface and ROM must be a part of POM)

At the moment this is happening in lines; 59-67 in the class
org.apache.maven.project.Project (in module maven-project)

(I tried to mark all "smelling points" with @todo tag.)

e.g (line 62) *private* List repositories;

should read List<RepositoryDescriptor> repositories

(other list should be read as List<Artifact>)


Sorry for chaos of this presentation :)

regards

Michal



_______________________________________________
marvin mailing list
marvin@lists.codehaus.org
http://lists.codehaus.org/mailman/listinfo/marvin