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. 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.
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 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]
