mirror of https://github.com/apache/maven.git
160 lines
4.8 KiB
Plaintext
160 lines
4.8 KiB
Plaintext
[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 |