[jira] [Commented] (SUREFIRE-1516) Should surefire specialize test runner when test isolation (i.e., fork) is needed?

2018-04-24 Thread Tibor Digana (JIRA) 

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16450476#comment-16450476
 ] 

Tibor Digana commented on SUREFIRE-1516:


[~forkscript]
I want to understand where those 49% is lost in Surefire. There should not be a 
difference because we also fork java process. There is no difference. Did you 
use a profiler?

> Should surefire specialize test runner when test isolation (i.e., fork) is 
> needed?
> --
>
> Key: SUREFIRE-1516
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1516
> Project: Maven Surefire
>  Issue Type: New Feature
>  Components: Maven Surefire Plugin
>Affects Versions: 2.21.0
>Reporter: Fork Script
>Priority: Major
>
> We observed that {code:java} mvn test -DforkCount=1 -DreuseForks=false {code} 
> has high overhead for several projects we recently used.
> We developed a specific runner for this option, which reduces test execution 
> time by 49% on average. (Please see detailed results in the table below.)
> [Here|https://github.com/forkscript/maven-surefire/commit/38f102f0165f081dd28c6a3023e0b052662857f0]
>  is a link to our commit (see ForkStarter.java:388). Our approach is hackish, 
> but we believe it can be engineered better if needed. Is this of interest to 
> surefire?  We would be happy to discuss this further and provide more results.
> Detailed results are below. Machine we used: Intel i7-6700U CPU @ 3.40GHz 
> with 16GB of RAM, running Ubuntu 17.10. We can share our script used to 
> collect the numbers.
> || project || maven current (sec) || maven with our hack (sec) || time 
> reduced by ||
> | activiti | 1300.54 | 1069.20 | 17% |
> | bukkit | 18.98 | 4.80 | 74% |
> | closurecompiler | 399.42 | 271.68 | 31% |
> | commonscodec | 46.98 | 13.85 | 70% |
> | commonsio | 107.35 | 67.41 | 37% |
> | commonslang | 89.70 | 35.39 | 60% |
> | commonsmath | 391.20 | 110.79 | 71% |
> | commonsnet | 74.50 | 59.46 | 20% |
> | commonsvalidator | 37.30 | 13.24 | 64% |
> | configuration | 126.73 | 62.37 | 50% |
> | crypto | 23.75 | 7.14 | 69% |
> | gedcom4j | 195.43 | 64.10 | 67% |
> | graphhopper | 90.80 | 41.25 | 54% |
> | jaxx | 36.00 | 23.33 | 35% |
> | la4j | 15.23 | 7.60 | 50% |
> | openfire | 28.52 | 18.51 | 35% |
> | retrofit | 53.22 | 35.36 | 33% |
> | scribejava | 13.35 | 4.32 | 67% |
> | vectorz | 37.90 | 11.19 | 70% |
> | ztexec | 23.94 | 17.75 | 25% |
> | Avg. | 155.54 | 96.93 | 49% |



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MEAR-267) assembly.xml contains incorrect references to modules

2018-04-24 Thread Karl Heinz Marbaise (JIRA) 

[ 
https://issues.apache.org/jira/browse/MEAR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16450450#comment-16450450
 ] 

Karl Heinz Marbaise commented on MEAR-267:
--

The changes are mentioned on the page of the plugin as [change for 
3.0.0|https://maven.apache.org/plugins/maven-ear-plugin/]. Apart from that can 
you check if it's really a bug in M2E ? If you checked you can give a feedback 
in the comments...Thanks.

> assembly.xml contains incorrect references to modules
> -
>
> Key: MEAR-267
> URL: https://issues.apache.org/jira/browse/MEAR-267
> Project: Maven Ear Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Leonid Rozenblyum
>Priority: Major
>
> SCENARIO:
> Create a EAR project with maven-ear-plugin 3.0.0
> execute mvn ear:ear
> EXPECTED:
> assembly.xml contains reference to the jar/war equivalent to their physical 
> names inside
> the EAR
> (e.g. if the jar is named tryEar-ejb-1.0-SNAPSHOT.jar then assembly.xml 
> reference would be:
> {quote}{{}}
> tryEar-ejb-1.0-SNAPSHOT.jar
>  
> {quote}
> (this worked in 2.10.1)
> ACTUALLY:
>  assembly.xml contains reference
> {quote}
>  com.leokom-tryEar-ejb-1.0-SNAPSHOT.jar
>  
> {quote}
>  
> Due to this difference - JBoss/WildFly cannot deploy the EAR.
> (it's easy to reproduce: you may create a ear project from some standard ones 
> from maven-archetypes and change maven-ear-plugin version to 3.0.0).
>  
> UPDATE: Sorry, maybe it's a bug in M2E-WTP plugin of Eclipse. I tried this 
> scenario in standalone mode without Eclipse - and assembly.xml is consistent 
> with the jar files



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SUREFIRE-1508) SurefireBooterForkException with Maven 3.5.3

2018-04-24 Thread Tibor Digana (JIRA) 

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16450425#comment-16450425
 ] 

Tibor Digana commented on SUREFIRE-1508:


/proc//stat does not work on FreeBSD and therefore we used ps -p.
The idea with Exit 0 sounds interesting. How would alive-check work? Please
write some pseudocode.
The /proc//stat was also an idea. I have to check the
permissions for reading this file by Java on Docker container. The etime we
have now tells us if the pid is reused or not. The /proc/pid/stat is
binary, right, and the starttime is in there too.
https://www.redhat.com/archives/axp-list/2001-January/msg00355.html
Maybe we can use these alternatives. FreeBSD has another one and we use it
in Surefire too. This can be reused in the forked JVM. Regarding the time,
we had a problem with DST and it is fixed in snapshot version, so maybe we
have to test it properly with Linux once we have decided for /proc/pid/stat.

On Tue, Apr 24, 2018 at 8:49 AM, Andreas Gudian (JIRA) 



> SurefireBooterForkException with Maven 3.5.3
> 
>
> Key: SUREFIRE-1508
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1508
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
> Environment: Docker Image maven:3.5.2-jdk-8
> SpringBoot Application testet with Spring Platform Versions Brussels-SR7 and 
> Brussels-SR3
>Reporter: Pertschy Simon
>Priority: Major
> Attachments: 2018-03-28T16-00-51_221-jvmRun1.dump, 
> failsafe-summary.xml
>
>
> Running junit integration tests with Maven 3.5.3 gives 
> org.apache.maven.surefire.booter.SurefireBooterForkException. 
> With Maven 3.5.2 everything runs fine.
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-failsafe-plugin:2.20.1:verify (default) on 
> project explosive: There are test failures.
> [ERROR] 
> [ERROR] Please refer to /usr/src/mymaven/target/failsafe-reports for the 
> individual test results.
> [ERROR] Please refer to dump files (if any exist) [date]-jvmRun[N].dump, 
> [date].dumpstream and [date]-jvmRun[N].dumpstream.
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: The 
> forked VM terminated without properly saying goodbye. VM crash or System.exit 
> called?
> [ERROR] Command was /bin/sh -c cd /usr/src/mymaven && 
> /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java -Dfile.encoding=UTF-8 -jar 
> /usr/src/mymaven/target/surefire/surefirebooter8650244765410237450.jar 
> /usr/src/mymaven/target/surefire 2018-03-28T16-00-51_221-jvmRun1 
> surefire1685882686721224264tmp surefire_03464518048239249547tmp
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] Process Exit Code: 1
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:686)
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:535)
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:280)
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
> [ERROR] at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1124)
> [ERROR] at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:954)
> [ERROR] at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:832)
> [ERROR] at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
> [ERROR] at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> [ERROR] at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> [ERROR] at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> [ERROR] at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> [ERROR] at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> [ERROR] at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
> [ERROR] at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> [ERROR] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
> [ERROR] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
> [ERROR] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
> [ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:956)
> [ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:290)
> [ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:194)
> [ERROR] at

[jira] [Updated] (MEAR-267) assembly.xml contains incorrect references to modules

2018-04-24 Thread Leonid Rozenblyum (JIRA) 

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

Leonid Rozenblyum updated MEAR-267:
---
Description: 
SCENARIO:

Create a EAR project with maven-ear-plugin 3.0.0

execute mvn ear:ear

EXPECTED:

assembly.xml contains reference to the jar/war equivalent to their physical 
names inside

the EAR

(e.g. if the jar is named tryEar-ejb-1.0-SNAPSHOT.jar then assembly.xml 
reference would be:
{quote}{{}}
{{ tryEar-ejb-1.0-SNAPSHOT.jar}}
{{ }}
{quote}
(this worked in 2.10.1)

ACTUALLY:
 assembly.xml contains reference
{quote}
 com.leokom-tryEar-ejb-1.0-SNAPSHOT.jar
 
{quote}
 

Due to this difference - JBoss/WildFly cannot deploy the EAR.

(it's easy to reproduce: you may create a ear project from some standard ones 
from maven-archetypes and change maven-ear-plugin version to 3.0.0).

 

UPDATE: Sorry, maybe it's a bug in M2E-WTP plugin of Eclipse. I tried this 
scenario in standalone mode without Eclipse - and assembly.xml is consistent 
with the jar files

  was:
SCENARIO:

Create a EAR project with maven-ear-plugin 3.0.0

execute mvn ear:ear

EXPECTED:

assembly.xml contains reference to the jar/war equivalent to their physical 
names inside

the EAR

(e.g. if the jar is named tryEar-ejb-1.0-SNAPSHOT.jar then assembly.xml 
reference would be:


 tryEar-ejb-1.0-SNAPSHOT.jar
 

(this worked in 2.10.1)

ACTUALLY:
 assembly.xml contains reference


 com.leokom-tryEar-ejb-1.0-SNAPSHOT.jar
 

 

Due to this difference - JBoss/WildFly cannot deploy the EAR.

(it's easy to reproduce: you may create a ear project from some standard ones 
from maven-archetypes and change maven-ear-plugin version to 3.0.0).

 

UPDATE: Sorry, maybe it's a bug in M2E-WTP plugin of Eclipse. I tried this 
scenario in standalone mode without Eclipse - and assembly.xml is consistent 
with the jar files


> assembly.xml contains incorrect references to modules
> -
>
> Key: MEAR-267
> URL: https://issues.apache.org/jira/browse/MEAR-267
> Project: Maven Ear Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Leonid Rozenblyum
>Priority: Major
>
> SCENARIO:
> Create a EAR project with maven-ear-plugin 3.0.0
> execute mvn ear:ear
> EXPECTED:
> assembly.xml contains reference to the jar/war equivalent to their physical 
> names inside
> the EAR
> (e.g. if the jar is named tryEar-ejb-1.0-SNAPSHOT.jar then assembly.xml 
> reference would be:
> {quote}{{}}
> {{ tryEar-ejb-1.0-SNAPSHOT.jar}}
> {{ }}
> {quote}
> (this worked in 2.10.1)
> ACTUALLY:
>  assembly.xml contains reference
> {quote}
>  com.leokom-tryEar-ejb-1.0-SNAPSHOT.jar
>  
> {quote}
>  
> Due to this difference - JBoss/WildFly cannot deploy the EAR.
> (it's easy to reproduce: you may create a ear project from some standard ones 
> from maven-archetypes and change maven-ear-plugin version to 3.0.0).
>  
> UPDATE: Sorry, maybe it's a bug in M2E-WTP plugin of Eclipse. I tried this 
> scenario in standalone mode without Eclipse - and assembly.xml is consistent 
> with the jar files



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MEAR-267) assembly.xml contains incorrect references to modules

2018-04-24 Thread Leonid Rozenblyum (JIRA) 

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

Leonid Rozenblyum updated MEAR-267:
---
Description: 
SCENARIO:

Create a EAR project with maven-ear-plugin 3.0.0

execute mvn ear:ear

EXPECTED:

assembly.xml contains reference to the jar/war equivalent to their physical 
names inside

the EAR

(e.g. if the jar is named tryEar-ejb-1.0-SNAPSHOT.jar then assembly.xml 
reference would be:
{quote}{{}}
tryEar-ejb-1.0-SNAPSHOT.jar
 
{quote}
(this worked in 2.10.1)

ACTUALLY:
 assembly.xml contains reference
{quote}
 com.leokom-tryEar-ejb-1.0-SNAPSHOT.jar
 
{quote}
 

Due to this difference - JBoss/WildFly cannot deploy the EAR.

(it's easy to reproduce: you may create a ear project from some standard ones 
from maven-archetypes and change maven-ear-plugin version to 3.0.0).

 

UPDATE: Sorry, maybe it's a bug in M2E-WTP plugin of Eclipse. I tried this 
scenario in standalone mode without Eclipse - and assembly.xml is consistent 
with the jar files

  was:
SCENARIO:

Create a EAR project with maven-ear-plugin 3.0.0

execute mvn ear:ear

EXPECTED:

assembly.xml contains reference to the jar/war equivalent to their physical 
names inside

the EAR

(e.g. if the jar is named tryEar-ejb-1.0-SNAPSHOT.jar then assembly.xml 
reference would be:
{quote}{{}}
{{ tryEar-ejb-1.0-SNAPSHOT.jar}}
{{ }}
{quote}
(this worked in 2.10.1)

ACTUALLY:
 assembly.xml contains reference
{quote}
 com.leokom-tryEar-ejb-1.0-SNAPSHOT.jar
 
{quote}
 

Due to this difference - JBoss/WildFly cannot deploy the EAR.

(it's easy to reproduce: you may create a ear project from some standard ones 
from maven-archetypes and change maven-ear-plugin version to 3.0.0).

 

UPDATE: Sorry, maybe it's a bug in M2E-WTP plugin of Eclipse. I tried this 
scenario in standalone mode without Eclipse - and assembly.xml is consistent 
with the jar files


> assembly.xml contains incorrect references to modules
> -
>
> Key: MEAR-267
> URL: https://issues.apache.org/jira/browse/MEAR-267
> Project: Maven Ear Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Leonid Rozenblyum
>Priority: Major
>
> SCENARIO:
> Create a EAR project with maven-ear-plugin 3.0.0
> execute mvn ear:ear
> EXPECTED:
> assembly.xml contains reference to the jar/war equivalent to their physical 
> names inside
> the EAR
> (e.g. if the jar is named tryEar-ejb-1.0-SNAPSHOT.jar then assembly.xml 
> reference would be:
> {quote}{{}}
> tryEar-ejb-1.0-SNAPSHOT.jar
>  
> {quote}
> (this worked in 2.10.1)
> ACTUALLY:
>  assembly.xml contains reference
> {quote}
>  com.leokom-tryEar-ejb-1.0-SNAPSHOT.jar
>  
> {quote}
>  
> Due to this difference - JBoss/WildFly cannot deploy the EAR.
> (it's easy to reproduce: you may create a ear project from some standard ones 
> from maven-archetypes and change maven-ear-plugin version to 3.0.0).
>  
> UPDATE: Sorry, maybe it's a bug in M2E-WTP plugin of Eclipse. I tried this 
> scenario in standalone mode without Eclipse - and assembly.xml is consistent 
> with the jar files



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MEAR-267) assembly.xml contains incorrect references to modules

2018-04-24 Thread Leonid Rozenblyum (JIRA) 

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

Leonid Rozenblyum updated MEAR-267:
---
Description: 
SCENARIO:

Create a EAR project with maven-ear-plugin 3.0.0

execute mvn ear:ear

EXPECTED:

assembly.xml contains reference to the jar/war equivalent to their physical 
names inside

the EAR

(e.g. if the jar is named tryEar-ejb-1.0-SNAPSHOT.jar then assembly.xml 
reference would be:


 tryEar-ejb-1.0-SNAPSHOT.jar
 

(this worked in 2.10.1)

ACTUALLY:
 assembly.xml contains reference


 com.leokom-tryEar-ejb-1.0-SNAPSHOT.jar
 

 

Due to this difference - JBoss/WildFly cannot deploy the EAR.

(it's easy to reproduce: you may create a ear project from some standard ones 
from maven-archetypes and change maven-ear-plugin version to 3.0.0).

 

UPDATE: Sorry, maybe it's a bug in M2E-WTP plugin of Eclipse. I tried this 
scenario in standalone mode without Eclipse - and assembly.xml is consistent 
with the jar files

  was:
SCENARIO:

Create a EAR project with maven-ear-plugin 3.0.0

execute mvn ear:ear

EXPECTED:

assembly.xml contains reference to the jar/war equivalent to their physical 
names inside

the EAR

(e.g. if the jar is named tryEar-ejb-1.0-SNAPSHOT.jar then assembly.xml 
reference would be:


 tryEar-ejb-1.0-SNAPSHOT.jar
 

(this worked in 2.10.1)

ACTUALLY:
 assembly.xml contains reference


 com.leokom-tryEar-ejb-1.0-SNAPSHOT.jar
 

 

Due to this difference - JBoss/WildFly cannot deploy the EAR.

(it's easy to reproduce: you may create a ear project from some standard ones 
from maven-archetypes and change maven-ear-plugin version to 3.0.0).

 

Sorry, maybe it's a bug in M2E-WTP plugin of Eclipse. I tried this scenario in 
standalone mode without Eclipse - and assembly.xml is consistent with the jar 
files


> assembly.xml contains incorrect references to modules
> -
>
> Key: MEAR-267
> URL: https://issues.apache.org/jira/browse/MEAR-267
> Project: Maven Ear Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Leonid Rozenblyum
>Priority: Major
>
> SCENARIO:
> Create a EAR project with maven-ear-plugin 3.0.0
> execute mvn ear:ear
> EXPECTED:
> assembly.xml contains reference to the jar/war equivalent to their physical 
> names inside
> the EAR
> (e.g. if the jar is named tryEar-ejb-1.0-SNAPSHOT.jar then assembly.xml 
> reference would be:
> 
>  tryEar-ejb-1.0-SNAPSHOT.jar
>  
> (this worked in 2.10.1)
> ACTUALLY:
>  assembly.xml contains reference
> 
>  com.leokom-tryEar-ejb-1.0-SNAPSHOT.jar
>  
>  
> Due to this difference - JBoss/WildFly cannot deploy the EAR.
> (it's easy to reproduce: you may create a ear project from some standard ones 
> from maven-archetypes and change maven-ear-plugin version to 3.0.0).
>  
> UPDATE: Sorry, maybe it's a bug in M2E-WTP plugin of Eclipse. I tried this 
> scenario in standalone mode without Eclipse - and assembly.xml is consistent 
> with the jar files



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MEAR-267) assembly.xml contains incorrect references to modules

2018-04-24 Thread Leonid Rozenblyum (JIRA) 

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

Leonid Rozenblyum updated MEAR-267:
---
Description: 
SCENARIO:

Create a EAR project with maven-ear-plugin 3.0.0

execute mvn ear:ear

EXPECTED:

assembly.xml contains reference to the jar/war equivalent to their physical 
names inside

the EAR

(e.g. if the jar is named tryEar-ejb-1.0-SNAPSHOT.jar then assembly.xml 
reference would be:


 tryEar-ejb-1.0-SNAPSHOT.jar
 

(this worked in 2.10.1)

ACTUALLY:
 assembly.xml contains reference


 com.leokom-tryEar-ejb-1.0-SNAPSHOT.jar
 

 

Due to this difference - JBoss/WildFly cannot deploy the EAR.

(it's easy to reproduce: you may create a ear project from some standard ones 
from maven-archetypes and change maven-ear-plugin version to 3.0.0).

 

Sorry, maybe it's a bug in M2E-WTP plugin of Eclipse. I tried this scenario in 
standalone mode without Eclipse - and assembly.xml is consistent with the jar 
files

  was:
SCENARIO:

Create a EAR project with maven-ear-plugin 3.0.0

execute mvn ear:ear

EXPECTED:

assembly.xml contains reference to the jar/war equivalent to their physical 
names inside

the EAR

(e.g. if the jar is named tryEar-ejb-1.0-SNAPSHOT.jar then assembly.xml 
reference would be:


 tryEar-ejb-1.0-SNAPSHOT.jar
 

(this worked in 2.10.1)

ACTUALLY:
 assembly.xml contains reference


 com.leokom-tryEar-ejb-1.0-SNAPSHOT.jar
 

 

Due to this difference - JBoss/WildFly cannot deploy the EAR.

(it's easy to reproduce: you may create a ear project from some standard ones 
from maven-archetypes and change maven-ear-plugin version to 3.0.0).

 

Sorry, maybe it's a bug in M2E-WTP plugin of Eclipse. I tried this scenario in 
standalone mode without Eclipse - and the build is consistent


> assembly.xml contains incorrect references to modules
> -
>
> Key: MEAR-267
> URL: https://issues.apache.org/jira/browse/MEAR-267
> Project: Maven Ear Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Leonid Rozenblyum
>Priority: Major
>
> SCENARIO:
> Create a EAR project with maven-ear-plugin 3.0.0
> execute mvn ear:ear
> EXPECTED:
> assembly.xml contains reference to the jar/war equivalent to their physical 
> names inside
> the EAR
> (e.g. if the jar is named tryEar-ejb-1.0-SNAPSHOT.jar then assembly.xml 
> reference would be:
> 
>  tryEar-ejb-1.0-SNAPSHOT.jar
>  
> (this worked in 2.10.1)
> ACTUALLY:
>  assembly.xml contains reference
> 
>  com.leokom-tryEar-ejb-1.0-SNAPSHOT.jar
>  
>  
> Due to this difference - JBoss/WildFly cannot deploy the EAR.
> (it's easy to reproduce: you may create a ear project from some standard ones 
> from maven-archetypes and change maven-ear-plugin version to 3.0.0).
>  
> Sorry, maybe it's a bug in M2E-WTP plugin of Eclipse. I tried this scenario 
> in standalone mode without Eclipse - and assembly.xml is consistent with the 
> jar files



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MEAR-267) assembly.xml contains incorrect references to modules

2018-04-24 Thread Leonid Rozenblyum (JIRA) 

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

Leonid Rozenblyum updated MEAR-267:
---
Description: 
SCENARIO:

Create a EAR project with maven-ear-plugin 3.0.0

execute mvn ear:ear

EXPECTED:

assembly.xml contains reference to the jar/war equivalent to their physical 
names inside

the EAR

(e.g. if the jar is named tryEar-ejb-1.0-SNAPSHOT.jar then assembly.xml 
reference would be:


 tryEar-ejb-1.0-SNAPSHOT.jar
 

(this worked in 2.10.1)

ACTUALLY:
 assembly.xml contains reference


 com.leokom-tryEar-ejb-1.0-SNAPSHOT.jar
 

 

Due to this difference - JBoss/WildFly cannot deploy the EAR.

(it's easy to reproduce: you may create a ear project from some standard ones 
from maven-archetypes and change maven-ear-plugin version to 3.0.0).

 

Sorry, maybe it's a bug in M2E-WTP plugin of Eclipse. I tried this scenario in 
standalone mode without Eclipse - and the build is consistent

  was:
SCENARIO:

Create a EAR project with maven-ear-plugin 3.0.0

execute mvn ear:ear

EXPECTED:

assembly.xml contains reference to the jar/war equivalent to their physical 
names inside

the EAR

(e.g. if the jar is named tryEar-ejb-1.0-SNAPSHOT.jar then assembly.xml 
reference would be:


 tryEar-ejb-1.0-SNAPSHOT.jar
 

(this worked in 2.10.1)

ACTUALLY:
assembly.xml contains reference


 com.leokom-tryEar-ejb-1.0-SNAPSHOT.jar
 

 

Due to this difference - JBoss/WildFly cannot deploy the EAR.

(it's easy to reproduce: you may create a ear project from some standard ones 
from maven-archetypes and change maven-ear-plugin version to 3.0.0)


> assembly.xml contains incorrect references to modules
> -
>
> Key: MEAR-267
> URL: https://issues.apache.org/jira/browse/MEAR-267
> Project: Maven Ear Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Leonid Rozenblyum
>Priority: Major
>
> SCENARIO:
> Create a EAR project with maven-ear-plugin 3.0.0
> execute mvn ear:ear
> EXPECTED:
> assembly.xml contains reference to the jar/war equivalent to their physical 
> names inside
> the EAR
> (e.g. if the jar is named tryEar-ejb-1.0-SNAPSHOT.jar then assembly.xml 
> reference would be:
> 
>  tryEar-ejb-1.0-SNAPSHOT.jar
>  
> (this worked in 2.10.1)
> ACTUALLY:
>  assembly.xml contains reference
> 
>  com.leokom-tryEar-ejb-1.0-SNAPSHOT.jar
>  
>  
> Due to this difference - JBoss/WildFly cannot deploy the EAR.
> (it's easy to reproduce: you may create a ear project from some standard ones 
> from maven-archetypes and change maven-ear-plugin version to 3.0.0).
>  
> Sorry, maybe it's a bug in M2E-WTP plugin of Eclipse. I tried this scenario 
> in standalone mode without Eclipse - and the build is consistent



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (MEAR-267) assembly.xml contains incorrect references to modules

2018-04-24 Thread Leonid Rozenblyum (JIRA) 
Leonid Rozenblyum created MEAR-267:
--

 Summary: assembly.xml contains incorrect references to modules
 Key: MEAR-267
 URL: https://issues.apache.org/jira/browse/MEAR-267
 Project: Maven Ear Plugin
  Issue Type: Bug
Affects Versions: 3.0.0
Reporter: Leonid Rozenblyum


SCENARIO:

Create a EAR project with maven-ear-plugin 3.0.0

execute mvn ear:ear

EXPECTED:

assembly.xml contains reference to the jar/war equivalent to their physical 
names inside

the EAR

(e.g. if the jar is named tryEar-ejb-1.0-SNAPSHOT.jar then assembly.xml 
reference would be:


 tryEar-ejb-1.0-SNAPSHOT.jar
 

(this worked in 2.10.1)

ACTUALLY:
assembly.xml contains reference


 com.leokom-tryEar-ejb-1.0-SNAPSHOT.jar
 

 

Due to this difference - JBoss/WildFly cannot deploy the EAR.

(it's easy to reproduce: you may create a ear project from some standard ones 
from maven-archetypes and change maven-ear-plugin version to 3.0.0)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MSOURCES-113) Store source encoding info in a standard file

2018-04-24 Thread Fred Bricon (JIRA) 

[ 
https://issues.apache.org/jira/browse/MSOURCES-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16450292#comment-16450292
 ] 

Fred Bricon commented on MSOURCES-113:
--

I think `encoding=UTF-8` would be best

It gives us the opportunity to do more crazy stuff like defining 
encoding/some/specific/files=UTF-8 eventually (but probably not).

I have no preference whether to add a line ending or not. I don't think it 
matters much.

I imagine the `encoding` file encoding would be UTF-8

> Store source encoding info in a standard file
> -
>
> Key: MSOURCES-113
> URL: https://issues.apache.org/jira/browse/MSOURCES-113
> Project: Maven Source Plugin
>  Issue Type: New Feature
>Reporter: Fred Bricon
>Assignee: Karl Heinz Marbaise
>Priority: Major
> Fix For: 3.1.0
>
>
> It'd be nice if IDEs were able to automatically set proper source encoding 
> when attaching sources to project dependencies. 
> In eclipse/m2e, we tried to automatically detect encoding but it didn't work 
> out [https://git.eclipse.org/r/#/c/116390/]
> A more reliable way would be to ensure the encoding info was stored inside 
> the source archive, so that IDEs could peek into it and ensure proper 
> settings.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (MNG-6400) can not work with a system dependency on a unix / mac / windows project

2018-04-24 Thread Terrien Jean-Yves (JIRA) 
Terrien Jean-Yves created MNG-6400:
--

 Summary: can not work with a system dependency on a unix / mac / 
windows project
 Key: MNG-6400
 URL: https://issues.apache.org/jira/browse/MNG-6400
 Project: Maven
  Issue Type: Bug
  Components: Dependencies
Affects Versions: 3.5.3
 Environment: Windows 07
Reporter: Terrien Jean-Yves


the sapjco3.jar and sapIdoc3.jar jars can not be renamed.
to work with you have to use an addiction system

however, a unix / windows project can not have an identical absolute path on 
both systems.

in previous versions of maven you can set properties in .m2 / settings.xml 
 and  and use  system 
 $ \{sapidoc3} 

a warnning will be displayed.
on version 3.5.3 it is an error.

But that's not all because even putting the system dependency with an absolute 
path the jar is not found with the correct name


 de.sap
 sapjco3
 3.0.0
 system
 D:/project-ati/libs/libsap/sapjco3.jar
 

JCO3 code


 protected boolean registerNativeMethods(Class clazz){
 if(!initializedDLL){
 try{
 JCoRuntime.nativeLibraryPath = loadLibrary("sapjco3");
 initializedDLL = true;
 }catch(UnsatisfiedLinkError arg2){
 JCoRuntime.nativeLibraryPath = "not loaded, caused by " + arg2.toString();
 arg2.printStackTrace();
 throw arg2;
 }
 }

return true;
 }

java.lang.UnsatisfiedLinkError: no sapjco3 in java.library.path
 at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1865)
 at java.lang.Runtime.loadLibrary0(Runtime.java:870)
 at java.lang.System.loadLibrary(System.java:1122)
 at 
com.sap.conn.jco.rt.DefaultJCoRuntime.loadLibrary(DefaultJCoRuntime.java:444)

 

The first sap-schema-plugin is a project with sap dependencies defined by an 
absolute path or property. it compiles well.

the second project use this plugin. 
if the plugin project is compiled whith properties
=> error absolute pah is ${sapjco3}
if the plugin project is compiled with absolute path
=> java.lang.UnsatisfiedLinkError: no sapjco3 in java.library.path

 

the same project without change with maven 3.3.9 works perfectly

 

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MSOURCES-113) Store source encoding info in a standard file

2018-04-24 Thread Karl Heinz Marbaise (JIRA) 

[ 
https://issues.apache.org/jira/browse/MSOURCES-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16450230#comment-16450230
 ] 

Karl Heinz Marbaise commented on MSOURCES-113:
--

Some questions coming into my mind. 

The file itself should have an encoding itself for example {{UTF-8}} ? What 
about the format of the file? Just something like this (property like):
{code:java}
encoding=UTF-18
{code}
Or do you think about something very plain like this:
{code:java}
UTF-18
{code}
What about a line ending?

> Store source encoding info in a standard file
> -
>
> Key: MSOURCES-113
> URL: https://issues.apache.org/jira/browse/MSOURCES-113
> Project: Maven Source Plugin
>  Issue Type: New Feature
>Reporter: Fred Bricon
>Assignee: Karl Heinz Marbaise
>Priority: Major
> Fix For: 3.1.0
>
>
> It'd be nice if IDEs were able to automatically set proper source encoding 
> when attaching sources to project dependencies. 
> In eclipse/m2e, we tried to automatically detect encoding but it didn't work 
> out [https://git.eclipse.org/r/#/c/116390/]
> A more reliable way would be to ensure the encoding info was stored inside 
> the source archive, so that IDEs could peek into it and ensure proper 
> settings.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WAGON-518) AbstractHttpClientWagon#putFromStream() reads entire content to memory

2018-04-24 Thread Chris Lott (JIRA) 

[ 
https://issues.apache.org/jira/browse/WAGON-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16450144#comment-16450144
 ] 

Chris Lott commented on WAGON-518:
--

That test is still pending, thanks for asking. My initial test was in a little 
library that uses Wagon.  The real test must wait for another component that 
uses the little library.

> AbstractHttpClientWagon#putFromStream() reads entire content to memory
> --
>
> Key: WAGON-518
> URL: https://issues.apache.org/jira/browse/WAGON-518
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-http
>Affects Versions: 2.12
>Reporter: Chris Lott
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.1.0
>
>
> Method putFromSteam in class AbstractHttpClientWagon seems to violate the 
> implied contract of working with streams.  It uses much memory because it 
> first consumes the input stream argument, then transfers that content.  The 
> code that consumes the stream is in the private class 
> RequestEntityImplementation ctor:
> {code:java}
>      byte[] bytes = IOUtil.toByteArray( stream );{code}
> Please revise it, if possible, to behave more like the superclass 
> StreamWagon's putFromStream method, which does the transfer straight from the 
> input stream.
> We are attempting to PUT some 150MB artifacts in a java microservice that 
> runs with rather sharp memory limits.  As a local workaround we increased the 
> JVM's -Xmx argument but that way lies madness.
> Thanks in advance for any suggestions or workarounds. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WAGON-518) AbstractHttpClientWagon#putFromStream() reads entire content to memory

2018-04-24 Thread Michael Osipov (JIRA) 

[ 
https://issues.apache.org/jira/browse/WAGON-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16450114#comment-16450114
 ] 

Michael Osipov commented on WAGON-518:
--

So you big deployment does work now?

> AbstractHttpClientWagon#putFromStream() reads entire content to memory
> --
>
> Key: WAGON-518
> URL: https://issues.apache.org/jira/browse/WAGON-518
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-http
>Affects Versions: 2.12
>Reporter: Chris Lott
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.1.0
>
>
> Method putFromSteam in class AbstractHttpClientWagon seems to violate the 
> implied contract of working with streams.  It uses much memory because it 
> first consumes the input stream argument, then transfers that content.  The 
> code that consumes the stream is in the private class 
> RequestEntityImplementation ctor:
> {code:java}
>      byte[] bytes = IOUtil.toByteArray( stream );{code}
> Please revise it, if possible, to behave more like the superclass 
> StreamWagon's putFromStream method, which does the transfer straight from the 
> input stream.
> We are attempting to PUT some 150MB artifacts in a java microservice that 
> runs with rather sharp memory limits.  As a local workaround we increased the 
> JVM's -Xmx argument but that way lies madness.
> Thanks in advance for any suggestions or workarounds. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (WAGON-518) AbstractHttpClientWagon#putFromStream() reads entire content to memory

2018-04-24 Thread Chris Lott (JIRA) 

[ 
https://issues.apache.org/jira/browse/WAGON-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16449870#comment-16449870
 ] 

Chris Lott edited comment on WAGON-518 at 4/24/18 1:43 PM:
---

I cloned, switched to branch WAGON-518, ran mvn install, changed my code to use 
version 3.1.0-SNAPSHOT, built mine and the tests revealed no errors. Not tested 
with Maven.  HTH


was (Author: chrislott):
I cloned, ran mvn install, changed my code to use version 3.1.0-SNAPSHOT, built 
mine and the tests revealed no errors. Not tested with Maven.  HTH

> AbstractHttpClientWagon#putFromStream() reads entire content to memory
> --
>
> Key: WAGON-518
> URL: https://issues.apache.org/jira/browse/WAGON-518
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-http
>Affects Versions: 2.12
>Reporter: Chris Lott
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.1.0
>
>
> Method putFromSteam in class AbstractHttpClientWagon seems to violate the 
> implied contract of working with streams.  It uses much memory because it 
> first consumes the input stream argument, then transfers that content.  The 
> code that consumes the stream is in the private class 
> RequestEntityImplementation ctor:
> {code:java}
>      byte[] bytes = IOUtil.toByteArray( stream );{code}
> Please revise it, if possible, to behave more like the superclass 
> StreamWagon's putFromStream method, which does the transfer straight from the 
> input stream.
> We are attempting to PUT some 150MB artifacts in a java microservice that 
> runs with rather sharp memory limits.  As a local workaround we increased the 
> JVM's -Xmx argument but that way lies madness.
> Thanks in advance for any suggestions or workarounds. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WAGON-518) AbstractHttpClientWagon#putFromStream() reads entire content to memory

2018-04-24 Thread Chris Lott (JIRA) 

[ 
https://issues.apache.org/jira/browse/WAGON-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16449870#comment-16449870
 ] 

Chris Lott commented on WAGON-518:
--

I cloned, ran mvn install, changed my code to use version 3.1.0-SNAPSHOT, built 
mine and the tests revealed no errors. Not tested with Maven.  HTH

> AbstractHttpClientWagon#putFromStream() reads entire content to memory
> --
>
> Key: WAGON-518
> URL: https://issues.apache.org/jira/browse/WAGON-518
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-http
>Affects Versions: 2.12
>Reporter: Chris Lott
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.1.0
>
>
> Method putFromSteam in class AbstractHttpClientWagon seems to violate the 
> implied contract of working with streams.  It uses much memory because it 
> first consumes the input stream argument, then transfers that content.  The 
> code that consumes the stream is in the private class 
> RequestEntityImplementation ctor:
> {code:java}
>      byte[] bytes = IOUtil.toByteArray( stream );{code}
> Please revise it, if possible, to behave more like the superclass 
> StreamWagon's putFromStream method, which does the transfer straight from the 
> input stream.
> We are attempting to PUT some 150MB artifacts in a java microservice that 
> runs with rather sharp memory limits.  As a local workaround we increased the 
> JVM's -Xmx argument but that way lies madness.
> Thanks in advance for any suggestions or workarounds. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (MSITE-821) add documentation on site plugin dependencies

2018-04-24 Thread JIRA 

[ 
https://issues.apache.org/jira/browse/MSITE-821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16449839#comment-16449839
 ] 

Hervé Boutemy edited comment on MSITE-821 at 4/24/18 1:25 PM:
--

https://gitbox.apache.org/repos/asf?p=maven-site-plugin.git;a=commit;h=3085aac29fc29a96d6bbbf680b8df602c116bda9
https://gitbox.apache.org/repos/asf?p=maven-site-plugin.git=commit=0b587a800d71a1e70439d9a47a080ebde05b5ada


was (Author: hboutemy):
https://gitbox.apache.org/repos/asf?p=maven-site-plugin.git;a=commit;h=3085aac29fc29a96d6bbbf680b8df602c116bda9

> add documentation on site plugin dependencies
> -
>
> Key: MSITE-821
> URL: https://issues.apache.org/jira/browse/MSITE-821
> Project: Maven Site Plugin
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 3.7
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>Priority: Major
> Fix For: 3.7.1
>
>
> useful to know which version of Doxia, Doxia Sitetools & Reporting Executor 
> is used by which version of maven-site-plugin



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (MSITE-821) add documentation on site plugin dependencies

2018-04-24 Thread JIRA 

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

Hervé Boutemy closed MSITE-821.
---
Resolution: Fixed

> add documentation on site plugin dependencies
> -
>
> Key: MSITE-821
> URL: https://issues.apache.org/jira/browse/MSITE-821
> Project: Maven Site Plugin
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 3.7
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>Priority: Major
> Fix For: 3.7.1
>
>
> useful to know which version of Doxia, Doxia Sitetools & Reporting Executor 
> is used by which version of maven-site-plugin



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MSITE-821) add documentation on site plugin dependencies

2018-04-24 Thread JIRA 

[ 
https://issues.apache.org/jira/browse/MSITE-821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16449839#comment-16449839
 ] 

Hervé Boutemy commented on MSITE-821:
-

https://gitbox.apache.org/repos/asf?p=maven-site-plugin.git;a=commit;h=3085aac29fc29a96d6bbbf680b8df602c116bda9

> add documentation on site plugin dependencies
> -
>
> Key: MSITE-821
> URL: https://issues.apache.org/jira/browse/MSITE-821
> Project: Maven Site Plugin
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 3.7
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>Priority: Major
> Fix For: 3.7.1
>
>
> useful to know which version of Doxia, Doxia Sitetools & Reporting Executor 
> is used by which version of maven-site-plugin



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MSITE-821) add documentation on site plugin dependencies

2018-04-24 Thread Hudson (JIRA) 

[ 
https://issues.apache.org/jira/browse/MSITE-821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16449838#comment-16449838
 ] 

Hudson commented on MSITE-821:
--

Build failed in Jenkins: Maven TLP » maven-site-plugin » master #37

See https://builds.apache.org/job/maven-box/job/maven-site-plugin/job/master/37/

> add documentation on site plugin dependencies
> -
>
> Key: MSITE-821
> URL: https://issues.apache.org/jira/browse/MSITE-821
> Project: Maven Site Plugin
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 3.7
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>Priority: Major
> Fix For: 3.7.1
>
>
> useful to know which version of Doxia, Doxia Sitetools & Reporting Executor 
> is used by which version of maven-site-plugin



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (MSITE-821) add documentation on site plugin dependencies

2018-04-24 Thread JIRA 
Hervé Boutemy created MSITE-821:
---

 Summary: add documentation on site plugin dependencies
 Key: MSITE-821
 URL: https://issues.apache.org/jira/browse/MSITE-821
 Project: Maven Site Plugin
  Issue Type: Task
  Components: documentation
Affects Versions: 3.7
Reporter: Hervé Boutemy
Assignee: Hervé Boutemy
 Fix For: 3.7.1


useful to know which version of Doxia, Doxia Sitetools & Reporting Executor is 
used by which version of maven-site-plugin



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (MDEP-608) copy goal should support setting (executable) permissions

2018-04-24 Thread Julius Schwartzenberg (JIRA) 
Julius Schwartzenberg created MDEP-608:
--

 Summary: copy goal should support setting (executable) permissions
 Key: MDEP-608
 URL: https://issues.apache.org/jira/browse/MDEP-608
 Project: Maven Dependency Plugin
  Issue Type: Improvement
Reporter: Julius Schwartzenberg


We have some executables in Nexus as build artifacts. The native plug-in 
generates those for instance. When we copy them to the target directory so that 
they can be used with our integration tests, they are not executable however as 
{{chmod +x}} is still needed.

It would be nice if the copy goal would support this.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ARCHETYPE-547) triple underlines

2018-04-24 Thread Dorin Brage (JIRA) 

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

Dorin Brage updated ARCHETYPE-547:
--
Summary: triple underlines  (was: triple underline)

> triple underlines
> -
>
> Key: ARCHETYPE-547
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-547
> Project: Maven Archetype
>  Issue Type: Bug
>  Components: Archetypes
>Affects Versions: 3.0.1
>Reporter: Dorin Brage
>Priority: Major
>
> Let's say you have the next path
> {code:java}
> /src/main/resources/50rootArtifactId__.ui/
> |---local___rootArtifactId__.properties
> |---prod___rootArtifactId__.properties  {code}
> I want to achieve 
>  
> {code:java}
> /src/main/resources/50_demoApp.ui/
> |---local_demoApp.ui.properties
> |---prod_demoApp.ui.properties  
> {code}
> The console output
>  
> {code:java}
> [WARNING] Property '_rootArtifactId' was not specified, so the token in 
> 'src/main/resources/50___rootArtifactId__.ui/local___rootArtifactId__.properties
> {code}
>  
> Workaround 
> Avoid adding as a prefix/suffix extra underlines
> {code:java}
> 50.__rootArtifactId__.ui
> {code}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (ARCHETYPE-547) triple underline

2018-04-24 Thread Dorin Brage (JIRA) 
Dorin Brage created ARCHETYPE-547:
-

 Summary: triple underline
 Key: ARCHETYPE-547
 URL: https://issues.apache.org/jira/browse/ARCHETYPE-547
 Project: Maven Archetype
  Issue Type: Bug
  Components: Archetypes
Affects Versions: 3.0.1
Reporter: Dorin Brage


Let's say you have the next path
{code:java}
/src/main/resources/50rootArtifactId__.ui/
|---local___rootArtifactId__.properties
|---prod___rootArtifactId__.properties  {code}
I want to achieve 

 
{code:java}
/src/main/resources/50_demoApp.ui/
|---local_demoApp.ui.properties
|---prod_demoApp.ui.properties  
{code}
The console output

 
{code:java}
[WARNING] Property '_rootArtifactId' was not specified, so the token in 
'src/main/resources/50___rootArtifactId__.ui/local___rootArtifactId__.properties
{code}
 

Workaround 

Avoid adding as a prefix/suffix extra underlines
{code:java}
50.__rootArtifactId__.ui
{code}
 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WAGON-518) AbstractHttpClientWagon#putFromStream() reads entire content to memory

2018-04-24 Thread Michael Osipov (JIRA) 

[ 
https://issues.apache.org/jira/browse/WAGON-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16449427#comment-16449427
 ] 

Michael Osipov commented on WAGON-518:
--

As soon as I push the branch, Jenkins will run alls tests on it. The tests work 
for me on Windows 10 and FreeBSD 11.1-RELEASE. Please checkout the branch and 
test. You need to build a custom Maven versoin with this if you want to test 
Wagon with Maven.

> AbstractHttpClientWagon#putFromStream() reads entire content to memory
> --
>
> Key: WAGON-518
> URL: https://issues.apache.org/jira/browse/WAGON-518
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-http
>Affects Versions: 2.12
>Reporter: Chris Lott
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.1.0
>
>
> Method putFromSteam in class AbstractHttpClientWagon seems to violate the 
> implied contract of working with streams.  It uses much memory because it 
> first consumes the input stream argument, then transfers that content.  The 
> code that consumes the stream is in the private class 
> RequestEntityImplementation ctor:
> {code:java}
>      byte[] bytes = IOUtil.toByteArray( stream );{code}
> Please revise it, if possible, to behave more like the superclass 
> StreamWagon's putFromStream method, which does the transfer straight from the 
> input stream.
> We are attempting to PUT some 150MB artifacts in a java microservice that 
> runs with rather sharp memory limits.  As a local workaround we increased the 
> JVM's -Xmx argument but that way lies madness.
> Thanks in advance for any suggestions or workarounds. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6391) Printout version of last built module in reactor build

2018-04-24 Thread Michael Osipov (JIRA) 

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

Michael Osipov commented on MNG-6391:
-

This still looks displaced for me. Why not say {{Reactor Summary 
(4.0.0-SNAPSHOT)}}? In the case of an aggregator this wouldn't be there, but 
would be on every module.

> Printout version of last built module in reactor build
> --
>
> Key: MNG-6391
> URL: https://issues.apache.org/jira/browse/MNG-6391
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 3.5.3
>Reporter: Alexander Griesbaum
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.4
>
>
> MNG-6352 introduced printout of the version in a reactor build.
> If I build a multi-module project, not just the parent has the version 
> printout but also the last built module.
> {code:java}
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO] 
> [INFO] parent 4.0.0-SNAPSHOT . SUCCESS [ 3.610 s]
> [INFO] parent-lib  SUCCESS [ 0.492 s]
> [INFO] commons ... SUCCESS [ 25.444 s]
> [INFO] loadbalancer-starter .. SUCCESS [ 21.198 s]
> [INFO] proxy-config-starter 4.0.0-SNAPSHOT ... SUCCESS [ 7.496 s]
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> {code}
> If I remove the "proxy-config-starter" module, "loadbalancer-starter" got the 
> version printout.
> Also this is not the order I configured the modules in the parent pom but I 
> think this could be something on my side.
> {code:java}
> 
> commons
> loadbalancer-starter
> parent-lib
> proxy-config-starter
> 
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SUREFIRE-1508) SurefireBooterForkException with Maven 3.5.3

2018-04-24 Thread Andreas Gudian (JIRA) 

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16449400#comment-16449400
 ] 

Andreas Gudian commented on SUREFIRE-1508:
--

I'm not talking about the maven image, I'm talking about the openjdk image:

Alpine {{ps}} doesn't support {{-p}}
{code}
> docker run --rm openjdk:8-jdk-alpine /bin/ps -p 1
/bin/ps: unrecognized option: p
{code}

Debian slim doesn't come with {{ps}} out of the box, thus the check is 
disabled, unless the {{procps}} package is being installed (like it is for the 
latest Maven images, which is not used everywhere):
{code}
> docker run --rm openjdk:8-jdk-slim which ps
> (nothing)
{code}

So how about checking the exit code of {{ps -p 1}} in the PpidChecker and if 
it's not 0, then use an alternative alive-check? (process id 1 should always be 
available, right?). Or don't use {{ps -p}} on linux and check the file 
{{/proc//stat}}?

> SurefireBooterForkException with Maven 3.5.3
> 
>
> Key: SUREFIRE-1508
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1508
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
> Environment: Docker Image maven:3.5.2-jdk-8
> SpringBoot Application testet with Spring Platform Versions Brussels-SR7 and 
> Brussels-SR3
>Reporter: Pertschy Simon
>Priority: Major
> Attachments: 2018-03-28T16-00-51_221-jvmRun1.dump, 
> failsafe-summary.xml
>
>
> Running junit integration tests with Maven 3.5.3 gives 
> org.apache.maven.surefire.booter.SurefireBooterForkException. 
> With Maven 3.5.2 everything runs fine.
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-failsafe-plugin:2.20.1:verify (default) on 
> project explosive: There are test failures.
> [ERROR] 
> [ERROR] Please refer to /usr/src/mymaven/target/failsafe-reports for the 
> individual test results.
> [ERROR] Please refer to dump files (if any exist) [date]-jvmRun[N].dump, 
> [date].dumpstream and [date]-jvmRun[N].dumpstream.
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: The 
> forked VM terminated without properly saying goodbye. VM crash or System.exit 
> called?
> [ERROR] Command was /bin/sh -c cd /usr/src/mymaven && 
> /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java -Dfile.encoding=UTF-8 -jar 
> /usr/src/mymaven/target/surefire/surefirebooter8650244765410237450.jar 
> /usr/src/mymaven/target/surefire 2018-03-28T16-00-51_221-jvmRun1 
> surefire1685882686721224264tmp surefire_03464518048239249547tmp
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] Process Exit Code: 1
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:686)
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:535)
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:280)
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
> [ERROR] at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1124)
> [ERROR] at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:954)
> [ERROR] at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:832)
> [ERROR] at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
> [ERROR] at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> [ERROR] at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> [ERROR] at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> [ERROR] at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> [ERROR] at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> [ERROR] at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
> [ERROR] at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> [ERROR] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
> [ERROR] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
> [ERROR] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
> [ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:956)
> [ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:290)
> [ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:194)
> [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [ERROR] at 
>

[jira] [Commented] (MSITE-812) Missing '/' in log when deploying documentation by site:stage

2018-04-24 Thread Akira Ajisaka (JIRA) 

[ 
https://issues.apache.org/jira/browse/MSITE-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16449364#comment-16449364
 ] 

Akira Ajisaka commented on MSITE-812:
-

Thanks [~hboutemy] for the additional fix!

> Missing '/' in log when deploying documentation by site:stage
> -
>
> Key: MSITE-812
> URL: https://issues.apache.org/jira/browse/MSITE-812
> Project: Maven Site Plugin
>  Issue Type: Bug
>  Components: site:stage(-deploy)
>Affects Versions: 3.7
>Reporter: Akira Ajisaka
>Assignee: Hervé Boutemy
>Priority: Major
> Fix For: 3.7.1
>
>
> When running {{mvn site:stage -DstagingDirectory=/Users/ajisaka/YARN-7736}} 
> {noformat}
> [INFO] 
> 
> [INFO] Building Apache Hadoop Project POM 3.2.0-SNAPSHOT
> [INFO] 
> 
> [INFO] 
> [INFO] --- maven-site-plugin:3.7:stage (default-cli) @ hadoop-project ---
> [INFO] Using this base directory for staging: /Users/ajisaka/YARN-7736
> [INFO] Pushing /Users/ajisaka/git/hadoop/hadoop-project/target/site
> [INFO]>>> to file:///Users/ajisaka/YARN-7736hadoop-project
> {noformat}
> '/' is missing between YARN-7736 and hadoop-project.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MNG-6394) ${revision} and parent.releativePath

2018-04-24 Thread Dorian Vallant (JIRA) 

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

Dorian Vallant updated MNG-6394:

Attachment: test-projects-flatten.jar

> ${revision} and parent.releativePath
> 
>
> Key: MNG-6394
> URL: https://issues.apache.org/jira/browse/MNG-6394
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.5.3
> Environment: Ubuntu 17.10; Maven 3.5.3; Java 1.8.0_161
>Reporter: Dorian Vallant
>Priority: Major
> Attachments: test-projects-flatten.jar, test-projects.jar, 
> test-projects.jar
>
>
> If the CI friendly ${revision} property is used it seems maven does not 
> simple replace the property with the given value.
> Consider the following example:
> parent-project/
>      pom.xml
>  child-project/
>      pom.xml
> parent-project/pom.xml:
> ...
>     my.group
>     parentArtifact
>     ${revision}
>     pom
> ...
> child-project/pom.xml:
>   
> my.group
> parentArtifact
> ${revision}
> ../parent-project
>   
> If you build the child-project with 'mvn -Drevision=1.0.0-SNAPSHOT -f 
> child-project/pom.xml clean install' all works fine as long as the parent 
> project is present in the file system. But if you move the parent project to 
> another place, build & install it to your local repository and then try to 
> build the child project, maven tries to download the pom.xml of the parent 
> project but does not replace ${revision}. So maven complains about a missing 
> dependency.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6394) ${revision} and parent.releativePath

2018-04-24 Thread Dorian Vallant (JIRA) 

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

Dorian Vallant commented on MNG-6394:
-

Same example with maven-flatten-plugin included...

 [^test-projects-flatten.jar] 

> ${revision} and parent.releativePath
> 
>
> Key: MNG-6394
> URL: https://issues.apache.org/jira/browse/MNG-6394
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.5.3
> Environment: Ubuntu 17.10; Maven 3.5.3; Java 1.8.0_161
>Reporter: Dorian Vallant
>Priority: Major
> Attachments: test-projects-flatten.jar, test-projects.jar, 
> test-projects.jar
>
>
> If the CI friendly ${revision} property is used it seems maven does not 
> simple replace the property with the given value.
> Consider the following example:
> parent-project/
>      pom.xml
>  child-project/
>      pom.xml
> parent-project/pom.xml:
> ...
>     my.group
>     parentArtifact
>     ${revision}
>     pom
> ...
> child-project/pom.xml:
>   
> my.group
> parentArtifact
> ${revision}
> ../parent-project
>   
> If you build the child-project with 'mvn -Drevision=1.0.0-SNAPSHOT -f 
> child-project/pom.xml clean install' all works fine as long as the parent 
> project is present in the file system. But if you move the parent project to 
> another place, build & install it to your local repository and then try to 
> build the child project, maven tries to download the pom.xml of the parent 
> project but does not replace ${revision}. So maven complains about a missing 
> dependency.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Issue Comment Deleted] (MNG-6394) ${revision} and parent.releativePath

2018-04-24 Thread Dorian Vallant (JIRA) 

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

Dorian Vallant updated MNG-6394:

Comment: was deleted

(was: Same example with maven-flatten-plugin included in parent's pom.xml...

 [^test-projects.jar] )

> ${revision} and parent.releativePath
> 
>
> Key: MNG-6394
> URL: https://issues.apache.org/jira/browse/MNG-6394
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.5.3
> Environment: Ubuntu 17.10; Maven 3.5.3; Java 1.8.0_161
>Reporter: Dorian Vallant
>Priority: Major
> Attachments: test-projects.jar, test-projects.jar
>
>
> If the CI friendly ${revision} property is used it seems maven does not 
> simple replace the property with the given value.
> Consider the following example:
> parent-project/
>      pom.xml
>  child-project/
>      pom.xml
> parent-project/pom.xml:
> ...
>     my.group
>     parentArtifact
>     ${revision}
>     pom
> ...
> child-project/pom.xml:
>   
> my.group
> parentArtifact
> ${revision}
> ../parent-project
>   
> If you build the child-project with 'mvn -Drevision=1.0.0-SNAPSHOT -f 
> child-project/pom.xml clean install' all works fine as long as the parent 
> project is present in the file system. But if you move the parent project to 
> another place, build & install it to your local repository and then try to 
> build the child project, maven tries to download the pom.xml of the parent 
> project but does not replace ${revision}. So maven complains about a missing 
> dependency.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6394) ${revision} and parent.releativePath

2018-04-24 Thread Dorian Vallant (JIRA) 

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

Dorian Vallant commented on MNG-6394:
-

Same example with maven-flatten-plugin included in parent's pom.xml...

 [^test-projects.jar] 

> ${revision} and parent.releativePath
> 
>
> Key: MNG-6394
> URL: https://issues.apache.org/jira/browse/MNG-6394
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.5.3
> Environment: Ubuntu 17.10; Maven 3.5.3; Java 1.8.0_161
>Reporter: Dorian Vallant
>Priority: Major
> Attachments: test-projects.jar, test-projects.jar
>
>
> If the CI friendly ${revision} property is used it seems maven does not 
> simple replace the property with the given value.
> Consider the following example:
> parent-project/
>      pom.xml
>  child-project/
>      pom.xml
> parent-project/pom.xml:
> ...
>     my.group
>     parentArtifact
>     ${revision}
>     pom
> ...
> child-project/pom.xml:
>   
> my.group
> parentArtifact
> ${revision}
> ../parent-project
>   
> If you build the child-project with 'mvn -Drevision=1.0.0-SNAPSHOT -f 
> child-project/pom.xml clean install' all works fine as long as the parent 
> project is present in the file system. But if you move the parent project to 
> another place, build & install it to your local repository and then try to 
> build the child project, maven tries to download the pom.xml of the parent 
> project but does not replace ${revision}. So maven complains about a missing 
> dependency.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MNG-6394) ${revision} and parent.releativePath

2018-04-24 Thread Dorian Vallant (JIRA) 

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

Dorian Vallant updated MNG-6394:

Attachment: test-projects.jar

> ${revision} and parent.releativePath
> 
>
> Key: MNG-6394
> URL: https://issues.apache.org/jira/browse/MNG-6394
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.5.3
> Environment: Ubuntu 17.10; Maven 3.5.3; Java 1.8.0_161
>Reporter: Dorian Vallant
>Priority: Major
> Attachments: test-projects.jar, test-projects.jar
>
>
> If the CI friendly ${revision} property is used it seems maven does not 
> simple replace the property with the given value.
> Consider the following example:
> parent-project/
>      pom.xml
>  child-project/
>      pom.xml
> parent-project/pom.xml:
> ...
>     my.group
>     parentArtifact
>     ${revision}
>     pom
> ...
> child-project/pom.xml:
>   
> my.group
> parentArtifact
> ${revision}
> ../parent-project
>   
> If you build the child-project with 'mvn -Drevision=1.0.0-SNAPSHOT -f 
> child-project/pom.xml clean install' all works fine as long as the parent 
> project is present in the file system. But if you move the parent project to 
> another place, build & install it to your local repository and then try to 
> build the child project, maven tries to download the pom.xml of the parent 
> project but does not replace ${revision}. So maven complains about a missing 
> dependency.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (MSITE-817) inherit edit value in site.xml

2018-04-24 Thread JIRA 

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

Hervé Boutemy closed MSITE-817.
---
Resolution: Fixed

https://gitbox.apache.org/repos/asf?p=maven-site-plugin.git=commit=1042495efdaa4329e3f68548d04b7554435b1b18

> inherit edit value in site.xml
> --
>
> Key: MSITE-817
> URL: https://issues.apache.org/jira/browse/MSITE-817
> Project: Maven Site Plugin
>  Issue Type: Bug
>  Components: doxia integration
>Affects Versions: 3.7
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>Priority: Major
> Fix For: 3.7.1
>
>
> see DOXIASITETOOLS-187



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (MSITE-812) Missing '/' in log when deploying documentation by site:stage

2018-04-24 Thread JIRA 

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

Hervé Boutemy closed MSITE-812.
---
Resolution: Fixed
  Assignee: Hervé Boutemy

https://gitbox.apache.org/repos/asf?p=maven-site-plugin.git=commit=348b9fcc58e5fc4a42691ca2ecd49201a055e4d3

> Missing '/' in log when deploying documentation by site:stage
> -
>
> Key: MSITE-812
> URL: https://issues.apache.org/jira/browse/MSITE-812
> Project: Maven Site Plugin
>  Issue Type: Bug
>  Components: site:stage(-deploy)
>Affects Versions: 3.7
>Reporter: Akira Ajisaka
>Assignee: Hervé Boutemy
>Priority: Major
> Fix For: 3.7.1
>
>
> When running {{mvn site:stage -DstagingDirectory=/Users/ajisaka/YARN-7736}} 
> {noformat}
> [INFO] 
> 
> [INFO] Building Apache Hadoop Project POM 3.2.0-SNAPSHOT
> [INFO] 
> 
> [INFO] 
> [INFO] --- maven-site-plugin:3.7:stage (default-cli) @ hadoop-project ---
> [INFO] Using this base directory for staging: /Users/ajisaka/YARN-7736
> [INFO] Pushing /Users/ajisaka/git/hadoop/hadoop-project/target/site
> [INFO]>>> to file:///Users/ajisaka/YARN-7736hadoop-project
> {noformat}
> '/' is missing between YARN-7736 and hadoop-project.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)