maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Scholte (JIRA)" <j...@codehaus.org>
Subject [jira] (MEAR-171) Full customization of FileNameMapping is needed (WTF is the "full" mode? This
Date Thu, 14 Nov 2013 22:04:20 GMT

     [ https://jira.codehaus.org/browse/MEAR-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Robert Scholte updated MEAR-171:
--------------------------------

    Description: 
What is the logic with the seemingly non-standard conversion groupId by replacing '.' with
'-' in the "full" mode ?  Surely this mode should have been called "full-with-groupId-rewrite".

The purpose of this decision should have been documented in the code, someone needs to do
so or make this format obsolete.

Alternately the field should look at the maven-war-plugin and the ability to support mapping
like:
{noformat} @{groupId}@.@{artifactId}@@{dashClassifier?}@-@{version}@.@{extension}@ {noformat}

Also the $\{project.finalName} and $\{project.name} would be useful (taken out of the dependency's
own POM, not the EAR project).

If this unusual replacement of groupId is required, then maybe @{groupIdReplaceDots}@ can
be provided.


The problem is that the names used are IMPORTANT to know and automate because it maybe necessary
to place them on the Class-Path in MANIFEST.MF files.

This non-standard choice needs to be explained because it really is non-intuitive and there
are no other mechanisms across the maven plugins to manage and rewrite Class-Path values in
accordance with this convention.  There is on the other hand clear ways to configure a project
and decide on the output file names on a project by project basis.  This is what should be
the default, what the project itself decided it wanted to be called like ${project.finalName}.

The Maven documentation should include complete example of this "full" behaviour along with
explanation of why it is useful to the user.

  was:
What is the logic with the seemingly non-standard conversion groupId by replacing '.' with
'-' in the "full" mode ?  Surely this mode should have been called "full-with-groupId-rewrite".

The purpose of this decision should have been documented in the code, someone needs to do
so or make this format obsolete.

Alternately the field should look at the maven-war-plugin and the ability to support mapping
like:

@{groupId}@.@{artifactId}@@{dashClassifier?}@-@{version}@.@{extension}@

Also the ${project.finalName} and ${project.name} would be useful (taken out of the dependency's
own POM, not the EAR project).

If this unusual replacement of groupId is required, then maybe @{groupIdReplaceDots}@ can
be provided.


The problem is that the names used are IMPORTANT to know and automate because it maybe necessary
to place them on the Class-Path in MANIFEST.MF files.

This non-standard choice needs to be explained because it really is non-intuitive and there
are no other mechanisms across the maven plugins to manage and rewrite Class-Path values in
accordance with this convention.  There is on the other hand clear ways to configure a project
and decide on the output file names on a project by project basis.  This is what should be
the default, what the project itself decided it wanted to be called like ${project.finalName}.

The Maven documentation should include complete example of this "full" behaviour along with
explanation of why it is useful to the user.

    
> Full customization of FileNameMapping is needed (WTF is the "full" mode?  This
> ------------------------------------------------------------------------------
>
>                 Key: MEAR-171
>                 URL: https://jira.codehaus.org/browse/MEAR-171
>             Project: Maven Ear Plugin
>          Issue Type: Bug
>    Affects Versions: 2.8
>            Reporter: Darryl L. Miles
>
> What is the logic with the seemingly non-standard conversion groupId by replacing '.'
with '-' in the "full" mode ?  Surely this mode should have been called "full-with-groupId-rewrite".
> The purpose of this decision should have been documented in the code, someone needs to
do so or make this format obsolete.
> Alternately the field should look at the maven-war-plugin and the ability to support
mapping like:
> {noformat} @{groupId}@.@{artifactId}@@{dashClassifier?}@-@{version}@.@{extension}@ {noformat}
> Also the $\{project.finalName} and $\{project.name} would be useful (taken out of the
dependency's own POM, not the EAR project).
> If this unusual replacement of groupId is required, then maybe @{groupIdReplaceDots}@
can be provided.
> The problem is that the names used are IMPORTANT to know and automate because it maybe
necessary to place them on the Class-Path in MANIFEST.MF files.
> This non-standard choice needs to be explained because it really is non-intuitive and
there are no other mechanisms across the maven plugins to manage and rewrite Class-Path values
in accordance with this convention.  There is on the other hand clear ways to configure a
project and decide on the output file names on a project by project basis.  This is what should
be the default, what the project itself decided it wanted to be called like ${project.finalName}.
> The Maven documentation should include complete example of this "full" behaviour along
with explanation of why it is useful to the user.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message