[jira] (MRELEASE-812) "prepare" does not commit before tagging and therefore deploys snapshot instead of release
[
https://jira.codehaus.org/browse/MRELEASE-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=351075#comment-351075
]
Torben Knerr commented on MRELEASE-812:
---
Interestingly, I'm seeing this with maven-3.0.5 / maven-release-plugin 2.4.2 on
our build server (ubuntu) but not on my local windows machine (windows).
I had run exactly the same commands ({{mvn release:clean release:prepare -B -X
-DreleaseVersion=1.0-alpha-1 -DupdateWorkingCopyVersions=false}}) on both my
windows workstation and on our ubuntu buildserver.
They produced exactly the same output, same plugin dependencies (run with
{{-X}} flag), but on the buildserver the commit / push of the modified pom was
missing.
I have no clue why this behaves differently on my windows workstation vs.
buildserver.
Pinning maven-release-plugin to 2.5 in pluginManagement solved the problem for
me.
> "prepare" does not commit before tagging and therefore deploys snapshot
> instead of release
> --
>
> Key: MRELEASE-812
> URL: https://jira.codehaus.org/browse/MRELEASE-812
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: Git
>Affects Versions: 2.3.2, 2.4
>Reporter: Andrei Pozolotin
>Assignee: Robert Scholte
>Priority: Critical
> Fix For: 2.5
>
> Attachments: mvn-2.3.2.txt, mvn-2.4.0.txt
>
>
> thank you very much for new release!
> http://mail-archives.apache.org/mod_mbox/maven-announce/201212.mbox/%3Cop.wpjbptp1kdkhrr@columbia%3E
> it seems we need an emergency fix:
> attached are 2 logs:
> 1) mvn-2.3.2.txt invocation that works fine with 2.3.2
> 2) mvn-2.4.0.txt invocation that fails with 2.4
> problem:
> "perform" does not commit tags, deploys snapshot instead of release
> here is project parent:
> http://search.maven.org/remotecontent?filepath=com/barchart/base/barchart-archon/2.3.6/barchart-archon-2.3.6.pom
> build is invoked both times with this:
> mvn --define resume=false release:prepare
> mvn --define resume=false release:perform
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5674) Connection - Time out
Heinz Wittig created MNG-5674: - Summary: Connection - Time out Key: MNG-5674 URL: https://jira.codehaus.org/browse/MNG-5674 Project: Maven Issue Type: Bug Components: Command Line Affects Versions: 3.2.1 Environment: Ubuntu 12.04 Reporter: Heinz Wittig Priority: Blocker By run an mvn clean install or mvn compile on a project with dependencies defined on a local server, the connection hangs up and and don't gives feedback. If I try to put some error on the setting.xml (by setting username and password) and I will become back the correct error (auth failure). I tried with -X to have more information but nothing. Then I installed an older version (3.0.4) without changing anything and the download of the dependencies worked. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5675) Invert goal execution order during post-integration-test phase
Giovanni Toraldo created MNG-5675: - Summary: Invert goal execution order during post-integration-test phase Key: MNG-5675 URL: https://jira.codehaus.org/browse/MNG-5675 Project: Maven Issue Type: Improvement Components: Plugins and Lifecycle Affects Versions: 3.1.1 Reporter: Giovanni Toraldo Hi, I have defined multiple plugin execution during the pre-integration-test and post-integration-test phase, and they get executed in the same order that have been defined in pom.xml. Unfortunately, since I am launching an a message broker and a servlet container, I need that during the post-integration-test phase they get executed in the inverse order (compared to pre-integration-test) to properly shutdown those services. Maybe provide a way to explicit the ordering for each execution is a better solution to cover all the possibile use-case. Thanks. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-198) ensure use of latest available released version of artefact
Bjoern Koos created MENFORCER-198: - Summary: ensure use of latest available released version of artefact Key: MENFORCER-198 URL: https://jira.codehaus.org/browse/MENFORCER-198 Project: Maven Enforcer Plugin Issue Type: Wish Reporter: Bjoern Koos The plugin (if it does not already) should provide means to enforce the use of the latest release version of e.g. a utility library. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-199) allow the file based rules to use wildcards on resources
Bjoern Koos created MENFORCER-199: - Summary: allow the file based rules to use wildcards on resources Key: MENFORCER-199 URL: https://jira.codehaus.org/browse/MENFORCER-199 Project: Maven Enforcer Plugin Issue Type: Wish Reporter: Bjoern Koos To check e.g. a maximum file size on multiple resources it would be helpful to use wildcards. Either in the specified files entries or maybe by using a fileSet-like semantics. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRELEASE-812) "prepare" does not commit before tagging and therefore deploys snapshot instead of release
[
https://jira.codehaus.org/browse/MRELEASE-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=35#comment-35
]
Torben Knerr commented on MRELEASE-812:
---
Re: 2.5 solved the problem only for projects with top-level pom files, run into
MRELEASE-875 as well :-/
I tried switching back to 2.4.2 or 2.3.2 but none of the suggested approaches
worked for me (neither with {{LANG=en_US.UTF8}} nor with the git-exe 1.9 plugin
dependency)
> "prepare" does not commit before tagging and therefore deploys snapshot
> instead of release
> --
>
> Key: MRELEASE-812
> URL: https://jira.codehaus.org/browse/MRELEASE-812
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: Git
>Affects Versions: 2.3.2, 2.4
>Reporter: Andrei Pozolotin
>Assignee: Robert Scholte
>Priority: Critical
> Fix For: 2.5
>
> Attachments: mvn-2.3.2.txt, mvn-2.4.0.txt
>
>
> thank you very much for new release!
> http://mail-archives.apache.org/mod_mbox/maven-announce/201212.mbox/%3Cop.wpjbptp1kdkhrr@columbia%3E
> it seems we need an emergency fix:
> attached are 2 logs:
> 1) mvn-2.3.2.txt invocation that works fine with 2.3.2
> 2) mvn-2.4.0.txt invocation that fails with 2.4
> problem:
> "perform" does not commit tags, deploys snapshot instead of release
> here is project parent:
> http://search.maven.org/remotecontent?filepath=com/barchart/base/barchart-archon/2.3.6/barchart-archon-2.3.6.pom
> build is invoked both times with this:
> mvn --define resume=false release:prepare
> mvn --define resume=false release:perform
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRELEASE-875) release:prepare does not commit pom.xml if not in the git root
[
https://jira.codehaus.org/browse/MRELEASE-875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=351113#comment-351113
]
Torben Knerr commented on MRELEASE-875:
---
workaround above {{git config --add status.displayCommentPrefix true}} did not
work for me with Git 1.9.1 and release plugin 2.4.2
> release:prepare does not commit pom.xml if not in the git root
> --
>
> Key: MRELEASE-875
> URL: https://jira.codehaus.org/browse/MRELEASE-875
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare, scm
>Affects Versions: 2.5
> Environment: git 1.9.0
>Reporter: john ten Den
>Assignee: Dominik Bartholdi
>
> When the project pom.xml is not in the Git project root (f.e. in the "src"
> directory) the pom.xml not committed and pushed (before tagging)
> Commit of the pom.xml during release:prepare works fine if it is in the /
> (root) of the git repository
> Using the pom.xml in a subdirectory worked well with version 2.4.2 using git
> 1.7.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1088) When test fail during initialization the test execution time can result in a large negative number.
Daniel Cruver created SUREFIRE-1088: --- Summary: When test fail during initialization the test execution time can result in a large negative number. Key: SUREFIRE-1088 URL: https://jira.codehaus.org/browse/SUREFIRE-1088 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Affects Versions: 2.16 Reporter: Daniel Cruver Priority: Minor For example it will print out this: Time elapsed: -1,317,678.69 sec <<< ERROR! This happened in a call to @BeforeClass method and was specifically when a class was not found when loading in a spring context. The later is not that important because we have seen it happen in other cases. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRELEASE-875) release:prepare does not commit pom.xml if not in the git root
[ https://jira.codehaus.org/browse/MRELEASE-875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=351118#comment-351118 ] Martin Ellis commented on MRELEASE-875: --- Torben: If you run maven with the -X option, it'll show the output of the git status command in the log. That way you'll be able to verify whether the comment prefix is being added. The regular expressions the git output is being matched against are the static fields in this class: http://svn.apache.org/repos/asf/maven/scm/tags/maven-scm-1.7/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/status/GitStatusConsumer.java > release:prepare does not commit pom.xml if not in the git root > -- > > Key: MRELEASE-875 > URL: https://jira.codehaus.org/browse/MRELEASE-875 > Project: Maven Release Plugin > Issue Type: Bug > Components: prepare, scm >Affects Versions: 2.5 > Environment: git 1.9.0 >Reporter: john ten Den >Assignee: Dominik Bartholdi > > When the project pom.xml is not in the Git project root (f.e. in the "src" > directory) the pom.xml not committed and pushed (before tagging) > Commit of the pom.xml during release:prepare works fine if it is in the / > (root) of the git repository > Using the pom.xml in a subdirectory worked well with version 2.4.2 using git > 1.7. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MDEP-406) skip is ignored
[
https://jira.codehaus.org/browse/MDEP-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MDEP-406.
---
Resolution: Not A Bug
Assignee: Robert Scholte
Dependency resolution is part of Maven core, this plugin has no influence on it.
> skip is ignored
> ---
>
> Key: MDEP-406
> URL: https://jira.codehaus.org/browse/MDEP-406
> Project: Maven Dependency Plugin
> Issue Type: Bug
>Affects Versions: 2.7
> Environment: Maven 3.0.4, Dependency Plugin 2.7
>Reporter: H.-C. Gürsoy
>Assignee: Robert Scholte
>
> I've a build there I've to skip dependency resolution.
> According to the 2.7 documentation, using the skip parameter should prevent
> from running the whole plugin execution.
> Call mvn with -Dmdep.skip=true or setting skip to true in the plugin
> configuration with
> {code}
>
>
> org.apache.maven.plugins
>
> maven-dependency-plugin
> 2.7
>
> true
>
>
> {code}
> is allways ignored.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MDEP-424) Maven Dependency Plugin homepage should link to dependency:list-repositories
[ https://jira.codehaus.org/browse/MDEP-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte reassigned MDEP-424: --- Assignee: Robert Scholte > Maven Dependency Plugin homepage should link to dependency:list-repositories > > > Key: MDEP-424 > URL: https://jira.codehaus.org/browse/MDEP-424 > Project: Maven Dependency Plugin > Issue Type: Bug >Reporter: Michael Vorburger >Assignee: Robert Scholte > > http://maven.apache.org/plugins/maven-dependency-plugin/ should list and have > a link to > http://maven.apache.org/plugins/maven-dependency-plugin/list-repositories-mojo.html -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MDEP-424) Maven Dependency Plugin homepage should link to dependency:list-repositories
[ https://jira.codehaus.org/browse/MDEP-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MDEP-424. --- Resolution: Fixed Fix Version/s: 2.9 Fixed in [r1616565|http://svn.apache.org/r1616565] > Maven Dependency Plugin homepage should link to dependency:list-repositories > > > Key: MDEP-424 > URL: https://jira.codehaus.org/browse/MDEP-424 > Project: Maven Dependency Plugin > Issue Type: Bug >Reporter: Michael Vorburger >Assignee: Robert Scholte > Fix For: 2.9 > > > http://maven.apache.org/plugins/maven-dependency-plugin/ should list and have > a link to > http://maven.apache.org/plugins/maven-dependency-plugin/list-repositories-mojo.html -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MDEP-261) Adding dependencies to existing poms via shell
[ https://jira.codehaus.org/browse/MDEP-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MDEP-261. --- Resolution: Won't Fix Assignee: Robert Scholte Most IDEs have a much stronger way to handle including auto-completion Anyhow I wouldn't use the dependency plugin for this purpose. You might consider [Forge|http://forge.jboss.org/addon/org.jboss.forge.addon:projects] which was designed for this purpose. > Adding dependencies to existing poms via shell > -- > > Key: MDEP-261 > URL: https://jira.codehaus.org/browse/MDEP-261 > Project: Maven Dependency Plugin > Issue Type: Improvement >Reporter: Oliver Schrenk >Assignee: Robert Scholte >Priority: Minor > > It would be a nice addition if you could be able to inject dependencies while > you are in your shell. > Maybe something like: > mvn dependency:add -DgroupID=com.acme -DartifactId=project > which then injects the dependency into the pom. The approach felt natural and > I was kinda confused that this doesn't exist yet. > Thoughts? -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MDEP-218) new mojo to move dependencies up/down within multi-module projects
[ https://jira.codehaus.org/browse/MDEP-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MDEP-218. --- Resolution: Won't Fix Assignee: Robert Scholte The dependency plugin is primarily meant for analysis and downloading dependencies, not for changing the pom.xml. Maybe the [tidy-maven-plugin|http://mojo.codehaus.org/tidy-maven-plugin/] is a better maven-plugin for such an option or a tool like [Forge|http://forge.jboss.org/] > new mojo to move dependencies up/down within multi-module projects > -- > > Key: MDEP-218 > URL: https://jira.codehaus.org/browse/MDEP-218 > Project: Maven Dependency Plugin > Issue Type: New Feature >Reporter: jieryn >Assignee: Robert Scholte >Priority: Minor > > Brian Fox and I discussed this a bit over IRC today. What I would like to see > is two new goals which will operate on a multi-module project. They both are > related in that they move dependency definitions either to or from an > aggregate pom.xml. > Moving dependencies TO aggregate pom from the modules would be the easiest > case, and also the least recommended. This would basically siphon out all of > the from each module's pom, the module list found in > aggregate's , and place them into the aggregates > section. While this isn't really the purist Maven way, it is a valid way of > organizing a pom.xml, and a strategy employed by many users -- and therefore > useful to the population at large. > Moving dependencies FROM aggregate pom to the modules would be a harder, but > recommended case. This would basically run dependency:analyze to determine > which dependencies listed in aggregate pom's section were > required in each of the module's pom (again, the module list found in > aggregate's ). Using the analyzed information, it could remove the > aggregate's section and push these dependencies into exactly > the right places. > In both cases we'd end up modifying the pom.xml with the updated dependency > information. It would be wise to mirror the m-release-p behavior of keeping > around backup pom.xml documents for backing out the changes in case of error. > Finally, there's a case where we have multiple levels of depth where an > aggregate contains at least one module which is also an aggregate. I welcome > comments, but to me, these enhancements would operate at a global level in > that they'd move dependencies all the way to the root aggregate or down to > the leaf modules, respectively for cases TO and FROM. Also, this only works > for modules which are on the relative file system path -- I often have an > aggregate pom whose parent's is a super pom not located anywhere on my file > system. If the system detects this case, it would consider stop the recursion. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MDEP-241) Dependency-Unpack and Unpack do not preserve executable flags
[
https://jira.codehaus.org/browse/MDEP-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MDEP-241.
---
Resolution: Cannot Reproduce
Assignee: Robert Scholte
PLXCOMP-147 was fixed with plexus-archiver-2.0.2. The
maven-dependency-plugin-2.6 already uses 2.2, so this is already fixed for a
long time.
> Dependency-Unpack and Unpack do not preserve executable flags
> -
>
> Key: MDEP-241
> URL: https://jira.codehaus.org/browse/MDEP-241
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: unpack, unpack-dependencies
>Reporter: Matthew Jensen
>Assignee: Robert Scholte
>
> Using {{unpack}} and {{unpack-dependencies}} will not preserve any files that
> have their executable bit set.
> This is because of PLXCOMP-147 which has a patch.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MDEP-421) Unpack Incredibly Slow for
[
https://jira.codehaus.org/browse/MDEP-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MDEP-421:
Description:
I've got a zipfile that is 240MB and has ~84k entries. I'm trying to use
unpack-dependencies and it is taking an inordinate amount of time such that it
is basically unusable. It seems that it's eagerly trying to read through every
zip file entry before actually unpacking. This takes roughly 15 minutes where
using the maven antrun plugin / unzip task takes less than a minute.
{noformat}
java.lang.Thread.State: RUNNABLE
at java.util.Hashtable.put(Hashtable.java:549)
- locked <0x0007e160ea18> (a java.util.Hashtable)
at
org.codehaus.plexus.archiver.zip.ZipFile.resolveLocalFileHeaderData(ZipFile.java:451)
at org.codehaus.plexus.archiver.zip.ZipFile.(ZipFile.java:153)
at
org.codehaus.plexus.archiver.zip.AbstractZipUnArchiver.execute(AbstractZipUnArchiver.java:138)
at
org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:120)
at
org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:315)
at
org.apache.maven.plugin.dependency.fromDependencies.UnpackDependenciesMojo.doExecute(UnpackDependenciesMojo.java:91)
at
org.apache.maven.plugin.dependency.AbstractDependencyMojo.execute(AbstractDependencyMojo.java:167)
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:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
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)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
{noformat}
was:
I've got a zipfile that is 240MB and has ~84k entries. I'm trying to use
unpack-dependencies and it is taking an inordinate amount of time such that it
is basically unusable. It seems that it's eagerly trying to read through every
zip file entry before actually unpacking. This takes roughly 15 minutes where
using the maven antrun plugin / unzip task takes less than a minute.
java.lang.Thread.State: RUNNABLE
at java.util.Hashtable.put(Hashtable.java:549)
- locked <0x0007e160ea18> (a java.util.Hashtable)
at
org.codehaus.plexus.archiver.zip.ZipFile.resolveLocalFileHeaderData(ZipFile.java:451)
at org.codehaus.plexus.archiver.zip.ZipFile.(ZipFile.java:153)
at
org.codehaus.plexus.archiver.zip.AbstractZipUnArchiver.execute(AbstractZipUnArchiver.java:138)
at
org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:120)
at
org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:315)
at
org.apache.maven.plugin.dependency.fromDependencies.UnpackDependenciesMojo.doExecute(UnpackDependenciesMojo.java:91)
at
org.apache.maven.plugin.dependency.AbstractDependencyMojo.execute(AbstractDependencyMojo.java:167)
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.
[jira] (MDEP-108) update site to show how to inject custom unarchiver
[
https://jira.codehaus.org/browse/MDEP-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MDEP-108:
Description:
I'have developed a Maven plugin that defines a new packaging type. Produced
artifacts with this packaging type, have a "car" extension.
Modules, that depends on "car" modules must unpack them to use them. To do so,
I configure the maven-dependency-plugin like this (note that "cecilia-lib" is
the name of the packaging type I've defined):
{code:xml}
maven-dependency-plugin
unpack
process-resources
unpack-dependencies
cecilia-lib
{code}
Here, I get the error :
{noformat}
Unknown archiver type
Embedded error: No such archiver: 'car'.
{noformat}
After some investigations, I add the following in the plexus/components.xml of
my plugin:
{code:xml}
org.codehaus.plexus.archiver.UnArchiver
car
org.codehaus.plexus.archiver.zip.ZipUnArchiver
per-lookup
{code}
But I still get the same error.
If I had somewhere in my plugin the following code:
{code}
container.lookup( "org.codehaus.plexus.archiver.Archiver", "car");
archiverManager.getUnArchiver( "car" )
{code}
It works correctly...
So I can't figure out why it doesn't work from the dependency plugin.
was:
I'have developed a Maven plugin that defines a new packaging type. Produced
artifacts with this packaging type, have a "car" extension.
Modules, that depends on "car" modules must unpack them to use them. To do so,
I configure the maven-dependency-plugin like this (note that "cecilia-lib" is
the name of the packaging type I've defined):
maven-dependency-plugin
unpack
process-resources
unpack-dependencies
cecilia-lib
Here, I get the error :
Unknown archiver type
Embedded error: No such archiver: 'car'.
After some investigations, I add the following in the plexus/components.xml of
my plugin:
org.codehaus.plexus.archiver.UnArchiver
car
org.codehaus.plexus.archiver.zip.ZipUnArchiver
per-lookup
But I still get the same error.
If I had somewhere in my plugin the following code:
container.lookup( "org.codehaus.plexus.archiver.Archiver", "car");
archiverManager.getUnArchiver( "car" )
It works correctly...
So I can't figure out why it doesn't work from the dependency plugin.
> update site to show how to inject custom unarchiver
> ---
>
> Key: MDEP-108
> URL: https://jira.codehaus.org/browse/MDEP-108
> Project: Maven Dependency Plugin
> Issue Type: Improvement
> Components: unpack-dependencies
>Affects Versions: 2.0-alpha-4
>Reporter: Matthieu Leclercq
>Priority: Minor
>
> I'have developed a Maven plugin that defines a new packaging type. Produced
> artifacts with this packaging type, have a "car" extension.
> Modules, that depends on "car" modules must unpack them to use them. To do
> so, I configure the maven-dependency-plugin like this (note that
> "cecilia-lib" is the name of the packaging type I've defined):
> {code:xml}
>
> maven-dependency-plugin
>
>
> unpack
> process-resources
>
> unpack-dependencies
>
>
>
>
> cecilia-lib
>
>
> {code}
> Here, I get the error :
> {noformat}
> Unknown archiver type
> Embedded error: No such archiver: 'car'.
> {noformat}
> After some investigations, I add the following in the plexus/components.xml
> of my plugin:
> {code:xml}
>
> org.codehaus.plexus.archiver.UnArchiver
> car
>
>
> org.codehaus.plexus.archiver.zip.ZipUnArchiver
> per-lookup
>
> {code}
> But I still get the same error.
> If I had somewhere in my plugin the following code:
> {code}
> container.lookup( "org.codehaus.plexus.archiver.Archiver", "car");
> archiverManager.getUnArchiver( "car" )
> {code}
> It works correctly...
> So I can't figure out why it doesn't work from the dependency plugin.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MDEP-258) Unpack does not seem to extract *.txt files
[
https://jira.codehaus.org/browse/MDEP-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MDEP-258:
Description:
When using the maven-dependency-plugin in the following example any *.txt files
do not seem to get extracted, although everything else does. I've tried with
and without any exclude patterns and with different phase values, but nothing
seems to make a difference. Sample JAR is included. Apologies if this is due
to some rule about what can/cannot be included in a JAR file, but I would
assume that since the *.txt files are packaged by Maven that they should also
be allowed to be extracted.
{code:xml}
org.apache.maven.plugins
maven-dependency-plugin
unpack
unpack
org.jamwiki
jamwiki-db
jar
${project.build.directory}/classes
{code}
was:
When using the maven-dependency-plugin in the following example any *.txt files
do not seem to get extracted, although everything else does. I've tried with
and without any exclude patterns and with different phase values, but nothing
seems to make a difference. Sample JAR is included. Apologies if this is due
to some rule about what can/cannot be included in a JAR file, but I would
assume that since the *.txt files are packaged by Maven that they should also
be allowed to be extracted.
org.apache.maven.plugins
maven-dependency-plugin
unpack
unpack
org.jamwiki
jamwiki-db
jar
${project.build.directory}/classes
> Unpack does not seem to extract *.txt files
> ---
>
> Key: MDEP-258
> URL: https://jira.codehaus.org/browse/MDEP-258
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: unpack
>Affects Versions: 2.1
> Environment: Windows 7 (64-bit), Java 1.5.0_22, Maven 2.2.1
>Reporter: Ryan Holliday
> Attachments: jamwiki-db-0.9.0-SNAPSHOT.jar
>
>
> When using the maven-dependency-plugin in the following example any *.txt
> files do not seem to get extracted, although everything else does. I've
> tried with and without any exclude patterns and with different phase values,
> but nothing seems to make a difference. Sample JAR is included. Apologies
> if this is due to some rule about what can/cannot be included in a JAR file,
> but I would assume that since the *.txt files are packaged by Maven that they
> should also be allowed to be extracted.
> {code:xml}
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
>
>
> unpack
>
> unpack
>
>
>
>
> org.jamwiki
> jamwiki-db
> jar
>
> ${project.build.directory}/classes
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5674) Connection - Time out
[ https://jira.codehaus.org/browse/MNG-5674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Heinz Wittig updated MNG-5674: -- Affects Version/s: 3.2.2 > Connection - Time out > - > > Key: MNG-5674 > URL: https://jira.codehaus.org/browse/MNG-5674 > Project: Maven > Issue Type: Bug > Components: Command Line >Affects Versions: 3.2.1, 3.2.2 > Environment: Ubuntu 12.04 >Reporter: Heinz Wittig >Priority: Blocker > > By run an mvn clean install or mvn compile on a project with dependencies > defined on a local server, the connection hangs up and and don't gives > feedback. > If I try to put some error on the setting.xml (by setting username and > password) and I will become back the correct error (auth failure). > I tried with -X to have more information but nothing. Then I installed an > older version (3.0.4) without changing anything and the download of the > dependencies worked. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5674) Connection - Time out
[ https://jira.codehaus.org/browse/MNG-5674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Heinz Wittig updated MNG-5674: -- Description: By run an mvn clean install or mvn compile on a project with dependencies defined on a local server, the connection hangs up and and don't gives feedback. If I try to put some error on the setting.xml (by setting username and password) and I will become back the correct error (auth failure). I tried with -X to have more information but nothing. Then I installed an older version (3.0.4) without changing anything and the download of the dependencies worked. I have the same behaviour in the current version 3.2.2 was: By run an mvn clean install or mvn compile on a project with dependencies defined on a local server, the connection hangs up and and don't gives feedback. If I try to put some error on the setting.xml (by setting username and password) and I will become back the correct error (auth failure). I tried with -X to have more information but nothing. Then I installed an older version (3.0.4) without changing anything and the download of the dependencies worked. > Connection - Time out > - > > Key: MNG-5674 > URL: https://jira.codehaus.org/browse/MNG-5674 > Project: Maven > Issue Type: Bug > Components: Command Line >Affects Versions: 3.2.1, 3.2.2 > Environment: Ubuntu 12.04 >Reporter: Heinz Wittig >Priority: Blocker > > By run an mvn clean install or mvn compile on a project with dependencies > defined on a local server, the connection hangs up and and don't gives > feedback. > If I try to put some error on the setting.xml (by setting username and > password) and I will become back the correct error (auth failure). > I tried with -X to have more information but nothing. Then I installed an > older version (3.0.4) without changing anything and the download of the > dependencies worked. > I have the same behaviour in the current version 3.2.2 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5676) mvn -U crashes with IBM JDK
Dan Tran created MNG-5676: - Summary: mvn -U crashes with IBM JDK Key: MNG-5676 URL: https://jira.codehaus.org/browse/MNG-5676 Project: Maven Issue Type: Bug Affects Versions: 3.2.2, 3.1.1 Environment: IBM JDK, OpenSuSE enterprise server 11 Reporter: Dan Tran details discussion is at http://maven.40175.n5.nabble.com/Upgrade-to-3-1-1-causes-problems-td5776875.html work around is replace boot/plexus-classworlds-2.5.x.jar with plexus-classworlds-2.4.1.jar as discussed at the link -- This message was sent by Atlassian JIRA (v6.1.6#6162)
