[marvin] Marvin NOTES Date: Friday 09:33:59 pm From: Michal Maczka 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 repositories (other list should be read as List) Sorry for chaos of this presentation :) regards Michal _______________________________________________ marvin mailing list marvin@lists.codehaus.org http://lists.codehaus.org/mailman/listinfo/marvin