Hi,
Such changes will not happen easy! think about the consequences in all
existing MANIFEST.MF files with classpaths .....
Most users will use the group id as a organizational help but still use
"almost" unique artifactId's as identifications. -> When i see the name
of the jar i know what it is.
Ritchie
Carlos Sanchez wrote:
> On Nov 28, 2007 6:40 PM, Richard van Nieuwenhoven <[EMAIL PROTECTED]> wrote:
>> The reason for me is that eclipse is the source of the jars and eclipse
>> does repeat the group name in the jar name.
>>
>> It looks very strange to have 10 different jars in the classpath all
>> called "resource.jar". And what would happen when you need to package
>> the jars together in a directory (ear, war, standalone tool). What would
>> the resulting MANIFEST.MF look like.
>
> plugins (war, ear,...) should support and even make it the default, to
> package the jars using the full group+arifact id, because using just
> the artifactId has limitations. What happens now if you have 2 jars
> with same artifactId and version in a war? they overwrite each other
>
>> Sorry to reopen this discussion, but i think a jar's name should be as
>> near as possible to the original jar name.
>>
>> It is done all the time, example:
>> "maven-eclipse-plugin" is not called "eclipse" because the groupId
>> contains "maven" and "plugin".
>
> but i think if groupid is org.apache.maven.plugins then the artifact
> should be just eclipse. Doesnt happen now, but it probably should
>
>> Ritchie
>>
>>
>>
>>
>> Carlos Sanchez wrote:
>>> why would we use groupIds and artifactIds if we were going to repeat
>>> the same information in both fields?
>>>
>>> this was already brought before and the way the jars are stored
>>> doesn't imply the way they are used
>>>
>>> On Nov 27, 2007 8:12 PM, Richard van Nieuwenhoven <[EMAIL PROTECTED]> wrote:
>>>> I think it is important that {artifactId}-{version}.jar results in a
>>>> name as similar as possible the the name as they are in the plugin
>>>> directory of eclipse.
>>>>
>>>> And the eclipse project name should represent the group id of the plugin
>>>> as on http://www.eclipse.org/projects/ , whereas i do not care if only
>>>> top-level-projects are used as group-id's. Or (to keep it simple) just
>>>> use the first three words as a groupId....
>>>>
>>>> this way the jar should be:
>>>>
>>>> <groupId>org.eclipse.platform</groupId>
>>>> <artefactId>org-eclipse-core-resources</artefactId>
>>>> <version>3.2.1</version>
>>>>
>>>> or
>>>>
>>>> <groupId>org.eclipse.platform.core</groupId>
>>>> <artefactId>org-eclipse-core-resources</artefactId>
>>>> <version>3.2.1</version>
>>>>
>>>> or
>>>>
>>>> <groupId>org.eclipse.core</groupId>
>>>> <artefactId>org-eclipse-core-resources</artefactId>
>>>> <version>3.2.1</version>
>>>>
>>>> any other idea's...
>>>>
>>>> Ritchie
>>>>
>>>>
>>>> Max Bowsher wrote:
>>>>> Carlos Sanchez wrote:
>>>>>> I'm uploading right now a good number of jars to
>>>>>> http://repo1.maven.org/eclipse-staging/
>>>>>> If it looks good I will sync to central
>>>>>>
>>>>>> Note that the location for the one you want should be
>>>>>> http://repo1.maven.org/eclipse-staging/org/eclipse/core/resources/3.2.1/
>>>>> I wonder if this groupId:artifactId mapping is a bad idea?
>>>>>
>>>>> Most jars in the repository have an artifactId which is, whilst not
>>>>> necessarily globally unique, good enough to give you a pretty good idea
>>>>> what they are. This is a good thing, since there are several use cases
>>>>> where a collection of jars is bundled into a single directory, and those
>>>>> jars are named {artifactId}-{version}.jar (e.g, war file WEB-INF/lib/,
>>>>> common usage of assembly plugin).
>>>>>
>>>>> The suggested mapping of just taking the last component of the name as
>>>>> the artifactId will lead to many artifacts with non-descriptive and
>>>>> clashing names like "common", "core", "ui", etc. At best case, this
>>>>> will merely be horrendously confusing for humans attempting to
>>>>> understand and debug these generated collections of jars. At worst case,
>>>>> some of the artifacts will not only have the same artifactId, but same
>>>>> version too, and will overwrite each other.
>>>>>
>>>>> So, I think the current mapping fits poorly with existing Maven
>>>>> use-cases and plugin design, and needs further consideration.
>>>>>
>>>>> Max.
>>>>>
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>
>>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
