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.
> 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}
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.
> It's simply useless and not wise to make evry thing configurable. Standards
> are not configurable.
You are preaching to the choir :-)
I understand what you are saying.
> Why would anybody care about it if it has a reasonable well know location?
I don't think they would, but as we have seen some people do and
sometimes have a valid reason even though I would agree people generally
want things because they just want them because that's what they are
used to doing.
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.
If we find it's never being overridden,great. If we find that it is then
we can do something about it. Aside from transitive dependencies this is
one of the biggest reasons I want to get POMs into the repository. To
start gleaning some facts about POM usage.
> The contract for a report generator is simple: put generated files to
> "{maven.build.dir}/generated-xdocs".
Sure, I'll I'm saying is make that part of a standard POM instead of a
property and let people choose if they must for whatever reason. It
would easy enough for people to circumvent
${maven.build.dir}/generated-xdocs if they really wanted to, but in most
cases they don't. Just as I'm sure the same would be the case for a
standard inherited element in the POM.
I just want to get rid of the arbitrary distinction between what is a
property and isn't. All reports use ${maven.build.dir}/generated-xdocs
which is still subject to typos. Whereas most plugins dealing with
sources use ${pom.build.sourceDirectory} where within the POM you are
still subject to typos but a plugin could be made to puke when a
${pom.X} didn't exist.
I'm all for locking things down and have always wanted to move to
standardization for everything. I think we can achieve that with a
parent POM which has all our recommended options if people want to
deviate that's their choice.
> I don't know anybody who ever even tried to change this location. We just
> live with it.
> I am sure the same can happen to source code generators.
Certainly.
>
>
> If today we have
>
> <reports>
> <report>xx</report>
> </reports>
>
> We can imagine
> ( I personally think that one source generator per project is the maximum
> and this is just an example which illustrates my way of thinking)
See, this you can't do because you are limiting people to the tools they
might use for their projects. We've already had an example in the last
couple days of someone generating sources and then running xdoclet over
the generated sources.
> <javaSourceGenerators>
> <javaSourceGenrator>javacc</javaSourceGenrator>
> <javaSourceGenrator>xdoclet</javaSourceGenrator>
> <javaSourceGenerators>
>
> <byteCodeEnhancers>
> <byteCodeEnhancer>kodo</byteCodeEnhancer>
> <byteCodeEnhancer>weblogicEJBCompiler</byteCodeEnhancer>
> </byteCodeEnhancers>
>
> and dozen other categories of tools.
Eventually we could categorize things for easy navigating and searching
for tools but I'm not sure how this block above relates to the argument
at hand.
>
> Michal
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
