On Tue, 19 Oct 2004 06:47:53 +1000, Brett Porter <[EMAIL PROTECTED]> wrote:
> It's for this reason that it may stay as it is for now. The repository
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?
> 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.
> That said, for consistency - how about defaulting to
> ${maven.final.name}.war, but making a copy to ${pom.artifactId}.war for
> existing builds? Output a warning that says it will be turned off in the
> future.
Ok, that makes sense.
> Felipe, what is the reason to introduce all the different final.name
> properties? Why isn't maven.final.name sufficient?
I'm introducing the new properties to fix MPJAVA-8, which I think makes sense (i.e.,
the reporter complained the plugins are not consistent regarding that property, and I
agree. Besides, nobody complained so far when I said I would fix it). But if we look
further in the past changes, we can find these reasons:
WAR:
-------
<action dev="vmassol" type="update">
Made the <code>maven.war.final.name</code> property public as it is
required by several other plugins and before this change the only
way is for these plugins was to call the non-public
<code>war:init</code> goal.
</action>
EJB:
------
<action dev="vmassol" type="update">
Modified existing <code>maven.ejb.final.name</code> property (and
exposed it as a public property) so that it doesn't include the path
(the path is now provided by the new <code>maven.ejb.build.dir</code>
property). This allows aligning the WAR and EJB plugin properties.
Note: This is a breaking change for all those using the
<code>maven.ejb.final.name</code> property (which was not a public
property).
</action>
<action dev="vmassol" type="update">
Made the <code>maven.ejb.final.name</code> property public as it is
required by several other plugins and before this change the only
way is for these plugins was to call the non-public
<code>ejb:init</code> goal.
</action>
> 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).
> I should have been watching the JIRA issues come in more carefully,
+1 :-)
> 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).
-- Felipe
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
