Hi, A couple of weeks ago I posted a proposal about a centralized reporting feature for maven that would allow easy aggregation of information at whatever level is needed. This proposal is centered around the idea of creating and maintaining a RDF database that could be used by plugins to find information or store information to be latter processed by other plugins or external tools.
I am trying to implement a small proof of concept without modifying maven base codebase and using only plugins. I plan to do the following: 1. a base plugin to create initially the RDF database and populate it with basic pom's information 2. a modified compiler plugin to store source files structure information 3. a modified surefire plugin to store test results in the graph attached to the test source files and projects 4. a modified test report lpugin that would take advantage of the RDF graph to generate aggregated reports I have started learning to use Jena's API which is quite simple and I am currently stuck with the following problem. A basic feature of this idea is that inheritance be handled correctly, which means that if the CreateMojo is invoked in a subproject with its 'inherit' attribute set to true, then it should attach its informations in its parents RDF database, not in its own. Furthermore, this should be done recursively until one reach the toplevel project or 'inherit' is set to false. Questions (which may be trivial) are: 1. Is there one mojo instance for each project in the hierarchy ? I think this is the case but I am not sure. 2. How can I retrieve a mojo instance from another mojo in the same or a sub project ? Help appreciated of course :-). BTW, thinking about all this, it occured to me that maven may be viewed as an interpreter for a DSL dedicated to software artifacts construction and management. The language is declarative and takes the (rather verbose and unhandy) form of an XML dialect. The various POM's ingredients describes either: 1. data *values*, to be later processed by *functions*: File path settings, configuration options, project's id card all fall into this case. These values are organized in a tree such that one can refer to variable's values using dotted notation (eg. =foo.bar.baz=) 2. *functions* that process the project's data, that is essentially plugins (essentiallye mojos), which may themselves be parameterized by some more data or values. The POM (and maven defaults settings ) itself can be viewed as a function providing *scheduling* or orchestration of the various *phases* of the build process. The lifecycle feature of maven gives a declarative way to *hook* functions invocations (ie. plugins and their contained mojos) or in maven parlance *binding a mojo to a phase of the lifecycle*. Sub-modules structure is just plain old function recursion. Dependency management is preparation step to allow proper linking and may not be considered part of the "language" it self. Thinking that way, one can imagine doing the following things: - provide a non-XML language layer tha would allow expressing a build process in an easier to use form than what is actually available - compile the build program for: - optimizing the build time - eventually detecting concurrency pattern such that distributed execution (eg. using compile farms) coul be provided Is this plain scrap or has someone else already thought about doing that kind of things ? regards -- OQube < software engineering \ génie logiciel > Arnaud Bailly, Dr. \web> http://www.oqube.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
