Maven 1.x Java Plugin

Consistent properties for jar, war, ejb and ear

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    2

Description

The current naming conventions for properties defining the names of jar, ejb, war and ear are somewhat inconsistent.

This patch introduces 4 new properties:

  1. defined in the java plugin's plugin.properties
    maven.jar.final.name = ${maven.final.name}.jar

    # defined in the war plugin's plugin.properties
    maven.war.final.name = ${maven.final.name}.war
  1. defined in the ejb plugin's plugin.properties
    maven.ejb.final.name = ${maven.final.name}.jar

    # defined in the ear plugin's plugin.properties
    maven.ear.final.name = ${maven.final.name}.ear

This patch solves the following problems:

1) It removes the risk of name clashes for projects that produce both plain
jar files and ejb jar files, since the maven.ejb.final.name property can be overridden.

2) When packaging wars and ejbs inside ears, it is sometimes desirable to have different names for ejbs and wars, like foo-ejb-1.0.jar and foo-war-1.0.war. This is necessary when the contents of an ear file is to be deployed on different weblogic servers with weblogic.deploy. This can now be achieved by overriding maven.ejb.final.name and/or maven.war.final.name.

This patch should not change any of the current functionality, and the documentation has been updated too.

  1. MPJAVA-8-new1.patch
    22/Aug/04 10:28 PM
    25 kB
    Felipe Leme
  2. patch.diff
    25/Mar/03 5:11 AM
    21 kB
    Aslak Hellesoy

Issue Links

Activity

Hide
Aslak Hellesoy added a comment -

Here is the patch

Show
Aslak Hellesoy added a comment - Here is the patch
Hide
dion gillard added a comment -

Is this still an issue?

Show
dion gillard added a comment - Is this still an issue?
Hide
Aslak Hellesoy added a comment -

Not for me

Show
Aslak Hellesoy added a comment - Not for me
Hide
Brett Porter added a comment -

this patch no longer applies

Show
Brett Porter added a comment - this patch no longer applies
Hide
Felipe Leme added a comment -

Brett,

What do you mean by "this patch no longer applies"? Does it means this is not an issue anymore (because it's fixed by some other changes) or does it means the provided patch does not work with the current on code on CVS? If you mean the later option, then I can try to work on a new patch (as I think this is an important issue).

– Felipe

Show
Felipe Leme added a comment - Brett, What do you mean by "this patch no longer applies"? Does it means this is not an issue anymore (because it's fixed by some other changes) or does it means the provided patch does not work with the current on code on CVS? If you mean the later option, then I can try to work on a new patch (as I think this is an important issue). – Felipe
Hide
Brett Porter added a comment -

the latter

Show
Brett Porter added a comment - the latter
Hide
Felipe Leme added a comment -

Brett,

Here is a new patch. I haven't tested it yet (I couldn't test 'maven site:generate' due to a missing cvs/netbeans lib, among othe problems), but it should be ok.

Anyway, it adds the following properties

jar plugin -> maven.jar.final.name
ejb plugin -> maven.ejb.client.final.name
rar plugin -> maven.rar.final.name

Note also that some of the proposed properties were already in the code:

ejb plugin -> maven.ejb.final.name
war plugin -> maven.war.final.name

I haven't changed the plugins changes.xml neither.

Felipe

PS: as the original reporter mentioned, this patch should not change any of the current functionality. On the other hand, even if the properties are changed by the user, the artifact tags will still install/deploy the artifacts using the old name. I have already opened an issue for that (MPARTIFACT-35), so I think this patch per se is fine.

Show
Felipe Leme added a comment - Brett, Here is a new patch. I haven't tested it yet (I couldn't test 'maven site:generate' due to a missing cvs/netbeans lib, among othe problems), but it should be ok. Anyway, it adds the following properties jar plugin -> maven.jar.final.name ejb plugin -> maven.ejb.client.final.name rar plugin -> maven.rar.final.name Note also that some of the proposed properties were already in the code: ejb plugin -> maven.ejb.final.name war plugin -> maven.war.final.name I haven't changed the plugins changes.xml neither. Felipe PS: as the original reporter mentioned, this patch should not change any of the current functionality. On the other hand, even if the properties are changed by the user, the artifact tags will still install/deploy the artifacts using the old name. I have already opened an issue for that (MPARTIFACT-35), so I think this patch per se is fine.
Hide
Felipe Leme added a comment -

BTW, currently, the existing properties don't carry the version:

maven.war.final.name = ${pom.artifactId}.war
maven.ejb.final.name = ${maven.final.name}.jar

Wouldn't it be better to add the version, as above?

maven.war.final.name = ${pom.artifactId}-${pom.currentVersion}.war
maven.ejb.final.name = ${maven.final.name}-${pom.currentVersion}.jar

The only drawback I can see of adding the version is the name of the application when it's deployed. For instance, if I deploy a project-x.y.z.war on JBoss or Tomcat, it would be accessed as /project-x.y.z, instead of /project. But the version number is added anyway on installs and deploys, so I think we should add it to the property (so it's included in the war/ejb-jar generated at target).

Show
Felipe Leme added a comment - BTW, currently, the existing properties don't carry the version: maven.war.final.name = ${pom.artifactId}.war maven.ejb.final.name = ${maven.final.name}.jar Wouldn't it be better to add the version, as above? maven.war.final.name = ${pom.artifactId}-${pom.currentVersion}.war maven.ejb.final.name = ${maven.final.name}-${pom.currentVersion}.jar The only drawback I can see of adding the version is the name of the application when it's deployed. For instance, if I deploy a project-x.y.z.war on JBoss or Tomcat, it would be accessed as /project-x.y.z, instead of /project. But the version number is added anyway on installs and deploys, so I think we should add it to the property (so it's included in the war/ejb-jar generated at target).
Hide
Felipe Leme added a comment -

I created 3 new issues, one for each plugin (jar, ear and rar).

Show
Felipe Leme added a comment - I created 3 new issues, one for each plugin (jar, ear and rar).
Hide
Felipe Leme added a comment -

I'm re-openning this issue, as it has affects more than the plugins I created sub-issues for.

Show
Felipe Leme added a comment - I'm re-openning this issue, as it has affects more than the plugins I created sub-issues for.
Hide
Felipe Leme added a comment -
Show
Felipe Leme added a comment - PS: here is a thread where this issue was discussed: http://nagoya.apache.org/eyebrowse/BrowseList?listName=dev@maven.apache.org&by=thread&from=905391
Hide
Felipe Leme added a comment -

I'm unassigning it as I haven't been able to do any Maven work on the last 2-3 months and the situations doesn't seem to be changing in the short time

Show
Felipe Leme added a comment - I'm unassigning it as I haven't been able to do any Maven work on the last 2-3 months and the situations doesn't seem to be changing in the short time
Hide
Lukas Theussl added a comment -

I don't think this is completely fixed, the war plugin still has maven.war.final.name = ${pom.artifactId}.war, while all the others (jar,ear,ejb,rar) have maven.jar.final.name = ${maven.final.name}.jar, etc. Need to review the mailing list thread given by Felipe above.

Show
Lukas Theussl added a comment - I don't think this is completely fixed, the war plugin still has maven.war.final.name = ${pom.artifactId}.war, while all the others (jar,ear,ejb,rar) have maven.jar.final.name = ${maven.final.name}.jar, etc. Need to review the mailing list thread given by Felipe above.
Hide
Lukas Theussl added a comment -

Closing now that MPPLUGIN-35 is fixed, I don't see any other place where this is still an issue. The war case won't be fixed for backwards compatibility reasons, see http://tinyurl.com/ayefj .

Show
Lukas Theussl added a comment - Closing now that MPPLUGIN-35 is fixed, I don't see any other place where this is still an issue. The war case won't be fixed for backwards compatibility reasons, see http://tinyurl.com/ayefj .

People

Vote (3)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved:

Time Tracking

Estimated:
Not Specified
Original Estimate - Not Specified
Remaining:
0m
Remaining Estimate - 0 minutes
Logged:
30m
Time Spent - 30 minutes