[jira] [Created] (MASSEMBLY-772) tar.gz contents owned by user who ran build

2015-06-08 Thread Axel Fontaine (JIRA)
Axel Fontaine created MASSEMBLY-772:
---

 Summary: tar.gz contents owned by user who ran build
 Key: MASSEMBLY-772
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-772
 Project: Maven Assembly Plugin
  Issue Type: Bug
  Components: maven-archiver
Affects Versions: 2.5.5
 Environment: Windows, Maven 3.3.3
Reporter: Axel Fontaine


When creating a tar.gz, the files it contains have no group (OK), but do have a 
user (not OK). More specifically it is the user who ran the build. This should 
really be empty to avoid any surprises.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MASSEMBLY-771) Regression: Unable to create tar.gz in cross-platform build without error messages on Windows

2015-06-08 Thread Axel Fontaine (JIRA)

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14578367#comment-14578367
 ] 

Axel Fontaine commented on MASSEMBLY-771:
-

Nevermind. Removing / did the trick. Thanks 
for your help and sorry for the inconvenience.

> Regression: Unable to create tar.gz in cross-platform build without error 
> messages on Windows
> -
>
> Key: MASSEMBLY-771
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-771
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.5.5
> Environment: Windows
>Reporter: Axel Fontaine
>
> Recent versions of the assembly plugin started outputting a harmless, but 
> annoying error message when creating tar.gz files from Windows:
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific 
> root-relative-reference (starting with slash) /mypath
> This used to work fine with older versions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MASSEMBLY-771) Regression: Unable to create tar.gz in cross-platform build without error messages on Windows

2015-06-08 Thread Axel Fontaine (JIRA)

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14578360#comment-14578360
 ] 

Axel Fontaine commented on MASSEMBLY-771:
-

Thanks. I edited my original post while you answered. How do you also deal with 
files that have to be put in the root of the tar file? (like LICENSE_DE.txt in 
this example)

> Regression: Unable to create tar.gz in cross-platform build without error 
> messages on Windows
> -
>
> Key: MASSEMBLY-771
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-771
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.5.5
> Environment: Windows
>Reporter: Axel Fontaine
>
> Recent versions of the assembly plugin started outputting a harmless, but 
> annoying error message when creating tar.gz files from Windows:
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific 
> root-relative-reference (starting with slash) /mypath
> This used to work fine with older versions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (MASSEMBLY-771) Regression: Unable to create tar.gz in cross-platform build without error messages on Windows

2015-06-08 Thread Axel Fontaine (JIRA)

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14578351#comment-14578351
 ] 

Axel Fontaine edited comment on MASSEMBLY-771 at 6/9/15 5:42 AM:
-

Here is the descriptor:

http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0";
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
  
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
 http://maven.apache.org/xsd/assembly-1.1.0.xsd";>
linux-x64

tar.gz

base


src/main/assembly/component.xml



src/main/assembly/LICENSE_DE.txt
/
644
lf
true


src/main/assembly/LICENSES-THIRD-PARTY.txt
/
644
lf
true





target/dependency/server-jre-linux-x64-tar.gz/jdk1.8.0_45/jre
/jre
755




Since this build has to run both on Windows & Linux, I wouldn't know how to fix 
it. Suggestions?


was (Author: axel.fontaine):
Here is the descriptor:

http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0";
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
  
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
 http://maven.apache.org/xsd/assembly-1.1.0.xsd";>
linux-x64

tar.gz

base


src/main/assembly/component.xml




target/dependency/server-jre-linux-x64-tar.gz/jdk1.8.0_45/jre
/jre
755




Since this build has to run both on Windows & Linux, I wouldn't know how to fix 
it. Suggestions?

> Regression: Unable to create tar.gz in cross-platform build without error 
> messages on Windows
> -
>
> Key: MASSEMBLY-771
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-771
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.5.5
> Environment: Windows
>Reporter: Axel Fontaine
>
> Recent versions of the assembly plugin started outputting a harmless, but 
> annoying error message when creating tar.gz files from Windows:
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific 
> root-relative-reference (starting with slash) /mypath
> This used to work fine with older versions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MASSEMBLY-771) Regression: Unable to create tar.gz in cross-platform build without error messages on Windows

2015-06-08 Thread Kristian Rosenvold (JIRA)

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14578357#comment-14578357
 ] 

Kristian Rosenvold commented on MASSEMBLY-771:
--

Removing the leading slash from /jre should do the trick. Or do you intend to 
produce a tar file that extracts to the root of the linux file system ? 
(Because I see that's obviously going to create this warning on windows...)

> Regression: Unable to create tar.gz in cross-platform build without error 
> messages on Windows
> -
>
> Key: MASSEMBLY-771
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-771
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.5.5
> Environment: Windows
>Reporter: Axel Fontaine
>
> Recent versions of the assembly plugin started outputting a harmless, but 
> annoying error message when creating tar.gz files from Windows:
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific 
> root-relative-reference (starting with slash) /mypath
> This used to work fine with older versions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (MASSEMBLY-771) Regression: Unable to create tar.gz in cross-platform build without error messages on Windows

2015-06-08 Thread Axel Fontaine (JIRA)

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14578351#comment-14578351
 ] 

Axel Fontaine edited comment on MASSEMBLY-771 at 6/9/15 5:38 AM:
-

Here is the descriptor:

http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0";
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
  
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
 http://maven.apache.org/xsd/assembly-1.1.0.xsd";>
linux-x64

tar.gz

base


src/main/assembly/component.xml




target/dependency/server-jre-linux-x64-tar.gz/jdk1.8.0_45/jre
/jre
755




Since this build has to run both on Windows & Linux, I wouldn't know how to fix 
it. Suggestions?


was (Author: axel.fontaine):
Here is the descriptor:

http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0";
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
  
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
 http://maven.apache.org/xsd/assembly-1.1.0.xsd";>
linux-x64

tar.gz

base


src/main/assembly/component.xml




target/dependency/server-jre-linux-x64-tar.gz/jdk1.${jre.version.major}.0_${jre.version.minor}/jre
/jre
755




Since this build has to run both on Windows & Linux, I wouldn't know how to fix 
it. Suggestions?

> Regression: Unable to create tar.gz in cross-platform build without error 
> messages on Windows
> -
>
> Key: MASSEMBLY-771
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-771
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.5.5
> Environment: Windows
>Reporter: Axel Fontaine
>
> Recent versions of the assembly plugin started outputting a harmless, but 
> annoying error message when creating tar.gz files from Windows:
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific 
> root-relative-reference (starting with slash) /mypath
> This used to work fine with older versions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MASSEMBLY-771) Regression: Unable to create tar.gz in cross-platform build without error messages on Windows

2015-06-08 Thread Axel Fontaine (JIRA)

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14578351#comment-14578351
 ] 

Axel Fontaine commented on MASSEMBLY-771:
-

Here is the descriptor:

http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0";
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
  
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
 http://maven.apache.org/xsd/assembly-1.1.0.xsd";>
linux-x64

tar.gz

base


src/main/assembly/component.xml




target/dependency/server-jre-linux-x64-tar.gz/jdk1.${jre.version.major}.0_${jre.version.minor}/jre
/jre
755




Since this build has to run both on Windows & Linux, I wouldn't know how to fix 
it. Suggestions?

> Regression: Unable to create tar.gz in cross-platform build without error 
> messages on Windows
> -
>
> Key: MASSEMBLY-771
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-771
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.5.5
> Environment: Windows
>Reporter: Axel Fontaine
>
> Recent versions of the assembly plugin started outputting a harmless, but 
> annoying error message when creating tar.gz files from Windows:
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific 
> root-relative-reference (starting with slash) /mypath
> This used to work fine with older versions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MASSEMBLY-771) Regression: Unable to create tar.gz in cross-platform build without error messages on Windows

2015-06-08 Thread Kristian Rosenvold (JIRA)

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14578349#comment-14578349
 ] 

Kristian Rosenvold commented on MASSEMBLY-771:
--

Why dont you just fix the descriptor ? (Or attach it if you believe the message 
is incorrect)

> Regression: Unable to create tar.gz in cross-platform build without error 
> messages on Windows
> -
>
> Key: MASSEMBLY-771
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-771
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.5.5
> Environment: Windows
>Reporter: Axel Fontaine
>
> Recent versions of the assembly plugin started outputting a harmless, but 
> annoying error message when creating tar.gz files from Windows:
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific 
> root-relative-reference (starting with slash) /mypath
> This used to work fine with older versions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MNG-5835) Maven-Plugin's getLog() ignores -Dorg.slf4j.simpleLogger.defaultLogLevel=warn

2015-06-08 Thread S L (JIRA)

[ 
https://issues.apache.org/jira/browse/MNG-5835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14578026#comment-14578026
 ] 

S L commented on MNG-5835:
--

Hi [~j...@kafsemo.org] thanks for clarifying the difference behind the scenes. 
This really helps and I highly appreciate the time you take to look into my 
problem :-) 
I wasn't aware that you get some sort of different logger if you call the 
getLog before the construction.

In my option not caching the logger value somewhere can under some condition 
violate the OOP principle of encapsulation.
I personally prefer some sort of LoggerBridge so in case something with the 
logging change I just need to adjust the Bridge and not my whole code [maybe 
this is old-fashioned but I suffered once and don't want to repeat that ;)].
I guess this may be some sort of personal problem and to be honest I don't want 
to have changed anything in the behavior you outlined in your previous post.

Nevertheless, and regrading the workaround, I think that the original problem 
needs to be addressed. As you outlined this either needs to be addressed in the 
docs or in the code. From my personal point of view I slightly prefer that 
issue to be fixed in the code.
This is due to the fact that the SimpleLogger checks whether there are 
properties present for slf4j logger configuration
{quote}
http://grepcode.com/file/repo1.maven.org/maven2/org.slf4j/slf4j-simple/1.7.12/org/slf4j/impl/SimpleLogger.java/#SimpleLogger.init%28%29

static void  init() {
String defaultLogLevelString = getStringProperty(DEFAULT_LOG_LEVEL_KEY, 
null);
if (defaultLogLevelString != null)
DEFAULT_LOG_LEVEL = stringToLevel(defaultLogLevelString);

whereas getStringProperty should extracts the Property from the System 
Properties:
http://grepcode.com/file/repo1.maven.org/maven2/org.slf4j/slf4j-simple/1.7.12/org/slf4j/impl/SimpleLogger.java/#SimpleLogger.getStringProperty%28java.lang.String%29

System.getProperty(name);
{quote}

> Maven-Plugin's getLog() ignores -Dorg.slf4j.simpleLogger.defaultLogLevel=warn
> -
>
> Key: MNG-5835
> URL: https://issues.apache.org/jira/browse/MNG-5835
> Project: Maven
>  Issue Type: Bug
>  Components: Logging
>Affects Versions: 3.2.3, 3.3.3
>Reporter: S L
> Attachments: hello-maven-plugin.zip, hello-maven-plugin2.zip
>
>
> Hi,
> since Maven should supports slf4j-Logging combined with the SLF4J Simple 
> implementation from Maven 3.1.0 onward 
> (http://maven.apache.org/maven-logging.html).
> I'm kind of wondering why the default getLog() called from a Plugin ignores 
> the Environment-Variable ``-Dorg.slf4j.simpleLogger.defaultLogLevel=warn``
> I'm currently using:
> Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 
> 2014-08-11T22:58:10+02:00)
> Maven home: /usr/share/maven-3.2.3
> Java version: 1.7.0_80, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-7-oracle/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "linux", version: "3.16.0-33-generic", arch: "amd64", family: "unix"
> Tested with different Maven-Versions and different maven-plugin-api Versions, 
> still no success.
> Any help is highly appreciated.
> Thanks,
> PS: Hopefully I can attach my Example-Project which can be executed by using:
> mvn clean install && mvn clean package -Pdemo 
> -Dorg.slf4j.simpleLogger.defaultLogLevel=warn



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (MSHARED-422) Change DependencyGraphBuilder method signatures

2015-06-08 Thread Robert Scholte (JIRA)
Robert Scholte created MSHARED-422:
--

 Summary: Change DependencyGraphBuilder method signatures
 Key: MSHARED-422
 URL: https://issues.apache.org/jira/browse/MSHARED-422
 Project: Maven Shared Components
  Issue Type: Bug
  Components: maven-dependency-tree
Reporter: Robert Scholte
Assignee: Robert Scholte
 Fix For: maven-dependency-tree-3.0


In maven-dependency-tree 2.x the {{DependencyGraphBuilder}} has 2 methods:
{code}
DependencyNode buildDependencyGraph( MavenProject project, ArtifactFilter 
filter )
throws DependencyGraphBuilderException;

DependencyNode buildDependencyGraph( MavenProject project, ArtifactFilter 
filter,
 Collection 
reactorProjects )
throws DependencyGraphBuilderException;
{code}

This was required to be Maven2 compatible but was not correct and efficient for 
Maven3.
Instead the first argument should be changed to {{ProjectBuildingRequest}} 
which contains both the {{MavenProject}} and Aethers {{RepositorySystemSession}}

Developers should upgrade their code to
{code}
@Parameter ( defaultValue="${session}", required=true, readOnly=true )
private MavenSession session;

@Component 
private DependencyGraphBuilder dependencyGraphBuilder;
...
public void doExecute()
{
  ArtifactFilter filter = null; 
  dependencyGraphBuilder.buildDependencyGraph( 
session.getProjectBuildingRequest(), filter );
}
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (MSHARED-421) Change JDK + Maven requirements

2015-06-08 Thread Robert Scholte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MSHARED-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Scholte closed MSHARED-421.
--
Resolution: Fixed

Fixed in [r1684260|http://svn.apache.org/r1684260]

> Change JDK + Maven requirements
> ---
>
> Key: MSHARED-421
> URL: https://issues.apache.org/jira/browse/MSHARED-421
> Project: Maven Shared Components
>  Issue Type: Improvement
>  Components: maven-dependency-tree
>Reporter: Robert Scholte
>Assignee: Robert Scholte
> Fix For: maven-dependency-tree-3.0
>
>
> Dependency Tree will now require at least Maven 3.0 and Java 1.6 as runtime



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (MSHARED-331) Sections in own manifest file are mixed up

2015-06-08 Thread Kristian Rosenvold (JIRA)

 [ 
https://issues.apache.org/jira/browse/MSHARED-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold closed MSHARED-331.
--
Resolution: Invalid
  Assignee: Kristian Rosenvold

The jar specification explicitly states that a blank line is newline newline, 
hence spaces are not permitted.

> Sections in own manifest file are mixed up
> --
>
> Key: MSHARED-331
> URL: https://issues.apache.org/jira/browse/MSHARED-331
> Project: Maven Shared Components
>  Issue Type: Bug
>  Components: maven-archiver
>Affects Versions: maven-archiver-2.5
>Reporter: Johannes Schneider
>Assignee: Kristian Rosenvold
>
> I'm using my own manifest file as described 
> [here|http://maven.apache.org/shared/maven-archiver/examples/manifestFile.html].
>  Plugin-Config:
> {code:xml}
> 
> org.apache.maven.plugins
> maven-jar-plugin
> 2.4
> 
> 
> 
> 
> ${project.version}
> 
> manifest.mf
> 
> 
> 
> {code}
> The manifest.mf file contains a "Name: Dependencies" section:
> {noformat}
> Implementation-Title: hello-api
> Implementation-Vendor: js
> 
> Name: Dependencies
> helloModule: 3.0.0
> somethingElse: 6.4:0.2
> tools:  6.4:0.64
> {noformat}
> In the resulting MANIFEST.MF inside the jar file, however, all entries are 
> disorderd. In particular, the section is destroyed:
> {noformat}
> Manifest-Version: 1.0
> Implementation-Vendor: js   
> Implementation-Title: hello-api
> somethingElse: 6.4:0.2
> tools:  6.4:0.64
> Implementation-Version: 6.4.11-2-SNAPSHOT
> Built-By: js
> Build-Jdk: 1.7.0_51
> Name: Dependencies
> helloModule: 3.0.0
> Created-By: Apache Maven 3.0.5
> Archiver-Version: Plexus Archiver
> {noformat}
> As a workaround, I can define the whole manifest in the pom file. However, 
> this is not a good solution since I do not want everyone to edit the pom 
> file, which always involves the risk of destroying/manipulating the build. 
> Furthermore, it is not very convenient to search for the  section in 
> a lengthy pom file.
> Remark: I am not sure which version of maven-archiver is used by 
> maven-jar-plugin 2.4, so I chose the most recent one.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MSHARED-331) Sections in own manifest file are mixed up

2015-06-08 Thread Kristian Rosenvold (JIRA)

[ 
https://issues.apache.org/jira/browse/MSHARED-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14577636#comment-14577636
 ] 

Kristian Rosenvold commented on MSHARED-331:


Sections are preserved as long as the blank line separating sections does not 
contain anything, like spaces. I am quite certain this is the JDK parsing code 
that acts this way, so I believe the issue is invalid.

> Sections in own manifest file are mixed up
> --
>
> Key: MSHARED-331
> URL: https://issues.apache.org/jira/browse/MSHARED-331
> Project: Maven Shared Components
>  Issue Type: Bug
>  Components: maven-archiver
>Affects Versions: maven-archiver-2.5
>Reporter: Johannes Schneider
>
> I'm using my own manifest file as described 
> [here|http://maven.apache.org/shared/maven-archiver/examples/manifestFile.html].
>  Plugin-Config:
> {code:xml}
> 
> org.apache.maven.plugins
> maven-jar-plugin
> 2.4
> 
> 
> 
> 
> ${project.version}
> 
> manifest.mf
> 
> 
> 
> {code}
> The manifest.mf file contains a "Name: Dependencies" section:
> {noformat}
> Implementation-Title: hello-api
> Implementation-Vendor: js
> 
> Name: Dependencies
> helloModule: 3.0.0
> somethingElse: 6.4:0.2
> tools:  6.4:0.64
> {noformat}
> In the resulting MANIFEST.MF inside the jar file, however, all entries are 
> disorderd. In particular, the section is destroyed:
> {noformat}
> Manifest-Version: 1.0
> Implementation-Vendor: js   
> Implementation-Title: hello-api
> somethingElse: 6.4:0.2
> tools:  6.4:0.64
> Implementation-Version: 6.4.11-2-SNAPSHOT
> Built-By: js
> Build-Jdk: 1.7.0_51
> Name: Dependencies
> helloModule: 3.0.0
> Created-By: Apache Maven 3.0.5
> Archiver-Version: Plexus Archiver
> {noformat}
> As a workaround, I can define the whole manifest in the pom file. However, 
> this is not a good solution since I do not want everyone to edit the pom 
> file, which always involves the risk of destroying/manipulating the build. 
> Furthermore, it is not very convenient to search for the  section in 
> a lengthy pom file.
> Remark: I am not sure which version of maven-archiver is used by 
> maven-jar-plugin 2.4, so I chose the most recent one.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (MASSEMBLY-771) Regression: Unable to create tar.gz in cross-platform build without error messages on Windows

2015-06-08 Thread Axel Fontaine (JIRA)
Axel Fontaine created MASSEMBLY-771:
---

 Summary: Regression: Unable to create tar.gz in cross-platform 
build without error messages on Windows
 Key: MASSEMBLY-771
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-771
 Project: Maven Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.5.5
 Environment: Windows
Reporter: Axel Fontaine


Recent versions of the assembly plugin started outputting a harmless, but 
annoying error message when creating tar.gz files from Windows:

[ERROR] OS=Windows and the assembly descriptor contains a *nix-specific 
root-relative-reference (starting with slash) /mypath

This used to work fine with older versions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (MDEP-489) Regression: unpack-dependencies fails on Windows for tar.gz containing executable file

2015-06-08 Thread Axel Fontaine (JIRA)
Axel Fontaine created MDEP-489:
--

 Summary: Regression: unpack-dependencies fails on Windows for 
tar.gz containing executable file
 Key: MDEP-489
 URL: https://issues.apache.org/jira/browse/MDEP-489
 Project: Maven Dependency Plugin
  Issue Type: Bug
  Components: unpack-dependencies
Affects Versions: 2.10
Reporter: Axel Fontaine


unpack-dependencies fails on Windows for a tar.gz dependency containing an 
executable file with the following message:

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-dependency-plugin:2.10:unpack-dependencies (unpa
ck-jres) on project boxfuse-commandline: Error unpacking file: 
C:\Users\Axel\.m2\repository\com\oracle\server-
jre\8.45\server-jre-8.45-linux-x64.tar.gz to: 
C:\Workspaces\boxfuse-client\boxfuse-commandline\target\dependen
cy\server-jre-linux-x64-tar.gz
[ERROR] org.codehaus.plexus.archiver.ArchiverException: Error while expanding 
C:\Users\Axel\.m2\repository\com
\oracle\server-jre\8.45\server-jre-8.45-linux-x64.tar.gz: 
C:\Workspaces\boxfuse-client\boxfuse-commandline\tar
get\dependency\server-jre-linux-x64-tar.gz\jdk1.8.0_45\jre\lib\amd64\server\libjsig.so:
 A required privilege i
s not held by the client.

This was working fine in all previous versions including 2.8 and 2.9



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MNG-5837) Syntax error in bin/mvn on Solaris SPARC

2015-06-08 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/MNG-5837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14577282#comment-14577282
 ] 

ASF GitHub Bot commented on MNG-5837:
-

Github user josephw commented on the pull request:

https://github.com/apache/maven/pull/50#issuecomment-110022166
  
I've pushed a further change to switch $(..) to backticks. However, perhaps 
[this idiom](https://bugs.freedesktop.org/show_bug.cgi?id=5278) would be a 
better way to ensure a POSIX shell on Solaris:

# Do the Solaris Dance:
if [ ! -d ~root ]  ; then
exec /usr/xpg4/bin/sh $0 "$@" 



> Syntax error in bin/mvn on Solaris SPARC
> 
>
> Key: MNG-5837
> URL: https://issues.apache.org/jira/browse/MNG-5837
> Project: Maven
>  Issue Type: Bug
>  Components: Command Line
>Affects Versions: 3.3.1
> Environment: Solaris 10
>Reporter: Erlend Birkedal
>
> When running {{mvn}} on Solaris 10 we get the following error:
> {code:none}/opt/apache-maven-3.3.1/bin/mvn: syntax error at line 200: `(' 
> unexpected{code}
> Looks like similas issues as in MNG-5658



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (MCHECKSTYLE-295) Test resources are not included

2015-06-08 Thread JIRA

[ 
https://issues.apache.org/jira/browse/MCHECKSTYLE-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14577022#comment-14577022
 ] 

Csaba Kozák edited comment on MCHECKSTYLE-295 at 6/8/15 11:15 AM:
--

Patch for fixing the issue and adding an integration test.


was (Author: wondercsabo):
Path for fixing the issue and adding an integration test.

> Test resources are not included
> ---
>
> Key: MCHECKSTYLE-295
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-295
> Project: Maven Checkstyle Plugin
>  Issue Type: Bug
>  Components: checkstyle:check
>Affects Versions: 2.15
>Reporter: Csaba Kozák
> Attachments: MCHECKSTYLE-295.diff
>
>
> The documentation says the plugin includes test resources by default, but 
> apparently it never does.
> After examining the code, it seems {{CheckstyleViolationCheckMojo.execute()}} 
> forgets to call {{request.setTestResources()}}, hence that is always null and 
> skipped from audit. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (MCHECKSTYLE-295) Test resources are not included

2015-06-08 Thread JIRA

 [ 
https://issues.apache.org/jira/browse/MCHECKSTYLE-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Csaba Kozák updated MCHECKSTYLE-295:

Attachment: MCHECKSTYLE-295.diff

Path for fixing the issue and adding an integration test.

> Test resources are not included
> ---
>
> Key: MCHECKSTYLE-295
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-295
> Project: Maven Checkstyle Plugin
>  Issue Type: Bug
>  Components: checkstyle:check
>Affects Versions: 2.15
>Reporter: Csaba Kozák
> Attachments: MCHECKSTYLE-295.diff
>
>
> The documentation says the plugin includes test resources by default, but 
> apparently it never does.
> After examining the code, it seems {{CheckstyleViolationCheckMojo.execute()}} 
> forgets to call {{request.setTestResources()}}, hence that is always null and 
> skipped from audit. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MNG-5837) Syntax error in bin/mvn on Solaris SPARC

2015-06-08 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/MNG-5837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14577008#comment-14577008
 ] 

ASF GitHub Bot commented on MNG-5837:
-

Github user birkedal commented on the pull request:

https://github.com/apache/maven/pull/50#issuecomment-109946813
  
Looks like there are still problems on Solaris after applying the patch. It 
seams like it's the `$()` that is problematic. See this comment on 
[MNG-5658](https://issues.apache.org/jira/browse/MNG-5658): 
https://issues.apache.org/jira/browse/MNG-5658?focusedCommentId=14420034&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14420034


> Syntax error in bin/mvn on Solaris SPARC
> 
>
> Key: MNG-5837
> URL: https://issues.apache.org/jira/browse/MNG-5837
> Project: Maven
>  Issue Type: Bug
>  Components: Command Line
>Affects Versions: 3.3.1
> Environment: Solaris 10
>Reporter: Erlend Birkedal
>
> When running {{mvn}} on Solaris 10 we get the following error:
> {code:none}/opt/apache-maven-3.3.1/bin/mvn: syntax error at line 200: `(' 
> unexpected{code}
> Looks like similas issues as in MNG-5658



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MSKINS-117) Improve lisibility and user-friendliness in the left menu

2015-06-08 Thread Cyril JACQUENOT (JIRA)

[ 
https://issues.apache.org/jira/browse/MSKINS-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14576740#comment-14576740
 ] 

Cyril JACQUENOT commented on MSKINS-117:


OK, thank you Mickael for your precision. The problem is that I am not very 
good for developping in CSS and new web technologies. I will have a look to 
create a patch but if you have any idea to implement this new functionality in 
the sources, I would be glad to get some help :-)

> Improve lisibility and user-friendliness in the left menu
> -
>
> Key: MSKINS-117
> URL: https://issues.apache.org/jira/browse/MSKINS-117
> Project: Maven Skins
>  Issue Type: Wish
>  Components: Fluido Skin
>Affects Versions: fluido-1.4
>Reporter: Cyril JACQUENOT
>  Labels: close-pending
> Attachments: actual_skin_bad_lisibility.jpg, 
> skin_maven_old_better_lisibility.jpg
>
>
> In our company, we now use *Maven Fluido Skin* for our projects 
> online-documentation.
> I like the design but the lisibility is not optimal: it is hard for me to 
> find the location of my current page in the menu.
> Great improvements should be :
>  * to increase indentations
>  * to use fonts weight to show different levels of indentation
>  * to give the possibility to manage more than 2 levels in the menu
> _here is the bad lisibility skin :_
> !actual_skin_bad_lisibility.jpg!
> _here is an old skin, but with *better lisibility* :_
> !skin_maven_old_better_lisibility.jpg!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MNG-5835) Maven-Plugin's getLog() ignores -Dorg.slf4j.simpleLogger.defaultLogLevel=warn

2015-06-08 Thread Joseph Walton (JIRA)

[ 
https://issues.apache.org/jira/browse/MNG-5835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14576707#comment-14576707
 ] 

Joseph Walton commented on MNG-5835:


bq. However, I just created a slightly changed hello-maven-plugin

Don't do that ;-)

If you call {{getLog()}} in your constructor then you'll [get an instance of 
{{SystemStreamLog}}|https://github.com/apache/maven/blob/40d5087b6b134842e2b61a567dbb4bfbcfab7ae6/maven-plugin-api/src/main/java/org/apache/maven/plugin/AbstractMojo.java#L177]
 that unconditionally logs to {{System.out}}. Your mojo will be wired with an 
SLF4J-backed logger *after* construction.

Call {{getLog()}} during the {{execute()}} method, and don't cache the value.

If any of this behaviour seems like it could be improved, consider being 
specific about your use case and your expectations. Otherwise these sound like 
cases where the documentation should be clearer, rather than the behaviour 
changed.


> Maven-Plugin's getLog() ignores -Dorg.slf4j.simpleLogger.defaultLogLevel=warn
> -
>
> Key: MNG-5835
> URL: https://issues.apache.org/jira/browse/MNG-5835
> Project: Maven
>  Issue Type: Bug
>  Components: Logging
>Affects Versions: 3.2.3, 3.3.3
>Reporter: S L
> Attachments: hello-maven-plugin.zip, hello-maven-plugin2.zip
>
>
> Hi,
> since Maven should supports slf4j-Logging combined with the SLF4J Simple 
> implementation from Maven 3.1.0 onward 
> (http://maven.apache.org/maven-logging.html).
> I'm kind of wondering why the default getLog() called from a Plugin ignores 
> the Environment-Variable ``-Dorg.slf4j.simpleLogger.defaultLogLevel=warn``
> I'm currently using:
> Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 
> 2014-08-11T22:58:10+02:00)
> Maven home: /usr/share/maven-3.2.3
> Java version: 1.7.0_80, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-7-oracle/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "linux", version: "3.16.0-33-generic", arch: "amd64", family: "unix"
> Tested with different Maven-Versions and different maven-plugin-api Versions, 
> still no success.
> Any help is highly appreciated.
> Thanks,
> PS: Hopefully I can attach my Example-Project which can be executed by using:
> mvn clean install && mvn clean package -Pdemo 
> -Dorg.slf4j.simpleLogger.defaultLogLevel=warn



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)