[jira] (MJAR-166) Ability to add additional class directories to create jar
[ https://jira.codehaus.org/browse/MJAR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335183#comment-335183 ] Anders Hammar commented on MJAR-166: I think this is bending this plugin too much. The plugin goes hand-in-hand with the jar packaging type. If you want to create some other sort of special jar in som project you can always use the assembly plugin. > Ability to add additional class directories to create jar > - > > Key: MJAR-166 > URL: https://jira.codehaus.org/browse/MJAR-166 > Project: Maven JAR Plugin > Issue Type: Improvement >Affects Versions: 2.4 >Reporter: Viraj >Priority: Minor > Fix For: 2.5 > > Attachments: MNG-MJAR-166-maven-jar-plugin.patch > > > Current maven-jar-plugin create jar using target/classes and additional > resources directories. It will be useful if one can add additional classes > directories. -- 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] (MJAR-166) Ability to add additional class directories to create jar
[ https://jira.codehaus.org/browse/MJAR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335184#comment-335184 ] Tony Chemit commented on MJAR-166: -- @Anders +1, keep it simple ;) This usage is exotic to me. > Ability to add additional class directories to create jar > - > > Key: MJAR-166 > URL: https://jira.codehaus.org/browse/MJAR-166 > Project: Maven JAR Plugin > Issue Type: Improvement >Affects Versions: 2.4 >Reporter: Viraj >Priority: Minor > Fix For: 2.5 > > Attachments: MNG-MJAR-166-maven-jar-plugin.patch > > > Current maven-jar-plugin create jar using target/classes and additional > resources directories. It will be useful if one can add additional classes > directories. -- 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] (MJAR-172) Manifest entries are in wrong (visual) order
Anders Hammar created MJAR-172: -- Summary: Manifest entries are in wrong (visual) order Key: MJAR-172 URL: https://jira.codehaus.org/browse/MJAR-172 Project: Maven JAR Plugin Issue Type: Bug Affects Versions: 2.4 Environment: Windows 7, IBM JDK 1.6.0, Maven 3.0.4 Reporter: Anders Hammar Priority: Minor When enabling addDefaultImplementationEntries and/or addDefaultSpecificationEntries, these added manifest entries are not listed together, which makes it not so nice visually. This was not the case with v2.3.x (and prior) of the plugin, where they were added as explained here: http://maven.apache.org/shared/maven-archiver/examples/manifest.html Most likely this is due to some bug in maven-archiver. -- 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] (MJAR-172) Manifest entries are in wrong (visual) order
[ https://jira.codehaus.org/browse/MJAR-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335190#comment-335190 ] Anders Hammar commented on MJAR-172: Some investigation shows that this is due to a change introduced in org.codehaus.plexus:plexus-archiver:2.1 > Manifest entries are in wrong (visual) order > > > Key: MJAR-172 > URL: https://jira.codehaus.org/browse/MJAR-172 > Project: Maven JAR Plugin > Issue Type: Bug >Affects Versions: 2.4 > Environment: Windows 7, IBM JDK 1.6.0, Maven 3.0.4 >Reporter: Anders Hammar >Priority: Minor > > When enabling addDefaultImplementationEntries and/or > addDefaultSpecificationEntries, these added manifest entries are not listed > together, which makes it not so nice visually. This was not the case with > v2.3.x (and prior) of the plugin, where they were added as explained here: > http://maven.apache.org/shared/maven-archiver/examples/manifest.html > Most likely this is due to some bug in maven-archiver. -- 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] (MJAR-172) Manifest entries are in wrong (visual) order
[ https://jira.codehaus.org/browse/MJAR-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Hammar updated MJAR-172: --- Description: When enabling addDefaultImplementationEntries and/or addDefaultSpecificationEntries, these added manifest entries are not listed together, which makes it not so nice visually. This was not the case with v2.3.x (and prior) of the plugin, where they were added as explained here: http://maven.apache.org/shared/maven-archiver/examples/manifest.html was: When enabling addDefaultImplementationEntries and/or addDefaultSpecificationEntries, these added manifest entries are not listed together, which makes it not so nice visually. This was not the case with v2.3.x (and prior) of the plugin, where they were added as explained here: http://maven.apache.org/shared/maven-archiver/examples/manifest.html Most likely this is due to some bug in maven-archiver. > Manifest entries are in wrong (visual) order > > > Key: MJAR-172 > URL: https://jira.codehaus.org/browse/MJAR-172 > Project: Maven JAR Plugin > Issue Type: Bug >Affects Versions: 2.4 > Environment: Windows 7, IBM JDK 1.6.0, Maven 3.0.4 >Reporter: Anders Hammar >Priority: Minor > > When enabling addDefaultImplementationEntries and/or > addDefaultSpecificationEntries, these added manifest entries are not listed > together, which makes it not so nice visually. This was not the case with > v2.3.x (and prior) of the plugin, where they were added as explained here: > http://maven.apache.org/shared/maven-archiver/examples/manifest.html -- 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-853) Use "git --depth 1"Â When Checking Out
Ernst de Haan created MRELEASE-853:
--
Summary: Use "git --depth 1"Â When Checking Out
Key: MRELEASE-853
URL: https://jira.codehaus.org/browse/MRELEASE-853
Project: Maven Release Plugin
Issue Type: New Feature
Components: Git
Affects Versions: 2.2.2
Environment: Maven 3.1.1
Reporter: Ernst de Haan
*Executive summary: Please use {{--depth 1}} when checking out from a git
repository.*
Currently when doing {{mvn release:prepare release:perform}}, the git checkout
step takes a significant amount of time.
During the git checkout it appears to not only check out the correct version of
the code, but also _all_ history, as would be done with a regular:
{code:none}git clone URL{code}
However, git supports checking out only the latest version of the code base,
using this command: {code:none}git clone --depth 1 URL{code}
For the purpose of the Maven Release Plugin, that should be sufficient, as far
as I can see.
Changing the plugin to use {{--depth 1}} would significantly improve
performance and reduce I/O on repositories with a lot of history.
--
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-671) Cryptic debug warning message needs improvement and/or documentation
Steve Cohen created MASSEMBLY-671:
-
Summary: Cryptic debug warning message needs improvement and/or
documentation
Key: MASSEMBLY-671
URL: https://jira.codehaus.org/browse/MASSEMBLY-671
Project: Maven Assembly Plugin
Issue Type: Bug
Components: component descriptor
Affects Versions: 2.4, 2.2.1
Environment: irrelevant
Reporter: Steve Cohen
I have used the assembly plugin both versions 2.4 and 2.2.1. While the plugin
basically works, I have some problems with it, (see MASSEMBLY-670), which I
suspect may be related to the following message that shows up when running
Maven in debug mode (-X):
{noformat}
[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(Dele
[jira] (MRELEASE-853) Use "git --depth 1" When Checking Out
[
https://jira.codehaus.org/browse/MRELEASE-853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernst de Haan updated MRELEASE-853:
---
Summary: Use "git --depth 1" When Checking Out (was: Use "git --depth 1"Â
When Checking Out)
> Use "git --depth 1" When Checking Out
> -
>
> Key: MRELEASE-853
> URL: https://jira.codehaus.org/browse/MRELEASE-853
> Project: Maven Release Plugin
> Issue Type: New Feature
> Components: Git
>Affects Versions: 2.2.2
> Environment: Maven 3.1.1
>Reporter: Ernst de Haan
>
> *Executive summary: Please use {{--depth 1}} when checking out from a git
> repository.*
> Currently when doing {{mvn release:prepare release:perform}}, the git
> checkout step takes a significant amount of time.
> During the git checkout it appears to not only check out the correct version
> of the code, but also _all_ history, as would be done with a regular:
> {code:none}git clone URL{code}
> However, git supports checking out only the latest version of the code base,
> using this command: {code:none}git clone --depth 1 URL{code}
> For the purpose of the Maven Release Plugin, that should be sufficient, as
> far as I can see.
> Changing the plugin to use {{--depth 1}} would significantly improve
> performance and reduce I/O on repositories with a lot of history.
--
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-709) REGRESSION: git status doesn't work if repository root is not the working directory
[
https://jira.codehaus.org/browse/SCM-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335206#comment-335206
]
Ernst de Haan commented on SCM-709:
---
Note that I incentified this issue via Donay on Sept 30, 2013. If anyone would
like to claim it, let me know, otherwise I might reallocate it to a different
issue.
> REGRESSION: git status doesn't work if repository root is not the working
> directory
> ---
>
> Key: SCM-709
> URL: https://jira.codehaus.org/browse/SCM-709
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-git
>Affects Versions: 1.8, 1.8.1
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Blocker
> Attachments:
> 0001-use-new-File-.toURI-to-fix-handling-of-paths-with-sp.patch
>
>
> SCM-686 introduced the {{--porcelain}} option to make the {{status}} result
> language independend.
> Without the {{--porcelain}} option files were listed relative to the working
> directory, but with {{--porcelain}} files are listed relative to the
> repository root. In most cases these are the same, but not always.
--
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-854) non-interactive "always yes" option
Markus KARG created MRELEASE-854: Summary: non-interactive "always yes" option Key: MRELEASE-854 URL: https://jira.codehaus.org/browse/MRELEASE-854 Project: Maven Release Plugin Issue Type: Improvement Reporter: Markus KARG Priority: Minor The Maven Release Plugin asks whether -SNAPSHOT dependencies shall be replaced by dependencies, and when answered with "yes" it suggests the release and new development versions. This is great and works well in many cases. Unfortunately, when using automations like Jenkins etc., this feature cannot be used, as apparently that "yes, please apply all your suggestions but don't ask me anything" answer can only be given in interactive mode, while there is no property which would enable the same behaviour in nin-interactive mode. Hence, I wish there would be a parameter (like "alwaysApplyDefaults" which defaults to "false" for backwards compatibility) which, when set to "true" explicitly, just answers "yes" to all questions and suggestions. :-) -- 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] (MCOMPILER-179) Warnings
[
https://jira.codehaus.org/browse/MCOMPILER-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335208#comment-335208
]
Eric Sirianni commented on MCOMPILER-179:
-
I am still seeing this issue in maven 3.1.1. See this [Hadoop
JIRA|https://issues.apache.org/jira/browse/HDFS-5462] as an example.
> Warnings
> -
>
> Key: MCOMPILER-179
> URL: https://jira.codehaus.org/browse/MCOMPILER-179
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.4, 2.5, 2.5.1
> Environment: Windows7, 64-bit
> VMs, 1.6.0_32 and 1.7.0_04 both 64-bit
>Reporter: Sascha Vogt
>Assignee: Anders Hammar
> Fix For: 3.0
>
>
> If one error occurs, all warnings are shown as error as well. Up to {{2.3.2}}
> this was not the case. Sample output {{2.4}} and higher:
> {noformat}
> [INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR] bad path element "": no such file or directory
> C:\dev-tmp\sample\src\main\java\de\maybebuggy\sample\Main.java:[19,18]
> [unchecked] unchecked call to add(E) as a member of the raw type
> java.util.List
> [ERROR]
> C:\dev-tmp\sample\src\main\java\de\maybebuggy\sample\Main.java:[20,18]
> [unchecked] unchecked call to add(E) as a member of the raw type
> java.util.List
> [ERROR]
> C:\dev-tmp\sample\src\main\java\de\maybebuggy\sample\Main.java:[24,15]
> [unchecked] unchecked conversion
> found : java.util.List
> required: java.util.List
> [ERROR]
> C:\dev-tmp\sample\src\main\java\de\maybebuggy\sample\Main.java:[29,29]
> getList() in de.maybebuggy.sample.Main cannot be applied to (int)
> [INFO] 4 errors
> {noformat}
> Sample output {{2.3.2}}:
> {noformat}
> [INFO] -
> [WARNING] COMPILATION WARNING :
> [INFO] -
> [WARNING]
> \dev-tmp\sample\src\main\java\de\maybebuggy\sample\Main.java:[19,18]
> [unchecked] unchecked call to add(E) as a member of the raw type
> java.util.List
> [WARNING]
> \dev-tmp\sample\src\main\java\de\maybebuggy\sample\Main.java:[20,18]
> [unchecked] unchecked call to add(E) as a member of the raw type
> java.util.List
> [WARNING]
> \dev-tmp\sample\src\main\java\de\maybebuggy\sample\Main.java:[24,15]
> [unchecked] unchecked conversion
> found : java.util.List
> required: java.util.List
> [INFO] 3 warnings
> [INFO] -
> [INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> \dev-tmp\sample\src\main\java\de\maybebuggy\sample\Main.java:[29,29]
> getList() in de.maybebuggy.sample.Main cannot be applied to (int)
> [INFO] 1 error
> [INFO] -
> {noformat}
> With the current behavior it is extremely hard to spot the error if there are
> multiple warnings in a project.
--
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=335210#comment-335210 ] Steve Cohen commented on MASSEMBLY-670: --- Thank you. I had an idea as to what the plugin might not have liked. My assembly descriptor was defining both input and output directories of fileSets using properties that were defined in pom.xml. My theory was that this could have been a phase timing issue. Since eventually that correct directories were being made, maybe the problem was that while the filesets were being read, the properties had not been interpolated. That was what the "[DEBUG] After assembly is interpolated:" logging message showed. That was my theory. Alas, it did not pan out. I replaced all these property references with hardcoded directory names. It didn't help. The same error message was produced and the timestamps were still not what I was expecting. > 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=335211#comment-335211 ] Steve Cohen commented on MASSEMBLY-670: --- In response to your comment about http://mail-archives.apache.org/mod_mbox/maven-users/201110.mbox/%3cCAHCAor7DcA9UKMpQredEovqkxw2EPZxJkqJ+=pewkuxjjve...@mail.gmail.com%3e, I had previously found that, and tried the fix that worked for that user. It did not help my 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=335212#comment-335212 ] Steve Cohen commented on MASSEMBLY-670: --- Another theory debunked: running maven under jdk 1.7 did not resolve the issue. > 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-671) Cryptic debug warning message needs improvement and/or documentation
[
https://jira.codehaus.org/browse/MASSEMBLY-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Cohen updated MASSEMBLY-671:
--
Description:
I have used the assembly plugin both versions 2.4 and 2.2.1. While the plugin
basically works, I have some problems with it, (see MASSEMBLY-670), which I
suspect may be related to the following message that shows up when running
Maven in debug mode (-X):
{noformat}
[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.jav
[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=335213#comment-335213 ] Steve Cohen commented on MASSEMBLY-670: --- In regard to your suggestion about running mvnDebug, I've never done this and am not sure how. Could I do this under Eclipse? That's about the only debugger I use these days and that only rarely. > 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] (MDEP-431) new options to output from control dependency:analyze(-only)
Robert Platt created MDEP-431: - Summary: new options to output from control dependency:analyze(-only) Key: MDEP-431 URL: https://jira.codehaus.org/browse/MDEP-431 Project: Maven Dependency Plugin Issue Type: Improvement Affects Versions: 2.8 Reporter: Robert Platt Attachments: mdep.patch Including dependency:analyze-only with failOnWarning into a build can be very effective at catching dependency issues. However, it is pretty much all-or-nothing at the moment. In the case of complex or legacy projects it can be difficult to incorporate the plugin into the build. This is a patch (see attached mdep.path) to version 2.8 to provide more control over dependency analysis output, introducing three new configuration options. In all cases, the default options provide the current plugin behavior: 1. warnUnusedDeclared (default true). Unused declared dependencies generate a warning if this is true, otherwise it is just info. 2. ignoreManagedUndeclared (default false). If true, then used undeclared dependencies which are dependency managed are not reported in the warnings. The reasoning behind this option is that used undeclared dependencies are less likely to break a build in subtle ways if they are dependency managed, since the version will not change without developer intervention. Turning this option on focuses the analysis on compiling against unmanaged transitive dependencies. 3. preferManagedVersionOutput (default false). If true, when outputting XML, versions are left unspecified for managed dependencies. This can be handy when you aren't using ignoreManagedUndeclared but want to use managed versions when fixing undeclared dependencies. Finally, the wording for the output of unused declared dependencies has been changed to 'Potentially unused declared dependencies found' because, as documented, their are limitations to this detection process with the default analyzer. This wording makes it clearer to developers without that working knowledge. -- 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-854) non-interactive "always yes" option
[ https://jira.codehaus.org/browse/MRELEASE-854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRELEASE-854. --- Resolution: Duplicate Assignee: Robert Scholte > non-interactive "always yes" option > --- > > Key: MRELEASE-854 > URL: https://jira.codehaus.org/browse/MRELEASE-854 > Project: Maven Release Plugin > Issue Type: Improvement >Reporter: Markus KARG >Assignee: Robert Scholte >Priority: Minor > > The Maven Release Plugin asks whether -SNAPSHOT dependencies shall be > replaced by dependencies, and when answered with "yes" it suggests the > release and new development versions. This is great and works well in many > cases. > Unfortunately, when using automations like Jenkins etc., this feature cannot > be used, as apparently that "yes, please apply all your suggestions but don't > ask me anything" answer can only be given in interactive mode, while there is > no property which would enable the same behaviour in nin-interactive mode. > Hence, I wish there would be a parameter (like "alwaysApplyDefaults" which > defaults to "false" for backwards compatibility) which, when set to "true" > explicitly, just answers "yes" to all questions and suggestions. :-) -- 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-853) Use "git --depth 1" When Checking Out
[
https://jira.codehaus.org/browse/MRELEASE-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335217#comment-335217
]
Robert Scholte commented on MRELEASE-853:
-
This is something which should be fixed in the [SCM
project|https://jira.codehaus.org/browse/SCM/component/12667]
> Use "git --depth 1" When Checking Out
> -
>
> Key: MRELEASE-853
> URL: https://jira.codehaus.org/browse/MRELEASE-853
> Project: Maven Release Plugin
> Issue Type: New Feature
> Components: Git
>Affects Versions: 2.2.2
> Environment: Maven 3.1.1
>Reporter: Ernst de Haan
>
> *Executive summary: Please use {{--depth 1}} when checking out from a git
> repository.*
> Currently when doing {{mvn release:prepare release:perform}}, the git
> checkout step takes a significant amount of time.
> During the git checkout it appears to not only check out the correct version
> of the code, but also _all_ history, as would be done with a regular:
> {code:none}git clone URL{code}
> However, git supports checking out only the latest version of the code base,
> using this command: {code:none}git clone --depth 1 URL{code}
> For the purpose of the Maven Release Plugin, that should be sufficient, as
> far as I can see.
> Changing the plugin to use {{--depth 1}} would significantly improve
> performance and reduce I/O on repositories with a lot of history.
--
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] (MDEP-431) new options to control output from dependency:analyze(-only)
[ https://jira.codehaus.org/browse/MDEP-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Platt updated MDEP-431: -- Summary: new options to control output from dependency:analyze(-only) (was: new options to output from control dependency:analyze(-only)) > new options to control output from dependency:analyze(-only) > > > Key: MDEP-431 > URL: https://jira.codehaus.org/browse/MDEP-431 > Project: Maven Dependency Plugin > Issue Type: Improvement >Affects Versions: 2.8 >Reporter: Robert Platt > Attachments: mdep.patch > > > Including dependency:analyze-only with failOnWarning into a build can be very > effective at catching dependency issues. However, it is pretty much > all-or-nothing at the moment. In the case of complex or legacy projects it > can be difficult to incorporate the plugin into the build. > This is a patch (see attached mdep.path) to version 2.8 to provide more > control over dependency analysis output, introducing three new configuration > options. In all cases, the default options provide the current plugin > behavior: > 1. warnUnusedDeclared (default true). Unused declared dependencies generate > a warning if this is true, otherwise it is just info. > 2. ignoreManagedUndeclared (default false). If true, then used undeclared > dependencies which are dependency managed are not reported in the warnings. > The reasoning behind this option is that used undeclared dependencies are > less likely to break a build in subtle ways if they are dependency managed, > since the version will not change without developer intervention. Turning > this option on focuses the analysis on compiling against unmanaged transitive > dependencies. > 3. preferManagedVersionOutput (default false). If true, when outputting XML, > versions are left unspecified for managed dependencies. This can be handy > when you aren't using ignoreManagedUndeclared but want to use managed > versions when fixing undeclared dependencies. > Finally, the wording for the output of unused declared dependencies has been > changed to 'Potentially unused declared dependencies found' because, as > documented, their are limitations to this detection process with the default > analyzer. This wording makes it clearer to developers without that working > knowledge. -- 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-709) REGRESSION: git status doesn't work if repository root is not the working directory
[
https://jira.codehaus.org/browse/SCM-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335225#comment-335225
]
Robert Scholte commented on SCM-709:
IIRC this issue should already be partly solved, at least for the git status
part. However, nobody has tested the current snapshot and came with good
feedback. As long as nobody has confirmed that it is fixed, I need to keep this
issue open.
> REGRESSION: git status doesn't work if repository root is not the working
> directory
> ---
>
> Key: SCM-709
> URL: https://jira.codehaus.org/browse/SCM-709
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-git
>Affects Versions: 1.8, 1.8.1
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Blocker
> Attachments:
> 0001-use-new-File-.toURI-to-fix-handling-of-paths-with-sp.patch
>
>
> SCM-686 introduced the {{--porcelain}} option to make the {{status}} result
> language independend.
> Without the {{--porcelain}} option files were listed relative to the working
> directory, but with {{--porcelain}} files are listed relative to the
> repository root. In most cases these are the same, but not always.
--
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=335227#comment-335227 ] Robert Scholte commented on MASSEMBLY-670: -- It's easy, read http://it-worx.blogspot.nl/2010/03/debug-maven-project-in-eclipse.html > 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] (MCHANGES-317) GitHub: "API rate limit exceeded"
[ https://jira.codehaus.org/browse/MCHANGES-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335229#comment-335229 ] Johannes Schneider commented on MCHANGES-317: - This is an issue for me, too. At least the build shouldn't fail but instead cache the values? > GitHub: "API rate limit exceeded" > - > > Key: MCHANGES-317 > URL: https://jira.codehaus.org/browse/MCHANGES-317 > Project: Maven Changes Plugin > Issue Type: Bug > Components: github >Affects Versions: 2.9 >Reporter: Johannes Schneider > > I tried to generate a report and got this message: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project > stax-mate: Error during page generation: Error rendering Maven report: API > rate limit exceeded for 149.###.###.##. See > http://developer.github.com/v3/#rate-limiting for details. (403) -> [Help 1] > I think this is caused by having a low limit for unauthenticated requests. I > think it would be great if there was a way to authenticate... -- 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] (MCHANGES-317) GitHub: "API rate limit exceeded"
[ https://jira.codehaus.org/browse/MCHANGES-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335230#comment-335230 ] Johannes Schneider commented on MCHANGES-317: - And please, please respect "-o"... There seems to be no way to avoid this problem currently... > GitHub: "API rate limit exceeded" > - > > Key: MCHANGES-317 > URL: https://jira.codehaus.org/browse/MCHANGES-317 > Project: Maven Changes Plugin > Issue Type: Bug > Components: github >Affects Versions: 2.9 >Reporter: Johannes Schneider > > I tried to generate a report and got this message: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project > stax-mate: Error during page generation: Error rendering Maven report: API > rate limit exceeded for 149.###.###.##. See > http://developer.github.com/v3/#rate-limiting for details. (403) -> [Help 1] > I think this is caused by having a low limit for unauthenticated requests. I > think it would be great if there was a way to authenticate... -- 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=335231#comment-335231 ] Steve Cohen commented on MASSEMBLY-670: --- Thanks, Robert. I am debugging now, but I think I need the plexus source code for it to make any sense. Where do I get that? > 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=335231#comment-335231 ] Steve Cohen edited comment on MASSEMBLY-670 at 11/5/13 2:37 PM: Thanks, Robert. I am debugging now, but I think I need the plexus source code for it to make any sense. Where do I get that? I tried svn checkout https://svn.codehaus.org/plexus/trunks plexus-site and I am stuck for a long time in "Fetching external item into 'plexus-site\plexus-classworlds'" This does not seem to be the right way to get it. was (Author: sco...@javactivity.org): Thanks, Robert. I am debugging now, but I think I need the plexus source code for it to make any sense. Where do I get that? > 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] (MJAR-173) Check correctness of declared deps
[ https://jira.codehaus.org/browse/MJAR-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Hammar reassigned MJAR-173: -- Assignee: Anders Hammar > Check correctness of declared deps > -- > > Key: MJAR-173 > URL: https://jira.codehaus.org/browse/MJAR-173 > Project: Maven JAR Plugin > Issue Type: Task >Affects Versions: 2.4 > Environment: n/a >Reporter: Anders Hammar >Assignee: Anders Hammar > > dependency:analyze reports some incorrectness wrt declared deps. Should be > investigated and fixed. > [WARNING] Used undeclared dependencies found: > [WARNING]xml-apis:xml-apis:jar:1.0.b2:runtime > [WARNING]org.apache.maven:maven-core:jar:2.0.6:compile > [WARNING]jtidy:jtidy:jar:4aug2000r7-dev:runtime > [WARNING] Unused declared dependencies found: > [WARNING]org.apache.maven:maven-model:jar:2.0.6:runtime > [WARNING]commons-lang:commons-lang:jar:2.1:compile > [WARNING]org.codehaus.plexus:plexus-utils:jar:3.0.15:compile > [WARNING]junit:junit:jar:3.8.2:test -- 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] (MJAR-173) Check correctness of declared deps
Anders Hammar created MJAR-173: -- Summary: Check correctness of declared deps Key: MJAR-173 URL: https://jira.codehaus.org/browse/MJAR-173 Project: Maven JAR Plugin Issue Type: Task Affects Versions: 2.4 Environment: n/a Reporter: Anders Hammar dependency:analyze reports some incorrectness wrt declared deps. Should be investigated and fixed. [WARNING] Used undeclared dependencies found: [WARNING]xml-apis:xml-apis:jar:1.0.b2:runtime [WARNING]org.apache.maven:maven-core:jar:2.0.6:compile [WARNING]jtidy:jtidy:jar:4aug2000r7-dev:runtime [WARNING] Unused declared dependencies found: [WARNING]org.apache.maven:maven-model:jar:2.0.6:runtime [WARNING]commons-lang:commons-lang:jar:2.1:compile [WARNING]org.codehaus.plexus:plexus-utils:jar:3.0.15:compile [WARNING]junit:junit:jar:3.8.2:test -- 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=335234#comment-335234 ] Robert Scholte commented on MASSEMBLY-670: -- I would expect that these sources are available at Maven Central, so Eclipse should be able to download it for you (assuming you're using the m2eclipse plugin). If you're unlucky, just download the jar from http://search.maven.org/#search%7Cga%7C1%7Cplexus-archiver matching the right version. In eclipse, right-click the plexus-archiver jar and select "Java Source Attachment". But again: Eclipse should be able to download it for you if you select a class from this jar. > 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=335235#comment-335235 ] Steve Cohen commented on MASSEMBLY-670: --- That was a firewall issue. I got the software out of SVN, sneakernetted it onto the PC where the build is run, and tried to add the source location for the plexus code. This behaved oddly: the source appeared for a fraction of a second and then disappeared. Somehow Eclipse found it wanting. Perhaps, the source I got did not match the code that maven is running with? > 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] (MJAR-173) Check correctness of declared deps
[ https://jira.codehaus.org/browse/MJAR-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Hammar updated MJAR-173: --- Fix Version/s: 2.5 > Check correctness of declared deps > -- > > Key: MJAR-173 > URL: https://jira.codehaus.org/browse/MJAR-173 > Project: Maven JAR Plugin > Issue Type: Task >Affects Versions: 2.4 > Environment: n/a >Reporter: Anders Hammar >Assignee: Anders Hammar > Fix For: 2.5 > > > dependency:analyze reports some incorrectness wrt declared deps. Should be > investigated and fixed. > [WARNING] Used undeclared dependencies found: > [WARNING]xml-apis:xml-apis:jar:1.0.b2:runtime > [WARNING]org.apache.maven:maven-core:jar:2.0.6:compile > [WARNING]jtidy:jtidy:jar:4aug2000r7-dev:runtime > [WARNING] Unused declared dependencies found: > [WARNING]org.apache.maven:maven-model:jar:2.0.6:runtime > [WARNING]commons-lang:commons-lang:jar:2.1:compile > [WARNING]org.codehaus.plexus:plexus-utils:jar:3.0.15:compile > [WARNING]junit:junit:jar:3.8.2:test -- 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=335236#comment-335236 ] Steve Cohen commented on MASSEMBLY-670: --- Thanks, Robert, I am using M2Eclipse. But the Maven Plugins do not appear in my Maven Dependencies, so I've nothing to right click on and get the Java Source Attachment option. How do I make my the plugins appear in Eclipse? > 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] (MPLUGIN-235) Doc example incorrectly states that plexus-utils is needed as a dependency
[
https://jira.codehaus.org/browse/MPLUGIN-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335239#comment-335239
]
Herve Boutemy commented on MPLUGIN-235:
---
as you can see in MPLUGIN-229, the dependency was removed in plugin-tools 3.2,
but the doc wasn't updated
> Doc example incorrectly states that plexus-utils is needed as a dependency
> --
>
> Key: MPLUGIN-235
> URL: https://jira.codehaus.org/browse/MPLUGIN-235
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Affects Versions: 3.2
> Environment: n/a
>Reporter: Anders Hammar
>Assignee: Anders Hammar
> Fix For: 3.3
>
>
> On the plugin site, in the "Using Plugin Tools Java5 Annotations" example, it
> states:
> {quote}
>
>
> org.codehaus.plexus
> plexus-utils
> 3.0.1
>
> {quote}
> This is not correct and this dependency should be removed from the 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] (MPLUGIN-229) don't use Plexus' Xpp3 in generated HelpMojo to read XML files: XML parser in JDK is sufficient
[ https://jira.codehaus.org/browse/MPLUGIN-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335240#comment-335240 ] Herve Boutemy commented on MPLUGIN-229: --- [r1405040|http://svn.apache.org/r1405040] > don't use Plexus' Xpp3 in generated HelpMojo to read XML files: XML parser in > JDK is sufficient > --- > > Key: MPLUGIN-229 > URL: https://jira.codehaus.org/browse/MPLUGIN-229 > Project: Maven Plugin Tools > Issue Type: Improvement > Components: Plugin Plugin >Affects Versions: 3.1 >Reporter: Herve Boutemy >Assignee: Kristian Rosenvold > Fix For: 3.2 > > > replacing a dependency on plexus-utils with JDK is a Good Thing (TM) > part of MNG-2255, easy to do -- 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-668) Provide a way to optionally set owner and group of archive files as tar does
[ https://jira.codehaus.org/browse/MASSEMBLY-668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335242#comment-335242 ] Steve Cohen commented on MASSEMBLY-668: --- Please close this issue. I no longer think this is worth pursuing, given the fact that it flies in the face of unix prohibition of anyone but root being able to change file ownership. > Provide a way to optionally set owner and group of archive files as tar does > > > Key: MASSEMBLY-668 > URL: https://jira.codehaus.org/browse/MASSEMBLY-668 > Project: Maven Assembly Plugin > Issue Type: New Feature > Components: component descriptor >Affects Versions: 2.4 > Environment: RHEL 5 >Reporter: Steven Cohen >Priority: Minor > > Why isn't there a way to set the ownership of files packaged by the assembly > plugin, similar to how it allows you to set permissions? > The unix tar program offers --user= and --group=. It would be nice if there > were a way to do this in the assembly plugin -- 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=335244#comment-335244 ] Steve Cohen commented on MASSEMBLY-670: --- The culprit seems to be the tag. This seems to cause a temporary folder to be created in which the file is modified and this process changes the modified date of the archived file. Removing this tag from one of the file sets caused its timestamps to be unmodified while those which had the tag still had their timestamps modified.ut it' I guess this makes sense in some way but it's undesirable from the point of view of my use 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
