[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=361685#comment-361685 ] Kristian Rosenvold commented on MASSEMBLY-748: -- I just created a testcase in plexus-archiver that verifies what I say: If you leave encoding unspecified it will create a well-formed utf-8 archive which will unpack perfectly with maven/plexus-archiver. I may be a bit slow, but I'm having some problems understanding exactly which combination you are having troubles with. Please be specific; this area is a mine-field of legacy issues. > 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 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] (MNGSITE-222) Incorrect statement regarding profiles activated with -P
[
https://jira.codehaus.org/browse/MNGSITE-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361689#comment-361689
]
Michael Osipov commented on MNGSITE-222:
Yes, you recommendation is better. It makes the stuff quite clear. I will apply
the change in the next couple of days.
> Incorrect statement regarding profiles activated with -P
>
>
> Key: MNGSITE-222
> URL: https://jira.codehaus.org/browse/MNGSITE-222
> Project: Maven Project Web Site
> Issue Type: Bug
> Environment:
> http://maven.apache.org/guides/introduction/introduction-to-profiles.html
>Reporter: SebbASF
>
> Website as above says:
> {quote}
> Profiles can be explicitly specified using the -P CLI option.
> This option takes an argument that is a comma-delimited list of profile-ids
> to use. When this option is specified, no profiles other than those specified
> in the option argument will be activated.
> {quote}
> The last sentence above is not true.
> As proof, try the following:
> {code}
> mvn -f help:active-profiles -Papache-release
> {code}
> The output is
> {code}
> Active Profiles for Project 'org.apache:apache:pom:16':
> The following profiles are active:
> - apache-release (source: org.apache:apache:16)
> - maven-3 (source: org.apache:apache:16)
> {code}
--
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] (MNGSITE-222) Incorrect statement regarding profiles activated with -P
[
https://jira.codehaus.org/browse/MNGSITE-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MNGSITE-222:
--
Assignee: Michael Osipov
> Incorrect statement regarding profiles activated with -P
>
>
> Key: MNGSITE-222
> URL: https://jira.codehaus.org/browse/MNGSITE-222
> Project: Maven Project Web Site
> Issue Type: Bug
> Environment:
> http://maven.apache.org/guides/introduction/introduction-to-profiles.html
>Reporter: SebbASF
>Assignee: Michael Osipov
>
> Website as above says:
> {quote}
> Profiles can be explicitly specified using the -P CLI option.
> This option takes an argument that is a comma-delimited list of profile-ids
> to use. When this option is specified, no profiles other than those specified
> in the option argument will be activated.
> {quote}
> The last sentence above is not true.
> As proof, try the following:
> {code}
> mvn -f help:active-profiles -Papache-release
> {code}
> The output is
> {code}
> Active Profiles for Project 'org.apache:apache:pom:16':
> The following profiles are active:
> - apache-release (source: org.apache:apache:16)
> - maven-3 (source: org.apache:apache:16)
> {code}
--
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 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=361693#comment-361693 ] Kristian Rosenvold commented on MASSEMBLY-748: -- It seems to me like you are really complaining that "archiverConfig" does not work for extracting from a zip ? If you choose the "encoding" strategy you describe. You will create a zip file that will produce umlauts in windows file explorer. The zip file will not create proper umlauts on MacOs or Linux, and I will not guarantee that all windows zip archivers will work either. But the standard explorer in windows will do the right thing, unless of course *I* extract the file on *my* machine since I don't have CP850 default character set since I am in Norway. So no umlauts for me. But I assume you're fine with all these constraints > 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 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=361697#comment-361697 ] Kristian Rosenvold commented on MASSEMBLY-748: -- Ok thanks, now I understand, and I see the problem in the code. I'll see if I can get this fixed for 2.5.4 > 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: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] (MSHARED-408) EmbeddedMavenModelExposer ignores parent values in pom
[
https://jira.codehaus.org/browse/MSHARED-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Markus Bollerey updated MSHARED-408:
Description:
Many Maven archives define a parent in their pom and leave values of groupId
and/or version to parent. Consequently they then do not define explicit values
for groupId and/or version again.
Because this exposer implementation does not read parent values, it often finds
no groupId and/or version where in Maven terms is one defined (in the parent).
Solution:
Just add the following six lines of code ('NEW') to the existing four lines
('OLD') adding values to the instance. Don't remove any of the
existing code, just insert the new ones before as shown:
NEW1: // read parent values first
NEW2: if (model.getParent() != null) {
NEW3:
NEW4: identification.addAndSetGroupId(model.getParent().getGroupId());
NEW5: identification.addAndSetVersion(model.getParent().getVersion());
NEW6: }
OLD1: identification.addAndSetGroupId(model.getGroupId());
OLD2: identification.addAndSetArtifactId(model.getArtifactId());
OLD3: identification.addAndSetVersion(model.getVersion());
OLD4: identification.addAndSetName(model.getName());
was:
Many Maven archives define a parent in their pom and leave values of groupId
and/or version to parent. Consequently they then do not define explicit values
for groupId and/or version again.
Because this exposer implementation does not read parent values, it often finds
no groupId and/or version where in Maven terms is one defined (in the parent).
Solution:
Just add the following two lines of code ('NEW') to the existing four lines
('OLD') adding values to the instance. Don't remove any of the
existing code, just insert the new ones before as shown:
NEW: // read parent values first
NEW: identification.addAndSetGroupId(model.getParent().getGroupId());
NEW: identification.addAndSetVersion(model.getParent().getVersion());
OLD: identification.addAndSetGroupId(model.getGroupId());
OLD: identification.addAndSetArtifactId(model.getArtifactId());
OLD: identification.addAndSetVersion(model.getVersion());
OLD: identification.addAndSetName(model.getName());
> EmbeddedMavenModelExposer ignores parent values in pom
> --
>
> Key: MSHARED-408
> URL: https://jira.codehaus.org/browse/MSHARED-408
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-shared-jar
>Affects Versions: maven-shared-jar-1.1
> Environment: not depending on environment
>Reporter: Markus Bollerey
>Priority: Minor
>
> Many Maven archives define a parent in their pom and leave values of groupId
> and/or version to parent. Consequently they then do not define explicit
> values for groupId and/or version again.
> Because this exposer implementation does not read parent values, it often
> finds no groupId and/or version where in Maven terms is one defined (in the
> parent).
> Solution:
> Just add the following six lines of code ('NEW') to the existing four lines
> ('OLD') adding values to the instance. Don't remove any of
> the existing code, just insert the new ones before as shown:
> NEW1: // read parent values first
> NEW2: if (model.getParent() != null) {
> NEW3:
> NEW4: identification.addAndSetGroupId(model.getParent().getGroupId());
> NEW5: identification.addAndSetVersion(model.getParent().getVersion());
> NEW6: }
> OLD1: identification.addAndSetGroupId(model.getGroupId());
> OLD2: identification.addAndSetArtifactId(model.getArtifactId());
> OLD3: identification.addAndSetVersion(model.getVersion());
> OLD4: identification.addAndSetName(model.getName());
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHANGES-352) Plugin should report when not all issues are returned
SebbASF created MCHANGES-352:
Summary: Plugin should report when not all issues are returned
Key: MCHANGES-352
URL: https://jira.codehaus.org/browse/MCHANGES-352
Project: Maven Changes Plugin
Issue Type: Bug
Reporter: SebbASF
The plugin should provide some kind of report when not all requested issues
have been returned.
This information is available in the response, for example (from -X output):
Payload: {"expand":"schema,names","startAt":0,"maxResults":100,"total":141,
If total is greater than maxResults, then some issues have been dropped.
This could be reported as a Maven warning and/or added to the report itself.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHANGES-352) Plugin should report when not all issues are returned
[
https://jira.codehaus.org/browse/MCHANGES-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361711#comment-361711
]
Michael Osipov commented on MCHANGES-352:
-
This is some duplicate of MCHANGES-351 for me whch in turn is a dup of another
issue.
> Plugin should report when not all issues are returned
> --
>
> Key: MCHANGES-352
> URL: https://jira.codehaus.org/browse/MCHANGES-352
> Project: Maven Changes Plugin
> Issue Type: Bug
>Reporter: SebbASF
>
> The plugin should provide some kind of report when not all requested issues
> have been returned.
> This information is available in the response, for example (from -X output):
> Payload: {"expand":"schema,names","startAt":0,"maxResults":100,"total":141,
> If total is greater than maxResults, then some issues have been dropped.
> This could be reported as a Maven warning and/or added to the report itself.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHANGES-352) Plugin should report when not all issues are returned
[
https://jira.codehaus.org/browse/MCHANGES-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361712#comment-361712
]
SebbASF commented on MCHANGES-352:
--
I think this is different.
Even if paging is enabled, it seems to me that the API may return fewer results
than requested.
> Plugin should report when not all issues are returned
> --
>
> Key: MCHANGES-352
> URL: https://jira.codehaus.org/browse/MCHANGES-352
> Project: Maven Changes Plugin
> Issue Type: Bug
>Reporter: SebbASF
>
> The plugin should provide some kind of report when not all requested issues
> have been returned.
> This information is available in the response, for example (from -X output):
> Payload: {"expand":"schema,names","startAt":0,"maxResults":100,"total":141,
> If total is greater than maxResults, then some issues have been dropped.
> This could be reported as a Maven warning and/or added to the report itself.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHANGES-351) No paging when maxEntries is reached
[
https://jira.codehaus.org/browse/MCHANGES-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361713#comment-361713
]
SebbASF commented on MCHANGES-351:
--
There are two aspects to this:
* output pagination support so output pages don't become too large
* retrieval pagination so the plugin is able to retrieve more than the API
limit (this issue)
These should be treated as independent; it may well be that the JIRA instance
has a lower maxEntries setting than would fit reasonably on an web page.
> No paging when maxEntries is reached
>
>
> Key: MCHANGES-351
> URL: https://jira.codehaus.org/browse/MCHANGES-351
> Project: Maven Changes Plugin
> Issue Type: Wish
> Components: jira
>Affects Versions: 2.11
> Environment: Maven 3.2.5; Java 1.7.0_72 x64 on win7, german
>Reporter: Bernd Eckenfels
>
> I try to generate a JIRA changes report for apache commons VFS. If I set the
> maxEntries to 600 it wont work. It looks like the Apache Instance only allows
> to search for 100 entries (JIRA On Demand seems to be limited to 1000). In my
> case there are 141 bugs in the current fixversion and the query finds 295).
> According to the JIRA docu you can query with different offsets, so would it
> be possible to query startAt=0-99,100-199,... and so on?
> Here is the request and the response:
> {code}
> Address: https://issues.apache.org/jira/rest/api/2/search
> Http-Method: POST
> Content-Type: application/json
> Headers: {Accept=[application/json], Content-Type=[application/json],
> Payload: {"jql":"project = VFS AND status in (5, 6) AND resolution in
> (1) AND type in (1, 2, 3, 4, 5, 6) ORDER BY fixversion DESC, type ASC,
> key DESC","maxResults":600,"fields":["*all"]...
> Response-Code: 200
> Encoding: UTF-8
> Content-Type: application/json;charset=UTF-8
> Headers: \{Cache-Control=[no-cache, no-store, no-transform],
> connection=[Keep-Alive], content-type=[application/json;charset=UTF-8],
> Date=[Mon, 19 Jan 2015 01:50:37 GMT], Keep-Alive=[timeout=5, max=96],
> Server=[Apache-Coyote/1.1],
> Set-Cookie=[JSESSIONID=4871902251E72BC474B2D32941521F9A; Path=/jira/; Secure;
> HttpOnly], transfer-encoding=[chunked], X-AREQUESTID=[110x29767730x2],
> X-ASEN=[SEN-2062203], X-AUSERNAME=[anonymous],
> X-Content-Type-Options=[nosniff]}
> Messages:
> Message (saved to tmp file):
> Filename:
> C:\Users\eckenfel\AppData\Local\Temp\cxf-tmp-435678\cos4903552076318255093tmp
> (message truncated to 102400 bytes)
> Payload:
> {"expand":"schema,names","startAt":0,"maxResults":100,"total":295, ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRELEASE-868) Allow passing in SSH key via parameter for Git releases
[ https://jira.codehaus.org/browse/MRELEASE-868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361714#comment-361714 ] Justin Georgeson commented on MRELEASE-868: --- I'm thinking it's deeper than that, in Git itself. Git doesn't have an option to specify your private key. It relies on SSH knowing what key to use. The standard practice is to write an ssh wrapper script that allows specifying the key via env variable, and then using GIT_SSH env variable to have Git run that wrapper script instead of running SSH directly. This appears to be how the Jenkins Git Plugin works in tandem with the SSH Credentials plugin to support putting a private key as a Jenkins credential and doing Jenkins using that credential to do the Git clone. So the M2 Release plugin would have to do this # Support username/password and SSH key Credentials instead of text fields for username/password # When Credentials are SSH key store in Jenkins write the key to a private temp file # When SCM is Git write a private temp shell/batch script file to run ssh -i _file/from/step2_ and set GIT_SSH env var # Execute release workflow # Delete files from steps 2 and 3 > Allow passing in SSH key via parameter for Git releases > --- > > Key: MRELEASE-868 > URL: https://jira.codehaus.org/browse/MRELEASE-868 > Project: Maven Release Plugin > Issue Type: Improvement >Affects Versions: 2.4.2 >Reporter: Konrad Windszus > > When triggering a release from a shared server (e.g. a globally shared > jenkins), it is useful to let the release manager use his own credentials for > the release. The release plugin from > https://wiki.jenkins-ci.org/display/JENKINS/M2+Release+Plugin supports that > for username, password authentication. In case of SSH authentication I cannot > inject anything, because the maven-release-plugin does not provide that > option. It would be great if you could allow to pass in an arbitrary SSH key > (together with a passphrase) to be used during the release. > That should work with jGit and Native Git. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-742) Unclosed ZipFile warnings when ZIP archives are included
[
https://jira.codehaus.org/browse/MASSEMBLY-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361715#comment-361715
]
Dawid Weiss commented on MASSEMBLY-742:
---
Unfortunately plexus-archiver doesn't even compile at the latest commit on 2.x
branch (867eee8e47ee29799):
{code}
[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR]
c:\Work\maven\plexus-archiver\src\main\java\org\codehaus\plexus\archiver\zip\ConcurrentJarCreator.java:[31,55]
error: cannot find symbol
[ERROR] symbol: class ZipArchiveEntryRequest
location: package org.apache.commons.compress.archivers.zip
c:\Work\maven\plexus-archiver\src\main\java\org\codehaus\plexus\archiver\zip\ConcurrentJarCreator.java:[31,0]
error: static import only from classes and interfaces
[ERROR]
c:\Work\maven\plexus-archiver\src\main\java\org\codehaus\plexus\archiver\zip\ConcurrentJarCreator.java:[60,36]
error: no suitable constructor found for
ParallelScatterZipCreator(ExecutorService,ScatterGatherBackingStoreSupplier)
[ERROR] constructor
ParallelScatterZipCreator.ParallelScatterZipCreator(int,ScatterGatherBackingStoreSupplier)
is not applicable
(actual argument ExecutorService cannot be converted to int by method
invocation conversion)
constructor ParallelScatterZipCreator.ParallelScatterZipCreator(int) is not
applicable
(actual and formal argument lists differ in length)
constructor ParallelScatterZipCreator.ParallelScatterZipCreator() is not
applicable
(actual and formal argument lists differ in length)
c:\Work\maven\plexus-archiver\src\main\java\org\codehaus\plexus\archiver\zip\ConcurrentJarCreator.java:[78,40]
error: cannot find symbol
[ERROR] symbol: method
createZipArchiveEntryRequest(ZipArchiveEntry,InputStreamSupplier)
location: class ConcurrentJarCreator
c:\Work\maven\plexus-archiver\src\main\java\org\codehaus\plexus\archiver\zip\ConcurrentJarCreator.java:[83,37]
error: cannot find symbol
{code}
How come it worked for you?
> Unclosed ZipFile warnings when ZIP archives are included
>
>
> Key: MASSEMBLY-742
> URL: https://jira.codehaus.org/browse/MASSEMBLY-742
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 2.5.2
>Reporter: Dawid Weiss
>Assignee: Kristian Rosenvold
>Priority: Minor
> Fix For: 2.5.3, 2.5.4
>
> Attachments: example.zip
>
>
> I get the following warnings at the end of Maven build:
> {code}
> Cleaning up unclosed ZipFile for archive C:\...foo-0.2.0-SNAPSHOT.zip
> {code}
> These warnings originate from assembly plugin, but in fact they're caused by
> the fact that plexus resource abstraction opens up a ZipFile from
> commons-compress, but never closes it. Commons-compress then force-closes all
> such objects in finalize, emitting a warning.
> I created a synthetic capture of the allocation stack in maven assembly, it's
> here:
> {code}
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:211)
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:193)
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:154)
> org.codehaus.plexus.archiver.zip.PlexusIoZipFileResourceCollection.getEntries(PlexusIoZipFileResourceCollection.java:29)
> org.codehaus.plexus.components.io.resources.AbstractPlexusIoArchiveResourceCollection.getResources(AbstractPlexusIoArchiveResourceCollection.java:69)
> org.codehaus.plexus.components.io.resources.proxy.PlexusIoProxyResourceCollection.getResources(PlexusIoProxyResourceCollection.java:111)
> org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:493)
> org.codehaus.plexus.archiver.dir.DirectoryArchiver.execute(DirectoryArchiver.java:71)
> org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:940)
> org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:541)
> org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:180)
> org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:486)
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(Li
[jira] (MASSEMBLY-742) Unclosed ZipFile warnings when ZIP archives are included
[
https://jira.codehaus.org/browse/MASSEMBLY-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361716#comment-361716
]
Dawid Weiss commented on MASSEMBLY-742:
---
I figured it out -- it's my local stale dependency on commons-compress.
> Unclosed ZipFile warnings when ZIP archives are included
>
>
> Key: MASSEMBLY-742
> URL: https://jira.codehaus.org/browse/MASSEMBLY-742
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 2.5.2
>Reporter: Dawid Weiss
>Assignee: Kristian Rosenvold
>Priority: Minor
> Fix For: 2.5.3, 2.5.4
>
> Attachments: example.zip
>
>
> I get the following warnings at the end of Maven build:
> {code}
> Cleaning up unclosed ZipFile for archive C:\...foo-0.2.0-SNAPSHOT.zip
> {code}
> These warnings originate from assembly plugin, but in fact they're caused by
> the fact that plexus resource abstraction opens up a ZipFile from
> commons-compress, but never closes it. Commons-compress then force-closes all
> such objects in finalize, emitting a warning.
> I created a synthetic capture of the allocation stack in maven assembly, it's
> here:
> {code}
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:211)
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:193)
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:154)
> org.codehaus.plexus.archiver.zip.PlexusIoZipFileResourceCollection.getEntries(PlexusIoZipFileResourceCollection.java:29)
> org.codehaus.plexus.components.io.resources.AbstractPlexusIoArchiveResourceCollection.getResources(AbstractPlexusIoArchiveResourceCollection.java:69)
> org.codehaus.plexus.components.io.resources.proxy.PlexusIoProxyResourceCollection.getResources(PlexusIoProxyResourceCollection.java:111)
> org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:493)
> org.codehaus.plexus.archiver.dir.DirectoryArchiver.execute(DirectoryArchiver.java:71)
> org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:940)
> org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:541)
> org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:180)
> org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:486)
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
> org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
> org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> java.lang.reflect.Method.invoke(Method.java:483)
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {code}
> Hope this helps, somehow.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-742) Unclosed ZipFile warnings when ZIP archives are included
[
https://jira.codehaus.org/browse/MASSEMBLY-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361718#comment-361718
]
Dawid Weiss commented on MASSEMBLY-742:
---
The problem persists. I dug a bit deeper -- there are so many levels of
indirection and iterator wrappers that it's quite difficult for me to wrap my
head around it, but walking in debug mode the problem is here, in this loop:
{code}
https://github.com/sonatype/plexus-archiver/blob/2.x/src/main/java/org/codehaus/plexus/archiver/AbstractArchiver.java#L519
{code}
When ioResourceIter's entries are consumed and later returned, its underlying
iterator (closeable) is never actually closed and the returned ResourceIterator
is not Closeable at all (so it never will propagate the call). I tried closing
those ioResourceIter's here:
{code}
if ( ioResourceIter.hasNext() )
{
final PlexusIoResource resource =
(PlexusIoResource) ioResourceIter.next();
nextEntry = asArchiveEntry(
currentResourceCollection, resource );
}
else
{
// CLOSE ioResourceIter if closeable
ioResourceIter = null;
}
{code}
but this of course won't fly because you're effectively returning pointers to
Zip entries of a closed file, which will result in exceptions later on.
I think this ResourceIterator should be closeable and it should close any
iterators which entries it returns.
> Unclosed ZipFile warnings when ZIP archives are included
>
>
> Key: MASSEMBLY-742
> URL: https://jira.codehaus.org/browse/MASSEMBLY-742
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 2.5.2
>Reporter: Dawid Weiss
>Assignee: Kristian Rosenvold
>Priority: Minor
> Fix For: 2.5.3, 2.5.4
>
> Attachments: example.zip
>
>
> I get the following warnings at the end of Maven build:
> {code}
> Cleaning up unclosed ZipFile for archive C:\...foo-0.2.0-SNAPSHOT.zip
> {code}
> These warnings originate from assembly plugin, but in fact they're caused by
> the fact that plexus resource abstraction opens up a ZipFile from
> commons-compress, but never closes it. Commons-compress then force-closes all
> such objects in finalize, emitting a warning.
> I created a synthetic capture of the allocation stack in maven assembly, it's
> here:
> {code}
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:211)
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:193)
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:154)
> org.codehaus.plexus.archiver.zip.PlexusIoZipFileResourceCollection.getEntries(PlexusIoZipFileResourceCollection.java:29)
> org.codehaus.plexus.components.io.resources.AbstractPlexusIoArchiveResourceCollection.getResources(AbstractPlexusIoArchiveResourceCollection.java:69)
> org.codehaus.plexus.components.io.resources.proxy.PlexusIoProxyResourceCollection.getResources(PlexusIoProxyResourceCollection.java:111)
> org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:493)
> org.codehaus.plexus.archiver.dir.DirectoryArchiver.execute(DirectoryArchiver.java:71)
> org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:940)
> org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:541)
> org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:180)
> org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:486)
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
> org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
> org.apache.maven.cli.MavenCli.doM
[jira] (MASSEMBLY-742) Unclosed ZipFile warnings when ZIP archives are included
[
https://jira.codehaus.org/browse/MASSEMBLY-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361720#comment-361720
]
Dawid Weiss commented on MASSEMBLY-742:
---
I attach my feeble attempt to fix it. It's not working and is not complete --
these resources are floating around even with the underlying iterator exhausted
so it cannot be eagerly closed (because this closes the resources too).
I don't have enough knowledge to fix it properly, unfortunately, but it looks
like a more serious flaw to me than just the warning -- these open resources/
files are never closed until GC-ed which can result in odd failures (locked
files, etc.) at random times.
> Unclosed ZipFile warnings when ZIP archives are included
>
>
> Key: MASSEMBLY-742
> URL: https://jira.codehaus.org/browse/MASSEMBLY-742
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 2.5.2
>Reporter: Dawid Weiss
>Assignee: Kristian Rosenvold
>Priority: Minor
> Fix For: 2.5.3, 2.5.4
>
> Attachments: example.zip
>
>
> I get the following warnings at the end of Maven build:
> {code}
> Cleaning up unclosed ZipFile for archive C:\...foo-0.2.0-SNAPSHOT.zip
> {code}
> These warnings originate from assembly plugin, but in fact they're caused by
> the fact that plexus resource abstraction opens up a ZipFile from
> commons-compress, but never closes it. Commons-compress then force-closes all
> such objects in finalize, emitting a warning.
> I created a synthetic capture of the allocation stack in maven assembly, it's
> here:
> {code}
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:211)
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:193)
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:154)
> org.codehaus.plexus.archiver.zip.PlexusIoZipFileResourceCollection.getEntries(PlexusIoZipFileResourceCollection.java:29)
> org.codehaus.plexus.components.io.resources.AbstractPlexusIoArchiveResourceCollection.getResources(AbstractPlexusIoArchiveResourceCollection.java:69)
> org.codehaus.plexus.components.io.resources.proxy.PlexusIoProxyResourceCollection.getResources(PlexusIoProxyResourceCollection.java:111)
> org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:493)
> org.codehaus.plexus.archiver.dir.DirectoryArchiver.execute(DirectoryArchiver.java:71)
> org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:940)
> org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:541)
> org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:180)
> org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:486)
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
> org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
> org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> java.lang.reflect.Method.invoke(Method.java:483)
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {code}
> Hope this helps, somehow.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
