[jira] (MDEP-187) dependency:copy fails when invoked from m2e with workspace resolution enabled, or more generally when copying within reactor for phases earlier than package
[ https://jira.codehaus.org/browse/MDEP-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353540#comment-353540 ] Hannes Kogler commented on MDEP-187: same problem here! we have a common parent project that hosts some ant scripts we use in the single child projects what we want to do is to: => download the zip file of the parent project, including all the common ant scripts we need, and unpack it to the target folder of every single child project. on the build server, where pure Maven is used, this is no problem. But if we are in Eclipse workspace where we use m2e, and the *workspace resolution is enabled*, AND the *parent project* is also checked out *in the same workspace* directory, the download of the zip dependency doesn't work. The downloaded zip file gets corrupted and we get the message: _Error unpacking file: ... org.codehaus.plexus.archiver.ArchiverException: Error while expanding_ => the downloaded artifact is NOT the zip, but just the corresponding pom.xml file! (named as zip archive) As a workaround we tried to implement the same download concept using the maven-assembly-plugin, but this results in the same error trying to unpack the invalid archive. So I would say this is more a m2e bug than a specific problem in the maven-dependency-plugin?! > dependency:copy fails when invoked from m2e with workspace resolution > enabled, or more generally when copying within reactor for phases earlier > than package > > > Key: MDEP-187 > URL: https://jira.codehaus.org/browse/MDEP-187 > Project: Maven Dependency Plugin > Issue Type: Bug > Components: copy, copy-dependencies >Affects Versions: 2.1 >Reporter: Igor Fedorenko > Attachments: MDEP-187b.diff, MDEP-187c.diff, MDEP-187.diff > > > m2e resolves workspace artifacts to their output folders but dependency:copy > expects all artifacts to be files. I will provide trivial patch shortly. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MDEP-187) dependency:copy fails when invoked from m2e with workspace resolution enabled, or more generally when copying within reactor for phases earlier than package
[
https://jira.codehaus.org/browse/MDEP-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353588#comment-353588
]
Hannes Kogler commented on MDEP-187:
@Warren
but I need to download my artifact in a phase before package. the phase I want
to use this is initialize.
and Maven itself does it without any problems, but only when using the m2e
plugin ("Maven update project" in Eclipse instead of "run as Maven install")
the error that the downloaded artifact is invalid occurs
> dependency:copy fails when invoked from m2e with workspace resolution
> enabled, or more generally when copying within reactor for phases earlier
> than package
>
>
> Key: MDEP-187
> URL: https://jira.codehaus.org/browse/MDEP-187
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: copy, copy-dependencies
>Affects Versions: 2.1
>Reporter: Igor Fedorenko
> Attachments: MDEP-187b.diff, MDEP-187c.diff, MDEP-187.diff
>
>
> m2e resolves workspace artifacts to their output folders but dependency:copy
> expects all artifacts to be files. I will provide trivial patch shortly.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRELEASE-331) SCM urls are broken for all modules, except the parent
[ https://jira.codehaus.org/browse/MRELEASE-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=308691#comment-308691 ] Hannes Kogler commented on MRELEASE-331: is the problem fixed already? We have the same problem here! It seems that the maven-release-plugin automatically adding the artifactId to the end of an URL during the release:prepare execution, what leads to an error when trying to execute the release:perform goal in the next step!!! Is there no possibility to deactivate this "function" via any parameter of the release-plugin?? > SCM urls are broken for all modules, except the parent > --- > > Key: MRELEASE-331 > URL: https://jira.codehaus.org/browse/MRELEASE-331 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: scm >Affects Versions: 2.0-beta-7 >Reporter: Vincent Siveton >Priority: Blocker > Labels: scrub-review-started > > This comes from the parent pom, which is missing a / at the end of the scm > urls. > See: > http://www.nabble.com/Re%3A-svn-commit%3A-r635240---in--maven-plugin-tools-trunk%3A-.--maven-plugin-plugin--maven-plugin-tools-ant--maven-plugin-tools-api--maven-plugin-tools-beanshell--maven-plugin-tools-java--maven-plugin-tools-javadoc--maven-plugin-tools-model--tt15929761s177.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-331) SCM urls are broken for all modules, except the parent
[
https://jira.codehaus.org/browse/MRELEASE-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=308691#comment-308691
]
Hannes Kogler edited comment on MRELEASE-331 at 9/17/12 4:46 AM:
-
is the problem fixed already?
We have the same problem here! It seems that the maven-release-plugin
automatically adds the artifactId to the end of an URL during the
release:prepare execution, what leads to an error when trying to execute the
release:perform goal in the next step!!!
Is there no possibility to deactivate this "function" via any parameter of the
release-plugin??
By the way we are using CVS, so if we just leave out the property variable for
the module in the original url-definition
[scm\:cvs\:pserver\:user@server\:/path/to/cvs/project] instead of
[scm\:cvs\:pserver\:user@server\:/path/to/cvs/project\:${project.artifactId}]
we get an error that the scm url is invalid!
So the only chance is to add the variable that is replaced by property
interpolation, what ends up to the described problem...
was (Author: ntshko):
is the problem fixed already?
We have the same problem here! It seems that the maven-release-plugin
automatically adding the artifactId to the end of an URL during the
release:prepare execution, what leads to an error when trying to execute the
release:perform goal in the next step!!!
Is there no possibility to deactivate this "function" via any parameter of the
release-plugin??
> SCM urls are broken for all modules, except the parent
> ---
>
> Key: MRELEASE-331
> URL: https://jira.codehaus.org/browse/MRELEASE-331
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.0-beta-7
>Reporter: Vincent Siveton
>Priority: Blocker
> Labels: scrub-review-started
>
> This comes from the parent pom, which is missing a / at the end of the scm
> urls.
> See:
> http://www.nabble.com/Re%3A-svn-commit%3A-r635240---in--maven-plugin-tools-trunk%3A-.--maven-plugin-plugin--maven-plugin-tools-ant--maven-plugin-tools-api--maven-plugin-tools-beanshell--maven-plugin-tools-java--maven-plugin-tools-javadoc--maven-plugin-tools-model--tt15929761s177.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-4508) No way to avoid adding artifactId to site urls
[
https://jira.codehaus.org/browse/MNG-4508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=308696#comment-308696
]
Hannes Kogler commented on MNG-4508:
It seems that the problem described here is responsible for my current problem
when trying to use the maven-release-plugin ... :-(
I linked the following issue: MRELEASE-331
> No way to avoid adding artifactId to site urls
> --
>
> Key: MNG-4508
> URL: https://jira.codehaus.org/browse/MNG-4508
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Reporter: Richard van der Hoff
>Priority: Minor
> Fix For: 3.1
>
>
> Currently, whenever a child pom inherits from a parent (and doesn't override
> the relevant settings), both project.url and
> project.distributionManagement.site.url have the name of the child artifact
> appended.
> It would be nice to be able to have something like
> :code:
> scpexe://host/blah/${project.artifactId}/${project.version}
> :code:
> and have this inherited to all child poms in the obvious way.
> My usecase for this is that we have a single parent pom for all our projects,
> with useful settings such as distributionManagement, and I'd like to be able
> to deploy their sites to a single directory and have Apache generate me a
> directory listing for all the child projects. However, I curently have no way
> of releasing the parent project without obliterating the list of child
> projects.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5348) possibility for Interpolation just on runtime?!
Hannes Kogler created MNG-5348: -- Summary: possibility for Interpolation just on runtime?! Key: MNG-5348 URL: https://jira.codehaus.org/browse/MNG-5348 Project: Maven 2 & 3 Issue Type: Bug Components: Inheritance and Interpolation Affects Versions: 3.0.4 Reporter: Hannes Kogler Is there a possibility in Maven, especially when using the release-plugin, to interpolate properties just in runtime so that the files stay originally without replaced variables!? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSTAGE-16) Stage plugin doesn't work with maven3
[ https://jira.codehaus.org/browse/MSTAGE-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311295#comment-311295 ] Hannes Kogler commented on MSTAGE-16: - with fixed u mean that it should work now with Maven3 or we just don't mind about it ;-) because I faced the same problem currently with the same error message. > Stage plugin doesn't work with maven3 > - > > Key: MSTAGE-16 > URL: https://jira.codehaus.org/browse/MSTAGE-16 > Project: Maven 2.x Stage Plugin > Issue Type: Bug >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Blocker > Fix For: 1.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSTAGE-16) Stage plugin doesn't work with maven3
[ https://jira.codehaus.org/browse/MSTAGE-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311295#comment-311295 ] Hannes Kogler edited comment on MSTAGE-16 at 10/11/12 4:10 AM: --- with fixed u mean that it should work now with Maven3 or we just don't mind about it?! ;-) because I faced the same problem currently with the same error message. was (Author: ntshko): with fixed u mean that it should work now with Maven3 or we just don't mind about it ;-) because I faced the same problem currently with the same error message. > Stage plugin doesn't work with maven3 > - > > Key: MSTAGE-16 > URL: https://jira.codehaus.org/browse/MSTAGE-16 > Project: Maven 2.x Stage Plugin > Issue Type: Bug >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Blocker > Fix For: 1.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSTAGE-16) Stage plugin doesn't work with maven3
[ https://jira.codehaus.org/browse/MSTAGE-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311301#comment-311301 ] Hannes Kogler commented on MSTAGE-16: - hmm ok! can u tell me the latest snapshot version string please? > Stage plugin doesn't work with maven3 > - > > Key: MSTAGE-16 > URL: https://jira.codehaus.org/browse/MSTAGE-16 > Project: Maven 2.x Stage Plugin > Issue Type: Bug >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Blocker > Fix For: 1.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSTAGE-17) copy all dependencies automatically
Hannes Kogler created MSTAGE-17: --- Summary: copy all dependencies automatically Key: MSTAGE-17 URL: https://jira.codehaus.org/browse/MSTAGE-17 Project: Maven 2.x Stage Plugin Issue Type: Bug Reporter: Hannes Kogler as it seems the dependencies of the artifact are not copied automatically too. but thats what the feature of an artifact copy from one repository to another should be?! or am I doing anything wrong? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-138) release:prepare fails when checking in modified POMs of a multi-modules project
[ https://jira.codehaus.org/browse/MRELEASE-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311781#comment-311781 ] Hannes Kogler commented on MRELEASE-138: hi! we face the same problem with the same error message .. message : Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.0:prepare (default-cli) on project basic_module: An error is occurred in the checkin process: C:\Jenkins\workspace\basic Module\basic\pom.xml was not contained in C:\Jenkins\workspace\basic Module\basic_module cause : An error is occurred in the checkin process: C:\Jenkins\workspace\basic Module\basic\pom.xml was not contained in C:\Jenkins\workspace\basic Module\basic_module Stack trace : org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.0:prepare (default-cli) on project basic_module: An error is occurred in the checkin process: C:\Jenkins\workspace\basic Module\basic\pom.xml *was not contained in* C:\Jenkins\workspace\basic Module\basic_module at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) and so perhaps it makes sense that I answer your questions: ;-) * YES we want to release our multi-module project by running release:perform on the pom.xml from the (parent) root project called "basic_module"!! (which is not the parent project itself, just a project so declare the projects who belong together by module declaration) * YES we have a pom.xml in the basic_module project * we run the release:prepare statement by just one click on the GUI supported "M2 Release Plugin" for Jenkins * Maven release plugin: 2.0 / maven installation on machine with running Jenkins server: 3.0.4 * THATS the point where its getting interesting I think. what in your opinion is a "correct " declaration? in fact we use CVS as SCM and we have to declare the relative module declarations in a bit specialized way: ../basic ../basic_helper Moreover our declarations uses this syntax to come out to the parent folder => ../parentProject ... whereas - as you see - we use different projects for our PARENT project on the one hand (inheritance) and our project that declares multi-project modules (reactor) on the other hand. Is this probably a problem for the release plugin?? > release:prepare fails when checking in modified POMs of a multi-modules > project > --- > > Key: MRELEASE-138 > URL: https://jira.codehaus.org/browse/MRELEASE-138 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: scm >Affects Versions: 2.0-beta-4 > Environment: WinXP + Eclipse >Reporter: ol >Assignee: Robert Scholte >Priority: Critical > > Here is the project structure on the disk : > c:\javadev\prj\myproject\module1 > c:\javadev\prj\myproject\module2 > c:\javadev\prj\myproject\master > These 3 folders represent the 3 eclipse projects, each one containing a > pom.xml. > The master project's pom is the parent of the modules. > When I execute the release:prepare goal, Everything works fine (it asks to me > the tag name, the next dev version, ...) until I receive this error : > [INFO] Checking in modified POMs... > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] An error is occurred in the checkin process: > C:\javadev\prj\myproject\module1\pom.xml was not contained in > C:\javadev\prj\myproject\master > [INFO] > > [DEBUG] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: An error is occurred > in the checkin process: C:\javadev\prj\myproject\module1\pom.xml was not > contained in C:\javadev\prj\myproject\master > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) > > The problem is that the project structure is the only one that can be used > with eclipse. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on
[jira] (MRELEASE-633) release:prepare on CVS flat multi-module project breaks at tagging
[
https://jira.codehaus.org/browse/MRELEASE-633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311795#comment-311795
]
Hannes Kogler commented on MRELEASE-633:
is there any solution or workaround already???!
we ran into the same problem currently and the more I'm trying out with this M2
Release Plugin, the more I can understand what the critics of this plugin are
talking about...
> release:prepare on CVS flat multi-module project breaks at tagging
> --
>
> Key: MRELEASE-633
> URL: https://jira.codehaus.org/browse/MRELEASE-633
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.1, 2.2
> Environment: - Maven 3.0.1
> - Tested with relase-plugin 2.1 and 2.2-SNAPSHOT
>Reporter: Michael Glauche
>
> When running "{{mvn release:prepare -DcommitByProject=true}}" on a simple
> flat multi-module (parent and module are in the same directory) project the
> goal does exit with:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:2.1:prepare (default-cli) on
> project test-main: The scm url is invalid.
> [ERROR] - The connection string contains too few tokens.
> [ERROR] -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-release-plugin:2.1:prepare (default-cli)
> on project test-main: The scm url is invalid.
> - The connection string contains too few tokens.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:199)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140)
> 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:316)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:451)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:188)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:134)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoFailureException: The scm url is
> invalid.
> - The connection string contains too few tokens.
> at
> org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:287)
> at
> org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:237)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195)
> ... 19 more
> Caused by: org.apache.maven.shared.release.scm.ReleaseScmRepositoryException:
> The scm url is invalid.
> - The connection string contains too few tokens.
> at
> org.apache.maven.shared.release.phase.ScmTagPhase.execute(ScmTagPhase.java:87)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:203)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:140)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:103)
> at
> org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:279)
> ... 22 more
> {noformat}
> However, the cvs commits earlier do work fine :
> {noformat}
> [INFO] Checking in modified POMs...
> [INFO] Executing: cmd.exe /X /C "cvs -z3 -f -q commit -R -F
>
[jira] (MRELEASE-261) release:prepare should support flat directory multi-module projects
[ https://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311797#comment-311797 ] Hannes Kogler commented on MRELEASE-261: @Mike R. Haller I'm using CVS so I have the problem that the release plugin doesn't work for flat project structures correctly. But the other problem you describe about the entry of the reactor/Everything project to the poms of the child projects I also can reconstruct with the element in the section.. :-( > release:prepare should support flat directory multi-module projects > --- > > Key: MRELEASE-261 > URL: https://jira.codehaus.org/browse/MRELEASE-261 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: prepare > Environment: linux / maven2 / svn >Reporter: paul.whe...@gmail.com >Assignee: Maria Odea Ching > Fix For: 2.0 > > Attachments: flatProject.main.patch, flatProject.test.patch, > maven-release-issue.tar.gz, maven-release-issue.zip, MRELEASE-261.patch, > MRELEASE-261-sample-project.zip, MRELEASE-261-with-its.patch, > MRELEASE-261-with-its-v3.patch, odd-tags.png, PrepareReleaseMojo.patch > > > What I mean by flat file structure firstly. > parent/pom.xml > module1/pom.xml > module2/pom.xml > . > . > . > module15/pom.xml > the parent references the modules like so > > ../module1 > ../module2 > . > . > . > ../module15 > > When i release:prepare only the parent project is tagged the modules > projects versions are incremented etc but the modules are not tagged in svn. > I use this structure as i use eclipse as my IDE. > I would love to see a fix for the issue marked as closed here > http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand > each submodule of the projects but it would be so nice to have the release > plugin do this for me. > forgive my english. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-516) release:prepare should support a nested/flat hybrid SCM structure
[
https://jira.codehaus.org/browse/MRELEASE-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311800#comment-311800
]
Hannes Kogler commented on MRELEASE-516:
as a workaround during this is fixed, is there any possibility to deactivate
automated tagging when doing a release?!
> release:prepare should support a nested/flat hybrid SCM structure
> -
>
> Key: MRELEASE-516
> URL: https://jira.codehaus.org/browse/MRELEASE-516
> Project: Maven 2.x Release Plugin
> Issue Type: Improvement
> Components: perform, prepare
>Affects Versions: 2.0-beta-9
> Environment: OS X 10.5.8, Windows XP Prof, JDK 1.5.0_12, SVN, GIT, CVS
>Reporter: Eric Miles
> Attachments: maven-release-issue.zip,
> MRELEASE-516-flat-project-structure-support-2.txt,
> MRELEASE-516-flat-project-structure-support.txt, odd-tags.png
>
>
> This issue is related to MRELEASE-261 in that release prepare is having some
> difficulty in dealing with certain SCM structures during the prepare goal.
> Our project structure is flat as you would see in a typical IDE setup:
> {noformat}
> release-workspace\
> |
> |--release-parent
> ||+pom.xml (modules: ../release-module1, ../release-module2)
> |
> |--release-module1
> ||+pom.xml (parent: ../release-parent)
> |
> |--release-module2
> |+pom.xml (parent: ../release-parent)
> {noformat}
> Our SCM (svn) structure is as follows:
> {noformat}
> svnroot
> |
> +--release-parent/trunk/pom.xml
> +--release-parent/tags/release-parent-1.0.9/pom.xml
> |
> +--release-module1/trunk/pom.xml
> +--release-module1/tags/release-module1-1.0.9/pom.xml
> |
> +--release-module1/trunk/pom.xml
> +--release-module2/tags/release-module2-1.0.9/pom.xml
> {noformat}
> If we execute release:prepare with no configuration to the release plugin, we
> get the following error:
> {noformat}
> [INFO] [INFO]
>
> [INFO] Checking in modified POMs...
> [INFO] Executing: /bin/sh -c cd
> /Users/emiles/Projects/release-workspace/release-parent && svn
> --non-interactive commit --file
> /var/folders/fH/fHNZYBGdFd0bMMIPiloA2U+++TI/-Tmp-/maven-scm-1253932520.commit
> --targets
> /var/folders/fH/fHNZYBGdFd0bMMIPiloA2U+++TI/-Tmp-/maven-scm-4376558781490229966-targets
> [INFO] Working directory:
> /Users/emiles/Projects/release-workspace/release-parent
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] Unable to commit files
> Provider message:
> The svn command failed.
> Command output:
> svn: '/Users/emiles/Projects/release-workspace' is not a working copy
> {noformat}
> If we use the 2.0-beta-10-SNAPSHOT with flat project support and provide the
> -DcommitByProject=true JVM parameter, we do not get any errors, however
> tagging does not happen as expected. Rather than having tags for each of the
> projects, some odd tagging happened at the parent level where an entire
> structure was created (with branches, tags and trunk under the tag folder).
> I'm attaching a screen shot for reference.
> Ignoring the fact that the prepare only somewhat worked, when I attempted to
> perform the release, I get an error:
> {noformat}
> emiles-macbook:release-parent emiles$ mvn release:perform
> -DcommitByProject=true
> [INFO] Scanning for projects...
> [INFO] Reactor build order:
> [INFO] Unnamed - com.captechventures:release-parent:pom:0.0.3-SNAPSHOT
> [INFO] Unnamed - com.captechventures:release-module1:jar:0.0.3-SNAPSHOT
> [INFO] Unnamed - com.captechventures:release-module2:jar:0.0.3-SNAPSHOT
> [INFO]
>
> [INFO] Building Unnamed -
> com.captechventures:release-parent:pom:0.0.3-SNAPSHOT
> [INFO]task-segment: [release:perform] (aggregator-style)
> [INFO]
>
> [INFO] [release:perform {execution: default-cli}]
> [INFO] Checking out the project to perform the release ...
> [INFO] Executing: /bin/sh -c cd
> /Users/emiles/Projects/release-workspace/release-parent/target && svn
> --non-interactive checkout
> http://localhost/dev/release-parent/tags/release-parent-0.0.2
> /Users/emiles/Projects/release-workspace/release-parent/target/checkout
> [INFO] Working directory:
> /Users/emiles/Projects/release-workspace/release-parent/target
> [INFO] Executing goals 'deploy'...
> [WARNING] Base directory is a file. Using base directory as POM location.
> [WARNING] Maven will be executed in interactive mode, but no input stream has
> been con
[jira] (MRELEASE-138) release:prepare fails when checking in modified POMs of a multi-modules project
[
https://jira.codehaus.org/browse/MRELEASE-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311831#comment-311831
]
Hannes Kogler commented on MRELEASE-138:
thx for the fast answer!
I tried it again with the newest version of the release plugin. And I also
adapted my execution goals to be sure, that the error doesn't "just" come
across the release:perform process.
so now I really only try the following execution:
*Executing Maven: -B -f C:\Jenkins\workspace\basic Module\basic_module\pom.xml
-DdevelopmentVersion=0.0.2-SNAPSHOT -DreleaseVersion=0.0.1 -Dresume=false
-Dmaven.scm.provider.cvs.implementation=cvs_native release:prepare
-DcommitByProject=true*
now I get following error:
mavenExecutionResult exceptions not empty
message : Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare (default-cli) on
project basic_module: The scm url is invalid.
- Unknown transport: pserver
cause : The scm url is invalid.
- Unknown transport: pserver
Stack trace :
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare (default-cli) on
project basic_module: The scm url is invalid.
- Unknown transport: pserver
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
I've already read an other reporting of this error anywhere on the net.. so
obviously this problem isn't fixed at all, even on the prepare goal :-/
> release:prepare fails when checking in modified POMs of a multi-modules
> project
> ---
>
> Key: MRELEASE-138
> URL: https://jira.codehaus.org/browse/MRELEASE-138
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.0-beta-4
> Environment: WinXP + Eclipse
>Reporter: ol
>Assignee: Robert Scholte
>Priority: Critical
>
> Here is the project structure on the disk :
> {noformat}
> c:\javadev\prj\myproject\module1
> c:\javadev\prj\myproject\module2
> c:\javadev\prj\myproject\master
> {noformat}
> These 3 folders represent the 3 eclipse projects, each one containing a
> pom.xml.
> The master project's pom is the parent of the modules.
> When I execute the release:prepare goal, Everything works fine (it asks to me
> the tag name, the next dev version, ...) until I receive this error :
> {noformat}
> [INFO] Checking in modified POMs...
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] An error is occurred in the checkin process:
> C:\javadev\prj\myproject\module1\pom.xml was not contained in
> C:\javadev\prj\myproject\master
> [INFO]
>
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: An error is occurred
> in the checkin process: C:\javadev\prj\myproject\module1\pom.xml was not
> contained in C:\javadev\prj\myproject\master
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458)
>
> {noformat}
> The problem is that the project structure is the only one that can be used
> with eclipse.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-138) release:prepare fails when checking in modified POMs of a multi-modules project
[
https://jira.codehaus.org/browse/MRELEASE-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311831#comment-311831
]
Hannes Kogler edited comment on MRELEASE-138 at 10/19/12 3:26 AM:
--
thx for the fast answer!
I tried it again with the newest version of the release plugin. And I also
adapted my execution goals to be sure, that the error doesn't "just" come
across the release:perform process.
so now I really only try the following execution:
*Executing Maven: -B -f C:\Jenkins\workspace\basic Module\basic_module\pom.xml
-DdevelopmentVersion=0.0.2-SNAPSHOT -DreleaseVersion=0.0.1 -Dresume=false
-Dmaven.scm.provider.cvs.implementation=cvs_native release:prepare
-DcommitByProject=true*
now I get following error:
mavenExecutionResult exceptions not empty
message : Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare (default-cli) on
project basic_module: The scm url is invalid.
- Unknown transport: pserver
cause : The scm url is invalid.
- Unknown transport: pserver
Stack trace :
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare (default-cli) on
project basic_module: The scm url is invalid.
- Unknown transport: pserver
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
I've already read an other reporting of this error anywhere on the net.. so
obviously this problem isn't fixed at all, even on the prepare goal :-/
It's kind of funny, because he writes that the SCM URL is invalid BUT on the
other hand the checkin of the changed versioninfo in the pom from
0.0.1-SNAPSHOT to 0.0.1 is commited indeed.
was (Author: ntshko):
thx for the fast answer!
I tried it again with the newest version of the release plugin. And I also
adapted my execution goals to be sure, that the error doesn't "just" come
across the release:perform process.
so now I really only try the following execution:
*Executing Maven: -B -f C:\Jenkins\workspace\basic Module\basic_module\pom.xml
-DdevelopmentVersion=0.0.2-SNAPSHOT -DreleaseVersion=0.0.1 -Dresume=false
-Dmaven.scm.provider.cvs.implementation=cvs_native release:prepare
-DcommitByProject=true*
now I get following error:
mavenExecutionResult exceptions not empty
message : Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare (default-cli) on
project basic_module: The scm url is invalid.
- Unknown transport: pserver
cause : The scm url is invalid.
- Unknown transport: pserver
Stack trace :
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare (default-cli) on
project basic_module: The scm url is invalid.
- Unknown transport: pserver
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
I've already read an other reporting of this error anywhere on the net.. so
obviously this problem isn't fixed at all, even on the prepare goal :-/
> release:prepare fails when checking in modified POMs of a multi-modules
> project
> ---
>
> Key: MRELEASE-138
> URL: https://jira.codehaus.org/browse/MRELEASE-138
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.0-beta-4
> Environment: WinXP + Eclipse
>Reporter: ol
>Assignee: Robert Scholte
>Priority: Critical
>
> Here is the project structure on the disk :
> {noformat}
> c:\javadev\prj\myproject\module1
> c:\javadev\prj\myproject\module2
> c:\javadev\prj\myproject\master
> {noformat}
> These 3 folders represent the 3 eclipse projects, each one containing a
> pom.xml.
> The master project's pom is the parent of the modules.
> When I execute the release:prepare goal, Everything works fine (it asks to me
> the tag name, the next dev version, ...) until I receive this error :
> {noformat}
> [INFO] Checking in modified POMs...
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] An error is occurred in the checkin process:
> C:\javadev\prj\myproject\module1\pom.xml was not contained in
> C:\javadev\prj\myprojec
[jira] (MRELEASE-138) release:prepare fails when checking in modified POMs of a multi-modules project
[
https://jira.codehaus.org/browse/MRELEASE-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311831#comment-311831
]
Hannes Kogler edited comment on MRELEASE-138 at 10/19/12 3:37 AM:
--
thx for the fast answer!
I tried it again with the newest version of the release plugin. And I also
adapted my execution goals to be sure, that the error doesn't "just" come
across the release:perform process.
so now I really only try the following execution:
*Executing Maven: -B -f C:\Jenkins\workspace\basic Module\basic_module\pom.xml
-DdevelopmentVersion=0.0.2-SNAPSHOT -DreleaseVersion=0.0.1 -Dresume=false
-Dmaven.scm.provider.cvs.implementation=cvs_native release:prepare
-DcommitByProject=true*
now I get following error:
mavenExecutionResult exceptions not empty
message : Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare (default-cli) on
project basic_module: The scm url is invalid.
- Unknown transport: pserver
cause : The scm url is invalid.
- Unknown transport: pserver
Stack trace :
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare (default-cli) on
project basic_module: The scm url is invalid.
- Unknown transport: pserver
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
I've already read an other reporting of this error anywhere on the net.. so
obviously this problem isn't fixed at all, even on the prepare goal :-/
It's kind of funny, because he writes that the SCM URL is invalid BUT on the
other hand the checkin of the changed versioninfo in the pom from
0.0.1-SNAPSHOT to 0.0.1 is commited indeed.
_UPDATE:_
Now I tried it again without the commitByProject setted. Then I run again in
the error: C:\Jenkins\workspace\basic Module\basic\pom.xml was not contained in
C:\Jenkins\workspace\basic Module\basic_module
*So to prevent the "was not contained in" error the "commitByProject" parameter
works fine*, but everything concerning the SCM checkin (especially the tagging,
also on the prepare goal) is still failing at all!!
was (Author: ntshko):
thx for the fast answer!
I tried it again with the newest version of the release plugin. And I also
adapted my execution goals to be sure, that the error doesn't "just" come
across the release:perform process.
so now I really only try the following execution:
*Executing Maven: -B -f C:\Jenkins\workspace\basic Module\basic_module\pom.xml
-DdevelopmentVersion=0.0.2-SNAPSHOT -DreleaseVersion=0.0.1 -Dresume=false
-Dmaven.scm.provider.cvs.implementation=cvs_native release:prepare
-DcommitByProject=true*
now I get following error:
mavenExecutionResult exceptions not empty
message : Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare (default-cli) on
project basic_module: The scm url is invalid.
- Unknown transport: pserver
cause : The scm url is invalid.
- Unknown transport: pserver
Stack trace :
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare (default-cli) on
project basic_module: The scm url is invalid.
- Unknown transport: pserver
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
I've already read an other reporting of this error anywhere on the net.. so
obviously this problem isn't fixed at all, even on the prepare goal :-/
It's kind of funny, because he writes that the SCM URL is invalid BUT on the
other hand the checkin of the changed versioninfo in the pom from
0.0.1-SNAPSHOT to 0.0.1 is commited indeed.
> release:prepare fails when checking in modified POMs of a multi-modules
> project
> ---
>
> Key: MRELEASE-138
> URL: https://jira.codehaus.org/browse/MRELEASE-138
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.0-beta-4
> Environment: WinXP + Eclipse
>Reporter: ol
>Assignee: Robert Scholte
>Priority: Critical
>
> Here is the project structure on the disk :
> {noformat}
> c:\javadev\prj\myproject\module1
> c:\javadev\prj\myproject\module2
> c:\javadev\prj\myproject\master
> {noformat}
> These 3 folders represent the 3 eclipse projects, each one con
[jira] (MRELEASE-516) release:prepare should support a nested/flat hybrid SCM structure
[
https://jira.codehaus.org/browse/MRELEASE-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311838#comment-311838
]
Hannes Kogler commented on MRELEASE-516:
thx for the support. I know this goal but that's unfortunately just one step of
many this release plugin does or "should do".
obviously there's really until now no other way except releasing every single
project for your own. really exhausting...
> release:prepare should support a nested/flat hybrid SCM structure
> -
>
> Key: MRELEASE-516
> URL: https://jira.codehaus.org/browse/MRELEASE-516
> Project: Maven 2.x Release Plugin
> Issue Type: Improvement
> Components: perform, prepare
>Affects Versions: 2.0-beta-9
> Environment: OS X 10.5.8, Windows XP Prof, JDK 1.5.0_12, SVN, GIT, CVS
>Reporter: Eric Miles
> Attachments: maven-release-issue.zip,
> MRELEASE-516-flat-project-structure-support-2.txt,
> MRELEASE-516-flat-project-structure-support.txt, odd-tags.png
>
>
> This issue is related to MRELEASE-261 in that release prepare is having some
> difficulty in dealing with certain SCM structures during the prepare goal.
> Our project structure is flat as you would see in a typical IDE setup:
> {noformat}
> release-workspace\
> |
> |--release-parent
> ||+pom.xml (modules: ../release-module1, ../release-module2)
> |
> |--release-module1
> ||+pom.xml (parent: ../release-parent)
> |
> |--release-module2
> |+pom.xml (parent: ../release-parent)
> {noformat}
> Our SCM (svn) structure is as follows:
> {noformat}
> svnroot
> |
> +--release-parent/trunk/pom.xml
> +--release-parent/tags/release-parent-1.0.9/pom.xml
> |
> +--release-module1/trunk/pom.xml
> +--release-module1/tags/release-module1-1.0.9/pom.xml
> |
> +--release-module1/trunk/pom.xml
> +--release-module2/tags/release-module2-1.0.9/pom.xml
> {noformat}
> If we execute release:prepare with no configuration to the release plugin, we
> get the following error:
> {noformat}
> [INFO] [INFO]
>
> [INFO] Checking in modified POMs...
> [INFO] Executing: /bin/sh -c cd
> /Users/emiles/Projects/release-workspace/release-parent && svn
> --non-interactive commit --file
> /var/folders/fH/fHNZYBGdFd0bMMIPiloA2U+++TI/-Tmp-/maven-scm-1253932520.commit
> --targets
> /var/folders/fH/fHNZYBGdFd0bMMIPiloA2U+++TI/-Tmp-/maven-scm-4376558781490229966-targets
> [INFO] Working directory:
> /Users/emiles/Projects/release-workspace/release-parent
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] Unable to commit files
> Provider message:
> The svn command failed.
> Command output:
> svn: '/Users/emiles/Projects/release-workspace' is not a working copy
> {noformat}
> If we use the 2.0-beta-10-SNAPSHOT with flat project support and provide the
> -DcommitByProject=true JVM parameter, we do not get any errors, however
> tagging does not happen as expected. Rather than having tags for each of the
> projects, some odd tagging happened at the parent level where an entire
> structure was created (with branches, tags and trunk under the tag folder).
> I'm attaching a screen shot for reference.
> Ignoring the fact that the prepare only somewhat worked, when I attempted to
> perform the release, I get an error:
> {noformat}
> emiles-macbook:release-parent emiles$ mvn release:perform
> -DcommitByProject=true
> [INFO] Scanning for projects...
> [INFO] Reactor build order:
> [INFO] Unnamed - com.captechventures:release-parent:pom:0.0.3-SNAPSHOT
> [INFO] Unnamed - com.captechventures:release-module1:jar:0.0.3-SNAPSHOT
> [INFO] Unnamed - com.captechventures:release-module2:jar:0.0.3-SNAPSHOT
> [INFO]
>
> [INFO] Building Unnamed -
> com.captechventures:release-parent:pom:0.0.3-SNAPSHOT
> [INFO]task-segment: [release:perform] (aggregator-style)
> [INFO]
>
> [INFO] [release:perform {execution: default-cli}]
> [INFO] Checking out the project to perform the release ...
> [INFO] Executing: /bin/sh -c cd
> /Users/emiles/Projects/release-workspace/release-parent/target && svn
> --non-interactive checkout
> http://localhost/dev/release-parent/tags/release-parent-0.0.2
> /Users/emiles/Projects/release-workspace/release-parent/target/checkout
> [INFO] Working directory:
> /Users/emiles/Projects/release-workspace/release-parent/target
> [INFO] Executing goals 'deploy'...
> [WARNING] Base directory is a file
[jira] (MRELEASE-516) release:prepare should support a nested/flat hybrid SCM structure
[
https://jira.codehaus.org/browse/MRELEASE-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311838#comment-311838
]
Hannes Kogler edited comment on MRELEASE-516 at 10/19/12 7:07 AM:
--
thx for the support. I know this goal but that's unfortunately just one step of
many this release plugin does or "should do".
obviously there's really until now no other way except releasing every single
project for your own. really exhausting...
_UPDATE - new tryout:_
even if you define in your Jenkins *job configuration "../testproject/pom.xml"
instead of just "pom.xml"* for execution or your release:prepare goal the SCM
error occurs. But that also happens if the "testproject" IS definitely the
first added module so it acts like the root one. => that means he just *should
have used the exactly SAME pom* to execute like he does without problems for
the "pom.xml" and just fails to resolve the relative path!
I cannot imagine that this is such a great deal to fix?!
was (Author: ntshko):
thx for the support. I know this goal but that's unfortunately just one
step of many this release plugin does or "should do".
obviously there's really until now no other way except releasing every single
project for your own. really exhausting...
> release:prepare should support a nested/flat hybrid SCM structure
> -
>
> Key: MRELEASE-516
> URL: https://jira.codehaus.org/browse/MRELEASE-516
> Project: Maven 2.x Release Plugin
> Issue Type: Improvement
> Components: perform, prepare
>Affects Versions: 2.0-beta-9
> Environment: OS X 10.5.8, Windows XP Prof, JDK 1.5.0_12, SVN, GIT, CVS
>Reporter: Eric Miles
> Attachments: maven-release-issue.zip,
> MRELEASE-516-flat-project-structure-support-2.txt,
> MRELEASE-516-flat-project-structure-support.txt, odd-tags.png
>
>
> This issue is related to MRELEASE-261 in that release prepare is having some
> difficulty in dealing with certain SCM structures during the prepare goal.
> Our project structure is flat as you would see in a typical IDE setup:
> {noformat}
> release-workspace\
> |
> |--release-parent
> ||+pom.xml (modules: ../release-module1, ../release-module2)
> |
> |--release-module1
> ||+pom.xml (parent: ../release-parent)
> |
> |--release-module2
> |+pom.xml (parent: ../release-parent)
> {noformat}
> Our SCM (svn) structure is as follows:
> {noformat}
> svnroot
> |
> +--release-parent/trunk/pom.xml
> +--release-parent/tags/release-parent-1.0.9/pom.xml
> |
> +--release-module1/trunk/pom.xml
> +--release-module1/tags/release-module1-1.0.9/pom.xml
> |
> +--release-module1/trunk/pom.xml
> +--release-module2/tags/release-module2-1.0.9/pom.xml
> {noformat}
> If we execute release:prepare with no configuration to the release plugin, we
> get the following error:
> {noformat}
> [INFO] [INFO]
>
> [INFO] Checking in modified POMs...
> [INFO] Executing: /bin/sh -c cd
> /Users/emiles/Projects/release-workspace/release-parent && svn
> --non-interactive commit --file
> /var/folders/fH/fHNZYBGdFd0bMMIPiloA2U+++TI/-Tmp-/maven-scm-1253932520.commit
> --targets
> /var/folders/fH/fHNZYBGdFd0bMMIPiloA2U+++TI/-Tmp-/maven-scm-4376558781490229966-targets
> [INFO] Working directory:
> /Users/emiles/Projects/release-workspace/release-parent
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] Unable to commit files
> Provider message:
> The svn command failed.
> Command output:
> svn: '/Users/emiles/Projects/release-workspace' is not a working copy
> {noformat}
> If we use the 2.0-beta-10-SNAPSHOT with flat project support and provide the
> -DcommitByProject=true JVM parameter, we do not get any errors, however
> tagging does not happen as expected. Rather than having tags for each of the
> projects, some odd tagging happened at the parent level where an entire
> structure was created (with branches, tags and trunk under the tag folder).
> I'm attaching a screen shot for reference.
> Ignoring the fact that the prepare only somewhat worked, when I attempted to
> perform the release, I get an error:
> {noformat}
> emiles-macbook:release-parent emiles$ mvn release:perform
> -DcommitByProject=true
> [INFO] Scanning for projects...
> [INFO] Reactor build order:
> [INFO] Unnamed - com.captechventures:release-parent:pom:0.0.3-SNAPSHOT
> [INFO] Unnamed - com.captechventures:release-module1:jar:0.0.3-SNAPSHOT
> [INFO] Unnamed - com.captechventures:release-module2:jar:0.
[jira] (MRELEASE-261) release:prepare should support flat directory multi-module projects
[ https://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311797#comment-311797 ] Hannes Kogler edited comment on MRELEASE-261 at 10/19/12 7:58 AM: -- @Mike R. Haller I'm using CVS so I have the problem that the release plugin doesn't work for flat project structures correctly. But the other problem you describe about the entry of the reactor/Everything project to the poms of the child projects I also can reconstruct with the element in the section.. :-( this is NOT FIXED at all! was (Author: ntshko): @Mike R. Haller I'm using CVS so I have the problem that the release plugin doesn't work for flat project structures correctly. But the other problem you describe about the entry of the reactor/Everything project to the poms of the child projects I also can reconstruct with the element in the section.. :-( > release:prepare should support flat directory multi-module projects > --- > > Key: MRELEASE-261 > URL: https://jira.codehaus.org/browse/MRELEASE-261 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: prepare > Environment: linux / maven2 / svn >Reporter: paul.whe...@gmail.com >Assignee: Maria Odea Ching > Fix For: 2.0 > > Attachments: flatProject.main.patch, flatProject.test.patch, > maven-release-issue.tar.gz, maven-release-issue.zip, MRELEASE-261.patch, > MRELEASE-261-sample-project.zip, MRELEASE-261-with-its.patch, > MRELEASE-261-with-its-v3.patch, odd-tags.png, PrepareReleaseMojo.patch > > > What I mean by flat file structure firstly. > parent/pom.xml > module1/pom.xml > module2/pom.xml > . > . > . > module15/pom.xml > the parent references the modules like so > > ../module1 > ../module2 > . > . > . > ../module15 > > When i release:prepare only the parent project is tagged the modules > projects versions are incremented etc but the modules are not tagged in svn. > I use this structure as i use eclipse as my IDE. > I would love to see a fix for the issue marked as closed here > http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand > each submodule of the projects but it would be so nice to have the release > plugin do this for me. > forgive my english. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-138) release:prepare fails when checking in modified POMs of a multi-modules project
[
https://jira.codehaus.org/browse/MRELEASE-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311854#comment-311854
]
Hannes Kogler commented on MRELEASE-138:
I successfully validated my SCM URL this moment.
I think it just fails because of the "flat structure" topic...
Or have u worked with such flat structures too already?
> release:prepare fails when checking in modified POMs of a multi-modules
> project
> ---
>
> Key: MRELEASE-138
> URL: https://jira.codehaus.org/browse/MRELEASE-138
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.0-beta-4
> Environment: WinXP + Eclipse
>Reporter: ol
>Assignee: Robert Scholte
>Priority: Critical
>
> Here is the project structure on the disk :
> {noformat}
> c:\javadev\prj\myproject\module1
> c:\javadev\prj\myproject\module2
> c:\javadev\prj\myproject\master
> {noformat}
> These 3 folders represent the 3 eclipse projects, each one containing a
> pom.xml.
> The master project's pom is the parent of the modules.
> When I execute the release:prepare goal, Everything works fine (it asks to me
> the tag name, the next dev version, ...) until I receive this error :
> {noformat}
> [INFO] Checking in modified POMs...
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] An error is occurred in the checkin process:
> C:\javadev\prj\myproject\module1\pom.xml was not contained in
> C:\javadev\prj\myproject\master
> [INFO]
>
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: An error is occurred
> in the checkin process: C:\javadev\prj\myproject\module1\pom.xml was not
> contained in C:\javadev\prj\myproject\master
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458)
>
> {noformat}
> The problem is that the project structure is the only one that can be used
> with eclipse.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-138) release:prepare fails when checking in modified POMs of a multi-modules project
[
https://jira.codehaus.org/browse/MRELEASE-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311854#comment-311854
]
Hannes Kogler edited comment on MRELEASE-138 at 10/19/12 9:31 AM:
--
I successfully validated my SCM URL this moment.
I think it just fails because of the "flat structure" topic...
Or have u worked with such flat structures successfully too already?
was (Author: ntshko):
I successfully validated my SCM URL this moment.
I think it just fails because of the "flat structure" topic...
Or have u worked with such flat structures too already?
> release:prepare fails when checking in modified POMs of a multi-modules
> project
> ---
>
> Key: MRELEASE-138
> URL: https://jira.codehaus.org/browse/MRELEASE-138
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.0-beta-4
> Environment: WinXP + Eclipse
>Reporter: ol
>Assignee: Robert Scholte
>Priority: Critical
>
> Here is the project structure on the disk :
> {noformat}
> c:\javadev\prj\myproject\module1
> c:\javadev\prj\myproject\module2
> c:\javadev\prj\myproject\master
> {noformat}
> These 3 folders represent the 3 eclipse projects, each one containing a
> pom.xml.
> The master project's pom is the parent of the modules.
> When I execute the release:prepare goal, Everything works fine (it asks to me
> the tag name, the next dev version, ...) until I receive this error :
> {noformat}
> [INFO] Checking in modified POMs...
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] An error is occurred in the checkin process:
> C:\javadev\prj\myproject\module1\pom.xml was not contained in
> C:\javadev\prj\myproject\master
> [INFO]
>
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: An error is occurred
> in the checkin process: C:\javadev\prj\myproject\module1\pom.xml was not
> contained in C:\javadev\prj\myproject\master
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458)
>
> {noformat}
> The problem is that the project structure is the only one that can be used
> with eclipse.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-138) release:prepare fails when checking in modified POMs of a multi-modules project
[
https://jira.codehaus.org/browse/MRELEASE-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313314#comment-313314
]
Hannes Kogler commented on MRELEASE-138:
thanx for attaching my patch, but how will the release-process will take place
now?
moreover there are several other issues who rely on the same problem:
http://jira.codehaus.org/browse/MRELEASE-633
http://jira.codehaus.org/browse/MRELEASE-516
http://jira.codehaus.org/browse/MRELEASE-261
.. now flat directory structure should also be supported in combination of CVS!
just using the commitByProject flag!
PLEASE just make a NEW RELEASE of THE PLUGIN with those changes to honor the
time (and money) spent into this issues!
Who has RELEASE rights for the Maven Release Plugin???
> release:prepare fails when checking in modified POMs of a multi-modules
> project
> ---
>
> Key: MRELEASE-138
> URL: https://jira.codehaus.org/browse/MRELEASE-138
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.0-beta-4
> Environment: WinXP + Eclipse
>Reporter: ol
>Assignee: Robert Scholte
>Priority: Critical
> Attachments: MRELEASE-138.patch
>
>
> Here is the project structure on the disk :
> {noformat}
> c:\javadev\prj\myproject\module1
> c:\javadev\prj\myproject\module2
> c:\javadev\prj\myproject\master
> {noformat}
> These 3 folders represent the 3 eclipse projects, each one containing a
> pom.xml.
> The master project's pom is the parent of the modules.
> When I execute the release:prepare goal, Everything works fine (it asks to me
> the tag name, the next dev version, ...) until I receive this error :
> {noformat}
> [INFO] Checking in modified POMs...
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] An error is occurred in the checkin process:
> C:\javadev\prj\myproject\module1\pom.xml was not contained in
> C:\javadev\prj\myproject\master
> [INFO]
>
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: An error is occurred
> in the checkin process: C:\javadev\prj\myproject\module1\pom.xml was not
> contained in C:\javadev\prj\myproject\master
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458)
>
> {noformat}
> The problem is that the project structure is the only one that can be used
> with eclipse.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-138) release:prepare fails when checking in modified POMs of a multi-modules project
[
https://jira.codehaus.org/browse/MRELEASE-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313314#comment-313314
]
Hannes Kogler edited comment on MRELEASE-138 at 11/10/12 4:47 AM:
--
thanx for attaching my patch, but how will the release-process will take place
now?
moreover there are several other issues who rely on the same problem:
http://jira.codehaus.org/browse/MRELEASE-633
http://jira.codehaus.org/browse/MRELEASE-516
http://jira.codehaus.org/browse/MRELEASE-261
.. now flat directory structure should also be supported in combination of CVS!
just using the commitByProject flag!
PLEASE just make a NEW RELEASE of THE PLUGIN with those changes to honor the
time (and money) spent into these issues!
Who has RELEASE rights for the Maven Release Plugin???
was (Author: ntshko):
thanx for attaching my patch, but how will the release-process will take
place now?
moreover there are several other issues who rely on the same problem:
http://jira.codehaus.org/browse/MRELEASE-633
http://jira.codehaus.org/browse/MRELEASE-516
http://jira.codehaus.org/browse/MRELEASE-261
.. now flat directory structure should also be supported in combination of CVS!
just using the commitByProject flag!
PLEASE just make a NEW RELEASE of THE PLUGIN with those changes to honor the
time (and money) spent into this issues!
Who has RELEASE rights for the Maven Release Plugin???
> release:prepare fails when checking in modified POMs of a multi-modules
> project
> ---
>
> Key: MRELEASE-138
> URL: https://jira.codehaus.org/browse/MRELEASE-138
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.0-beta-4
> Environment: WinXP + Eclipse
>Reporter: ol
>Assignee: Robert Scholte
>Priority: Critical
> Attachments: MRELEASE-138.patch
>
>
> Here is the project structure on the disk :
> {noformat}
> c:\javadev\prj\myproject\module1
> c:\javadev\prj\myproject\module2
> c:\javadev\prj\myproject\master
> {noformat}
> These 3 folders represent the 3 eclipse projects, each one containing a
> pom.xml.
> The master project's pom is the parent of the modules.
> When I execute the release:prepare goal, Everything works fine (it asks to me
> the tag name, the next dev version, ...) until I receive this error :
> {noformat}
> [INFO] Checking in modified POMs...
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] An error is occurred in the checkin process:
> C:\javadev\prj\myproject\module1\pom.xml was not contained in
> C:\javadev\prj\myproject\master
> [INFO]
>
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: An error is occurred
> in the checkin process: C:\javadev\prj\myproject\module1\pom.xml was not
> contained in C:\javadev\prj\myproject\master
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458)
>
> {noformat}
> The problem is that the project structure is the only one that can be used
> with eclipse.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-138) release:prepare fails when checking in modified POMs of a multi-modules project
[
https://jira.codehaus.org/browse/MRELEASE-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313314#comment-313314
]
Hannes Kogler edited comment on MRELEASE-138 at 11/10/12 4:48 AM:
--
thanx for attaching my patch, but how will the release-process will take place
now?
moreover there are several other issues who rely on the same problem:
http://jira.codehaus.org/browse/MRELEASE-633
http://jira.codehaus.org/browse/MRELEASE-516
http://jira.codehaus.org/browse/MRELEASE-261
.. now flat directory structure should also be supported in combination with
CVS! just using the commitByProject flag!
PLEASE just make a NEW RELEASE of THE PLUGIN with those changes to honor the
time (and money) spent into these issues!
Who has RELEASE rights for the Maven Release Plugin???
was (Author: ntshko):
thanx for attaching my patch, but how will the release-process will take
place now?
moreover there are several other issues who rely on the same problem:
http://jira.codehaus.org/browse/MRELEASE-633
http://jira.codehaus.org/browse/MRELEASE-516
http://jira.codehaus.org/browse/MRELEASE-261
.. now flat directory structure should also be supported in combination of CVS!
just using the commitByProject flag!
PLEASE just make a NEW RELEASE of THE PLUGIN with those changes to honor the
time (and money) spent into these issues!
Who has RELEASE rights for the Maven Release Plugin???
> release:prepare fails when checking in modified POMs of a multi-modules
> project
> ---
>
> Key: MRELEASE-138
> URL: https://jira.codehaus.org/browse/MRELEASE-138
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.0-beta-4
> Environment: WinXP + Eclipse
>Reporter: ol
>Assignee: Robert Scholte
>Priority: Critical
> Attachments: MRELEASE-138.patch
>
>
> Here is the project structure on the disk :
> {noformat}
> c:\javadev\prj\myproject\module1
> c:\javadev\prj\myproject\module2
> c:\javadev\prj\myproject\master
> {noformat}
> These 3 folders represent the 3 eclipse projects, each one containing a
> pom.xml.
> The master project's pom is the parent of the modules.
> When I execute the release:prepare goal, Everything works fine (it asks to me
> the tag name, the next dev version, ...) until I receive this error :
> {noformat}
> [INFO] Checking in modified POMs...
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] An error is occurred in the checkin process:
> C:\javadev\prj\myproject\module1\pom.xml was not contained in
> C:\javadev\prj\myproject\master
> [INFO]
>
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: An error is occurred
> in the checkin process: C:\javadev\prj\myproject\module1\pom.xml was not
> contained in C:\javadev\prj\myproject\master
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458)
>
> {noformat}
> The problem is that the project structure is the only one that can be used
> with eclipse.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-138) release:prepare fails when checking in modified POMs of a multi-modules project
[
https://jira.codehaus.org/browse/MRELEASE-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313314#comment-313314
]
Hannes Kogler edited comment on MRELEASE-138 at 11/10/12 5:33 AM:
--
thanx for attaching my patch, but how will the release-process will take place
now?
moreover there are several other issues who rely on the same problem:
http://jira.codehaus.org/browse/MRELEASE-633
http://jira.codehaus.org/browse/MRELEASE-516
http://jira.codehaus.org/browse/MRELEASE-261
.. now flat directory structure should also be supported for Tagging/Branching
aso. (in combination with CVS too!)! just using the commitByProject flag!
PLEASE just make a NEW RELEASE of THE PLUGIN with those changes to honor the
time (and money) spent into these issues!
Who has RELEASE rights for the Maven Release Plugin???
was (Author: ntshko):
thanx for attaching my patch, but how will the release-process will take
place now?
moreover there are several other issues who rely on the same problem:
http://jira.codehaus.org/browse/MRELEASE-633
http://jira.codehaus.org/browse/MRELEASE-516
http://jira.codehaus.org/browse/MRELEASE-261
.. now flat directory structure should also be supported in combination with
CVS! just using the commitByProject flag!
PLEASE just make a NEW RELEASE of THE PLUGIN with those changes to honor the
time (and money) spent into these issues!
Who has RELEASE rights for the Maven Release Plugin???
> release:prepare fails when checking in modified POMs of a multi-modules
> project
> ---
>
> Key: MRELEASE-138
> URL: https://jira.codehaus.org/browse/MRELEASE-138
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.0-beta-4
> Environment: WinXP + Eclipse
>Reporter: ol
>Assignee: Robert Scholte
>Priority: Critical
> Attachments: MRELEASE-138.patch
>
>
> Here is the project structure on the disk :
> {noformat}
> c:\javadev\prj\myproject\module1
> c:\javadev\prj\myproject\module2
> c:\javadev\prj\myproject\master
> {noformat}
> These 3 folders represent the 3 eclipse projects, each one containing a
> pom.xml.
> The master project's pom is the parent of the modules.
> When I execute the release:prepare goal, Everything works fine (it asks to me
> the tag name, the next dev version, ...) until I receive this error :
> {noformat}
> [INFO] Checking in modified POMs...
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] An error is occurred in the checkin process:
> C:\javadev\prj\myproject\module1\pom.xml was not contained in
> C:\javadev\prj\myproject\master
> [INFO]
>
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: An error is occurred
> in the checkin process: C:\javadev\prj\myproject\module1\pom.xml was not
> contained in C:\javadev\prj\myproject\master
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458)
>
> {noformat}
> The problem is that the project structure is the only one that can be used
> with eclipse.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-138) release:prepare fails when checking in modified POMs of a multi-modules project
[
https://jira.codehaus.org/browse/MRELEASE-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313314#comment-313314
]
Hannes Kogler edited comment on MRELEASE-138 at 11/10/12 5:34 AM:
--
thanx for attaching my patch, but how will the release-process will take place
now?
moreover there are several other issues who rely on the same problem:
http://jira.codehaus.org/browse/MRELEASE-633
http://jira.codehaus.org/browse/MRELEASE-516
http://jira.codehaus.org/browse/MRELEASE-261
*.. now flat directory structure should also be supported for Tagging/Branching
aso. (in combination with CVS too!)! just using the commitByProject flag!*
*PLEASE just make a NEW RELEASE (2.4) of THE PLUGIN with those changes to honor
the time (and money) spent into these issues!*
Who has RELEASE rights for the Maven Release Plugin???
was (Author: ntshko):
thanx for attaching my patch, but how will the release-process will take
place now?
moreover there are several other issues who rely on the same problem:
http://jira.codehaus.org/browse/MRELEASE-633
http://jira.codehaus.org/browse/MRELEASE-516
http://jira.codehaus.org/browse/MRELEASE-261
.. now flat directory structure should also be supported for Tagging/Branching
aso. (in combination with CVS too!)! just using the commitByProject flag!
PLEASE just make a NEW RELEASE of THE PLUGIN with those changes to honor the
time (and money) spent into these issues!
Who has RELEASE rights for the Maven Release Plugin???
> release:prepare fails when checking in modified POMs of a multi-modules
> project
> ---
>
> Key: MRELEASE-138
> URL: https://jira.codehaus.org/browse/MRELEASE-138
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.0-beta-4
> Environment: WinXP + Eclipse
>Reporter: ol
>Assignee: Robert Scholte
>Priority: Critical
> Attachments: MRELEASE-138.patch
>
>
> Here is the project structure on the disk :
> {noformat}
> c:\javadev\prj\myproject\module1
> c:\javadev\prj\myproject\module2
> c:\javadev\prj\myproject\master
> {noformat}
> These 3 folders represent the 3 eclipse projects, each one containing a
> pom.xml.
> The master project's pom is the parent of the modules.
> When I execute the release:prepare goal, Everything works fine (it asks to me
> the tag name, the next dev version, ...) until I receive this error :
> {noformat}
> [INFO] Checking in modified POMs...
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] An error is occurred in the checkin process:
> C:\javadev\prj\myproject\module1\pom.xml was not contained in
> C:\javadev\prj\myproject\master
> [INFO]
>
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: An error is occurred
> in the checkin process: C:\javadev\prj\myproject\module1\pom.xml was not
> contained in C:\javadev\prj\myproject\master
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458)
>
> {noformat}
> The problem is that the project structure is the only one that can be used
> with eclipse.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-342) scm:tag should support flat project layout
[ https://jira.codehaus.org/browse/SCM-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315065#comment-315065 ] Hannes Kogler commented on SCM-342: --- same problem here. we prefer the flat project structure and I don't want to configure hundreds of jenkins config steps for just doing a checkin of hundreds projects from different base-folders... > scm:tag should support flat project layout > -- > > Key: SCM-342 > URL: https://jira.codehaus.org/browse/SCM-342 > Project: Maven SCM > Issue Type: Bug > Components: maven-plugin >Affects Versions: 1.0 > Environment: Windows XP, Eclipse 3.3 >Reporter: Duncan Doyle > Attachments: flatProjectTagPatch.txt > > > I have a Maven2 Flat Project Layout as described here: > http://maven.apache.org/guides/mini/guide-ide-eclipse.html > Basically my directory layout is as follows: > /MavenRoot/pom.xml (this is the SuperPom) > /Module1/pom.xml > /Module2/pom.xml > /Module3/pom.xml > Modules 1,2 and 3 are specified in the section of the SuperPom > (e.g() ../Module1). Each POM contains its own CVS connection > URL. > When I execute the scm:tag goal on the SuperPom in the MavenRoot project, > only the MavenRoot project gets tagged. The same behaviour can be seen with > the scm:update goal, which was fixed by providing a scm:update-subprojects > goal. > I would like to see this behaviour fixed in the SCM plugin, while Maven2 > advices a Flat Project Layout when working with Eclipse. At this moment I > can't use the tag goal at all (it should be executed automatically by > CruiseControl on a succesfull build). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-256) Regression: pom properties are no longer expanded in descriptor.
[
https://jira.codehaus.org/browse/MASSEMBLY-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=316082#comment-316082
]
Hannes Kogler commented on MASSEMBLY-256:
-
anybody here, to give a good reason why the interpolation is deactivated in the
descriptor's sections by this code?
blacklist.add( "outputFileNameMapping" );
blacklist.add( "outputDirectoryMapping" );
blacklist.add( "outputDirectory" );
I think ESPECIALLY at those 3 tags the interpolation would make the most
sense..
> Regression: pom properties are no longer expanded in descriptor.
>
>
> Key: MASSEMBLY-256
> URL: https://jira.codehaus.org/browse/MASSEMBLY-256
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-1, 2.2-beta-2
> Environment: maven 2.0.8
> windows xp sp2
>Reporter: Mark Reynolds
>Assignee: John Casey
> Fix For: 2.2-beta-3
>
> Attachments: assembly-issue.zip
>
>
> Attached is a minimal project which demonstrates this issue.
> The pom contains a property:
>
> ...
>
> file/path
>
>
> The descriptor uses this property in specifying the output directory for a
> fileSet:
>
> ...
>
>
> src/main/files
> ${fileLocation}
>
>
>
> In versions 2.1, 2.2-beta-1, and 2.2-SNAPSHOT of the assembly plugin, this
> property is expanded so the resulting archive has files in file/path/
> In the latest 2.2-beta-2-SNAPSHOT, the resulting archive has files in
> ${fileLocation}/...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-256) Regression: pom properties are no longer expanded in descriptor.
[
https://jira.codehaus.org/browse/MASSEMBLY-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=316082#comment-316082
]
Hannes Kogler edited comment on MASSEMBLY-256 at 12/21/12 5:49 AM:
---
anybody here, to give a good reason why the interpolation is deactivated in the
descriptor's sections by this code?
blacklist.add( "outputFileNameMapping" );
blacklist.add( "outputDirectoryMapping" );
blacklist.add( "outputDirectory" );
I think ESPECIALLY at those 3 tags the interpolation would make the most
sense..
or is there any opional parameter do deactivate this blacklist-behavior?
was (Author: ntshko):
anybody here, to give a good reason why the interpolation is deactivated in
the descriptor's sections by this code?
blacklist.add( "outputFileNameMapping" );
blacklist.add( "outputDirectoryMapping" );
blacklist.add( "outputDirectory" );
I think ESPECIALLY at those 3 tags the interpolation would make the most
sense..
> Regression: pom properties are no longer expanded in descriptor.
>
>
> Key: MASSEMBLY-256
> URL: https://jira.codehaus.org/browse/MASSEMBLY-256
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-1, 2.2-beta-2
> Environment: maven 2.0.8
> windows xp sp2
>Reporter: Mark Reynolds
>Assignee: John Casey
> Fix For: 2.2-beta-3
>
> Attachments: assembly-issue.zip
>
>
> Attached is a minimal project which demonstrates this issue.
> The pom contains a property:
>
> ...
>
> file/path
>
>
> The descriptor uses this property in specifying the output directory for a
> fileSet:
>
> ...
>
>
> src/main/files
> ${fileLocation}
>
>
>
> In versions 2.1, 2.2-beta-1, and 2.2-SNAPSHOT of the assembly plugin, this
> property is expanded so the resulting archive has files in file/path/
> In the latest 2.2-beta-2-SNAPSHOT, the resulting archive has files in
> ${fileLocation}/...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-394) Property filtering does not work inside the outputDirectory element content
[
https://jira.codehaus.org/browse/MASSEMBLY-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=316084#comment-316084
]
Hannes Kogler commented on MASSEMBLY-394:
-
I don't know what this blacklist "feature" is for?
Can anybody please describe why this makes sense?
The other critical point is, that on the one hand the own defined properties
from the pom.xml aren't interpolated in the assembly descriptors tags (
"outputFileNameMapping", "outputDirectoryMapping", "outputDirectory" ), but on
the other hand the interpolation within those tags work without any problems
with the default variables like ${artifact.groupId}.
> Property filtering does not work inside the outputDirectory element content
> ---
>
> Key: MASSEMBLY-394
> URL: https://jira.codehaus.org/browse/MASSEMBLY-394
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-3
> Environment: Maven version: 2.0.10
> Java version: 1.5.0_15
> Ubuntu 8.10
> OS name: "linux" version: "2.6.27-11-generic" arch: "i386" Family: "unix"
>Reporter: Keith Wedinger
>Assignee: John Casey
>
> Inside my POM, I have the following property defined:
>
> b2b_oba
>
> Inside my assembly descriptor, I am attempting to use the property above as
> well as project defined properties to filter the outputDirectory element
> content contained within . The relevant descriptor snippet is
> below:
>
>
>
> ${clump.codejar.output.directory}/${project.name}.jar
>
> ${project.name}/jars/${clump.name}/${clump.version.dir}
>
>
> After running mvn assembly:assembly, the resultant outputDirectory content
> remains as follows. None of the properties are replaced with their
> corresponding values.
> ${project.name}/jars/${project.name}/${clump.version.dir}
> maven-assembly-plugin version 2.1 does not have this issue. When I use
> version 2.1, property filtering on the outputDirectory works correctly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-394) Property filtering does not work inside the outputDirectory element content
[
https://jira.codehaus.org/browse/MASSEMBLY-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=316084#comment-316084
]
Hannes Kogler edited comment on MASSEMBLY-394 at 12/21/12 6:01 AM:
---
I don't know what this blacklist "feature" is for?
Can anybody please describe why this makes sense?
The other critical point is, that on the one hand the own defined properties
from the pom.xml aren't interpolated in the assembly descriptors tags (
"outputFileNameMapping", "outputDirectoryMapping", "outputDirectory" ), but on
the other hand the interpolation within those tags work without any problems
with the default variables like ${artifact.groupId}.
so where is the difference?
-> ${artifact.groupId} => works!
-> ${project.properties.anyPropFromPom} =>
won't be interpolated!?
was (Author: ntshko):
I don't know what this blacklist "feature" is for?
Can anybody please describe why this makes sense?
The other critical point is, that on the one hand the own defined properties
from the pom.xml aren't interpolated in the assembly descriptors tags (
"outputFileNameMapping", "outputDirectoryMapping", "outputDirectory" ), but on
the other hand the interpolation within those tags work without any problems
with the default variables like ${artifact.groupId}.
> Property filtering does not work inside the outputDirectory element content
> ---
>
> Key: MASSEMBLY-394
> URL: https://jira.codehaus.org/browse/MASSEMBLY-394
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-3
> Environment: Maven version: 2.0.10
> Java version: 1.5.0_15
> Ubuntu 8.10
> OS name: "linux" version: "2.6.27-11-generic" arch: "i386" Family: "unix"
>Reporter: Keith Wedinger
>Assignee: John Casey
>
> Inside my POM, I have the following property defined:
>
> b2b_oba
>
> Inside my assembly descriptor, I am attempting to use the property above as
> well as project defined properties to filter the outputDirectory element
> content contained within . The relevant descriptor snippet is
> below:
>
>
>
> ${clump.codejar.output.directory}/${project.name}.jar
>
> ${project.name}/jars/${clump.name}/${clump.version.dir}
>
>
> After running mvn assembly:assembly, the resultant outputDirectory content
> remains as follows. None of the properties are replaced with their
> corresponding values.
> ${project.name}/jars/${project.name}/${clump.version.dir}
> maven-assembly-plugin version 2.1 does not have this issue. When I use
> version 2.1, property filtering on the outputDirectory works correctly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-187) dependency:copy fails when invoked from m2e with workspace resolution enabled, or more generally when copying within reactor for phases earlier than package
[
https://jira.codehaus.org/browse/MDEP-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=356251#comment-356251
]
Hannes Kogler commented on MDEP-187:
Perhaps the logging gives some important hints for fixing this bad issue...
[*m2e plugin version*: 1.6.0.20140823-1318; using standalone Maven version
3.2.3]
[*eclipse version*: Luna Service Release 1 (4.4.1); Build id 20140925-1800]
if the workspace resolution is deactivated, the copying works and the message
in the Maven console says:
{color:blue}11/17/14, 12:57:32 PM GMT+1: [INFO] *Copying*
some.project-XX.XX.XX.jar to
C:\workspaces\some.other\target\some.project.jar{color}
if the workspace resolution is ACTIVE, m2e starts any other process on the
maven-dependency-plugin and fails copying with the message in the Maven console:
{color:blue}11/17/14, 1:15:02 PM GMT+1: [INFO] *Copying classes* to
C:\workspaces\some.other\target\some.project.jar{color}
*After all when failing he tries to copy only the classes of the jar file??!! *
> dependency:copy fails when invoked from m2e with workspace resolution
> enabled, or more generally when copying within reactor for phases earlier
> than package
>
>
> Key: MDEP-187
> URL: https://jira.codehaus.org/browse/MDEP-187
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: copy, copy-dependencies
>Affects Versions: 2.1
>Reporter: Igor Fedorenko
> Attachments: MDEP-187b.diff, MDEP-187c.diff, MDEP-187.diff
>
>
> m2e resolves workspace artifacts to their output folders but dependency:copy
> expects all artifacts to be files. I will provide trivial patch shortly.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SCM-714) mvn release:prepare fails if the command line is too long on windows
[ https://jira.codehaus.org/browse/SCM-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360482#comment-360482 ] Hannes Kogler commented on SCM-714: --- We have also come across this problem and after all this means that git is not really useable in combination with the maven-release-plugin up-to-now :-( Is there anybody working on this blocking issue already? > mvn release:prepare fails if the command line is too long on windows > > > Key: SCM-714 > URL: https://jira.codehaus.org/browse/SCM-714 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.8.1 >Reporter: Felix Simmendinger >Priority: Blocker > > The issue from SCM-697 does not solve the issue as the gitprovider is not > using the add command but the checkin command during a release. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-748) problem to extract zip files including file names with umlauts
Hannes Kogler created MASSEMBLY-748: --- Summary: problem to extract zip files including file names with umlauts Key: MASSEMBLY-748 URL: https://jira.codehaus.org/browse/MASSEMBLY-748 Project: Maven Assembly Plugin Issue Type: Bug Components: maven-archiver Affects Versions: 2.5.3 Environment: Reporter: Hannes Kogler Attachments: encoding_problem_on_zip_extract.7z Like in an other issue reported, you need to explicitly set the code page CP850 to create zip packages hosting file names with correct umlauts their names. (by using the following configuration) CP850 After all this solution is not 100% useful, because if you extract this file with the obiously correct umlauts in the zip, wrong chars for all umlauts reappear. It's strange, because if you unzip this zip file with all other zip tools (7zip, Windows native zip support aso.) the extraction works fine. Only using the maven-assembly-plugin the umlauts get corrupted. (a try to set the archiverConfig with the CP850 also for the extracting execution process of the assembly plugin just results in a bad error calling Failed to configure archiver: " org.codehaus.plexus.archiver.dir.DirectoryArchiver: Cannot find 'encoding' in class org.codehaus.plexus.archiver.dir.DirectoryArchiver " ) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-748) problem to extract zip files including file names with umlauts
[ https://jira.codehaus.org/browse/MASSEMBLY-748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hannes Kogler updated MASSEMBLY-748: Description: Like in an other issue reported, you need to explicitly set the code page CP850 to create zip packages hosting file names with correct umlauts their names. (by using the following configuration) CP850 After all this solution is not 100% useful, because if you extract this file with the obiously correct umlauts in the zip, wrong chars for all umlauts reappear. It's strange, because if you unzip this zip file with all other zip tools (7zip, Windows native zip support aso.) the extraction works fine. Only using the maven-assembly-plugin the umlauts get corrupted. (a try to set the archiverConfig with the CP850 also for the extracting execution process of the assembly plugin just results in a bad error calling Failed to configure archiver: " org.codehaus.plexus.archiver.dir.DirectoryArchiver: Cannot find 'encoding' in class org.codehaus.plexus.archiver.dir.DirectoryArchiver " ) was: Like in an other issue reported, you need to explicitly set the code page CP850 to create zip packages hosting file names with correct umlauts their names. (by using the following configuration) CP850 After all this solution is not 100% useful, because if you extract this file with the obiously correct umlauts in the zip, wrong chars for all umlauts reappear. It's strange, because if you unzip this zip file with all other zip tools (7zip, Windows native zip support aso.) the extraction works fine. Only using the maven-assembly-plugin the umlauts get corrupted. (a try to set the archiverConfig with the CP850 also for the extracting execution process of the assembly plugin just results in a bad error calling Failed to configure archiver: " org.codehaus.plexus.archiver.dir.DirectoryArchiver: Cannot find 'encoding' in class org.codehaus.plexus.archiver.dir.DirectoryArchiver " ) > problem to extract zip files including file names with umlauts > -- > > Key: MASSEMBLY-748 > URL: https://jira.codehaus.org/browse/MASSEMBLY-748 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: maven-archiver >Affects Versions: 2.5.3 > Environment: >Reporter: Hannes Kogler > Attachments: encoding_problem_on_zip_extract.7z > > > Like in an other issue reported, you need to explicitly set the code page > CP850 to create zip packages hosting file names with correct umlauts their > names. (by using the following configuration) > > CP850 > > After all this solution is not 100% useful, because if you extract this file > with the obiously correct umlauts in the zip, wrong chars for all umlauts > reappear. > It's strange, because if you unzip this zip file with all other zip tools > (7zip, Windows native zip support aso.) the extraction works fine. > Only using the maven-assembly-plugin the umlauts get corrupted. > (a try to set the archiverConfig with the CP850 also for the extracting > execution process of the assembly plugin just results in a bad error calling > Failed to configure archiver: > " org.codehaus.plexus.archiver.dir.DirectoryArchiver: Cannot find 'encoding' > in class org.codehaus.plexus.archiver.dir.DirectoryArchiver " ) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-748) problem to extract zip files including file names with umlauts
[ https://jira.codehaus.org/browse/MASSEMBLY-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360998#comment-360998 ] Hannes Kogler commented on MASSEMBLY-748: - I have also created and attached an sample project structure where you can easily reproduce the problem with the umlauts. there is one file in the src/main/resources folder of the project buildinf.playground calling "Artikel mit größerer Nachfrage.REP". This file, and some others, get packaged into a new zip file using the CP850. Everything looks ok. But when you try to extract it using an assembly descriptor (also provided in the sample package) the umlauts are away again... :-( Very interesting is the fact, that if you go the other way round, it works. Meaning DON'T use the CP850 on creating the zip file first, which results in a wrong looking zip file. And then the maven-assembly-plugin can extract it correctly where suddenly the umlauts are correct extracted. (you can reproduce this way by using the maven profile "otherWay" of the sample package) *What I request is a way, where I can produce good looking zip files with correct file name umlauts on the one hand and a correct extraction where the umlauts won't be changed on the other hand.* > problem to extract zip files including file names with umlauts > -- > > Key: MASSEMBLY-748 > URL: https://jira.codehaus.org/browse/MASSEMBLY-748 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: maven-archiver >Affects Versions: 2.5.3 > Environment: >Reporter: Hannes Kogler > Attachments: encoding_problem_on_zip_extract.7z > > > Like in an other issue reported, you need to explicitly set the code page > CP850 to create zip packages hosting file names with correct umlauts their > names. (by using the following configuration) > > CP850 > > After all this solution is not 100% useful, because if you extract this file > with the obiously correct umlauts in the zip, wrong chars for all umlauts > reappear. > It's strange, because if you unzip this zip file with all other zip tools > (7zip, Windows native zip support aso.) the extraction works fine. > Only using the maven-assembly-plugin the umlauts get corrupted. > (a try to set the archiverConfig with the CP850 also for the extracting > execution process of the assembly plugin just results in a bad error calling > Failed to configure archiver: > " org.codehaus.plexus.archiver.dir.DirectoryArchiver: Cannot find 'encoding' > in class org.codehaus.plexus.archiver.dir.DirectoryArchiver " ) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-748) problem to extract zip files including file names with umlauts
[ https://jira.codehaus.org/browse/MASSEMBLY-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361688#comment-361688 ] Hannes Kogler commented on MASSEMBLY-748: - But I cannot understand why the maven-assembly-plugin here should behave different from the default OS-behavior? Indeed Windows can handle umlauts also in zip compressed file names perfectly, if you just compress the same file(s) with the Windows compression tool itself. So if you take the buildinf.playground project (from my sample project), put it to windows desktop, rightclick on it and say "send to/Compressed (Zipped) folder" the compression works fine and also opening the zip file with Windows reads out the correct file name. So in my point of view the maven-assembly-plugin needs to behave just like you expect and know it from your OS. All other behaviors are just annoying and error-prone since you may loose the umlauts after extracting such a zip file on Windows currently. In other words there are two opportunities to solve this issue: * The maven-assembly-plugin should just use the OS-encoding. (like it did before your "switch over to UTF-8"?!) * The other alternative would be - just like the tag already provides but only for the way of compression - the default encoding can surely be UTF-8, but you need to have the possibility to configure an alternative encoding also for way of extraction, to work consistently. > problem to extract zip files including file names with umlauts > -- > > Key: MASSEMBLY-748 > URL: https://jira.codehaus.org/browse/MASSEMBLY-748 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: maven-archiver >Affects Versions: 2.5.3 > Environment: >Reporter: Hannes Kogler >Assignee: Kristian Rosenvold > Fix For: 2.5.4 > > Attachments: encoding_problem_on_zip_extract.7z > > > Like in an other issue reported, you need to explicitly set the code page > CP850 to create zip packages hosting file names with correct umlauts their > names. (by using the following configuration) > > CP850 > > After all this solution is not 100% useful, because if you extract this file > with the obiously correct umlauts in the zip, wrong chars for all umlauts > reappear. > It's strange, because if you unzip this zip file with all other zip tools > (7zip, Windows native zip support aso.) the extraction works fine. > Only using the maven-assembly-plugin the umlauts get corrupted. > (a try to set the archiverConfig with the CP850 also for the extracting > execution process of the assembly plugin just results in a bad error calling > Failed to configure archiver: > " org.codehaus.plexus.archiver.dir.DirectoryArchiver: Cannot find 'encoding' > in class org.codehaus.plexus.archiver.dir.DirectoryArchiver " ) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-748) problem to extract zip files including file names with umlauts
[ https://jira.codehaus.org/browse/MASSEMBLY-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361688#comment-361688 ] Hannes Kogler edited comment on MASSEMBLY-748 at 1/23/15 2:53 AM: -- But I cannot understand why the maven-assembly-plugin here should behave different from the default OS-behavior? Indeed Windows can handle umlauts also in zip compressed file names perfectly, if you just compress the same file(s) with the Windows compression tool itself. So if you take the buildinf.playground project (from my sample project), put it to windows desktop, rightclick on it and say "send to/Compressed (Zipped) folder" the compression works fine and also opening the zip file with Windows reads out the correct file name. So in my point of view the maven-assembly-plugin needs to behave just like you expect and know it from your OS. All other behaviors are just annoying and error-prone since you may loose the umlauts after extracting such a zip file on Windows currently. In other words there are two opportunities to solve this issue: * The maven-assembly-plugin should just use the OS-encoding. (like it did before your "switch over to UTF-8"?!) * The other alternative would be - just like the tag already provides but only for the way of compression - the default encoding can surely be UTF-8, but you need to have the possibility to configure an alternative encoding also for way of extraction, to work consistently. ps.: just execute a mvn clean install on the buildinf.module using the Maven profile "otherWay". then you should be able to reproduce that if you use this way of skipping the stanza you are able to decrompess it with the assembly-plugin, but you cannot really use the produced zip file on windows systems, because if you just extract it there you loose the umlauts forever. was (Author: ntshko): But I cannot understand why the maven-assembly-plugin here should behave different from the default OS-behavior? Indeed Windows can handle umlauts also in zip compressed file names perfectly, if you just compress the same file(s) with the Windows compression tool itself. So if you take the buildinf.playground project (from my sample project), put it to windows desktop, rightclick on it and say "send to/Compressed (Zipped) folder" the compression works fine and also opening the zip file with Windows reads out the correct file name. So in my point of view the maven-assembly-plugin needs to behave just like you expect and know it from your OS. All other behaviors are just annoying and error-prone since you may loose the umlauts after extracting such a zip file on Windows currently. In other words there are two opportunities to solve this issue: * The maven-assembly-plugin should just use the OS-encoding. (like it did before your "switch over to UTF-8"?!) * The other alternative would be - just like the tag already provides but only for the way of compression - the default encoding can surely be UTF-8, but you need to have the possibility to configure an alternative encoding also for way of extraction, to work consistently. > problem to extract zip files including file names with umlauts > -- > > Key: MASSEMBLY-748 > URL: https://jira.codehaus.org/browse/MASSEMBLY-748 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: maven-archiver >Affects Versions: 2.5.3 > Environment: >Reporter: Hannes Kogler >Assignee: Kristian Rosenvold > Fix For: 2.5.4 > > Attachments: encoding_problem_on_zip_extract.7z > > > Like in an other issue reported, you need to explicitly set the code page > CP850 to create zip packages hosting file names with correct umlauts their > names. (by using the following configuration) > > CP850 > > After all this solution is not 100% useful, because if you extract this file > with the obiously correct umlauts in the zip, wrong chars for all umlauts > reappear. > It's strange, because if you unzip this zip file with all other zip tools > (7zip, Windows native zip support aso.) the extraction works fine. > Only using the maven-assembly-plugin the umlauts get corrupted. > (a try to set the archiverConfig with the CP850 also for the extracting > execution process of the assembly plugin just results in a bad error calling > Failed to configure archiver: > " org.codehaus.plexus.archiver.dir.DirectoryArchiver: Cannot find 'encoding' > in class org.codehaus.plexus.archiver.dir.DirectoryArchiver " ) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-748) problem to extract zip files including file names with umlauts
[ https://jira.codehaus.org/browse/MASSEMBLY-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361688#comment-361688 ] Hannes Kogler edited comment on MASSEMBLY-748 at 1/23/15 2:55 AM: -- But I cannot understand why the maven-assembly-plugin here should behave different from the default OS-behavior? Indeed Windows can handle umlauts also in zip compressed file names perfectly, if you just compress the same file(s) with the Windows compression tool itself. So if you take the buildinf.playground project (from my sample project), put it to windows desktop, rightclick on it and say "send to/Compressed (Zipped) folder" the compression works fine and also opening the zip file with Windows reads out the correct file name. So in my point of view the maven-assembly-plugin needs to behave just like you expect and know it from your OS. All other behaviors are just annoying and error-prone since you may loose the umlauts after extracting such a zip file on Windows currently. In other words there are two opportunities to solve this issue: * The maven-assembly-plugin should just use the OS-encoding. (like it did before your "switch over to UTF-8"?!) * The other alternative would be - just like the tag already provides but only for the way of compression - the default encoding can surely be UTF-8, but you need to have the possibility to configure an alternative encoding also for way of extraction, to work consistently. ps.: just execute a mvn clean install on the buildinf.module using the Maven profile "otherWay". then you should be able to reproduce that if you use this way of skipping the stanza you are able to decrompess it with the assembly-plugin, but you cannot really use the produced zip file [of the project buildinf.playground] on windows systems, because if you just extract it there you loose the umlauts forever. was (Author: ntshko): But I cannot understand why the maven-assembly-plugin here should behave different from the default OS-behavior? Indeed Windows can handle umlauts also in zip compressed file names perfectly, if you just compress the same file(s) with the Windows compression tool itself. So if you take the buildinf.playground project (from my sample project), put it to windows desktop, rightclick on it and say "send to/Compressed (Zipped) folder" the compression works fine and also opening the zip file with Windows reads out the correct file name. So in my point of view the maven-assembly-plugin needs to behave just like you expect and know it from your OS. All other behaviors are just annoying and error-prone since you may loose the umlauts after extracting such a zip file on Windows currently. In other words there are two opportunities to solve this issue: * The maven-assembly-plugin should just use the OS-encoding. (like it did before your "switch over to UTF-8"?!) * The other alternative would be - just like the tag already provides but only for the way of compression - the default encoding can surely be UTF-8, but you need to have the possibility to configure an alternative encoding also for way of extraction, to work consistently. ps.: just execute a mvn clean install on the buildinf.module using the Maven profile "otherWay". then you should be able to reproduce that if you use this way of skipping the stanza you are able to decrompess it with the assembly-plugin, but you cannot really use the produced zip file on windows systems, because if you just extract it there you loose the umlauts forever. > problem to extract zip files including file names with umlauts > -- > > Key: MASSEMBLY-748 > URL: https://jira.codehaus.org/browse/MASSEMBLY-748 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: maven-archiver >Affects Versions: 2.5.3 > Environment: >Reporter: Hannes Kogler >Assignee: Kristian Rosenvold > Fix For: 2.5.4 > > Attachments: encoding_problem_on_zip_extract.7z > > > Like in an other issue reported, you need to explicitly set the code page > CP850 to create zip packages hosting file names with correct umlauts their > names. (by using the following configuration) > > CP850 > > After all this solution is not 100% useful, because if you extract this file > with the obiously correct umlauts in the zip, wrong chars for all umlauts > reappear. > It's strange, because if you unzip this zip file with all other zip tools > (7zip, Windows native zip support aso.) the extraction works fine. > Only using the maven-assembly-plugin the umlauts get corrupted. > (a try to set the archiverConfig with the CP850 also for the extracting > execution process of the assembly plugin just results in a bad error calling > Failed to configure archiver: >
[jira] (MASSEMBLY-748) problem to extract zip files including file names with umlauts
[ https://jira.codehaus.org/browse/MASSEMBLY-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361688#comment-361688 ] Hannes Kogler edited comment on MASSEMBLY-748 at 1/23/15 2:59 AM: -- But I cannot understand why the maven-assembly-plugin here should behave different from the default OS-behavior? Indeed Windows can handle umlauts also in zip compressed file names perfectly, if you just compress the same file(s) with the Windows compression tool itself. So if you take the buildinf.playground project (from my sample project), put it to windows desktop, rightclick on it and say "send to/Compressed (Zipped) folder" the compression works fine and also opening the zip file with Windows reads out the correct file name. So in my point of view the maven-assembly-plugin needs to behave just like you expect and know it from your OS. All other behaviors are just annoying and error-prone since you may loose the umlauts after extracting such a zip file on Windows currently. In other words there are two opportunities to solve this issue as I see it: * The maven-assembly-plugin should just use the OS-encoding. (like it did before your "switch over to UTF-8"?!) * The other alternative would be - just like the tag already provides but only for the way of compression - the default encoding can surely be UTF-8, but you need to have the possibility to configure an alternative encoding also for way of extraction, to work consistently. ps.: just execute a mvn clean install on the _buildinf.module_ using the Maven profile "otherWay". then you should be able to reproduce that because this profile uses the way of skipping the stanza. In this way you are able to decrompess it with the assembly-plugin, but you cannot really use the produced zip file [of the project buildinf.playground] on windows systems, because if you just extract it there you loose the umlauts forever. was (Author: ntshko): But I cannot understand why the maven-assembly-plugin here should behave different from the default OS-behavior? Indeed Windows can handle umlauts also in zip compressed file names perfectly, if you just compress the same file(s) with the Windows compression tool itself. So if you take the buildinf.playground project (from my sample project), put it to windows desktop, rightclick on it and say "send to/Compressed (Zipped) folder" the compression works fine and also opening the zip file with Windows reads out the correct file name. So in my point of view the maven-assembly-plugin needs to behave just like you expect and know it from your OS. All other behaviors are just annoying and error-prone since you may loose the umlauts after extracting such a zip file on Windows currently. In other words there are two opportunities to solve this issue: * The maven-assembly-plugin should just use the OS-encoding. (like it did before your "switch over to UTF-8"?!) * The other alternative would be - just like the tag already provides but only for the way of compression - the default encoding can surely be UTF-8, but you need to have the possibility to configure an alternative encoding also for way of extraction, to work consistently. ps.: just execute a mvn clean install on the buildinf.module using the Maven profile "otherWay". then you should be able to reproduce that if you use this way of skipping the stanza you are able to decrompess it with the assembly-plugin, but you cannot really use the produced zip file [of the project buildinf.playground] on windows systems, because if you just extract it there you loose the umlauts forever. > problem to extract zip files including file names with umlauts > -- > > Key: MASSEMBLY-748 > URL: https://jira.codehaus.org/browse/MASSEMBLY-748 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: maven-archiver >Affects Versions: 2.5.3 > Environment: >Reporter: Hannes Kogler >Assignee: Kristian Rosenvold > Fix For: 2.5.4 > > Attachments: encoding_problem_on_zip_extract.7z > > > Like in an other issue reported, you need to explicitly set the code page > CP850 to create zip packages hosting file names with correct umlauts their > names. (by using the following configuration) > > CP850 > > After all this solution is not 100% useful, because if you extract this file > with the obiously correct umlauts in the zip, wrong chars for all umlauts > reappear. > It's strange, because if you unzip this zip file with all other zip tools > (7zip, Windows native zip support aso.) the extraction works fine. > Only using the maven-assembly-plugin the umlauts get corrupted. > (a try to set the archiverConfig with the CP850 also for the extracting > execution process of the assemb
[jira] (MASSEMBLY-748) problem to extract zip files including file names with umlauts
[ https://jira.codehaus.org/browse/MASSEMBLY-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361688#comment-361688 ] Hannes Kogler edited comment on MASSEMBLY-748 at 1/23/15 3:00 AM: -- But I cannot understand why the maven-assembly-plugin here should behave different from the default OS-behavior? Indeed Windows can handle umlauts also in zip compressed file names perfectly, if you just compress the same file(s) with the Windows compression tool itself. So if you take the buildinf.playground project (from my sample project), put it to windows desktop, rightclick on it and say "send to/Compressed (Zipped) folder" the compression works fine and also opening the zip file with Windows reads out the correct file name. So in my point of view the maven-assembly-plugin needs to behave just like you expect and know it from your OS. All other behaviors are just annoying and error-prone since you may loose the umlauts after extracting such a zip file on Windows currently. In other words there are two opportunities to solve this issue as I see it: * The maven-assembly-plugin should just use the OS-encoding. (like it did before your mentioned "switch over to UTF-8"?!) * The other alternative would be - just like the tag already provides but only for the way of compression - the default encoding can surely be UTF-8, but you need to have the possibility to configure an alternative encoding also for way of extraction, to work consistently. ps.: just execute a mvn clean install on the _buildinf.module_ using the Maven profile "otherWay". then you should be able to reproduce that because this profile uses the way of skipping the stanza. In this way you are able to decrompess it with the assembly-plugin, but you cannot really use the produced zip file [of the project buildinf.playground] on windows systems, because if you just extract it there you loose the umlauts forever. was (Author: ntshko): But I cannot understand why the maven-assembly-plugin here should behave different from the default OS-behavior? Indeed Windows can handle umlauts also in zip compressed file names perfectly, if you just compress the same file(s) with the Windows compression tool itself. So if you take the buildinf.playground project (from my sample project), put it to windows desktop, rightclick on it and say "send to/Compressed (Zipped) folder" the compression works fine and also opening the zip file with Windows reads out the correct file name. So in my point of view the maven-assembly-plugin needs to behave just like you expect and know it from your OS. All other behaviors are just annoying and error-prone since you may loose the umlauts after extracting such a zip file on Windows currently. In other words there are two opportunities to solve this issue as I see it: * The maven-assembly-plugin should just use the OS-encoding. (like it did before your "switch over to UTF-8"?!) * The other alternative would be - just like the tag already provides but only for the way of compression - the default encoding can surely be UTF-8, but you need to have the possibility to configure an alternative encoding also for way of extraction, to work consistently. ps.: just execute a mvn clean install on the _buildinf.module_ using the Maven profile "otherWay". then you should be able to reproduce that because this profile uses the way of skipping the stanza. In this way you are able to decrompess it with the assembly-plugin, but you cannot really use the produced zip file [of the project buildinf.playground] on windows systems, because if you just extract it there you loose the umlauts forever. > problem to extract zip files including file names with umlauts > -- > > Key: MASSEMBLY-748 > URL: https://jira.codehaus.org/browse/MASSEMBLY-748 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: maven-archiver >Affects Versions: 2.5.3 > Environment: >Reporter: Hannes Kogler >Assignee: Kristian Rosenvold > Fix For: 2.5.4 > > Attachments: encoding_problem_on_zip_extract.7z > > > Like in an other issue reported, you need to explicitly set the code page > CP850 to create zip packages hosting file names with correct umlauts their > names. (by using the following configuration) > > CP850 > > After all this solution is not 100% useful, because if you extract this file > with the obiously correct umlauts in the zip, wrong chars for all umlauts > reappear. > It's strange, because if you unzip this zip file with all other zip tools > (7zip, Windows native zip support aso.) the extraction works fine. > Only using the maven-assembly-plugin the umlauts get corrupted. > (a try to set the archiverConfig with the CP850 also fo
[jira] (MASSEMBLY-748) problem to extract zip files including file names with umlauts
[ https://jira.codehaus.org/browse/MASSEMBLY-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361696#comment-361696 ] Hannes Kogler commented on MASSEMBLY-748: - Exactly this is what I am complaining. If you configure "archiverConfig" for the same plugin execution you use on extraction of a zip file you just get a plugin Exception (justl ike described in the main description of the issue you get the error: *org.codehaus.plexus.archiver.dir.DirectoryArchiver: Cannot find 'encoding' in class org.codehaus.plexus.archiver.dir.DirectoryArchiver* ) If I am able to produce a zip file using the with a special encoding like CP850, then I assume I can also extract it (however this works, I don't know the ZIP format specification or implementation exactly) using the same encoding to provide a consistent way of getting the files as they are correctly displayed/zipped in the compressed file. (without losing any char informations). So the maven-assembly-plugin needs to support any way to decompress zip files with alternative encodings of the source file's zipEntries to be consistent. And yes, those contraints would be ok. Because since umlauts are a typical german language part, I can assume that the target OS system, where those files will be viewed and handled will be CP850 compatible. If I get some zip files with russian chars in the file names of zipEntries I cannot expect that on my german OS system they will be displayed in a correct way, if I don't specify an alternative encoding to handle such files. > problem to extract zip files including file names with umlauts > -- > > Key: MASSEMBLY-748 > URL: https://jira.codehaus.org/browse/MASSEMBLY-748 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: maven-archiver >Affects Versions: 2.5.3 > Environment: >Reporter: Hannes Kogler >Assignee: Kristian Rosenvold > Fix For: 2.5.4 > > Attachments: encoding_problem_on_zip_extract.7z > > > Like in an other issue reported, you need to explicitly set the code page > CP850 to create zip packages hosting file names with correct umlauts their > names. (by using the following configuration) > > CP850 > > After all this solution is not 100% useful, because if you extract this file > with the obiously correct umlauts in the zip, wrong chars for all umlauts > reappear. > It's strange, because if you unzip this zip file with all other zip tools > (7zip, Windows native zip support aso.) the extraction works fine. > Only using the maven-assembly-plugin the umlauts get corrupted. > (a try to set the archiverConfig with the CP850 also for the extracting > execution process of the assembly plugin just results in a bad error calling > Failed to configure archiver: > " org.codehaus.plexus.archiver.dir.DirectoryArchiver: Cannot find 'encoding' > in class org.codehaus.plexus.archiver.dir.DirectoryArchiver " ) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-748) problem to extract zip files including file names with umlauts
[ https://jira.codehaus.org/browse/MASSEMBLY-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361696#comment-361696 ] Hannes Kogler edited comment on MASSEMBLY-748 at 1/23/15 5:18 AM: -- Exactly this is what I am complaining. If you configure "archiverConfig" for the same plugin execution you use on extraction of a zip file you just get a plugin Exception (justl ike described in the main description of the issue you get the error: *org.codehaus.plexus.archiver.dir.DirectoryArchiver: Cannot find 'encoding' in class org.codehaus.plexus.archiver.dir.DirectoryArchiver* ) Meaning, the same plugin configuration, with the only difference that one time I use an assembly descriptor that defines to unpacks the zip file, and one time using a assembly-descriptor to packs the file results one time in an error and one time it works. If I am able to produce a zip file using the with a special encoding like CP850, then I assume I can also extract it (however this works, I don't know the ZIP format specification or implementation exactly) using the same encoding to provide a consistent way of getting the files as they are correctly displayed/zipped in the compressed file. (without losing any char informations). So the maven-assembly-plugin needs to support any way to decompress zip files with alternative encodings of the source file's zipEntries to be consistent. And yes, those contraints would be ok. Because since umlauts are a typical german language part, I can assume that the target OS system, where those files will be viewed and handled will be CP850 compatible. If I get some zip files with russian chars in the file names of zipEntries I cannot expect that on my german OS system they will be displayed in a correct way, if I don't specify an alternative encoding to handle such files. was (Author: ntshko): Exactly this is what I am complaining. If you configure "archiverConfig" for the same plugin execution you use on extraction of a zip file you just get a plugin Exception (justl ike described in the main description of the issue you get the error: *org.codehaus.plexus.archiver.dir.DirectoryArchiver: Cannot find 'encoding' in class org.codehaus.plexus.archiver.dir.DirectoryArchiver* ) If I am able to produce a zip file using the with a special encoding like CP850, then I assume I can also extract it (however this works, I don't know the ZIP format specification or implementation exactly) using the same encoding to provide a consistent way of getting the files as they are correctly displayed/zipped in the compressed file. (without losing any char informations). So the maven-assembly-plugin needs to support any way to decompress zip files with alternative encodings of the source file's zipEntries to be consistent. And yes, those contraints would be ok. Because since umlauts are a typical german language part, I can assume that the target OS system, where those files will be viewed and handled will be CP850 compatible. If I get some zip files with russian chars in the file names of zipEntries I cannot expect that on my german OS system they will be displayed in a correct way, if I don't specify an alternative encoding to handle such files. > problem to extract zip files including file names with umlauts > -- > > Key: MASSEMBLY-748 > URL: https://jira.codehaus.org/browse/MASSEMBLY-748 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: maven-archiver >Affects Versions: 2.5.3 > Environment: >Reporter: Hannes Kogler >Assignee: Kristian Rosenvold > Fix For: 2.5.4 > > Attachments: encoding_problem_on_zip_extract.7z > > > Like in an other issue reported, you need to explicitly set the code page > CP850 to create zip packages hosting file names with correct umlauts their > names. (by using the following configuration) > > CP850 > > After all this solution is not 100% useful, because if you extract this file > with the obiously correct umlauts in the zip, wrong chars for all umlauts > reappear. > It's strange, because if you unzip this zip file with all other zip tools > (7zip, Windows native zip support aso.) the extraction works fine. > Only using the maven-assembly-plugin the umlauts get corrupted. > (a try to set the archiverConfig with the CP850 also for the extracting > execution process of the assembly plugin just results in a bad error calling > Failed to configure archiver: > " org.codehaus.plexus.archiver.dir.DirectoryArchiver: Cannot find 'encoding' > in class org.codehaus.plexus.archiver.dir.DirectoryArchiver " ) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-748) problem to extract zip files including file names with umlauts
[ https://jira.codehaus.org/browse/MASSEMBLY-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361696#comment-361696 ] Hannes Kogler edited comment on MASSEMBLY-748 at 1/23/15 5:19 AM: -- Exactly this is what I am complaining. If you configure "archiverConfig" for the same plugin execution you use on extraction of a zip file you just get a plugin Exception (justl ike described in the main description of the issue you get the error: *org.codehaus.plexus.archiver.dir.DirectoryArchiver: Cannot find 'encoding' in class org.codehaus.plexus.archiver.dir.DirectoryArchiver* ) Meaning, the same plugin configuration, with the only difference that one time I use an assembly descriptor that defines to pack the zip file, and one time using an assembly-descriptor to unpack the file, results one time in a well packed zip file an another time on unpacking in a hard plugin error. If I am able to produce a zip file using the with a special encoding like CP850, then I assume I can also extract it (however this works, I don't know the ZIP format specification or implementation exactly) using the same encoding to provide a consistent way of getting the files as they are correctly displayed/zipped in the compressed file. (without losing any char informations). So the maven-assembly-plugin needs to support any way to decompress zip files with alternative encodings of the source file's zipEntries to be consistent. And yes, those contraints would be ok. Because since umlauts are a typical german language part, I can assume that the target OS system, where those files will be viewed and handled will be CP850 compatible. If I get some zip files with russian chars in the file names of zipEntries I cannot expect that on my german OS system they will be displayed in a correct way, if I don't specify an alternative encoding to handle such files. was (Author: ntshko): Exactly this is what I am complaining. If you configure "archiverConfig" for the same plugin execution you use on extraction of a zip file you just get a plugin Exception (justl ike described in the main description of the issue you get the error: *org.codehaus.plexus.archiver.dir.DirectoryArchiver: Cannot find 'encoding' in class org.codehaus.plexus.archiver.dir.DirectoryArchiver* ) Meaning, the same plugin configuration, with the only difference that one time I use an assembly descriptor that defines to unpacks the zip file, and one time using a assembly-descriptor to packs the file results one time in an error and one time it works. If I am able to produce a zip file using the with a special encoding like CP850, then I assume I can also extract it (however this works, I don't know the ZIP format specification or implementation exactly) using the same encoding to provide a consistent way of getting the files as they are correctly displayed/zipped in the compressed file. (without losing any char informations). So the maven-assembly-plugin needs to support any way to decompress zip files with alternative encodings of the source file's zipEntries to be consistent. And yes, those contraints would be ok. Because since umlauts are a typical german language part, I can assume that the target OS system, where those files will be viewed and handled will be CP850 compatible. If I get some zip files with russian chars in the file names of zipEntries I cannot expect that on my german OS system they will be displayed in a correct way, if I don't specify an alternative encoding to handle such files. > problem to extract zip files including file names with umlauts > -- > > Key: MASSEMBLY-748 > URL: https://jira.codehaus.org/browse/MASSEMBLY-748 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: maven-archiver >Affects Versions: 2.5.3 > Environment: >Reporter: Hannes Kogler >Assignee: Kristian Rosenvold > Fix For: 2.5.4 > > Attachments: encoding_problem_on_zip_extract.7z > > > Like in an other issue reported, you need to explicitly set the code page > CP850 to create zip packages hosting file names with correct umlauts their > names. (by using the following configuration) > > CP850 > > After all this solution is not 100% useful, because if you extract this file > with the obiously correct umlauts in the zip, wrong chars for all umlauts > reappear. > It's strange, because if you unzip this zip file with all other zip tools > (7zip, Windows native zip support aso.) the extraction works fine. > Only using the maven-assembly-plugin the umlauts get corrupted. > (a try to set the archiverConfig with the CP850 also for the extracting > execution process of the assembly plugin just results in a bad error calling > Failed to configure a
[jira] (MASSEMBLY-748) problem to extract zip files including file names with umlauts
[ https://jira.codehaus.org/browse/MASSEMBLY-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361696#comment-361696 ] Hannes Kogler edited comment on MASSEMBLY-748 at 1/23/15 5:27 AM: -- Exactly this is what I am complaining. If you configure "archiverConfig" for the same plugin execution you use on extraction of a zip file you just get a plugin Exception (justl ike described in the main description of the issue you get the error: *org.codehaus.plexus.archiver.dir.DirectoryArchiver: Cannot find 'encoding' in class org.codehaus.plexus.archiver.dir.DirectoryArchiver* ) Meaning, the same plugin configuration, with the only difference that one time I use an assembly descriptor that defines to pack the zip file, and one time using an assembly-descriptor to unpack the file, results one time in a well packed zip file an another time on unpacking in a hard plugin error. If I am able to produce a zip file using the with a special encoding like CP850, [ CP850 ] then I assume I can also extract it (however this works, I don't know the ZIP format specification or implementation exactly) using the same encoding to provide a consistent way of getting the files as they are correctly displayed/zipped in the compressed file. (without losing any char informations). So the maven-assembly-plugin needs to support any way to decompress zip files with alternative encodings of the source file's zipEntries to be consistent. And yes, those contraints would be ok. Because since umlauts are a typical german language part, I can assume that the target OS system, where those files will be viewed and handled will be CP850 compatible. If I get some zip files with russian chars in the file names of zipEntries I cannot expect that on my german OS system they will be displayed in a correct way, if I don't specify an alternative encoding to handle such files. was (Author: ntshko): Exactly this is what I am complaining. If you configure "archiverConfig" for the same plugin execution you use on extraction of a zip file you just get a plugin Exception (justl ike described in the main description of the issue you get the error: *org.codehaus.plexus.archiver.dir.DirectoryArchiver: Cannot find 'encoding' in class org.codehaus.plexus.archiver.dir.DirectoryArchiver* ) Meaning, the same plugin configuration, with the only difference that one time I use an assembly descriptor that defines to pack the zip file, and one time using an assembly-descriptor to unpack the file, results one time in a well packed zip file an another time on unpacking in a hard plugin error. If I am able to produce a zip file using the with a special encoding like CP850, then I assume I can also extract it (however this works, I don't know the ZIP format specification or implementation exactly) using the same encoding to provide a consistent way of getting the files as they are correctly displayed/zipped in the compressed file. (without losing any char informations). So the maven-assembly-plugin needs to support any way to decompress zip files with alternative encodings of the source file's zipEntries to be consistent. And yes, those contraints would be ok. Because since umlauts are a typical german language part, I can assume that the target OS system, where those files will be viewed and handled will be CP850 compatible. If I get some zip files with russian chars in the file names of zipEntries I cannot expect that on my german OS system they will be displayed in a correct way, if I don't specify an alternative encoding to handle such files. > problem to extract zip files including file names with umlauts > -- > > Key: MASSEMBLY-748 > URL: https://jira.codehaus.org/browse/MASSEMBLY-748 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: maven-archiver >Affects Versions: 2.5.3 > Environment: >Reporter: Hannes Kogler >Assignee: Kristian Rosenvold > Fix For: 2.5.4 > > Attachments: encoding_problem_on_zip_extract.7z > > > Like in an other issue reported, you need to explicitly set the code page > CP850 to create zip packages hosting file names with correct umlauts their > names. (by using the following configuration) > > CP850 > > After all this solution is not 100% useful, because if you extract this file > with the obiously correct umlauts in the zip, wrong chars for all umlauts > reappear. > It's strange, because if you unzip this zip file with all other zip tools > (7zip, Windows native zip support aso.) the extraction works fine. > Only using the maven-assembly-plugin the umlauts get corrupted. > (a try to set the archiverConfig with the CP850 also for the extracting > execution process of the assembly plugin jus
[jira] (MASSEMBLY-748) problem to extract zip files including file names with umlauts
[ https://jira.codehaus.org/browse/MASSEMBLY-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361698#comment-361698 ] Hannes Kogler commented on MASSEMBLY-748: - Sounds great! After all thanks for the patience ;-) > problem to extract zip files including file names with umlauts > -- > > Key: MASSEMBLY-748 > URL: https://jira.codehaus.org/browse/MASSEMBLY-748 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: maven-archiver >Affects Versions: 2.5.3 > Environment: >Reporter: Hannes Kogler >Assignee: Kristian Rosenvold > Fix For: 2.5.4 > > Attachments: encoding_problem_on_zip_extract.7z > > > Like in an other issue reported, you need to explicitly set the code page > CP850 to create zip packages hosting file names with correct umlauts their > names. (by using the following configuration) > > CP850 > > After all this solution is not 100% useful, because if you extract this file > with the obiously correct umlauts in the zip, wrong chars for all umlauts > reappear. > It's strange, because if you unzip this zip file with all other zip tools > (7zip, Windows native zip support aso.) the extraction works fine. > Only using the maven-assembly-plugin the umlauts get corrupted. > (a try to set the archiverConfig with the CP850 also for the extracting > execution process of the assembly plugin just results in a bad error calling > Failed to configure archiver: > " org.codehaus.plexus.archiver.dir.DirectoryArchiver: Cannot find 'encoding' > in class org.codehaus.plexus.archiver.dir.DirectoryArchiver " ) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] [Commented] (MASSEMBLY-748) problem to extract zip files including file names with umlauts
[ https://issues.apache.org/jira/browse/MASSEMBLY-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14547785#comment-14547785 ] Hannes Kogler commented on MASSEMBLY-748: - Hello again! Can you please give an example where and how to configure this fix? The new "encoding" parameter should be available within the unpackOptions tag in the assembley descriptor? or in the maven-assembly-plugin configuration when extracting it? > problem to extract zip files including file names with umlauts > -- > > Key: MASSEMBLY-748 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-748 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: maven-archiver >Affects Versions: 2.5.3 > Environment: >Reporter: Hannes Kogler >Assignee: Kristian Rosenvold > Fix For: 2.5.4 > > Attachments: encoding_problem_on_zip_extract.7z > > > Like in an other issue reported, you need to explicitly set the code page > CP850 to create zip packages hosting file names with correct umlauts their > names. (by using the following configuration) > > CP850 > > After all this solution is not 100% useful, because if you extract this file > with the obiously correct umlauts in the zip, wrong chars for all umlauts > reappear. > It's strange, because if you unzip this zip file with all other zip tools > (7zip, Windows native zip support aso.) the extraction works fine. > Only using the maven-assembly-plugin the umlauts get corrupted. > (a try to set the archiverConfig with the CP850 also for the extracting > execution process of the assembly plugin just results in a bad error calling > Failed to configure archiver: > " org.codehaus.plexus.archiver.dir.DirectoryArchiver: Cannot find 'encoding' > in class org.codehaus.plexus.archiver.dir.DirectoryArchiver " ) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] (MPIR-251) Artifact ###### has no file error regression.
[
https://jira.codehaus.org/browse/MPIR-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317930#comment-317930
]
Hannes Kogler commented on MPIR-251:
I got the same error messages too. (Maven version 3.0.4; Plugin versions:
maven-site-plugin3.2 & maven-project-info-reports-plugin 2.6)
Hoping that there is anybody who creates a bugfix for it!
A suitable workaround if waiting for a bugfix is not a eal option, just try to
config the maven-project-info-reports-plugin with less message details:
...
org.apache.maven.plugins
maven-project-info-reports-plugin
2.6
false
false
...
it works for me!
> Artifact ## has no file error regression.
> -
>
> Key: MPIR-251
> URL: https://jira.codehaus.org/browse/MPIR-251
> Project: Maven 2.x Project Info Reports Plugin
> Issue Type: Bug
> Components: dependencies
>Affects Versions: 2.5
>Reporter: Ian Brandt
>Priority: Minor
> Attachments: pom.xml
>
>
> It appears that MPIR-158 has regressed. I'm seeing the same exact issue in
> 2.5 with Maven 3.0.4:
> {noformat}
> [INFO] Generating "Dependencies" report---
> maven-project-info-reports-plugin:2.5
> [ERROR] Artifact: com.sun:tools:jar:1.5.0 has no file.
> [ERROR] Artifact: com.thoughtworks.xstream:xstream:jar:1.3 has no file.
> [ERROR] Artifact: commons-beanutils:commons-beanutils:jar:1.8.0 has no file.
> [ERROR] Artifact: commons-cli:commons-cli:jar:1.1 has no file.
> [ERROR] Artifact: commons-codec:commons-codec:jar:1.3 has no file.
> [ERROR] Artifact: commons-collections:commons-collections:jar:3.2.1 has no
> file.
> [ERROR] Artifact: commons-digester:commons-digester:jar:2.0 has no file.
> [ERROR] Artifact: commons-fileupload:commons-fileupload:jar:1.2.2 has no file.
> ...{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPIR-251) Artifact ###### has no file error regression.
[
https://jira.codehaus.org/browse/MPIR-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317930#comment-317930
]
Hannes Kogler edited comment on MPIR-251 at 1/24/13 5:52 AM:
-
I got the same error messages too. (Maven version 3.0.4; Plugin versions:
maven-site-plugin3.2 & maven-project-info-reports-plugin 2.6)
Hoping that there is anybody who creates a bugfix for it!
A suitable workaround if waiting for a bugfix is not a eal option, just try to
config the maven-project-info-reports-plugin with less message details:
{code:title=Bar.java|borderStyle=solid}
...
org.apache.maven.plugins
maven-project-info-reports-plugin
2.6
false
false
...
{code}
it works for me!
was (Author: ntshko):
I got the same error messages too. (Maven version 3.0.4; Plugin versions:
maven-site-plugin3.2 & maven-project-info-reports-plugin 2.6)
Hoping that there is anybody who creates a bugfix for it!
A suitable workaround if waiting for a bugfix is not a eal option, just try to
config the maven-project-info-reports-plugin with less message details:
...
org.apache.maven.plugins
maven-project-info-reports-plugin
2.6
false
false
...
it works for me!
> Artifact ## has no file error regression.
> -
>
> Key: MPIR-251
> URL: https://jira.codehaus.org/browse/MPIR-251
> Project: Maven 2.x Project Info Reports Plugin
> Issue Type: Bug
> Components: dependencies
>Affects Versions: 2.5
>Reporter: Ian Brandt
>Priority: Minor
> Attachments: pom.xml
>
>
> It appears that MPIR-158 has regressed. I'm seeing the same exact issue in
> 2.5 with Maven 3.0.4:
> {noformat}
> [INFO] Generating "Dependencies" report---
> maven-project-info-reports-plugin:2.5
> [ERROR] Artifact: com.sun:tools:jar:1.5.0 has no file.
> [ERROR] Artifact: com.thoughtworks.xstream:xstream:jar:1.3 has no file.
> [ERROR] Artifact: commons-beanutils:commons-beanutils:jar:1.8.0 has no file.
> [ERROR] Artifact: commons-cli:commons-cli:jar:1.1 has no file.
> [ERROR] Artifact: commons-codec:commons-codec:jar:1.3 has no file.
> [ERROR] Artifact: commons-collections:commons-collections:jar:3.2.1 has no
> file.
> [ERROR] Artifact: commons-digester:commons-digester:jar:2.0 has no file.
> [ERROR] Artifact: commons-fileupload:commons-fileupload:jar:1.2.2 has no file.
> ...{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-229) release:rollback is missing remove tag implementation
[ https://jira.codehaus.org/browse/MRELEASE-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=323057#comment-323057 ] Hannes Kogler commented on MRELEASE-229: would be great if it was possible for CVS and/or GIT > release:rollback is missing remove tag implementation > - > > Key: MRELEASE-229 > URL: https://jira.codehaus.org/browse/MRELEASE-229 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: rollback >Affects Versions: 2.0-beta-5 >Reporter: Mark Hobson > > The remove-scm-tag phase of release:rollback is currently unimplemented - see > the TODO in RemoveScmTagPhase. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5418) Can't activate a profile by checking for the presence of a file in ${myProperty}
[
https://jira.codehaus.org/browse/MNG-5418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335685#comment-335685
]
Hannes Kogler commented on MNG-5418:
Hi!
I'm using the new Maven version 3.1.1 now but this doesn't work in this version
too.
Its a fact that until now I have never seen a Maven version that really
supports this feature?! (although every maven book describes it :-( )
> Can't activate a profile by checking for the presence of a file in
> ${myProperty}
>
>
> Key: MNG-5418
> URL: https://jira.codehaus.org/browse/MNG-5418
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 3.0.4
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
> Fix For: 3.1.0-alpha-1
>
>
> The following won't activate: {{${myProperty\}}}
> myProperty is a current project property.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-2802) Concurrent-safe access to local Maven repository
[ https://jira.codehaus.org/browse/MNG-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=336775#comment-336775 ] Hannes Kogler commented on MNG-2802: this is really very time consuming and makes Maven unusable for productive build environments after all. Is it fixed in Maven 3.1.1? > Concurrent-safe access to local Maven repository > > > Key: MNG-2802 > URL: https://jira.codehaus.org/browse/MNG-2802 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Stepan Roh >Assignee: John Casey > Fix For: Issues to be reviewed for 3.x > > > It seems that access to local Maven repository is not concurrent-safe that is > multiple Mavens running in parallel may damage contents of local Maven > repository. It would be a nice improvement, because sharing of local > repository will lower the need for contacting any other repository. I know > that Maven proxy can be used, but that adds another layer which may > unnecessarily stress the machine it runs on. -- 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
