[Fwd: Re: Is maven.final.name deprecated?]
Message meant for the list, Brett your reply-to points to you :-)
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
http://maven.apache.org
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
---BeginMessage---
On Tue, 2004-10-19 at 08:32, Brett Porter wrote:
I'll start by rounding up thoughts, with specific answer below to the
last email.
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?
That sounds good. As long as the artifact goes into the repository in
standard maven form it's all good. If the copy with a different name
locally provides convenience that's great.
Has the WAR always gone into the repository in the standard maven form?
If so then this certainly isn't a dire situation. The small nit being
the superfluous use of properties other than maven.final.name.
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 would
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.
This is right - you need to know what the single build artifact is, and
that should be {maven.final.name}.jar
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).
Another war with documentation? site:war? A documentation artifact is a
valid secondary artifact, whatever the format.
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.
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=threadfrom=875047
http://jira.codehaus.org/browse/MPWAR-30
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.
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
Re: [Fwd: Re: Is maven.final.name deprecated?]
It was sending both the list reply-to and one for me. I've changed a
config - let's see if this helps...
Jason van Zyl wrote:
Message meant for the list, Brett your reply-to points to you :-)
Subject:
Re: Is maven.final.name deprecated?
From:
Jason van Zyl [EMAIL PROTECTED]
Date:
19 Oct 2004 09:24:03 -0400
To:
[EMAIL PROTECTED]
To:
[EMAIL PROTECTED]
On Tue, 2004-10-19 at 08:32, Brett Porter wrote:
I'll start by rounding up thoughts, with specific answer below to the
last email.
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?
That sounds good. As long as the artifact goes into the repository in
standard maven form it's all good. If the copy with a different name
locally provides convenience that's great.
Has the WAR always gone into the repository in the standard maven form?
If so then this certainly isn't a dire situation. The small nit being
the superfluous use of properties other than maven.final.name.
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 would
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.
This is right - you need to know what the single build artifact is, and
that should be {maven.final.name}.jar
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).
Another war with documentation? site:war? A documentation artifact is a
valid secondary artifact, whatever the format.
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.
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=threadfrom=875047
http://jira.codehaus.org/browse/MPWAR-30
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.
Under your scenario, what happens in a multiproject build when you hit
the taglib? Does it build a jar or a war? both?
