[Fwd: Re: Is maven.final.name deprecated?]

[Jason van Zyl <jv...@maven.org>]

Message meant for the list, Brett  your reply-to points to you :-)

-- 
jvz.

Jason van Zyl
jason@maven.org
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 

Re: [Fwd: Re: Is maven.final.name deprecated?]

[Brett Porter <br...@apache.org>]

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 <jv...@maven.org>
> Date:
> 19 Oct 2004 09:24:03 -0400
> To:
> brett@apache.org
>
> To:
> brett@apache.org
>
>
>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/BrowseList?listName=users@maven.apache.org&by=thread&from=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 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: dev-unsubscribe@maven.apache.org
>>For additional commands, e-mail: dev-help@maven.apache.org
>>    
>>
>
>  
>
>------------------------------------------------------------------------
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>For additional commands, e-mail: dev-help@maven.apache.org
>



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org