> What do you mean stay as it is? Does it means no plugin should have the
> xxxx.final.name (relying only on maven.final.name) or leaving it in the
> current inconsistent way (where some plugins have the property but some
> others don't)?. Or are you just talking about the specific
> maven.war.final.name property?
Just talking about war staying without a version by default.
> > Generating it in target without it is not ideal, but is convenient and
> > backwards compatible. I don't see any issue with it.
>
> I agree with the backaward compatibility, not with the convenience. I mean,
> if the developer is relying on the target/xxx.war while developing, it's not
> productive anyway, as that war must be updated everytime a file is changed.
<Context docRoot="/home/bporter/cvs/.../target/foo.war">
Convenient :)
(admittedly in Tomcat you can do path="/foo" docRoot=".../foo-1.2.war", but
you get the point)
> > A project only produces one output, so maven.final.name should be able to
> be used in
> > any context.
>
> Yes, a product may produce only one output, but that output might be used to
> produce another 'secondary' outputs, like cactus's ear. So, if that property
> defining the output's final name is not exposed, the other plugins will need
> to 'guess' what's the output. For instance, cactus-plugin would be assuming
> the war is name ${maven.final.name}.war, which in turn is not even true (as
> it's in fact ${pom.artifactId}.war).
But it -should- be true. Now the plugin has to guess whether to use
maven.jar.final.name, maven.war.final.name, etc (sometimes - as for cactus -
this is contextual, sometimes not).
> > but unless there is a good reason I'd prefer we didn't have this change.
>
> I still think the property is useful (specially for the reason quoted in the
> previous paragraph). Anyway, I will stop my work on these issues by now,
> until we decide what to do (and again, I think we should finish this thread
> with a [VOTE] proposal for the final decisions).
I would like to think we could reach consensus or compromise on design issues,
not need a vote. So let's keep talking it through.
I'll email more when I get home.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
