My only contention here is that maven and it's associated plugins and whatnots be as encapsulated as possible. Now that I think of it, the generated source directory wouldn't really belong to any one single generation plugin, and therefore should be defined in the core to avoid the situation we're in now. As for the reports registry, that seems operational to me.
Where operation == some task you execute against a project to create a deliverable [artifact] of some type I agree that putting a reports list in the POM is the most convenient and probably the most intuitive way to store report info right now, but I also think that the reports registry in the project.xml is really an operational detail, in that it configures the site plugin. Therefore, it should ideally be configured somewhere that is on the same release schedule as maven-site-plugin. For instance, just because I don't want to include the javadoc report in the site generation doesn't mean that sometimes I won't want to generate javadocs. Of course, omitting the javadoc report from the POM will not restrict me from generating javadocs, but that seems to be the literal implication of omitting this report: that this source is incapable (somehow) of having javadoc run against it. However, if you were my manager, I'd simply bite my tongue on this issue, since I only have a complaint and not a potential solution. I'm not sure of a better way to configure the reports list... :) Please understand, I'm not trying to thump my shield and get a rally going here...I'm only trying to put in my 2 cents about the general architecture that I think would best fit maven. I know that this may seem like splitting hairs for now, but when maven truly hits the mainstream like ant has, it will make a difference to have an ultra-stable core (I know, preaching to the choir) and let the configuration of the plugins be separate. I elaborated on my reasoning more in another email earlier this afternoon... -john On Sun, 2004-01-11 at 16:54, Jason van Zyl wrote: > On Sat, 2004-01-10 at 18:34, John Casey wrote: > > It seems to me that the POM is the wrong place to put anything related > > to artifacts created during maven execution. I'd even go so far as to > > say that the list of reports to be generated doesn't belong in here. > > I don't agree, and I have changed my mind a couple times along the way > but the report element is a registry essentially and says what reports > you want for the projects. I happen to think the POM is the place for > it. For configuring each of the plugins that produce those reports, > probably not. > > > 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. > > I'm not sure what you mean by pure: as far as I have always thought, the > POM would describe everything about a project. I often see myself > working at a nice GUI tool operating on the project. From this > perspective, and to the user of this tool, whether things come from > properties files or the POM is irrelavent. The use of properties files > came into use simply because of their convenience and people being > accustomed to them in Ant. > > > To that end, configuring things like the generated source directory > > should take place in project.properties instead of the POM. > > I myself don't think so, I think a default value in a base POM inherited > by all projects would be more useful. > > > 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. > > Again, I don't agree. I see that as being important information and > should be part of the POM. I see a similiar mechanism for testing where > there is a registry for running various test plugins. To accurately > report on what reports are being generated or what test plugins are > being run. > > > In general, operational information used in maven execution but not > > having any use outside of maven SHOULD NOT be in the POM. > > Operational? > > > 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. > > With changes being done something has to change whether it be the POM > itself or properties files, but that being said the POM has still not > undergone any radical changes is probabaly not likely to and after 1.1 > and we have the structure worked out (as I think we can with the massive > amount of input we have now) it will most likely be additions. > > > -john > > > > > > On Fri, 2004-01-09 at 15:19, Michal Maczka wrote: > > > > -----Original Message----- > > > > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > > > > Sent: Friday, January 09, 2004 6:28 PM > > > > To: Maven Users List > > > > Subject: RE: Mutliple source directories in project.xml > > > > > > > > > > > > On Fri, 2004-01-09 at 11:33, Maczka Michal wrote: > > > > > > > > > > > > > > Because it is not necessary to have this aspect "configurable" > > > > > > > > How do you know this for certain? The answer is you can't without > > > > feedback from users over time. > > > > > > > > > > Sure I cannot > > > > > > I just looked at antlr, castor and xdoclet plugin. > > > Myself I have written jaxb and javacc plugins. > > > > > > But the point is that is easier to make something configurable then > > > lock it after. > > > > > > So we can always add an extra property. But it's generally harder to make it > > > other way around. > > > > > > Most of the code generators provides a possibility to customize output > > > directory. > > > > > > > > > > > > > > There is many plugin which are generating reports and which > > > > have hardcoded > > > > > the well known location: "{maven.build.dir}/generated-xdocs" > > > > > > > > > > > > > Sure, but ultimately I think this should come from the POM. An inherited > > > > POM for all projects so that specification of all these things is as > > > > easy as using the properties files are currrently, but in the POM > > > > nonetheless. > > > > > > > > > Example: (taken from SIMIAN plugin) > > > > > > > > > > <ant:simian output="${maven.build.dir}/generated-xdocs/simian.log" > > > > > lineCount="${maven.simian.linecount}" > > > > > failOnDuplication="${maven.simian.failonduplication}"> > > > > > > > > > > > > > > > And report generators are extremely plugable and they just works. > > > > > > > > Sure, this is because people generally copy one report to make another > > > > and get ${maven.build.dir}/generated-xdocs. Do you not think it would be > > > > better to have a standard element that could be used like: > > > > > > > > ${pom.generatedDocmentDirectory} > > > > > > > > > > I am all for strongly typed way of expressing things (If I can I prefer to > > > stay away from jelly :))! > > > But maybe some of the properties may be read-only? > > > I am simply afraid that this will be misused. > > > > > > > > > > > > > > > That's the major problem with jelly properties. It's easier to remember > > > "/target/generated-xdocs" > > > then ${maven.build.dir}/{i_even_dont_know_what_stands_for_generated-xdocs} > > > > > > > > > > Our use of properties on one hand and ${pom} elements in other cases is > > > > rather arbitrary and if we are going to move toward one mechanism I > > > > would be for the ${pom}. Providing a parent with all the defaults so we > > > > still have the convenience we do now with some added consistency. > > > > > > > > > > > > But my thought would be that a parent POM would have a > > > > <generateSourceDirectory/> that is the default that would be inherited. > > > > If we are right in that nobody cares then we will never see that element > > > > show up in POMs. Once we start getting POMs into the repo then at least > > > > for the population of OSS projects uploading things we could actually > > > > tell for certain within that population of projects what is being done. > > > > > > > Sure. Learing from experience and touching the reality is probably the best > > > option. > > > (After all we have always a possiblity of doing things as we maven > > > developers want, not as crowd of users wants.) > > > > > > > > > [...] > > > > > > Michal > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
