[jira] [Created] (MNG-6093) create a slf4j-simple provider extension that supports level color rendering
Hervé Boutemy created MNG-6093: -- Summary: create a slf4j-simple provider extension that supports level color rendering Key: MNG-6093 URL: https://issues.apache.org/jira/browse/MNG-6093 Project: Maven Issue Type: New Feature Components: Logging Reporter: Hervé Boutemy With color support, core Maven and plugins do general message colorization (or more high-level "message styling" through maven-shared-utils) slf4j provider however has to add color: - for log level output (DEBUG/INFO/WARNING/ERROR) - for stacktrace rendering That's why we use Gossip slf4j provider: it has sufficient little extension points to add this (see http://maven.apache.org/ref/3-LATEST/maven-embedder/apidocs/org/apache/maven/cli/logging/impl/gossip/package-summary.html ) The issue with switching to Gossip slf4j provider is that people don't know it and it does not have the same features as slf4j-simple, the configuration file is not the same (name nor content). But the extension points are not that big: if slf4j-simple provider just made a few methods protected instread of private, it would be extensible What if we just copy slf4j-simple to change the signatures and create small extension classes? The license permits it, we can try it and eventually see with slf4j if the modification can go into official release -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1230) Issue with config parameter 'redirectTestOutputToFile' when running cucumber parallel tests
[ https://issues.apache.org/jira/browse/SUREFIRE-1230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15512114#comment-15512114 ] James Taylor commented on SUREFIRE-1230: I'm seeing this issue and I'm not using Cucumber. > Issue with config parameter 'redirectTestOutputToFile' when running cucumber > parallel tests > --- > > Key: SUREFIRE-1230 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1230 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.18.1 >Reporter: Manoj Palki >Assignee: Tibor Digana > Attachments: cucumber_java_skeleton.tar.gz > > > The config parameter redirectTestOutputToFile behaves differently based on > how parallelism is configured in the surefire plugin. > If the config is > 2 > false > true > then the output from the tests is directed correctly to 'xxxtest-output.txt' > file. > However, if the config is > 2 > classes > true > then the output from the tests is partially directed to the > 'xxxtest-output.txt file and partially to stdout. > Also the output files have different names in two cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1230) Issue with config parameter 'redirectTestOutputToFile' when running cucumber parallel tests
[ https://issues.apache.org/jira/browse/SUREFIRE-1230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15512100#comment-15512100 ] Manoj Palki commented on SUREFIRE-1230: --- Hi Tibor, When I posted this bug, I was not sure whether it was caused by Surefire or Cucumber. It seems like this is a Cucumber issue. They have fixed it. See https://github.com/cucumber/cucumber-jvm/issues/966 > Issue with config parameter 'redirectTestOutputToFile' when running cucumber > parallel tests > --- > > Key: SUREFIRE-1230 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1230 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.18.1 >Reporter: Manoj Palki >Assignee: Tibor Digana > Attachments: cucumber_java_skeleton.tar.gz > > > The config parameter redirectTestOutputToFile behaves differently based on > how parallelism is configured in the surefire plugin. > If the config is > 2 > false > true > then the output from the tests is directed correctly to 'xxxtest-output.txt' > file. > However, if the config is > 2 > classes > true > then the output from the tests is partially directed to the > 'xxxtest-output.txt file and partially to stdout. > Also the output files have different names in two cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1230) Issue with config parameter 'redirectTestOutputToFile' when running cucumber parallel tests
[ https://issues.apache.org/jira/browse/SUREFIRE-1230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15512059#comment-15512059 ] James Taylor commented on SUREFIRE-1230: Good find, [~tibor17]. Is there a workaround? Would be awesome to get the fix into a point release. > Issue with config parameter 'redirectTestOutputToFile' when running cucumber > parallel tests > --- > > Key: SUREFIRE-1230 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1230 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.18.1 >Reporter: Manoj Palki >Assignee: Tibor Digana > Attachments: cucumber_java_skeleton.tar.gz > > > The config parameter redirectTestOutputToFile behaves differently based on > how parallelism is configured in the surefire plugin. > If the config is > 2 > false > true > then the output from the tests is directed correctly to 'xxxtest-output.txt' > file. > However, if the config is > 2 > classes > true > then the output from the tests is partially directed to the > 'xxxtest-output.txt file and partially to stdout. > Also the output files have different names in two cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1261) surefire hangs of failed tests and keeps lock on surefirebooter on Windows preventing clean
[
https://issues.apache.org/jira/browse/SUREFIRE-1261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15511404#comment-15511404
]
Tibor Digana commented on SUREFIRE-1261:
[~hohwille]
I hope your build now works well after properly configuring the plugin, see [1].
The way to achieve this is to set {{kill}}.
By default the parameter is set to {{testset}} which is maybe not useful for
you but we had to do it in order to guarantee backwards compatibility which was
seen in our ITs.
[1]
http://maven.apache.org/surefire/maven-surefire-plugin/examples/shutdown.html#Shutdown_of_forked_JVM_by_stopping_the_build
> surefire hangs of failed tests and keeps lock on surefirebooter on Windows
> preventing clean
> ---
>
> Key: SUREFIRE-1261
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1261
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.17, 2.19.1
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Maven home: C:\project\software\maven
> Java version: 1.8.0_66, vendor: Oracle Corporation
> Java home: C:\project\software\java\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "dos"
>Reporter: Jörg Hohwiller
>Assignee: Tibor Digana
>
> I have Spring-Tests run with surefire in a plain commandline maven build on
> windows. For whatever reason many tests fail with spring initialization
> exception. If I cancel the build in this case ([ctrl][c]) and then restart a
> clean build maven failes to delete the target directory. Using sysinternal
> tools I traced down that a java.exe process is hanging that locks a JAR
> called surefirebooter located in target. This is IMHO the forked process from
> the maven surefire plugin that was not terminated properly when the maven
> process was cancelled.
> You might need to register a shutdown hook in maven-surefire that properly
> cleans up the forked process. But this is just a brute guess...
> http://stackoverflow.com/questions/17465117/maven-surefirebooter
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (SUREFIRE-1261) surefire hangs of failed tests and keeps lock on surefirebooter on Windows preventing clean
[ https://issues.apache.org/jira/browse/SUREFIRE-1261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana reassigned SUREFIRE-1261: -- Assignee: Tibor Digana > surefire hangs of failed tests and keeps lock on surefirebooter on Windows > preventing clean > --- > > Key: SUREFIRE-1261 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1261 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin, process forking >Affects Versions: 2.17, 2.19.1 > Environment: Apache Maven 3.3.9 > (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00) > Maven home: C:\project\software\maven > Java version: 1.8.0_66, vendor: Oracle Corporation > Java home: C:\project\software\java\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "x86", family: "dos" >Reporter: Jörg Hohwiller >Assignee: Tibor Digana > > I have Spring-Tests run with surefire in a plain commandline maven build on > windows. For whatever reason many tests fail with spring initialization > exception. If I cancel the build in this case ([ctrl][c]) and then restart a > clean build maven failes to delete the target directory. Using sysinternal > tools I traced down that a java.exe process is hanging that locks a JAR > called surefirebooter located in target. This is IMHO the forked process from > the maven surefire plugin that was not terminated properly when the maven > process was cancelled. > You might need to register a shutdown hook in maven-surefire that properly > cleans up the forked process. But this is just a brute guess... > http://stackoverflow.com/questions/17465117/maven-surefirebooter -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MASSEMBLY-829) fileMode on a dependencySet with unpack does not work
[
https://issues.apache.org/jira/browse/MASSEMBLY-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15511290#comment-15511290
]
Guillaume Boué commented on MASSEMBLY-829:
--
I can reproduce the issue with version 2.6 of the plugin, but this is
apparently already fixed in the latest 3.0.0-SNAPSHOT. Running the sample
project with that version of the Assembly Plugin, I have:
{noformat}
$ mvn clean install
...
$ tar -tvf dist/target/assembly-fileMode-dist-1-SNAPSHOT-distribution.tar.gz
-rwxrwxr-x 0/0 34 2016-09-21 23:38 hello-world
{noformat}
which shows the expected 775 permissions.
> fileMode on a dependencySet with unpack does not work
> -
>
> Key: MASSEMBLY-829
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-829
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 2.6
> Environment: linux
>Reporter: Christophe Marchand
>Priority: Blocker
> Attachments: bug-maven-assembly-plugin.tar.gz
>
>
> {code:xml}
>
>
> false
> 775
>
> top.marchand.mvn.bug:assembly-fileMode-shells
>
> true
>
>
> META-INF/**
> META-INF
>
>
> runtime
>
> {code}
> Files from {{top.marchand.mvn.bug:assembly-fileMode-shells}} should be
> runnable by everyone, and they are not.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MASSEMBLY-829) fileMode on a dependencySet with unpack does not work
[
https://issues.apache.org/jira/browse/MASSEMBLY-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15511147#comment-15511147
]
Christophe Marchand commented on MASSEMBLY-829:
---
I've tested both, and in both cases, correct permissions are not set.
> fileMode on a dependencySet with unpack does not work
> -
>
> Key: MASSEMBLY-829
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-829
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 2.6
> Environment: linux
>Reporter: Christophe Marchand
>Priority: Blocker
> Attachments: bug-maven-assembly-plugin.tar.gz
>
>
> {code:xml}
>
>
> false
> 775
>
> top.marchand.mvn.bug:assembly-fileMode-shells
>
> true
>
>
> META-INF/**
> META-INF
>
>
> runtime
>
> {code}
> Files from {{top.marchand.mvn.bug:assembly-fileMode-shells}} should be
> runnable by everyone, and they are not.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MDEP-539) Upgrade maven-shared-components parent to version 30
[ https://issues.apache.org/jira/browse/MDEP-539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MDEP-539. Resolution: Fixed Fix Version/s: 3.0 Done in [r1761797|https://svn.apache.org/r1761797] > Upgrade maven-shared-components parent to version 30 > > > Key: MDEP-539 > URL: https://issues.apache.org/jira/browse/MDEP-539 > Project: Maven Dependency Plugin > Issue Type: Improvement >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MDEP-539) Upgrade maven-shared-components parent to version 30
Karl Heinz Marbaise created MDEP-539: Summary: Upgrade maven-shared-components parent to version 30 Key: MDEP-539 URL: https://issues.apache.org/jira/browse/MDEP-539 Project: Maven Dependency Plugin Issue Type: Improvement Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MASSEMBLY-830) Cannot handle relocated artifacts
Martin Todorov created MASSEMBLY-830:
Summary: Cannot handle relocated artifacts
Key: MASSEMBLY-830
URL: https://issues.apache.org/jira/browse/MASSEMBLY-830
Project: Maven Assembly Plugin
Issue Type: Bug
Components: dependencySet
Affects Versions: 2.6
Environment: $ mvn --version
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T16:41:47+00:00)
Maven home: C:\java\apache\maven-3.3.9
Java version: 1.8.0_92, vendor: Oracle Corporation
Java home: C:\java\jdk1.8.0_92\jre
Default locale: en_GB, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
Reporter: Martin Todorov
Priority: Blocker
When one of the transitive dependencies is relocated, the
{{maven-assembly-plugin}} doesn't follow the relocation and check the POM of
the relocated artifact, but uses the actual POM artifact that declares the
relocation. Since this POM doesn't define a version for the artifact, the build
fails with:
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-assembly-plugin:2.6:single (make-assembly) on
project blah: Execution make-assembly of goal
org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed: For artifact
{com.foo:bar:null:jar}: The version cannot be empty. -> [Help 1]
{code}
As this is a transitive dependency of a third-party library, we have no control
over it and have attempted to define:
* An {{}} for this artifact in the dependency which requires it.
* A direct dependency (as the very first {{}}) to the relocated
artifact (which has a version defined in the {{pom.xml}}).
Unfortunately, neither of these helped.
This is the POM with the relocation:
{code}
http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd " xmlns="
http://maven.apache.org/POM/4.0.0 "
xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance;>
4.0.0
com.foo
bar
b
1.5
{code}
Please, advise!
Many thanks in advance!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MASSEMBLY-829) fileMode on a dependencySet with unpack does not work
[
https://issues.apache.org/jira/browse/MASSEMBLY-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15510546#comment-15510546
]
Guillaume Boué commented on MASSEMBLY-829:
--
>From the documentation
>http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_dependencySet,
> the {{}} parameter should be written as an octal value. Can you try
>with {{0775}} instead?
> fileMode on a dependencySet with unpack does not work
> -
>
> Key: MASSEMBLY-829
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-829
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 2.6
> Environment: linux
>Reporter: Christophe Marchand
>Priority: Blocker
> Attachments: bug-maven-assembly-plugin.tar.gz
>
>
> {code:xml}
>
>
> false
> 775
>
> top.marchand.mvn.bug:assembly-fileMode-shells
>
> true
>
>
> META-INF/**
> META-INF
>
>
> runtime
>
> {code}
> Files from {{top.marchand.mvn.bug:assembly-fileMode-shells}} should be
> runnable by everyone, and they are not.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MCOMPILER-278) Incremental build does not track inter-module dependencies.
[
https://issues.apache.org/jira/browse/MCOMPILER-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15510220#comment-15510220
]
Michael Zav'yalov commented on MCOMPILER-278:
-
I do not see full good fix, but can we have a partial fix where jar checksum
can be used to detect modifications?
Here is a patch for this:
Index: src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java
===
--- src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java
(revision 1761542)
+++ src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java
(working copy)
@@ -18,7 +18,6 @@
* specific language governing permissions and limitations
* under the License.
*/
-
import org.apache.maven.execution.MavenSession;
import org.apache.maven.plugin.AbstractMojo;
import org.apache.maven.plugin.MojoExecution;
@@ -49,20 +48,28 @@
import org.codehaus.plexus.compiler.util.scan.mapping.SuffixMapping;
import java.io.File;
+import java.io.FileInputStream;
+import java.io.FileNotFoundException;
+import java.io.FileOutputStream;
+import java.io.IOException;
+import java.io.ObjectInputStream;
+import java.io.ObjectOutputStream;
import java.lang.reflect.Method;
import java.util.ArrayList;
+import java.util.Arrays;
import java.util.Date;
+import java.util.HashMap;
import java.util.HashSet;
import java.util.LinkedHashMap;
import java.util.List;
import java.util.Map;
import java.util.Set;
+import java.util.logging.Level;
+import java.util.logging.Logger;
/**
- * TODO: At least one step could be optimized, currently the plugin will do two
- * scans of all the source code if the compiler has to have the entire set of
- * sources. This is currently the case for at least the C# compiler and most
- * likely all the other .NET compilers too.
+ * TODO: At least one step could be optimized, currently the plugin will do
two scans of all the source code if the compiler has to have the
+ * entire set of sources. This is currently the case for at least the C#
compiler and most likely all the other .NET compilers too.
*
* @author others
* @author mailto:tryg...@inamo.no;>Trygve Laugstl
@@ -70,1139 +77,1251 @@
* @since 2.0
*/
public abstract class AbstractCompilerMojo
-extends AbstractMojo
+extends AbstractMojo
{
-// --
-// Configurables
-// --
-/**
- * Indicates whether the build will continue even if there are compilation
errors.
- *
- * @since 2.0.2
- */
-@Parameter(property = "maven.compiler.failOnError", defaultValue = "true")
-private boolean failOnError = true;
+ private static final String DEPENDENCY_INFO_FILENAME = "dependencies.info";
-/**
- * Set to true to include debugging information in the
compiled class files.
- */
-@Parameter(property = "maven.compiler.debug", defaultValue = "true")
-private boolean debug = true;
+ // --
+ // Configurables
+ // --
+ /**
+* Indicates whether the build will continue even if there are compilation
errors.
+*
+* @since 2.0.2
+*/
+ @Parameter(property = "maven.compiler.failOnError", defaultValue = "true")
+ private boolean failOnError = true;
-/**
- * Set to true to show messages about what the compiler is
doing.
- */
-@Parameter(property = "maven.compiler.verbose", defaultValue = "false")
-private boolean verbose;
+ /**
+* Set to true to include debugging information in the
compiled class files.
+*/
+ @Parameter(property = "maven.compiler.debug", defaultValue = "true")
+ private boolean debug = true;
-/**
- * Sets whether to show source locations where deprecated APIs are used.
- */
-@Parameter(property = "maven.compiler.showDeprecation", defaultValue =
"false")
-private boolean showDeprecation;
+ /**
+* Set to true to show messages about what the compiler is
doing.
+*/
+ @Parameter(property = "maven.compiler.verbose", defaultValue = "false")
+ private boolean verbose;
-/**
- * Set to true to optimize the compiled code using the
compiler's optimization methods.
- */
-@Parameter(property = "maven.compiler.optimize", defaultValue = "false")
-private boolean optimize;
+ /**
+* Sets whether to show source locations where deprecated APIs are used.
+*/
+ @Parameter(property = "maven.compiler.showDeprecation", defaultValue =
"false")
+ private boolean showDeprecation;
-/**
- * Set to true to show compilation warnings.
- */
-@Parameter(property = "maven.compiler.showWarnings", defaultValue =
[jira] [Created] (MCOMPILER-278) Incremental build does not track inter-module dependencies.
Michael Zav'yalov created MCOMPILER-278: --- Summary: Incremental build does not track inter-module dependencies. Key: MCOMPILER-278 URL: https://issues.apache.org/jira/browse/MCOMPILER-278 Project: Maven Compiler Plugin Issue Type: Bug Affects Versions: 3.1 Reporter: Michael Zav'yalov When useIncrementalCompilation=true the plugin actually assumes that this incremental compilation is supported by compiler itself (I state it because of all source files are always sent to compiler). But plugin provides an additional optimization - it can detect that there are no changes at all, so calling compiler can be skipped. It is especially critical for javac that does not support incremental build since 1.3. Unfortunately, plugin ignores claspath dependencies that are not directory, i.e. - jars, so when dependent jar is modified (in incompatible way) - our project is not re-compiled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MASSEMBLY-829) fileMode on a dependencySet with unpack does not work
[
https://issues.apache.org/jira/browse/MASSEMBLY-829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christophe Marchand updated MASSEMBLY-829:
--
Attachment: bug-maven-assembly-plugin.tar.gz
> fileMode on a dependencySet with unpack does not work
> -
>
> Key: MASSEMBLY-829
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-829
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 2.6
> Environment: linux
>Reporter: Christophe Marchand
>Priority: Blocker
> Attachments: bug-maven-assembly-plugin.tar.gz
>
>
> {code:xml}
>
>
> false
> 775
>
> top.marchand.mvn.bug:assembly-fileMode-shells
>
> true
>
>
> META-INF/**
> META-INF
>
>
> runtime
>
> {code}
> Files from {{top.marchand.mvn.bug:assembly-fileMode-shells}} should be
> runnable by everyone, and they are not.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MASSEMBLY-829) fileMode on a dependencySet with unpack does not work
[
https://issues.apache.org/jira/browse/MASSEMBLY-829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christophe Marchand updated MASSEMBLY-829:
--
Attachment: (was: bug-maven-assembly-plugin.tar.gz)
> fileMode on a dependencySet with unpack does not work
> -
>
> Key: MASSEMBLY-829
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-829
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 2.6
> Environment: linux
>Reporter: Christophe Marchand
>Priority: Blocker
>
> {code:xml}
>
>
> false
> 775
>
> top.marchand.mvn.bug:assembly-fileMode-shells
>
> true
>
>
> META-INF/**
> META-INF
>
>
> runtime
>
> {code}
> Files from {{top.marchand.mvn.bug:assembly-fileMode-shells}} should be
> runnable by everyone, and they are not.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MASSEMBLY-829) fileMode on a dependencySet with unpack does not work
[
https://issues.apache.org/jira/browse/MASSEMBLY-829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christophe Marchand updated MASSEMBLY-829:
--
Attachment: bug-maven-assembly-plugin.tar.gz
Unzip archive, and run the {{run-it.sh}}. It builds the project, then extract
the generated tar.gz, and show file status.
> fileMode on a dependencySet with unpack does not work
> -
>
> Key: MASSEMBLY-829
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-829
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 2.6
> Environment: linux
>Reporter: Christophe Marchand
>Priority: Blocker
> Attachments: bug-maven-assembly-plugin.tar.gz
>
>
> {code:xml}
>
>
> false
> 775
>
> top.marchand.mvn.bug:assembly-fileMode-shells
>
> true
>
>
> META-INF/**
> META-INF
>
>
> runtime
>
> {code}
> Files from {{top.marchand.mvn.bug:assembly-fileMode-shells}} should be
> runnable by everyone, and they are not.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MASSEMBLY-829) fileMode on a dependencySet with unpack does not work
Christophe Marchand created MASSEMBLY-829:
-
Summary: fileMode on a dependencySet with unpack does not work
Key: MASSEMBLY-829
URL: https://issues.apache.org/jira/browse/MASSEMBLY-829
Project: Maven Assembly Plugin
Issue Type: Bug
Components: dependencySet
Affects Versions: 2.6
Environment: linux
Reporter: Christophe Marchand
Priority: Blocker
{code:xml}
false
775
top.marchand.mvn.bug:assembly-fileMode-shells
true
META-INF/**
META-INF
runtime
{code}
Files from {{top.marchand.mvn.bug:assembly-fileMode-shells}} should be runnable
by everyone, and they are not.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1222) ForkClient attempts to consume unrelated lines
[
https://issues.apache.org/jira/browse/SUREFIRE-1222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15508951#comment-15508951
]
Martin Kouba commented on SUREFIRE-1222:
[~tibor17] Thanks a lot! I've created
https://github.com/arquillian/arquillian-container-se/issues/14 to track the
Arquillian SE adapter issue.
> ForkClient attempts to consume unrelated lines
> --
>
> Key: SUREFIRE-1222
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1222
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.17
> Environment: Oracle JDK7 (build 1.7.0_79-b15)
> Linux 3.13 x86_64 with default locale cs_CZ
>Reporter: Martin Kouba
>
> This month the [Weld
> SE|https://github.com/weld/core/tree/2.3/environments/se/tests] test suite
> suddenly started to fail on a Linux machine with Oracle JDK7 and the default
> locale {{cs_CZ}}:
> {code}
> Caused by: java.lang.StringIndexOutOfBoundsException: String index out of
> range: -1
> at java.lang.String.substring(String.java:1911)
> at
> org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:128)
> at
> org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> A {{java.util.logging.Logger}} is used in the forked process. The exception
> occurs when the following log message is written to the standard output:
> {code}
> I 29, 2016 2:01:43 ODP. org.jboss.arquillian.container.se.server.Main main
> {code}
> We have found out that the timestamp *I 29, 2016 2:01:43* (i.e. 2016-01-29
> 14:01:43) is incorrectly parsed as {{ForkingRunListener.BOOTERCODE_SYSPROPS}}
> operation.
> I think the protocol should be robust enough to avoid similar collisions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
