[jira] (MSHARED-298) Errors in manifest example on site
Anders Hammar created MSHARED-298:
-
Summary: Errors in manifest example on site
Key: MSHARED-298
URL: https://jira.codehaus.org/browse/MSHARED-298
Project: Maven Shared Components
Issue Type: Bug
Components: maven-archiver
Affects Versions: maven-archiver-2.5
Environment: on-line site
Maven 3.0.4
Reporter: Anders Hammar
Priority: Minor
In the examples/manifest.html page it says:
{quote}
If your pom.xml does not have a element, then the Specification-Title
and Implementation-Title entries will have "Unnamed -
$\{project.groupId}:$\{project.artifactId}:$\{project.version}" as their value.
{quote}
This is not true (at least not for Implementation-Title). If name is not
specified, artifactId is used. I *think* this is somethings that happens within
Maven Core. Maybe this is a Maven 3 thing?
--
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
[jira] (MSHARED-298) Errors in manifest example on site
[
https://jira.codehaus.org/browse/MSHARED-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335105#comment-335105
]
Anders Hammar commented on MSHARED-298:
---
Here's from the source code:
addManifestAttribute( m, entries, "Implementation-Title", project.getName() );
> Errors in manifest example on site
> --
>
> Key: MSHARED-298
> URL: https://jira.codehaus.org/browse/MSHARED-298
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-archiver
>Affects Versions: maven-archiver-2.5
> Environment: on-line site
> Maven 3.0.4
>Reporter: Anders Hammar
>Priority: Minor
>
> In the examples/manifest.html page it says:
> {quote}
> If your pom.xml does not have a element, then the Specification-Title
> and Implementation-Title entries will have "Unnamed -
> $\{project.groupId}:$\{project.artifactId}:$\{project.version}" as their
> value.
> {quote}
> This is not true (at least not for Implementation-Title). If name is not
> specified, artifactId is used. I *think* this is somethings that happens
> within Maven Core. Maybe this is a Maven 3 thing?
--
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
[jira] (SCM-530) Add support for git submodules to git SCM provider
[
https://jira.codehaus.org/browse/SCM-530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335106#comment-335106
]
Tomasz Krakowiak commented on SCM-530:
--
I would like to implement support of submodules in git scm providers.
This is what I think it should be implemented (pseudocode):
{code}
checkin(repository, fileSet, options){
gitmodules = listGitSubmodules();// Non-recursive
for(gitmodule : gitmodules){
moduleFileSet = narrowFileSetToModule(repository, gitmodule, fileset); //
Returns subset of files narrowed
//
to those contained in module's directory.
//
(relative paths are resolved to absolute
//
paths or relative to module's directory)
if(!isEmpty(moduleFileSet)){
if(!isSubmoduleInitialized(repository, gitmodule)){
return "Git submodule " + gitmodule + "is not initialized";
}
moduleRepository = submoduleRepository(repository, submodule);
result = checkin(moduleRepository, moduleFileSet, options);
if(!isSuccess(result)){
return result;
}
fileSet.add(submodule);
}
}
... // Do the same thing as currently.
}
{code}
I'm only worried about using scm connection for submodules not configured in
pom. Still everything should work as long everything is properly configured in
git (i would not recommend providing submodule url overriding).
> Add support for git submodules to git SCM provider
> --
>
> Key: SCM-530
> URL: https://jira.codehaus.org/browse/SCM-530
> Project: Maven SCM
> Issue Type: New Feature
> Components: maven-scm-provider-git
>Affects Versions: 1.3
>Reporter: Chas Emerick
>
> Pretty self-explanatory. Example fallout of this issue: release:perform on a
> project that refers to other git repos as submodules cannot succeed.
--
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
[jira] (MRELEASE-726) mvn release:prepare-with-pom not honouring the commitByProject parameter.
[
https://jira.codehaus.org/browse/MRELEASE-726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335107#comment-335107
]
Tomasz Krakowiak commented on MRELEASE-726:
---
I don't like the way chose to handle checkout with submodules. It look like you
assumed scm:checkout is only used by maven-release-plugin and "commitByProject"
option just with git.
Using commitByProject=true and pushChanges=false is common workaround for lack
of support of git-submodules in git scm providers. However what if we have
tagged only aggregating repository? Such checkout would fail. Parent repository
alredy have referenced commits whe should checkout.
> mvn release:prepare-with-pom not honouring the commitByProject parameter.
> -
>
> Key: MRELEASE-726
> URL: https://jira.codehaus.org/browse/MRELEASE-726
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: Git, prepare-with-pom
>Affects Versions: 2.2.2
> Environment: Linux 64bit (Ubuntu).
>Reporter: Dave Fennell
>Priority: Blocker
> Attachments: bug-726-scenario.zip,
> MNG-726-maven-release-manager.patch, MNG-726-maven-scm-provider-gitexe.patch,
> patched_output.txt, pre_patched_output.txt
>
>
> Using this in my pom file:
> {code:xml}
>
> org.apache.maven.plugins
> maven-release-plugin
> 2.2.2
>
> deploy
> false
> true
> true
>
>
> {code}
> Running this command:
> {{mvn release:prepare}}
> Correctly goes into each directory to make changes, e.g.
> {noformat}
> [INFO] Checking in modified POMs...
> [INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel && git add --
> pom.xml
> [INFO] Working directory: /usr/local/src/whitelabel
> [INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel && git status
> [INFO] Working directory: /usr/local/src/whitelabel
> [INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel && git commit
> --verbose -F /tmp/maven-scm-561169862.commit pom.xml
> [INFO] Working directory: /usr/local/src/whitelabel
> [INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel/foundation && git
> add -- pom.xml
> [INFO] Working directory: /usr/local/src/whitelabel/foundation
> [INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel/foundation && git
> status
> [INFO] Working directory: /usr/local/src/whitelabel/foundation
> [INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel/foundation && git
> commit --verbose -F /tmp/maven-scm-2018482909.commit pom.xml
> {noformat}
> etc ...
> However running this command:
> {{mvn release:prepare-with-pom}}
> So that I can generate a release-pom.xml file errors because it attempts to
> do all the checkins on one line:
> {noformat}
> [INFO] Executing: /bin/sh -c cd /usr/local/src/whitelabel && git add --
> release-pom.xml foundation/release-pom.xml module/release-pom.xml
> module/advertising/release-pom.xml module/buttonconfig/release-pom.xml
> module/core/release-pom.xml module/film/release-pom.xml
> module/profile/release-pom.xml module/proxy/release-pom.xml
> module/rental/release-pom.xml module/service/release-pom.xml
> module/smartcard/release-pom.xml module/telephony/release-pom.xml
> module/terminalui/release-pom.xml module/tv/release-pom.xml
> module/upsell/release-pom.xml module/urlconfig/release-pom.xml
> mule/release-pom.xml mule/advertising/release-pom.xml
> mule/button-config/release-pom.xml mule/film/release-pom.xml
> mule/hospediacard/release-pom.xml mule/location/release-pom.xml
> mule/profile/release-pom.xml mule/proxy/release-pom.xml
> mule/rental/release-pom.xml mule/service/release-pom.xml
> mule/smartcard/release-pom.xml mule/startup/release-pom.xml
> mule/terminaluimenu/release-pom.xml mule/tv/release-pom.xml
> mule/upsell/release-pom.xml mule/urlconfig/release-pom.xml
> {noformat}
> This doesn't work for my setup because each directory is a git submodule so
> must be run separately, it looks to me like it's simply ignoring the
> {{commitByProject}} setting, but the docs
> (http://maven.apache.org/plugins/maven-release-plugin/prepare-with-pom-mojo.html)
> list it as being a supported property since {{2.0-beta5}}. I've marked this
> as a blocker because I wanted to use the release-pom.xml and I have no way to
> generate them now (since the {{-DgenerateReleasePoms}} option on the
> {{release:prepare}} goal seems to have been deprecated).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, plea
[jira] (SCM-530) Add support for git submodules to git SCM provider
[ https://jira.codehaus.org/browse/SCM-530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335108#comment-335108 ] Tomasz Krakowiak commented on SCM-530: -- Probably recursive tagging option in scm and release plugins would also be nice. But if we would like to use different tag's in submodules it would require change in scm api. > Add support for git submodules to git SCM provider > -- > > Key: SCM-530 > URL: https://jira.codehaus.org/browse/SCM-530 > Project: Maven SCM > Issue Type: New Feature > Components: maven-scm-provider-git >Affects Versions: 1.3 >Reporter: Chas Emerick > > Pretty self-explanatory. Example fallout of this issue: release:perform on a > project that refers to other git repos as submodules cannot succeed. -- 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
[jira] (MASSEMBLY-661) Assembly plugin looses permissions when using fileSets
[ https://jira.codehaus.org/browse/MASSEMBLY-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335125#comment-335125 ] Eric Haszlakiewicz commented on MASSEMBLY-661: -- This is specific to the version maven. Maven 2.2.1 is listed as "an older, but stable version of Maven for projects that can't upgrade to Maven 3.x yet", and I have several projects that can't upgrade yet. Some time between 2.2.1 and 3.0.5 this problem was fixed, but it wasn't applied to the 2.2 code base. > Assembly plugin looses permissions when using fileSets > -- > > Key: MASSEMBLY-661 > URL: https://jira.codehaus.org/browse/MASSEMBLY-661 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: permissions >Affects Versions: 2.4 > Environment: RHEL5, Maven 2.2.1 >Reporter: Eric Haszlakiewicz > Attachments: pom.xml > > > When using an assembly descriptor that uses fileSets to include files the > permissions of the files from the file system are not preserved in the > tarballs. > This can be reproduced by creating a file with the executable bit set in the > "src" directory, then trying to use the pre-defined "src" descriptorRef to > create a tarball. See the attached pom file for an example. -- 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
[jira] (MASSEMBLY-670) assembly plugin tar.gz format does not preserve timestamps of files it adds to archive
[ https://jira.codehaus.org/browse/MASSEMBLY-670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335132#comment-335132 ] Steve Cohen commented on MASSEMBLY-670: --- Thank you. On the machine I'd like to test it on, I don't have git and cannot install it. I have tested it on another machine. However, I don't think that your test is a valid duplicate of my use case. My use case involves a custom assembly descriptor with filesets. It includes a jar built with maven and also some text format configuration files and it is these where I need timestamps preserved. My situation doesn't use git, it uses svn with the use-commit-times config option to preserve the timestamps on checkout. I want these timestamps preserved in the .tar.gz archive. I assume that git would have a similar configuration option, but I've not used git. A valid test case using git would enable this option. In your test case I see no timestamps earlier than the time I began the build, but with such an option enabled, presumably, we would have a valid test of my scenario. Also I've looked into the plugin source code and I find nothing there that would cause the source file timestamps to be applied to the destination archive entries, although it's certainly possible that I've missed where this happens. I may not respond as promptly as you'd like to your input on this issue because I cannot get the jira to respect my setting of wanting notification emails on my bugs, and several requests for help on this have gone unanswered. > assembly plugin tar.gz format does not preserve timestamps of files it adds > to archive > -- > > Key: MASSEMBLY-670 > URL: https://jira.codehaus.org/browse/MASSEMBLY-670 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: component descriptor >Affects Versions: 2.4 > Environment: linux >Reporter: Steve Cohen > > The .tar.gz archives created by the assembly plugin do not preserve the > timestamps of the files it adds to the archive. There is no setting to > override this. > This differs from the functionality of the tar program. That program > preserves timestamps by default, when adding to the archive and there is no > option to change this, although there are options to change the timestamps on > extraction. > The maven plugin should emulate tar here, I would think. -- 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
[jira] (MASSEMBLY-670) assembly plugin tar.gz format does not preserve timestamps of files it adds to archive
[ https://jira.codehaus.org/browse/MASSEMBLY-670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335132#comment-335132 ] Steve Cohen edited comment on MASSEMBLY-670 at 11/4/13 11:16 AM: - Thank you. On the machine I'd like to test it on, I don't have git and cannot install it. I have tested it on another machine. However, I don't think that your test is a valid duplicate of my use case. My use case involves a custom assembly descriptor with filesets. It includes a jar built with maven and also some text format configuration files and it is these where I need timestamps preserved. My situation doesn't use git, it uses svn with the use-commit-times config option to preserve the timestamps on checkout. I want these timestamps preserved in the .tar.gz archive. I assume that git would have a similar configuration option, but I've not used git before now. A valid test case using git would enable this option. In your test case I see no timestamps earlier than the time I began the build, but with such an option enabled, presumably, we would have a valid test of my scenario. Also I've looked into the plugin source code and I find nothing there that would cause the source file timestamps to be applied to the destination archive entries, although it's certainly possible that I've missed where this happens. I may not respond as promptly as you'd like to your input on this issue because I cannot get the jira to respect my setting of wanting notification emails on my bugs, and several requests for help on this have gone unanswered. was (Author: sco...@javactivity.org): Thank you. On the machine I'd like to test it on, I don't have git and cannot install it. I have tested it on another machine. However, I don't think that your test is a valid duplicate of my use case. My use case involves a custom assembly descriptor with filesets. It includes a jar built with maven and also some text format configuration files and it is these where I need timestamps preserved. My situation doesn't use git, it uses svn with the use-commit-times config option to preserve the timestamps on checkout. I want these timestamps preserved in the .tar.gz archive. I assume that git would have a similar configuration option, but I've not used git. A valid test case using git would enable this option. In your test case I see no timestamps earlier than the time I began the build, but with such an option enabled, presumably, we would have a valid test of my scenario. Also I've looked into the plugin source code and I find nothing there that would cause the source file timestamps to be applied to the destination archive entries, although it's certainly possible that I've missed where this happens. I may not respond as promptly as you'd like to your input on this issue because I cannot get the jira to respect my setting of wanting notification emails on my bugs, and several requests for help on this have gone unanswered. > assembly plugin tar.gz format does not preserve timestamps of files it adds > to archive > -- > > Key: MASSEMBLY-670 > URL: https://jira.codehaus.org/browse/MASSEMBLY-670 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: component descriptor >Affects Versions: 2.4 > Environment: linux >Reporter: Steve Cohen > > The .tar.gz archives created by the assembly plugin do not preserve the > timestamps of the files it adds to the archive. There is no setting to > override this. > This differs from the functionality of the tar program. That program > preserves timestamps by default, when adding to the archive and there is no > option to change this, although there are options to change the timestamps on > extraction. > The maven plugin should emulate tar here, I would think. -- 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
[jira] (MASSEMBLY-670) assembly plugin tar.gz format does not preserve timestamps of files it adds to archive
[ https://jira.codehaus.org/browse/MASSEMBLY-670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335136#comment-335136 ] Steve Cohen commented on MASSEMBLY-670: --- I realized that I could test this easily enough even with your git setup. I manually touched one file in the src/conf directory with a 2004 timestamp and found that the archive did reflect the changed timestamp. So what is the difference? My real situation is using apache-maven-3.0.5, my test situation is using 3.0.4, not likely to be relevant. Both situations use the assembly plugin version 2.4 My real situation is using jdk 1.6, the test situation is using 1.7 The real situation is using RHEL 5.0, the test situation is using Ubuntu 13.04 The only one of these I could possibly see as being relevant is the jdk. > assembly plugin tar.gz format does not preserve timestamps of files it adds > to archive > -- > > Key: MASSEMBLY-670 > URL: https://jira.codehaus.org/browse/MASSEMBLY-670 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: component descriptor >Affects Versions: 2.4 > Environment: linux >Reporter: Steve Cohen > > The .tar.gz archives created by the assembly plugin do not preserve the > timestamps of the files it adds to the archive. There is no setting to > override this. > This differs from the functionality of the tar program. That program > preserves timestamps by default, when adding to the archive and there is no > option to change this, although there are options to change the timestamps on > extraction. > The maven plugin should emulate tar here, I would think. -- 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
[jira] (MASSEMBLY-661) Assembly plugin looses permissions when using fileSets
[ https://jira.codehaus.org/browse/MASSEMBLY-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335138#comment-335138 ] Kristian Rosenvold commented on MASSEMBLY-661: -- Please verify that you are using fixed versions of the plugins in question; to my best knowledge this is /not/ functionality/bugs that would leak from maven core into the assembly plugin, even for version 2.2.1 (it might happen somewhere in the 2.0.X range, but not 2.2.1) The only thing I can think of that is markedly different between 2.2.1 and any 3.X version is the default version of all the plugins. Please double-check that you're not being tricked by some plugin being in an older version when running 2.2.1 > Assembly plugin looses permissions when using fileSets > -- > > Key: MASSEMBLY-661 > URL: https://jira.codehaus.org/browse/MASSEMBLY-661 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: permissions >Affects Versions: 2.4 > Environment: RHEL5, Maven 2.2.1 >Reporter: Eric Haszlakiewicz > Attachments: pom.xml > > > When using an assembly descriptor that uses fileSets to include files the > permissions of the files from the file system are not preserved in the > tarballs. > This can be reproduced by creating a file with the executable bit set in the > "src" directory, then trying to use the pre-defined "src" descriptorRef to > create a tarball. See the attached pom file for an example. -- 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
[jira] (MASSEMBLY-661) Assembly plugin looses permissions when using fileSets
[ https://jira.codehaus.org/browse/MASSEMBLY-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335139#comment-335139 ] Kristian Rosenvold commented on MASSEMBLY-661: -- You should, of course, also check that the files have the expected permissions on disk within the target folder. As long as this is the case, there should be nothing in maven core that affects this (other than the default version of plugins) > Assembly plugin looses permissions when using fileSets > -- > > Key: MASSEMBLY-661 > URL: https://jira.codehaus.org/browse/MASSEMBLY-661 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: permissions >Affects Versions: 2.4 > Environment: RHEL5, Maven 2.2.1 >Reporter: Eric Haszlakiewicz > Attachments: pom.xml > > > When using an assembly descriptor that uses fileSets to include files the > permissions of the files from the file system are not preserved in the > tarballs. > This can be reproduced by creating a file with the executable bit set in the > "src" directory, then trying to use the pre-defined "src" descriptorRef to > create a tarball. See the attached pom file for an example. -- 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
[jira] (MNG-5533) M2 vs M3
[
https://jira.codehaus.org/browse/MNG-5533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335140#comment-335140
]
Michael Osipov commented on MNG-5533:
-
The best thing would be to name it {{MVN_HOME}} and {{$HOME/.mvn}}. E.g., there
is no such thing as JAVA7_HOME, etc.
> M2 vs M3
>
>
> Key: MNG-5533
> URL: https://jira.codehaus.org/browse/MNG-5533
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Class Loading, Command Line, Documentation: General,
> General
>Affects Versions: Issues to be reviewed for 3.x
> Environment: Windows
>Reporter: Martin Spamer
>Priority: Critical
>
> Maven 3 uses the M2 environment variable. Surely it would be more reasonable
> to update this to M3 to allow sensible migration. e.g
> M2=C:\Program Files\Apache Software Foundation\apache-maven-2.2.1\bin
> M2_HOME=C:\Program Files\Apache Software Foundation\apache-maven-2.2.1
> M3=C:\Program Files\Apache Software Foundation\apache-maven-3.1.1\bin
> M3_HOME=C:\Program Files\Apache Software Foundation\apache-maven-3.1.1
> MAVEN=%M2% or MAVEN=%M3%
> PATH=%MAVEN%;%PATH%
--
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
[jira] (MASSEMBLY-670) assembly plugin tar.gz format does not preserve timestamps of files it adds to archive
[ https://jira.codehaus.org/browse/MASSEMBLY-670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335145#comment-335145 ] Steve Cohen commented on MASSEMBLY-670: --- Looking at source some more I eventually find my way here: org.codehaus.plexus.archiver.tar.TarArchiver line 318-320 318long teLastModified = entry.getResource().getLastModified(); 319te.setModTime( teLastModified == PlexusIoResource.UNKNOWN_MODIFICATION_DATE ? System.currentTimeMillis() 320: teLastModified ); evidently, in my case, teLastModified == PlexusIoResource.UNKNOWN_MODIFICATION_DATE (0) Why would that be the case? > assembly plugin tar.gz format does not preserve timestamps of files it adds > to archive > -- > > Key: MASSEMBLY-670 > URL: https://jira.codehaus.org/browse/MASSEMBLY-670 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: component descriptor >Affects Versions: 2.4 > Environment: linux >Reporter: Steve Cohen > > The .tar.gz archives created by the assembly plugin do not preserve the > timestamps of the files it adds to the archive. There is no setting to > override this. > This differs from the functionality of the tar program. That program > preserves timestamps by default, when adding to the archive and there is no > option to change this, although there are options to change the timestamps on > extraction. > The maven plugin should emulate tar here, I would think. -- 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
[jira] (MASSEMBLY-670) assembly plugin tar.gz format does not preserve timestamps of files it adds to archive
[ https://jira.codehaus.org/browse/MASSEMBLY-670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335147#comment-335147 ] Steve Cohen commented on MASSEMBLY-670: --- When running Maven on my build, with the -X option I encounter the following: [DEBUG] All known ContainerDescriptorHandler components: [plexus, metaInf-spring, metaInf-services, file-aggregator] [DEBUG] Cannot find ArtifactResolver with hint: project-cache-aware org.codehaus.plexus.component.repository.exception.ComponentLookupException: java.util.NoSuchElementException role: org.apache.maven.artifact.resolver.ArtifactResolver roleHint: project-cache-aware at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:257) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:233) at org.apache.maven.shared.repository.DefaultRepositoryAssembler.contextualize(DefaultRepositoryAssembler.java:721) at org.sonatype.guice.plexus.lifecycles.PlexusLifecycleManager.contextualize(PlexusLifecycleManager.java:317) at org.sonatype.guice.plexus.lifecycles.PlexusLifecycleManager.manageLifecycle(PlexusLifecycleManager.java:292) at org.sonatype.guice.plexus.lifecycles.PlexusLifecycleManager.onProvision(PlexusLifecycleManager.java:148) at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:108) at com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:55) at com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68) at com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:45) at com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46) at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1018) at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40) at com.google.inject.Scopes$1$1.get(Scopes.java:59) at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41) at com.google.inject.internal.InjectorImpl$3$1.call(InjectorImpl.java:965) at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1011) at com.google.inject.internal.InjectorImpl$3.get(InjectorImpl.java:961) at org.sonatype.guice.bean.locators.LazyBeanEntry.getValue(LazyBeanEntry.java:83) at org.sonatype.guice.plexus.locators.LazyPlexusBean.getValue(LazyPlexusBean.java:49) at org.sonatype.guice.bean.locators.EntryListAdapter$ValueIterator.next(EntryListAdapter.java:112) at org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:181) at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:436) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
[jira] (MASSEMBLY-670) assembly plugin tar.gz format does not preserve timestamps of files it adds to archive
[ https://jira.codehaus.org/browse/MASSEMBLY-670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335147#comment-335147 ] Steve Cohen edited comment on MASSEMBLY-670 at 11/4/13 4:44 PM: When running Maven on my build, with the -X option I encounter the following (right where the assembly plugin is working): [DEBUG] All known ContainerDescriptorHandler components: [plexus, metaInf-spring, metaInf-services, file-aggregator] [DEBUG] Cannot find ArtifactResolver with hint: project-cache-aware org.codehaus.plexus.component.repository.exception.ComponentLookupException: java.util.NoSuchElementException role: org.apache.maven.artifact.resolver.ArtifactResolver roleHint: project-cache-aware at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:257) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:233) at org.apache.maven.shared.repository.DefaultRepositoryAssembler.contextualize(DefaultRepositoryAssembler.java:721) at org.sonatype.guice.plexus.lifecycles.PlexusLifecycleManager.contextualize(PlexusLifecycleManager.java:317) at org.sonatype.guice.plexus.lifecycles.PlexusLifecycleManager.manageLifecycle(PlexusLifecycleManager.java:292) at org.sonatype.guice.plexus.lifecycles.PlexusLifecycleManager.onProvision(PlexusLifecycleManager.java:148) at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:108) at com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:55) at com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68) at com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:45) at com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46) at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1018) at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40) at com.google.inject.Scopes$1$1.get(Scopes.java:59) at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41) at com.google.inject.internal.InjectorImpl$3$1.call(InjectorImpl.java:965) at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1011) at com.google.inject.internal.InjectorImpl$3.get(InjectorImpl.java:961) at org.sonatype.guice.bean.locators.LazyBeanEntry.getValue(LazyBeanEntry.java:83) at org.sonatype.guice.plexus.locators.LazyPlexusBean.getValue(LazyPlexusBean.java:49) at org.sonatype.guice.bean.locators.EntryListAdapter$ValueIterator.next(EntryListAdapter.java:112) at org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:181) at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:436) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher
[jira] (MASSEMBLY-670) assembly plugin tar.gz format does not preserve timestamps of files it adds to archive
[ https://jira.codehaus.org/browse/MASSEMBLY-670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335157#comment-335157 ] Kristian Rosenvold commented on MASSEMBLY-670: -- It would appear one source of this problem can be seen in java.io.File#lastModified, which is the source of the "0" value creating UNKNOWN_MODIFICATION_DATE. There is a note about I/O errors or nonexistent files creating this response. I suggest you attach a debugger to assembly and try to determine what is happening when you get the nonexistent value. (Checkout assembly sources and just run with mvnDebug) There is a note in File.lastModified that we may use java.nio.file.Files#readAttributes(Path,Class,LinkOption[]) on jdk7 to detect this attribute without the annoying side effect of swallowing exceptions. Someone might patch up org.codehaus.plexus.components.io.resources.PlexusIoFileResource#getLastModified (surrounded by an test of org.codehaus.plexus.components.io.attributes.Java7Reflector#isJava7) to use the new method on jdk7. As for the stack trace, I'll have to look at that tonight > assembly plugin tar.gz format does not preserve timestamps of files it adds > to archive > -- > > Key: MASSEMBLY-670 > URL: https://jira.codehaus.org/browse/MASSEMBLY-670 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: component descriptor >Affects Versions: 2.4 > Environment: linux >Reporter: Steve Cohen > > The .tar.gz archives created by the assembly plugin do not preserve the > timestamps of the files it adds to the archive. There is no setting to > override this. > This differs from the functionality of the tar program. That program > preserves timestamps by default, when adding to the archive and there is no > option to change this, although there are options to change the timestamps on > extraction. > The maven plugin should emulate tar here, I would think. -- 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
[jira] (MASSEMBLY-670) assembly plugin tar.gz format does not preserve timestamps of files it adds to archive
[ https://jira.codehaus.org/browse/MASSEMBLY-670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335165#comment-335165 ] Kristian Rosenvold commented on MASSEMBLY-670: -- http://mail-archives.apache.org/mod_mbox/maven-users/201110.mbox/%3cCAHCAor7DcA9UKMpQredEovqkxw2EPZxJkqJ+=pewkuxjjve...@mail.gmail.com%3e > assembly plugin tar.gz format does not preserve timestamps of files it adds > to archive > -- > > Key: MASSEMBLY-670 > URL: https://jira.codehaus.org/browse/MASSEMBLY-670 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: component descriptor >Affects Versions: 2.4 > Environment: linux >Reporter: Steve Cohen > > The .tar.gz archives created by the assembly plugin do not preserve the > timestamps of the files it adds to the archive. There is no setting to > override this. > This differs from the functionality of the tar program. That program > preserves timestamps by default, when adding to the archive and there is no > option to change this, although there are options to change the timestamps on > extraction. > The maven plugin should emulate tar here, I would think. -- 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
[jira] (MASSEMBLY-670) assembly plugin tar.gz format does not preserve timestamps of files it adds to archive
[ https://jira.codehaus.org/browse/MASSEMBLY-670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335166#comment-335166 ] Kristian Rosenvold commented on MASSEMBLY-670: -- Googling project-cache-aware reveals lots of different potential explanations. If we can find the root cause of this, we can try to add some checks to improve the error message > assembly plugin tar.gz format does not preserve timestamps of files it adds > to archive > -- > > Key: MASSEMBLY-670 > URL: https://jira.codehaus.org/browse/MASSEMBLY-670 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: component descriptor >Affects Versions: 2.4 > Environment: linux >Reporter: Steve Cohen > > The .tar.gz archives created by the assembly plugin do not preserve the > timestamps of the files it adds to the archive. There is no setting to > override this. > This differs from the functionality of the tar program. That program > preserves timestamps by default, when adding to the archive and there is no > option to change this, although there are options to change the timestamps on > extraction. > The maven plugin should emulate tar here, I would think. -- 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
