On Sun, 2004-01-11 at 20:41, John Casey wrote: > 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 >
By the way, I come by this opinion honestly. When I moved from the <dependency> <id>...</id> . </dependency> POM to the <dependency> <groupId>...</groupId> <artifactId>...</artifactId> </dependency> POM, it was painful as hell. I have a set of 38 component projects (I know, puny compared to some on the lists) and it took me hours to get all the <id> declarations switched to <groupId><artifactId> declarations. BTW, this is also why you've seen emails from me on the subject of transitive dependencies, which are the bane of my existence. :) I know that the POM doesn't change much, but as the sophistication of maven grows, I have a vested interest in lobbying to make sure it stays rock-solid and dead stable. -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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
