Maven 2 & 3

Maven Archiver deleteing already existing pom.properties file.

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Won't Fix
  • Affects Version/s: 2.0.4
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Complexity:
    Intermediate
  • Patch Submitted:
    Yes
  • Number of attachments :
    1

Description

My project has it's own pom.properties file and it seems that maven archiver is deleting it right after packaging the application. Any particular reason why it's doing this? It seems to me the archiver shouldn't be deleting the file if it already exists. It should delete the file if it doesn't exists otherwise it should add the necessary information (version, groupId, etc) to the file and leave it be. I have attached a patch that fixes the issue.

Also note that this patch adds the "builtOn" property to the pom.properties which is satisfy the following enhancement request: http://jira.codehaus.org/browse/MNG-1830

Issue Links

This issue is depended upon by:
MSHARED-35 Recreating pom.properties always breaks the archivers uptodate check Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
John Casey added a comment -

IMO, this could be a vector for introducing false data which may eventually be depended upon (even unintentionally)...I'd tend to say that this file should always be generated.

What reason do you have for doing this?

Show
John Casey added a comment - IMO, this could be a vector for introducing false data which may eventually be depended upon (even unintentionally)...I'd tend to say that this file should always be generated. What reason do you have for doing this?
Hide
Permalink
Sharmarke Aden added a comment -

The rational behind not deleting the pom.properties files are:

1) Implicitly deleting a file explicitly created by the user is bad policy.

2) The idea behind not deleting the pom.properties is to facilitate external systems such as build systems to interact with maven. For example, communicating build number and date. The build system would place the build number in the pom.properties file and the maven can pickup this build information from the pom.properties file. Basically, this fix is necessary to support maven built-in properties enhancement request (see http://jira.codehaus.org/browse/MNG-1832).

Show
Sharmarke Aden added a comment - The rational behind not deleting the pom.properties files are: 1) Implicitly deleting a file explicitly created by the user is bad policy. 2) The idea behind not deleting the pom.properties is to facilitate external systems such as build systems to interact with maven. For example, communicating build number and date. The build system would place the build number in the pom.properties file and the maven can pickup this build information from the pom.properties file. Basically, this fix is necessary to support maven built-in properties enhancement request (see http://jira.codehaus.org/browse/MNG-1832).
Hide
Permalink
Jochen Wiedmann added a comment -

Please note MNG-2854 (I have created a new bug report, because my issue is the failing uptodate check, which isn't necessarily the same problem than here. Additionally, the suggested solutions are quite different. Nevertheless, it should be possible to close either MNG-2854 (this issue) or MNG-2301 as a duplicate of the other.

Show
Jochen Wiedmann added a comment - Please note MNG-2854 (I have created a new bug report, because my issue is the failing uptodate check, which isn't necessarily the same problem than here. Additionally, the suggested solutions are quite different. Nevertheless, it should be possible to close either MNG-2854 (this issue) or MNG-2301 as a duplicate of the other.
Hide
Permalink
Nigel Magnay added a comment -

> IMO, this could be a vector for introducing false data which may eventually be depended upon (even unintentionally)...I'd tend to say that this file should always be generated.

This seems right to me - it sounds like the fix in MNG-2854 also helps with this by moving the pom.properties artifact into a target subdirectory, which seems right. That way even if it doesn't get deleted, you know that it's always generated, and the risk that you're taking.

Show
Nigel Magnay added a comment - > IMO, this could be a vector for introducing false data which may eventually be depended upon (even unintentionally)...I'd tend to say that this file should always be generated. This seems right to me - it sounds like the fix in MNG-2854 also helps with this by moving the pom.properties artifact into a target subdirectory, which seems right. That way even if it doesn't get deleted, you know that it's always generated, and the risk that you're taking.
Hide
Permalink
Jason van Zyl added a comment -

The pom.properties is Maven's domain and is always generated. You need to use something else if you want to introduce your own data.

Show
Jason van Zyl added a comment - The pom.properties is Maven's domain and is always generated. You need to use something else if you want to introduce your own data.

People

Vote (2)
Watch (3)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.