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] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
