Jörg Schaible wrote:

> Phil Steitz wrote:
> 
>> On 1/22/14, 1:58 PM, Jörg Schaible wrote:
>>> Hi Gilles,
>>>
>>> Gilles wrote:
>>>
>>> [snip]
>>>  
>>>> It's a convention; the "component" part could be the component's name
>>>> i.e. Commons Math could give "commons-math" as a base name; then the
>>>> artefacts (archives and JAR files) would be differentiated solely on
>>>> the version number:
>>>>    commons-math-3.3.tar.gz
>>>>    commons-math-3.3.jar
>>>>
>>>> The current convention seems that the base name is derived from the
>>>> top-level package name (which could indeed be mildly confusing, hence
>>>> this thread):
>>>>    commons-math3-3.3.jar
>>>>
>>>> But since the top-level package is renamed with each major version, it
>>>> is redundant to have the major number present both in the name and in
>>>> the version number.
>>> Old discussion! Please stop and search the archives, it's a technical
>>> requirement. Both names for package and artifactId must be changed.
>> 
>> Did we discuss before departing from the file name / meta-data /
>> package correspondence?  That is what is being advocated here -
>> changing *file* names to break with the standard convention.  Not
>> sure I agree with it (especially not for the jars); but it is not
>> the same as internal maven artifactIDs and package names.
> 
> Gilles is *obviously* talking about the jar files.

OK, to be precise he is obviously *also* talking about the jars.

However, even for the two artifacts in the download area: The finalName 
parameter will only influence the name of those two artifacts in the local 
target directory. It has no relevance for the name of the artifact that will 
be deployed into the remote repository (here: the staging area). A release 
manager will therefore not only have to move the files into the download 
area, but also has to rename them again to the "proper" names.

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to