Let me sum up where I think we're at here:
- artifact separation. We've talked about this on the maven and m2-dev lists a lot in the last 6 months and thinking through all the issues concluded that one project = one artifact makes sense, and that we just need to make project creation simple. I don't think we should go over that again.
- final name properties.
* Strongly disagree with the addition of maven.jar.final.name.
* Strongly agree that maven.final.name should represent the primary artifact output for the project
* In the instance where a secondary artifact is made (ejb-client), I have no problem with an additional "final name" property for that artifact
* for the already existing properties such as maven.war.final.name, I think we should work to deprecate them while remaining backwards compatible
* For the specific instance of the war output - it should be moved to include the version, but keeping the deprecated backwards compat generation of pom.artifactId only named artifact. A FAQ should be created.
* None of this affects the filename in the repository
Are there any points on which we still disagree? Is there anyone else on the list that disagrees?
Felipe Leme wrote:
On Tue, 2004-10-19 at 02:53, Brett Porter wrote:
<Context docRoot="/home/bporter/cvs/.../target/foo.war">
Convenient :)
As I said, you need to update the war (ok, you could usen maven console for that, but it's not the same). What about:
<Context docRoot="/home/bporter/cvs/.../${maven.war.src">
(+ a maven.xml goal that copies all the dependencies on WEB-INF/lib and
maven.compile.target=${maven.war.src}/WEB-INF/class)
That would be maven war:inplace. But we digress :)
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).
No, it will use maven.jar.final.name or maven.war.final.name, depending
on that it needs the artifact for.
That's contextual, but as I think you say next, you don't always know.
Besides, maven.final.name wouldThis is right - you need to know what the single build artifact is, and that should be {maven.final.name}.jar
suffice, as the plugin wouldn't have a reliable way (except of
maven.multiproject.type, if I'm now wrong) to know the artifact's
extension.
Another war with documentation? site:war? A documentation artifact is a valid secondary artifact, whatever the format.
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.
Ok, agreed. By speaking of design issues, I'm fine about pushing the
'one artifact per project Maven way', but we should allow users to make
some exceptions for that rule. For instance, in many circumstances a
project might need to build a 'primary' artifact and many 'secondary'
ones, so Maven should support it (without requiring the multi-project
hell). One such situation is where a project's main artifact is a jar,
but it also provides a war to test it and maybe another with
documentation (that would be the case for all Jakarta Taglibs, for
example).
I don't believe this is the right way to go for the others - it is unneeded complexity. examples subproject, test harness subproject that depend on the original are better.
Yes, secondary artifacts are needed but they are just that - secondary.
Your argument against what I've said is it is overkill. Making a new pom is a piece of cake, and it nicely separates things out and they both do one thing, and do it the same as for anything else.BTW, I have discussed this case on Jira and in the users list, but we haven't reached any consensus yet:
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&by=thread&from=875047 http://jira.codehaus.org/browse/MPWAR-30
Under your scenario, what happens in a multiproject build when you hit the taglib? Does it build a jar or a war? both? what tests does it run?
So, what do you think about this situation in particular, would the
change make sense or it would be against the design issues?
Cheers, Brett
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
