mirror of https://github.com/apache/maven.git
Readd NOTES email
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@162509 13f79535-47bb-0310-9956-ffa450edef68
This commit is contained in:
pdonald
parent
1f82999b15
commit
24efec4c3a
|
|
@ -0,0 +1,160 @@
|
|||
[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..
|
||||
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
|
||||
Loading…
Reference in New Issue