You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Jochen Wiedmann (JIRA)" <ji...@codehaus.org> on 2007/03/03 22:37:00 UTC
[jira] Created: (MNG-2854) Recreating pom.properties always breaks
the archivers uptodate check
Recreating pom.properties always breaks the archivers uptodate check
--------------------------------------------------------------------
Key: MNG-2854
URL: http://jira.codehaus.org/browse/MNG-2854
Project: Maven 2
Issue Type: Bug
Components: maven-archiver
Affects Versions: 2.0.5
Reporter: Jochen Wiedmann
Attachments: maven-archiver-properties.patch
The maven-archiver creates a file called pom.properties on every invocation. (Unless the flag "addMavenDescriptor" is set to false, which few people do.) This forced recreation makes the uptodate check fail. In other words, jar files are always recreated, regardless whether anything was recompiled. Obviously, this makes the uptodate check of war files etc. fail as well, because the included jar files are always changed.. This is a major drawback, because it makes Maven much slower than, for example, Ant-.
The attached patch proposes a solution for the same problem. What the patch does:
- It is obviously bad, that the generated pom.properties file is in the projects directory. The
patch moves the file to ${project.build.directory}/maven-archiver, which seems to me to
be a more sensible solution.
- Second, whether we like it or not, there are projects, which create multiple artifacts. In other
words, it isn't good to have a single file. The patch renames the pom.properties file to
${groupId}/$artifactFinalName.properties. Hopefully, this is sufficiently unique.
- Finally, the patch makes the maven-archiver check, whether the pom.properties file has
actually changed. (In other words, whether groupId, artifactId, or version have changed.)
It does so, by writing the file to an internal buffer and comparing the file on the disk and
the internal buffer (after skipping the line with the timestamp).
In other words, in the usual case, where groupId, artifactId and version haven't changed, the pom.properties file remains unchanged. In particular, the jar file doesn't need to be recreated.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2854) Recreating pom.properties always
breaks the archivers uptodate check
Posted by "Jason van Zyl (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90820 ]
Jason van Zyl commented on MNG-2854:
------------------------------------
Point one is fine.
Point two is not fine. One artifact and so many people expect the pom.properties file and is what we document. That can't change and I will never support the widespread production of multiple artifacts.
Point three is fine.
Fix up the second point and I will apply the patch. Also, how did you test this?
> Recreating pom.properties always breaks the archivers uptodate check
> --------------------------------------------------------------------
>
> Key: MNG-2854
> URL: http://jira.codehaus.org/browse/MNG-2854
> Project: Maven 2
> Issue Type: Bug
> Components: maven-archiver
> Affects Versions: 2.0.5
> Reporter: Jochen Wiedmann
> Attachments: maven-archiver-properties.patch
>
>
> The maven-archiver creates a file called pom.properties on every invocation. (Unless the flag "addMavenDescriptor" is set to false, which few people do.) This forced recreation makes the uptodate check fail. In other words, jar files are always recreated, regardless whether anything was recompiled. Obviously, this makes the uptodate check of war files etc. fail as well, because the included jar files are always changed.. This is a major drawback, because it makes Maven much slower than, for example, Ant-.
> The attached patch proposes a solution for the same problem. What the patch does:
> - It is obviously bad, that the generated pom.properties file is in the projects directory. The
> patch moves the file to ${project.build.directory}/maven-archiver, which seems to me to
> be a more sensible solution.
> - Second, whether we like it or not, there are projects, which create multiple artifacts. In other
> words, it isn't good to have a single file. The patch renames the pom.properties file to
> ${groupId}/$artifactFinalName.properties. Hopefully, this is sufficiently unique.
> - Finally, the patch makes the maven-archiver check, whether the pom.properties file has
> actually changed. (In other words, whether groupId, artifactId, or version have changed.)
> It does so, by writing the file to an internal buffer and comparing the file on the disk and
> the internal buffer (after skipping the line with the timestamp).
> In other words, in the usual case, where groupId, artifactId and version haven't changed, the pom.properties file remains unchanged. In particular, the jar file doesn't need to be recreated.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2854) Recreating pom.properties always breaks
the archivers uptodate check
Posted by "Jochen Wiedmann (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jochen Wiedmann updated MNG-2854:
---------------------------------
Attachment: maven-archiver-properties-3.patch
Done.
Thanks for the hint regarding Properties.equals(...). One learns all the time. Of course, this simplifies the code drastically.
> Recreating pom.properties always breaks the archivers uptodate check
> --------------------------------------------------------------------
>
> Key: MNG-2854
> URL: http://jira.codehaus.org/browse/MNG-2854
> Project: Maven 2
> Issue Type: Bug
> Components: maven-archiver
> Affects Versions: 2.0.5
> Reporter: Jochen Wiedmann
> Attachments: maven-archiver-properties-2.patch, maven-archiver-properties-3.patch, maven-archiver-properties.patch
>
>
> The maven-archiver creates a file called pom.properties on every invocation. (Unless the flag "addMavenDescriptor" is set to false, which few people do.) This forced recreation makes the uptodate check fail. In other words, jar files are always recreated, regardless whether anything was recompiled. Obviously, this makes the uptodate check of war files etc. fail as well, because the included jar files are always changed.. This is a major drawback, because it makes Maven much slower than, for example, Ant-.
> The attached patch proposes a solution for the same problem. What the patch does:
> - It is obviously bad, that the generated pom.properties file is in the projects directory. The
> patch moves the file to ${project.build.directory}/maven-archiver, which seems to me to
> be a more sensible solution.
> - Second, whether we like it or not, there are projects, which create multiple artifacts. In other
> words, it isn't good to have a single file. The patch renames the pom.properties file to
> ${groupId}/$artifactFinalName.properties. Hopefully, this is sufficiently unique.
> - Finally, the patch makes the maven-archiver check, whether the pom.properties file has
> actually changed. (In other words, whether groupId, artifactId, or version have changed.)
> It does so, by writing the file to an internal buffer and comparing the file on the disk and
> the internal buffer (after skipping the line with the timestamp).
> In other words, in the usual case, where groupId, artifactId and version haven't changed, the pom.properties file remains unchanged. In particular, the jar file doesn't need to be recreated.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2854) Recreating pom.properties always breaks
the archivers uptodate check
Posted by "Carlos Sanchez (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Carlos Sanchez closed MNG-2854.
-------------------------------
Assignee: Carlos Sanchez
Resolution: Fixed
Applied in 2.3-SNAPSHOT
> Recreating pom.properties always breaks the archivers uptodate check
> --------------------------------------------------------------------
>
> Key: MNG-2854
> URL: http://jira.codehaus.org/browse/MNG-2854
> Project: Maven 2
> Issue Type: Bug
> Components: maven-archiver
> Affects Versions: 2.0.5
> Reporter: Jochen Wiedmann
> Assignee: Carlos Sanchez
> Attachments: maven-archiver-MNG2854-4.patch, maven-archiver-properties-2.patch, maven-archiver-properties-3.patch, maven-archiver-properties.patch
>
>
> The maven-archiver creates a file called pom.properties on every invocation. (Unless the flag "addMavenDescriptor" is set to false, which few people do.) This forced recreation makes the uptodate check fail. In other words, jar files are always recreated, regardless whether anything was recompiled. Obviously, this makes the uptodate check of war files etc. fail as well, because the included jar files are always changed.. This is a major drawback, because it makes Maven much slower than, for example, Ant-.
> The attached patch proposes a solution for the same problem. What the patch does:
> - It is obviously bad, that the generated pom.properties file is in the projects directory. The
> patch moves the file to ${project.build.directory}/maven-archiver, which seems to me to
> be a more sensible solution.
> - Second, whether we like it or not, there are projects, which create multiple artifacts. In other
> words, it isn't good to have a single file. The patch renames the pom.properties file to
> ${groupId}/$artifactFinalName.properties. Hopefully, this is sufficiently unique.
> - Finally, the patch makes the maven-archiver check, whether the pom.properties file has
> actually changed. (In other words, whether groupId, artifactId, or version have changed.)
> It does so, by writing the file to an internal buffer and comparing the file on the disk and
> the internal buffer (after skipping the line with the timestamp).
> In other words, in the usual case, where groupId, artifactId and version haven't changed, the pom.properties file remains unchanged. In particular, the jar file doesn't need to be recreated.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2854) Recreating pom.properties always
breaks the archivers uptodate check
Posted by "Carlos Sanchez (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_95979 ]
Carlos Sanchez commented on MNG-2854:
-------------------------------------
Please add the apache license to PomPropertiesUtil.java if you grant the license to the ASF
> Recreating pom.properties always breaks the archivers uptodate check
> --------------------------------------------------------------------
>
> Key: MNG-2854
> URL: http://jira.codehaus.org/browse/MNG-2854
> Project: Maven 2
> Issue Type: Bug
> Components: maven-archiver
> Affects Versions: 2.0.5
> Reporter: Jochen Wiedmann
> Attachments: maven-archiver-properties-2.patch, maven-archiver-properties-3.patch, maven-archiver-properties.patch
>
>
> The maven-archiver creates a file called pom.properties on every invocation. (Unless the flag "addMavenDescriptor" is set to false, which few people do.) This forced recreation makes the uptodate check fail. In other words, jar files are always recreated, regardless whether anything was recompiled. Obviously, this makes the uptodate check of war files etc. fail as well, because the included jar files are always changed.. This is a major drawback, because it makes Maven much slower than, for example, Ant-.
> The attached patch proposes a solution for the same problem. What the patch does:
> - It is obviously bad, that the generated pom.properties file is in the projects directory. The
> patch moves the file to ${project.build.directory}/maven-archiver, which seems to me to
> be a more sensible solution.
> - Second, whether we like it or not, there are projects, which create multiple artifacts. In other
> words, it isn't good to have a single file. The patch renames the pom.properties file to
> ${groupId}/$artifactFinalName.properties. Hopefully, this is sufficiently unique.
> - Finally, the patch makes the maven-archiver check, whether the pom.properties file has
> actually changed. (In other words, whether groupId, artifactId, or version have changed.)
> It does so, by writing the file to an internal buffer and comparing the file on the disk and
> the internal buffer (after skipping the line with the timestamp).
> In other words, in the usual case, where groupId, artifactId and version haven't changed, the pom.properties file remains unchanged. In particular, the jar file doesn't need to be recreated.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2854) Recreating pom.properties always breaks
the archivers uptodate check
Posted by "Jochen Wiedmann (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jochen Wiedmann updated MNG-2854:
---------------------------------
Attachment: maven-archiver-properties-2.patch
Ok, here's an updated version of the patch. Note, that it contains a test case (MavenArchiverTest.testRecreation) that verifies whether the jar file is indeed created when invoked for the first time, but isn't for the second time.
> Recreating pom.properties always breaks the archivers uptodate check
> --------------------------------------------------------------------
>
> Key: MNG-2854
> URL: http://jira.codehaus.org/browse/MNG-2854
> Project: Maven 2
> Issue Type: Bug
> Components: maven-archiver
> Affects Versions: 2.0.5
> Reporter: Jochen Wiedmann
> Attachments: maven-archiver-properties-2.patch, maven-archiver-properties.patch
>
>
> The maven-archiver creates a file called pom.properties on every invocation. (Unless the flag "addMavenDescriptor" is set to false, which few people do.) This forced recreation makes the uptodate check fail. In other words, jar files are always recreated, regardless whether anything was recompiled. Obviously, this makes the uptodate check of war files etc. fail as well, because the included jar files are always changed.. This is a major drawback, because it makes Maven much slower than, for example, Ant-.
> The attached patch proposes a solution for the same problem. What the patch does:
> - It is obviously bad, that the generated pom.properties file is in the projects directory. The
> patch moves the file to ${project.build.directory}/maven-archiver, which seems to me to
> be a more sensible solution.
> - Second, whether we like it or not, there are projects, which create multiple artifacts. In other
> words, it isn't good to have a single file. The patch renames the pom.properties file to
> ${groupId}/$artifactFinalName.properties. Hopefully, this is sufficiently unique.
> - Finally, the patch makes the maven-archiver check, whether the pom.properties file has
> actually changed. (In other words, whether groupId, artifactId, or version have changed.)
> It does so, by writing the file to an internal buffer and comparing the file on the disk and
> the internal buffer (after skipping the line with the timestamp).
> In other words, in the usual case, where groupId, artifactId and version haven't changed, the pom.properties file remains unchanged. In particular, the jar file doesn't need to be recreated.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2854) Recreating pom.properties always breaks
the archivers uptodate check
Posted by "Jochen Wiedmann (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jochen Wiedmann updated MNG-2854:
---------------------------------
Attachment: maven-archiver-MNG2854-4.patch
Done.
> Recreating pom.properties always breaks the archivers uptodate check
> --------------------------------------------------------------------
>
> Key: MNG-2854
> URL: http://jira.codehaus.org/browse/MNG-2854
> Project: Maven 2
> Issue Type: Bug
> Components: maven-archiver
> Affects Versions: 2.0.5
> Reporter: Jochen Wiedmann
> Attachments: maven-archiver-MNG2854-4.patch, maven-archiver-properties-2.patch, maven-archiver-properties-3.patch, maven-archiver-properties.patch
>
>
> The maven-archiver creates a file called pom.properties on every invocation. (Unless the flag "addMavenDescriptor" is set to false, which few people do.) This forced recreation makes the uptodate check fail. In other words, jar files are always recreated, regardless whether anything was recompiled. Obviously, this makes the uptodate check of war files etc. fail as well, because the included jar files are always changed.. This is a major drawback, because it makes Maven much slower than, for example, Ant-.
> The attached patch proposes a solution for the same problem. What the patch does:
> - It is obviously bad, that the generated pom.properties file is in the projects directory. The
> patch moves the file to ${project.build.directory}/maven-archiver, which seems to me to
> be a more sensible solution.
> - Second, whether we like it or not, there are projects, which create multiple artifacts. In other
> words, it isn't good to have a single file. The patch renames the pom.properties file to
> ${groupId}/$artifactFinalName.properties. Hopefully, this is sufficiently unique.
> - Finally, the patch makes the maven-archiver check, whether the pom.properties file has
> actually changed. (In other words, whether groupId, artifactId, or version have changed.)
> It does so, by writing the file to an internal buffer and comparing the file on the disk and
> the internal buffer (after skipping the line with the timestamp).
> In other words, in the usual case, where groupId, artifactId and version haven't changed, the pom.properties file remains unchanged. In particular, the jar file doesn't need to be recreated.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (MSHARED-35) Recreating pom.properties always breaks
the archivers uptodate check
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MSHARED-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brett Porter moved MNG-2854 to MSHARED-35:
------------------------------------------
Affects Version/s: (was: 2.0.5)
Component/s: (was: maven-archiver)
maven-archiver
Key: MSHARED-35 (was: MNG-2854)
Project: Maven Shared Components (was: Maven 2)
> Recreating pom.properties always breaks the archivers uptodate check
> --------------------------------------------------------------------
>
> Key: MSHARED-35
> URL: http://jira.codehaus.org/browse/MSHARED-35
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-archiver
> Reporter: Jochen Wiedmann
> Assignee: Carlos Sanchez
> Attachments: maven-archiver-MNG2854-4.patch, maven-archiver-properties-2.patch, maven-archiver-properties-3.patch, maven-archiver-properties.patch
>
>
> The maven-archiver creates a file called pom.properties on every invocation. (Unless the flag "addMavenDescriptor" is set to false, which few people do.) This forced recreation makes the uptodate check fail. In other words, jar files are always recreated, regardless whether anything was recompiled. Obviously, this makes the uptodate check of war files etc. fail as well, because the included jar files are always changed.. This is a major drawback, because it makes Maven much slower than, for example, Ant-.
> The attached patch proposes a solution for the same problem. What the patch does:
> - It is obviously bad, that the generated pom.properties file is in the projects directory. The
> patch moves the file to ${project.build.directory}/maven-archiver, which seems to me to
> be a more sensible solution.
> - Second, whether we like it or not, there are projects, which create multiple artifacts. In other
> words, it isn't good to have a single file. The patch renames the pom.properties file to
> ${groupId}/$artifactFinalName.properties. Hopefully, this is sufficiently unique.
> - Finally, the patch makes the maven-archiver check, whether the pom.properties file has
> actually changed. (In other words, whether groupId, artifactId, or version have changed.)
> It does so, by writing the file to an internal buffer and comparing the file on the disk and
> the internal buffer (after skipping the line with the timestamp).
> In other words, in the usual case, where groupId, artifactId and version haven't changed, the pom.properties file remains unchanged. In particular, the jar file doesn't need to be recreated.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2854) Recreating pom.properties always
breaks the archivers uptodate check
Posted by "Trygve Laugstol (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94213 ]
Trygve Laugstol commented on MNG-2854:
--------------------------------------
A couple of code comments:
* Call the class PomPropertiesUtil instead of Manager. There are a lot of other Manager classes in Maven and they are Plexus components, while this is a normal utility class.
* Use org.codehaus.plexus.util.IOUtil.close() to close streams.
* When comparing the properties file why not generate Properties object and load the existing properties file and use Properties.equals()? That should save you some hassle.
> Recreating pom.properties always breaks the archivers uptodate check
> --------------------------------------------------------------------
>
> Key: MNG-2854
> URL: http://jira.codehaus.org/browse/MNG-2854
> Project: Maven 2
> Issue Type: Bug
> Components: maven-archiver
> Affects Versions: 2.0.5
> Reporter: Jochen Wiedmann
> Attachments: maven-archiver-properties-2.patch, maven-archiver-properties.patch
>
>
> The maven-archiver creates a file called pom.properties on every invocation. (Unless the flag "addMavenDescriptor" is set to false, which few people do.) This forced recreation makes the uptodate check fail. In other words, jar files are always recreated, regardless whether anything was recompiled. Obviously, this makes the uptodate check of war files etc. fail as well, because the included jar files are always changed.. This is a major drawback, because it makes Maven much slower than, for example, Ant-.
> The attached patch proposes a solution for the same problem. What the patch does:
> - It is obviously bad, that the generated pom.properties file is in the projects directory. The
> patch moves the file to ${project.build.directory}/maven-archiver, which seems to me to
> be a more sensible solution.
> - Second, whether we like it or not, there are projects, which create multiple artifacts. In other
> words, it isn't good to have a single file. The patch renames the pom.properties file to
> ${groupId}/$artifactFinalName.properties. Hopefully, this is sufficiently unique.
> - Finally, the patch makes the maven-archiver check, whether the pom.properties file has
> actually changed. (In other words, whether groupId, artifactId, or version have changed.)
> It does so, by writing the file to an internal buffer and comparing the file on the disk and
> the internal buffer (after skipping the line with the timestamp).
> In other words, in the usual case, where groupId, artifactId and version haven't changed, the pom.properties file remains unchanged. In particular, the jar file doesn't need to be recreated.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira