On Sun, 2004-01-11 at 14:30, Brian Topping wrote: > > -----Original Message----- > > From: John Casey [mailto:[EMAIL PROTECTED] > > Subject: RE: Mutliple source directories in project.xml > > > > It seems to me that the POM is the wrong place to put anything related > > to artifacts created during maven execution. > > I tend to agree with this, but in my case, the generated artifacts are > abstract base classes and factory classes, one of each for every entity, > generated from a UML model (somewhat critical to the success of the goals... > ;) The correct implementation is likely that the XMI has special > representation in the POM, but is this just a specific case of a bigger > problem? If so, there will never be an end to this issue as new metamodels > are introduced. > > XDoclet is a tricky case of this because it is mixing two sources of > information (java classes and class metadata) into a single source set. The > problem with the POM might be the inability to differentiate between vanilla > source and source that is seasoned with XDoclet tags (or aspects, etc...). > It is a similar argument to the premise against projects having multiple > artifacts. > > If I understand the POM correctly, it almost seems that Maven could use > pluggable providers for various metamodels, allowing for it to direct > generation during build and querying of the project from a component/PM > perspective. Querying a project model but omitting the class metadata gives > an incomplete picture of the project, reducing the effectiveness of eventual > tools that will be able to query POMs on the net like Google (Poogle? :). > Imagine being very happy with a particular component and doing a "backwards > links" search for components that use it. If metamodels are not available > for querying (XDoclet, UML via XMI, etc.) much of that information could be > unavailable. >
I don't think I agree with this. The POM seems like a construct which essentially defines the structure of a project, without making any assumptions about the type of project it is. We can specify things like source directory, dependencies, unit test directories, and supporting files for compiles, etc. within this structure. In spite of current implementations which for good reason favor Java, the POM seems language-agnostic, in that it seems to try to capture the abstract data which would be required to build artifacts based on any type of project, in any language. For instance, in the case of XMI, it seems to me that the XMI files _are_ the source of the project, and the production of Java code based on them is a _generation_ step along the way toward building a particular type of artifact. It's not compulsory that this step take place; for instance, if you're simply documenting the project (as in the site:site target), you might not even be interested in the Java intermediaries. Taking this perspective, we don't need to muddy the waters with pluggable metamodels. Once you introduce such a concept, you have to define how each maven plugin will respond to different metamodels, and probably will have to allow for compound models (XMI with second-stage XDoclet, JavaCC, or antlr, for instance), which makes maven unimaginably complex to code for. Plugin development probably would grind to a halt in the face of this complexity. As far as search engine accessibility, it might be more simple to say that these would in fact search for some sort of standardized, generated info file which would contain the pertinent details of the project, much as the site deliverable does now, in the form of a directory structure. This way, the generation of the .info (or whatever) file could depend upon the type of sources in the source directory (or the type specification of the project, which currently doesn't exist). I still maintain that the project descriptor (which is after all what the POM is) should not contain any information about n-stage build operations. These should be completely contained within the plugin/plugin configuration (i.e. the project.properties, etc.) because that eliminates the need to change the POM every time a plugin's needs change. Sure, a change to a plugin in this new model might break one type of build in a particular project until the changes propagate to that project, but it _wouldn't_break_all_builds_. Each time you modify the POM, you have two problems: 1. Huge deprecation support issues. (Supporting old POM formats) 2. An extremely time-consuming upgrade path for your users, as POM deprecations become unsupported. I think continued modification of the POM is a real problem which will affect the viability of maven as a de-facto replacement for Ant in codebase management. > > I'd even go so far as to > > say that the list of reports to be generated doesn't belong > > in here. To > > me, it makes sense to have the POM describe the project > > itself, in pure > > terms, without making assumptions about what artifacts will be > > generated. > > It seems to me that the POM should be both a director to the generation of > artifacts as well as an indicator to the existence of artifacts. In a > potential alternate universe, the transitive closure of POMs through > dependencies includes all components ever built under various Maven > installations. This mirrors the web itself, but uses POM instead of HTML for > hyperlinking. > > Imagining that such a world existed, a developer could import a class by > name, and the IDE would automagically look it up in a hypothetical POM search > engine, then update the POM with the correct dependency. Or maybe Maven > starts to form the idea of a "build container", and a Java compiler that is > executing uses an import resolution service of the container for issues such > as missing imports. > > But without indication that an artifact (such as a report) existed, the > engine would have a harder time to find it. Could POM search engine > functionality be the metric by which inclusion in the POM is measured? If > so, how do generated artifacts fit in now? > > > To that end, configuring things like the generated source directory > > should take place in project.properties instead of the POM. Obviously, > > it's not acceptable to try to configure the list of reports via > > project.properties, but somehow this information should also > > be excluded > > from the POM. > > > > In general, operational information used in maven execution but not > > having any use outside of maven SHOULD NOT be in the POM. This will > > leave open the opportunity for the POM to outlive maven's current > > incarnation. Accomplishing this will make the POM much more > > stable, and > > will mean that users won't be penalized by having to rewrite POMs for > > each update to a maven plugin. It should also reduce the requirements > > involved in providing backwards compatibility. > > > > -john > > -b > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > Cheers, john --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
