You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "David Boden (JIRA)" <ji...@codehaus.org> on 2006/06/12 11:46:41 UTC
[jira] Created: (MASSEMBLY-115) Should avoid modifying assembly if
none of the underlying files have changed.
Should avoid modifying assembly if none of the underlying files have changed.
-----------------------------------------------------------------------------
Key: MASSEMBLY-115
URL: http://jira.codehaus.org/browse/MASSEMBLY-115
Project: Maven 2.x Assembly Plugin
Type: Improvement
Reporter: David Boden
At the moment, the assembly plugin always generates a the specified bundle, no matter whether or not the files to be placed in the bundle are changed.
This means that any plugins downstream (e.g. you want to digitally sign the bundle) behave as if a "clean" has taken place.
It would be better if the assembly plugin did not build a bundle if it is going to be the same as what was produced during the last build. That way, the last modified timestamp of the bundle won't get updated, and the downstream plugins will know that nothing has changed.
Adding an assembly to a build currently slows down the iterative "install" build very significantly because of this issue. Clean builds are not effected by this issue, but effectively the assembly is forcing a clean build every time.
--
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: (MASSEMBLY-115) Should avoid modifying assembly
if none of the underlying files have changed.
Posted by "Petar Tahchiev (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MASSEMBLY-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163982#action_163982 ]
Petar Tahchiev commented on MASSEMBLY-115:
------------------------------------------
All of the plexus archivers implement the Archiver interface, which has the setForce method defined.
We simply call the
delegate.setForced(forced);
method on the delegate Archiver interface object.
I think update functionality should work for all the archivers, since they implement the setForce method. And if it doesn't work for any of those then it should be a problem of the given archiver. And in this case we will fallback and support only forced (non-update) creation of archives for that archiver.
> Should avoid modifying assembly if none of the underlying files have changed.
> -----------------------------------------------------------------------------
>
> Key: MASSEMBLY-115
> URL: http://jira.codehaus.org/browse/MASSEMBLY-115
> Project: Maven 2.x Assembly Plugin
> Issue Type: Improvement
> Reporter: David Boden
> Assignee: Petar Tahchiev
> Fix For: 2.3-beta-1
>
> Attachments: massembly-115.patch
>
>
> At the moment, the assembly plugin always generates a the specified bundle, no matter whether or not the files to be placed in the bundle are changed.
> This means that any plugins downstream (e.g. you want to digitally sign the bundle) behave as if a "clean" has taken place.
> It would be better if the assembly plugin did not build a bundle if it is going to be the same as what was produced during the last build. That way, the last modified timestamp of the bundle won't get updated, and the downstream plugins will know that nothing has changed.
> Adding an assembly to a build currently slows down the iterative "install" build very significantly because of this issue. Clean builds are not effected by this issue, but effectively the assembly is forcing a clean build every time.
--
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: (MASSEMBLY-115) Should avoid modifying assembly
if none of the underlying files have changed.
Posted by "Andreas Christoforides (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MASSEMBLY-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_115289 ]
Andreas Christoforides commented on MASSEMBLY-115:
--------------------------------------------------
The current behavior of the assembly plugin considerably slows down the build time of projects that rely heavily on assemblies. I am currently working on a multimodule project that generates many artifacts using assemblies. Even with no changes to any source code the build takes a lot longer since it needs to zip and war a lot of files every time. The JAR and WAR plugins have the ability to check for modifications and build an artifact only if they were changes. It would be nice for the assembly plugin to behave in similar way.
> Should avoid modifying assembly if none of the underlying files have changed.
> -----------------------------------------------------------------------------
>
> Key: MASSEMBLY-115
> URL: http://jira.codehaus.org/browse/MASSEMBLY-115
> Project: Maven 2.x Assembly Plugin
> Issue Type: Improvement
> Reporter: David Boden
> Fix For: 2.3-beta-1
>
>
> At the moment, the assembly plugin always generates a the specified bundle, no matter whether or not the files to be placed in the bundle are changed.
> This means that any plugins downstream (e.g. you want to digitally sign the bundle) behave as if a "clean" has taken place.
> It would be better if the assembly plugin did not build a bundle if it is going to be the same as what was produced during the last build. That way, the last modified timestamp of the bundle won't get updated, and the downstream plugins will know that nothing has changed.
> Adding an assembly to a build currently slows down the iterative "install" build very significantly because of this issue. Clean builds are not effected by this issue, but effectively the assembly is forcing a clean build every time.
--
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: (MASSEMBLY-115) Should avoid modifying assembly if
none of the underlying files have changed.
Posted by "Petar Tahchiev (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MASSEMBLY-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Petar Tahchiev updated MASSEMBLY-115:
-------------------------------------
Attachment: massembly-115.patch
Here is a patch that adds the forced parameter in the configuration of the assembly plugin. The forced parameter is with default value true, and is set to the plexus archiver to force it to recreate the archive regardless of whether some of the files included in the archive are changed or not.
> Should avoid modifying assembly if none of the underlying files have changed.
> -----------------------------------------------------------------------------
>
> Key: MASSEMBLY-115
> URL: http://jira.codehaus.org/browse/MASSEMBLY-115
> Project: Maven 2.x Assembly Plugin
> Issue Type: Improvement
> Reporter: David Boden
> Fix For: 2.3-beta-1
>
> Attachments: massembly-115.patch
>
>
> At the moment, the assembly plugin always generates a the specified bundle, no matter whether or not the files to be placed in the bundle are changed.
> This means that any plugins downstream (e.g. you want to digitally sign the bundle) behave as if a "clean" has taken place.
> It would be better if the assembly plugin did not build a bundle if it is going to be the same as what was produced during the last build. That way, the last modified timestamp of the bundle won't get updated, and the downstream plugins will know that nothing has changed.
> Adding an assembly to a build currently slows down the iterative "install" build very significantly because of this issue. Clean builds are not effected by this issue, but effectively the assembly is forcing a clean build every time.
--
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: (MASSEMBLY-115) Should avoid modifying assembly
if none of the underlying files have changed.
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MASSEMBLY-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160514#action_160514 ]
John Casey commented on MASSEMBLY-115:
--------------------------------------
We need to verify whether unforced (i.e. update functionality?) works for the archivers provided by plexus-archiver...I don't think we can take that for granted, definitely.
> Should avoid modifying assembly if none of the underlying files have changed.
> -----------------------------------------------------------------------------
>
> Key: MASSEMBLY-115
> URL: http://jira.codehaus.org/browse/MASSEMBLY-115
> Project: Maven 2.x Assembly Plugin
> Issue Type: Improvement
> Reporter: David Boden
> Fix For: 2.3-beta-1
>
> Attachments: massembly-115.patch
>
>
> At the moment, the assembly plugin always generates a the specified bundle, no matter whether or not the files to be placed in the bundle are changed.
> This means that any plugins downstream (e.g. you want to digitally sign the bundle) behave as if a "clean" has taken place.
> It would be better if the assembly plugin did not build a bundle if it is going to be the same as what was produced during the last build. That way, the last modified timestamp of the bundle won't get updated, and the downstream plugins will know that nothing has changed.
> Adding an assembly to a build currently slows down the iterative "install" build very significantly because of this issue. Clean builds are not effected by this issue, but effectively the assembly is forcing a clean build every time.
--
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: (MASSEMBLY-115) Should avoid modifying assembly
if none of the underlying files have changed.
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MASSEMBLY-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163984#action_163984 ]
John Casey commented on MASSEMBLY-115:
--------------------------------------
Testing whether the forcing actually works on individual archivers (especially tar.gz, tar.bz2, tar, zip, jar, etc....the main ones in use) is exactly what I meant. I'm not at all certain or willing to bet that those archiver implementations are doing the right thing WRT forcing. We've had too many problems with features that are outside the mainstream in plexus-archiver historically for me to think they already work.
Call me a skeptic, but I'd much rather see tests for those archivers before we claim that this is working for the assembly plugin. I've been bitten too many times doing that.
> Should avoid modifying assembly if none of the underlying files have changed.
> -----------------------------------------------------------------------------
>
> Key: MASSEMBLY-115
> URL: http://jira.codehaus.org/browse/MASSEMBLY-115
> Project: Maven 2.x Assembly Plugin
> Issue Type: Improvement
> Reporter: David Boden
> Assignee: Petar Tahchiev
> Fix For: 2.3-beta-1
>
> Attachments: massembly-115.patch
>
>
> At the moment, the assembly plugin always generates a the specified bundle, no matter whether or not the files to be placed in the bundle are changed.
> This means that any plugins downstream (e.g. you want to digitally sign the bundle) behave as if a "clean" has taken place.
> It would be better if the assembly plugin did not build a bundle if it is going to be the same as what was produced during the last build. That way, the last modified timestamp of the bundle won't get updated, and the downstream plugins will know that nothing has changed.
> Adding an assembly to a build currently slows down the iterative "install" build very significantly because of this issue. Clean builds are not effected by this issue, but effectively the assembly is forcing a clean build every time.
--
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: (MASSEMBLY-115) Should avoid modifying assembly if
none of the underlying files have changed.
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MASSEMBLY-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
John Casey closed MASSEMBLY-115.
--------------------------------
Resolution: Fixed
Fix Version/s: (was: 2.3-beta-1)
2.2-beta-6
Assignee: John Casey (was: Petar Tahchiev)
added, the new configuration is <updateOnly>true|false</updateOnly>. Or, you can use -Dassembly.updateOnly=true|false
> Should avoid modifying assembly if none of the underlying files have changed.
> -----------------------------------------------------------------------------
>
> Key: MASSEMBLY-115
> URL: http://jira.codehaus.org/browse/MASSEMBLY-115
> Project: Maven 2.x Assembly Plugin
> Issue Type: Improvement
> Reporter: David Boden
> Assignee: John Casey
> Fix For: 2.2-beta-6
>
> Attachments: massembly-115.patch
>
>
> At the moment, the assembly plugin always generates a the specified bundle, no matter whether or not the files to be placed in the bundle are changed.
> This means that any plugins downstream (e.g. you want to digitally sign the bundle) behave as if a "clean" has taken place.
> It would be better if the assembly plugin did not build a bundle if it is going to be the same as what was produced during the last build. That way, the last modified timestamp of the bundle won't get updated, and the downstream plugins will know that nothing has changed.
> Adding an assembly to a build currently slows down the iterative "install" build very significantly because of this issue. Clean builds are not effected by this issue, but effectively the assembly is forcing a clean build every time.
--
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: (MASSEMBLY-115) Should avoid modifying assembly if
none of the underlying files have changed.
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MASSEMBLY-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
John Casey updated MASSEMBLY-115:
---------------------------------
Fix Version/s: 2.3-beta-1
> Should avoid modifying assembly if none of the underlying files have changed.
> -----------------------------------------------------------------------------
>
> Key: MASSEMBLY-115
> URL: http://jira.codehaus.org/browse/MASSEMBLY-115
> Project: Maven 2.x Assembly Plugin
> Issue Type: Improvement
> Reporter: David Boden
> Fix For: 2.3-beta-1
>
>
> At the moment, the assembly plugin always generates a the specified bundle, no matter whether or not the files to be placed in the bundle are changed.
> This means that any plugins downstream (e.g. you want to digitally sign the bundle) behave as if a "clean" has taken place.
> It would be better if the assembly plugin did not build a bundle if it is going to be the same as what was produced during the last build. That way, the last modified timestamp of the bundle won't get updated, and the downstream plugins will know that nothing has changed.
> Adding an assembly to a build currently slows down the iterative "install" build very significantly because of this issue. Clean builds are not effected by this issue, but effectively the assembly is forcing a clean build every time.
--
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