> Unfortunately the use of ${maven.build.dir} was not adopted
> by all parties else this discussion would have been moot.
> The source of our discomfort are the odors eminating from the
> use of hard-coded directory names like "src" and "target"
> in some templates and jelly scripts.
Hmm. Odd. I guess all I can say to that is that I have developed several
plugins (and may get permission to make them public one day) and it never
occurred to me to hard-code these names in my scripts.
In spite of what I've been saying before on this thread, this seems like an
area where you really .can. legitimately "force" people to use the
properties in plugins, because the plugin code in .only. used by Maven. I
can see how enforcing this would be difficult, though, as it would be hard
to spot. I can also imagine how it must have increased instability in the
field post-release as well.
Still, that sort of instability is controllable entirely within the Maven
project. That is not to say that it is easy, just that no "outside forces"
interfere with it. It seems to me like more of an issue of quality control
than architecture (unfortunately, decent quality control is much harder than
decent architecture). It might also be an issue of that early documentation
would have prevented (e.g. "Building Plugins the Maven Way" or something).
In any case, I have a better appreciation for the problem now. Honestly,
though, I still think the flexibility is worth the pain.
One other example of overriding the structure, BTW, though it doesn't deal
with /target. At our company, the following is in every project.properties
file:
maven.docs.src=${basedir}/doc/xdocs
We keep xdocs as a subdir of the doc folder. The doc folder tends to contain
other types of documentation (UML diagrams, specs, etc.) at its root. While
this is mostly an aesthetic choice, it does serve a practical purpose: it
makes security management of our Perforce depot less insane. We allow
product management into the doc tree, including the xdoc stuff. Making xodc
a subdir reduces the number of security settings we have to set up when
adding a new project.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
