[jira] [Commented] (MDEP-691) useBaseVersion ignored when resolving artifacts from lolcal repostory (works from remote)

2020-05-20 Thread Jakub Bochenski (Jira)


[ 
https://issues.apache.org/jira/browse/MDEP-691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112271#comment-17112271
 ] 

Jakub Bochenski commented on MDEP-691:
--

I think in the end it boils down to the presence of 
{{groupId/artifactId/version-SNAPSHOT/maven-metadata.xml}}
Typically this file is included in remote repositories, but its not present in 
the local repository for some reason. Instead there are files like 
{{groupId/artifactId/version-SNAPSHOT/maven-metadata-REPOSITORY_ID.xml}} but 
the code that tries to resolve the version fails to read those. 


> useBaseVersion ignored when resolving artifacts from lolcal repostory (works 
> from remote)
> -
>
> Key: MDEP-691
> URL: https://issues.apache.org/jira/browse/MDEP-691
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: copy
>Reporter: Jakub Bochenski
>Priority: Major
>
> Please compare the results. {{-Psonatype}} enables remote sonatype snapshots 
> repository.
> {code}$ mvn   dependency:copy 
> -Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -Psonatype 
> -U -Dmdep.useBaseVersion=false | grep Copying
> [INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
> /home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-20190311.143402-1.jar
> $ rm -rf '/home/bochja/${project.basedir}/target/dependency'
> $ mvn   dependency:copy 
> -Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -Psonatype 
> -U -Dmdep.useBaseVersion=true | grep Copying
> [INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
> /home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-SNAPSHOT.jar
> $ rm -rf '/home/bochja/${project.basedir}/target/dependency'
> $ mvn   dependency:copy 
> -Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -o 
> -Dmdep.useBaseVersion=true | grep Copying
> [INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
> /home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-SNAPSHOT.jar
> $ rm -rf '/home/bochja/${project.basedir}/target/dependency'
> $ mvn   dependency:copy 
> -Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -o 
> -Dmdep.useBaseVersion=false | grep Copying
> [INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
> /home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-SNAPSHOT.jar
> $ ls ~/.m2/repository/com/trello/identifier/package-identifier/0.0.2-SNAPSHOT/
> maven-metadata-sonatype.xml  maven-metadata-sonatype.xml.sha1  
> package-identifier-0.0.2-20190311.143402-1.jar  
> package-identifier-0.0.2-20190311.143402-1.jar.sha1  
> package-identifier-0.0.2-SNAPSHOT.jar  _remote.repositories  
> resolver-status.properties
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (MDEP-691) useBaseVersion ignored when resolving artifacts from lolcal repostory (works from remote)

2020-05-20 Thread Jakub Bochenski (Jira)


[ 
https://issues.apache.org/jira/browse/MDEP-691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112271#comment-17112271
 ] 

Jakub Bochenski edited comment on MDEP-691 at 5/20/20, 2:25 PM:


I think in the end it boils down to the presence of 
{{groupId/artifactId/version-SNAPSHOT/maven-metadata.xml}}
Typically this file is included in remote repositories, but its not present in 
the local repository for some reason.
Instead there are files like 
{{groupId/artifactId/version-SNAPSHOT/maven-metadata-REPOSITORY_ID.xml}} but 
the code that tries to resolve the version fails to read those. 



was (Author: jbochenski):
I think in the end it boils down to the presence of 
{{groupId/artifactId/version-SNAPSHOT/maven-metadata.xml}}
Typically this file is included in remote repositories, but its not present in 
the local repository for some reason. Instead there are files like 
{{groupId/artifactId/version-SNAPSHOT/maven-metadata-REPOSITORY_ID.xml}} but 
the code that tries to resolve the version fails to read those. 


> useBaseVersion ignored when resolving artifacts from lolcal repostory (works 
> from remote)
> -
>
> Key: MDEP-691
> URL: https://issues.apache.org/jira/browse/MDEP-691
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: copy
>Reporter: Jakub Bochenski
>Priority: Major
>
> Please compare the results. {{-Psonatype}} enables remote sonatype snapshots 
> repository.
> {code}$ mvn   dependency:copy 
> -Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -Psonatype 
> -U -Dmdep.useBaseVersion=false | grep Copying
> [INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
> /home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-20190311.143402-1.jar
> $ rm -rf '/home/bochja/${project.basedir}/target/dependency'
> $ mvn   dependency:copy 
> -Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -Psonatype 
> -U -Dmdep.useBaseVersion=true | grep Copying
> [INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
> /home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-SNAPSHOT.jar
> $ rm -rf '/home/bochja/${project.basedir}/target/dependency'
> $ mvn   dependency:copy 
> -Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -o 
> -Dmdep.useBaseVersion=true | grep Copying
> [INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
> /home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-SNAPSHOT.jar
> $ rm -rf '/home/bochja/${project.basedir}/target/dependency'
> $ mvn   dependency:copy 
> -Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -o 
> -Dmdep.useBaseVersion=false | grep Copying
> [INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
> /home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-SNAPSHOT.jar
> $ ls ~/.m2/repository/com/trello/identifier/package-identifier/0.0.2-SNAPSHOT/
> maven-metadata-sonatype.xml  maven-metadata-sonatype.xml.sha1  
> package-identifier-0.0.2-20190311.143402-1.jar  
> package-identifier-0.0.2-20190311.143402-1.jar.sha1  
> package-identifier-0.0.2-SNAPSHOT.jar  _remote.repositories  
> resolver-status.properties
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (MDEP-691) useBaseVersion ignored when resolving artifacts from lolcal repostory (works from remote)

2020-05-07 Thread Jakub Bochenski (Jira)


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

Jakub Bochenski updated MDEP-691:
-
Description: 
Please compare the results. {{-Psonatype}} enables remote sonatype snapshots 
repository.

{code}$ mvn   dependency:copy 
-Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -Psonatype 
-U -Dmdep.useBaseVersion=false | grep Copying
[INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
/home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-20190311.143402-1.jar
$ rm -rf '/home/bochja/${project.basedir}/target/dependency'
$ mvn   dependency:copy 
-Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -Psonatype 
-U -Dmdep.useBaseVersion=true | grep Copying
[INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
/home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-SNAPSHOT.jar
$ rm -rf '/home/bochja/${project.basedir}/target/dependency'
$ mvn   dependency:copy 
-Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -o 
-Dmdep.useBaseVersion=true | grep Copying
[INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
/home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-SNAPSHOT.jar
$ rm -rf '/home/bochja/${project.basedir}/target/dependency'
$ mvn   dependency:copy 
-Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -o 
-Dmdep.useBaseVersion=false | grep Copying
[INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
/home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-SNAPSHOT.jar
$ ls ~/.m2/repository/com/trello/identifier/package-identifier/0.0.2-SNAPSHOT/
maven-metadata-sonatype.xml  maven-metadata-sonatype.xml.sha1  
package-identifier-0.0.2-20190311.143402-1.jar  
package-identifier-0.0.2-20190311.143402-1.jar.sha1  
package-identifier-0.0.2-SNAPSHOT.jar  _remote.repositories  
resolver-status.properties
{code}

  was:
Please compare the results. {{-Psonatype}} enables remote sonatype snapshots 
repository.

{code}$ mvn   dependency:copy 
-Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -Psonatype 
-U -Dmdep.useBaseVersion=false | grep Copying
[INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
/home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-20190311.143402-1.jar
$ rm -rf '/home/bochja/${project.basedir}/target/dependency'
$ mvn   dependency:copy 
-Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -Psonatype 
-U -Dmdep.useBaseVersion=true | grep Copying
[INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
/home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-SNAPSHOT.jar
$ rm -rf '/home/bochja/${project.basedir}/target/dependency'
$ mvn   dependency:copy 
-Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -o 
-Dmdep.useBaseVersion=true | grep Copying
[INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
/home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-SNAPSHOT.jar
$ rm -rf '/home/bochja/${project.basedir}/target/dependency'
$ mvn   dependency:copy 
-Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -o 
-Dmdep.useBaseVersion=false | grep Copying
[INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
/home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-SNAPSHOT.jar
{code}


> useBaseVersion ignored when resolving artifacts from lolcal repostory (works 
> from remote)
> -
>
> Key: MDEP-691
> URL: https://issues.apache.org/jira/browse/MDEP-691
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: copy
>Reporter: Jakub Bochenski
>Priority: Major
>
> Please compare the results. {{-Psonatype}} enables remote sonatype snapshots 
> repository.
> {code}$ mvn   dependency:copy 
> -Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -Psonatype 
> -U -Dmdep.useBaseVersion=false | grep Copying
> [INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
> /home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-20190311.143402-1.jar
> $ rm -rf '/home/bochja/${project.basedir}/target/dependency'
> $ mvn   dependency:copy 
> -Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -Psonatype 
> -U -Dmdep.useBaseVersion=true | grep Copying
> [INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
> /home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-SNAPSHOT.jar
> $ rm -rf '/home/bochja/${project.basedir}/target/dependency'
> $ mvn   dependency:copy 
> -Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -o 
> -Dmdep.useBaseVersion=true | grep Copying
> [INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
> 

[jira] [Updated] (MDEP-691) useBaseVersion ignored when resolving artifacts from lolcal repostory (works from remote)

2020-05-07 Thread Jakub Bochenski (Jira)


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

Jakub Bochenski updated MDEP-691:
-
Description: 
Please compare the results. {{-Psonatype}} enables remote sonatype snapshots 
repository.

{code}$ mvn   dependency:copy 
-Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -Psonatype 
-U -Dmdep.useBaseVersion=false | grep Copying
[INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
/home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-20190311.143402-1.jar
$ rm -rf '/home/bochja/${project.basedir}/target/dependency'
$ mvn   dependency:copy 
-Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -Psonatype 
-U -Dmdep.useBaseVersion=true | grep Copying
[INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
/home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-SNAPSHOT.jar
$ rm -rf '/home/bochja/${project.basedir}/target/dependency'
$ mvn   dependency:copy 
-Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -o 
-Dmdep.useBaseVersion=true | grep Copying
[INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
/home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-SNAPSHOT.jar
$ rm -rf '/home/bochja/${project.basedir}/target/dependency'
$ mvn   dependency:copy 
-Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -o 
-Dmdep.useBaseVersion=false | grep Copying
[INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
/home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-SNAPSHOT.jar
{code}

  was:
Please compare the results. {{-Psonatype}} enables remote sonatype snapshots 
repository.

{code}$ mvn   dependency:copy 
-Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -Psonatype 
-U -Dmdep.useBaseVersion=false | grep Copying
[INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
/home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-20190311.143402-1.jar
$ rm -rf '/home/bochja/${project.basedir}/target/dependency'
$ mvn   dependency:copy 
-Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -Psonatype 
-U -Dmdep.useBaseVersion=true | grep Copying
$ rm -rf '/home/bochja/${project.basedir}/target/dependency'
$ mvn   dependency:copy 
-Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -o 
-Dmdep.useBaseVersion=true | grep Copying
[INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
/home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-SNAPSHOT.jar
$ rm -rf '/home/bochja/${project.basedir}/target/dependency'
$ mvn   dependency:copy 
-Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -o 
-Dmdep.useBaseVersion=false | grep Copying
[INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
/home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-SNAPSHOT.jar
{code}


> useBaseVersion ignored when resolving artifacts from lolcal repostory (works 
> from remote)
> -
>
> Key: MDEP-691
> URL: https://issues.apache.org/jira/browse/MDEP-691
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: copy
>Reporter: Jakub Bochenski
>Priority: Major
>
> Please compare the results. {{-Psonatype}} enables remote sonatype snapshots 
> repository.
> {code}$ mvn   dependency:copy 
> -Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -Psonatype 
> -U -Dmdep.useBaseVersion=false | grep Copying
> [INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
> /home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-20190311.143402-1.jar
> $ rm -rf '/home/bochja/${project.basedir}/target/dependency'
> $ mvn   dependency:copy 
> -Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -Psonatype 
> -U -Dmdep.useBaseVersion=true | grep Copying
> [INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
> /home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-SNAPSHOT.jar
> $ rm -rf '/home/bochja/${project.basedir}/target/dependency'
> $ mvn   dependency:copy 
> -Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -o 
> -Dmdep.useBaseVersion=true | grep Copying
> [INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
> /home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-SNAPSHOT.jar
> $ rm -rf '/home/bochja/${project.basedir}/target/dependency'
> $ mvn   dependency:copy 
> -Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -o 
> -Dmdep.useBaseVersion=false | grep Copying
> [INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
> /home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-SNAPSHOT.jar
> {code}



--
This message was sent by Atlassian Jira

[jira] [Updated] (MDEP-691) useBaseVersion ignored when resolving artifacts from lolcal repostory (works from remote)

2020-05-07 Thread Jakub Bochenski (Jira)


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

Jakub Bochenski updated MDEP-691:
-
Description: 
Please compare the results. {{-Psonatype}} enables remote sonatype snapshots 
repository.

{code}$ mvn   dependency:copy 
-Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -Psonatype 
-U -Dmdep.useBaseVersion=false | grep Copying
[INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
/home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-20190311.143402-1.jar
$ rm -rf '/home/bochja/${project.basedir}/target/dependency'
$ mvn   dependency:copy 
-Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -Psonatype 
-U -Dmdep.useBaseVersion=true | grep Copying
$ rm -rf '/home/bochja/${project.basedir}/target/dependency'
$ mvn   dependency:copy 
-Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -o 
-Dmdep.useBaseVersion=true | grep Copying
[INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
/home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-SNAPSHOT.jar
$ rm -rf '/home/bochja/${project.basedir}/target/dependency'
$ mvn   dependency:copy 
-Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -o 
-Dmdep.useBaseVersion=false | grep Copying
[INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
/home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-SNAPSHOT.jar
{code}

  was:
Please compare the results. {{-Psonatype}} enables remote sonatype snapshots 
repository.

{code}bochja@bochja-Latitude-7480:~$ mvn   dependency:copy 
-Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -Psonatype 
-U -Dmdep.useBaseVersion=false | grep Copying
[INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
/home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-20190311.143402-1.jar
bochja@bochja-Latitude-7480:~$ rm -rf 
'/home/bochja/${project.basedir}/target/dependency'
bochja@bochja-Latitude-7480:~$ mvn   dependency:copy 
-Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -Psonatype 
-U -Dmdep.useBaseVersion=true | grep Copying
[INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
/home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-SNAPSHOT.jar
bochja@bochja-Latitude-7480:~$ rm -rf 
'/home/bochja/${project.basedir}/target/dependency'
bochja@bochja-Latitude-7480:~$ mvn   dependency:copy 
-Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -o 
-Dmdep.useBaseVersion=true | grep Copying
[INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
/home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-SNAPSHOT.jar
bochja@bochja-Latitude-7480:~$ rm -rf 
'/home/bochja/${project.basedir}/target/dependency'
bochja@bochja-Latitude-7480:~$ mvn   dependency:copy 
-Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -o 
-Dmdep.useBaseVersion=false | grep Copying
[INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
/home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-SNAPSHOT.jar
{code}


> useBaseVersion ignored when resolving artifacts from lolcal repostory (works 
> from remote)
> -
>
> Key: MDEP-691
> URL: https://issues.apache.org/jira/browse/MDEP-691
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: copy
>Reporter: Jakub Bochenski
>Priority: Major
>
> Please compare the results. {{-Psonatype}} enables remote sonatype snapshots 
> repository.
> {code}$ mvn   dependency:copy 
> -Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -Psonatype 
> -U -Dmdep.useBaseVersion=false | grep Copying
> [INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
> /home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-20190311.143402-1.jar
> $ rm -rf '/home/bochja/${project.basedir}/target/dependency'
> $ mvn   dependency:copy 
> -Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -Psonatype 
> -U -Dmdep.useBaseVersion=true | grep Copying
> $ rm -rf '/home/bochja/${project.basedir}/target/dependency'
> $ mvn   dependency:copy 
> -Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -o 
> -Dmdep.useBaseVersion=true | grep Copying
> [INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
> /home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-SNAPSHOT.jar
> $ rm -rf '/home/bochja/${project.basedir}/target/dependency'
> $ mvn   dependency:copy 
> -Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -o 
> -Dmdep.useBaseVersion=false | grep Copying
> [INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
> /home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-SNAPSHOT.jar
> 

[jira] [Updated] (MDEP-691) useBaseVersion ignored when resolving artifacts from lolcal repostory (works from remote)

2020-05-07 Thread Jakub Bochenski (Jira)


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

Jakub Bochenski updated MDEP-691:
-
Description: 
Please compare the results. {{-Psonatype}} enables remote sonatype snapshots 
repository.

{code}bochja@bochja-Latitude-7480:~$ mvn   dependency:copy 
-Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -Psonatype 
-U -Dmdep.useBaseVersion=false | grep Copying
[INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
/home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-20190311.143402-1.jar
bochja@bochja-Latitude-7480:~$ rm -rf 
'/home/bochja/${project.basedir}/target/dependency'
bochja@bochja-Latitude-7480:~$ mvn   dependency:copy 
-Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -Psonatype 
-U -Dmdep.useBaseVersion=true | grep Copying
[INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
/home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-SNAPSHOT.jar
bochja@bochja-Latitude-7480:~$ rm -rf 
'/home/bochja/${project.basedir}/target/dependency'
bochja@bochja-Latitude-7480:~$ mvn   dependency:copy 
-Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -o 
-Dmdep.useBaseVersion=true | grep Copying
[INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
/home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-SNAPSHOT.jar
bochja@bochja-Latitude-7480:~$ rm -rf 
'/home/bochja/${project.basedir}/target/dependency'
bochja@bochja-Latitude-7480:~$ mvn   dependency:copy 
-Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -o 
-Dmdep.useBaseVersion=false | grep Copying
[INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
/home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-SNAPSHOT.jar
{code}

  was:It seems it's only respected by the dependency:copy-dependencies goal


> useBaseVersion ignored when resolving artifacts from lolcal repostory (works 
> from remote)
> -
>
> Key: MDEP-691
> URL: https://issues.apache.org/jira/browse/MDEP-691
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: copy
>Reporter: Jakub Bochenski
>Priority: Major
>
> Please compare the results. {{-Psonatype}} enables remote sonatype snapshots 
> repository.
> {code}bochja@bochja-Latitude-7480:~$ mvn   dependency:copy 
> -Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -Psonatype 
> -U -Dmdep.useBaseVersion=false | grep Copying
> [INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
> /home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-20190311.143402-1.jar
> bochja@bochja-Latitude-7480:~$ rm -rf 
> '/home/bochja/${project.basedir}/target/dependency'
> bochja@bochja-Latitude-7480:~$ mvn   dependency:copy 
> -Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -Psonatype 
> -U -Dmdep.useBaseVersion=true | grep Copying
> [INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
> /home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-SNAPSHOT.jar
> bochja@bochja-Latitude-7480:~$ rm -rf 
> '/home/bochja/${project.basedir}/target/dependency'
> bochja@bochja-Latitude-7480:~$ mvn   dependency:copy 
> -Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -o 
> -Dmdep.useBaseVersion=true | grep Copying
> [INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
> /home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-SNAPSHOT.jar
> bochja@bochja-Latitude-7480:~$ rm -rf 
> '/home/bochja/${project.basedir}/target/dependency'
> bochja@bochja-Latitude-7480:~$ mvn   dependency:copy 
> -Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -o 
> -Dmdep.useBaseVersion=false | grep Copying
> [INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to 
> /home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-SNAPSHOT.jar
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (MDEP-691) useBaseVersion ignored when resolving artifacts from lolcal repostory (works from remote)

2020-05-07 Thread Jakub Bochenski (Jira)


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

Jakub Bochenski updated MDEP-691:
-
Summary: useBaseVersion ignored when resolving artifacts from lolcal 
repostory (works from remote)  (was: useBaseVersion ignored for dependency:copy 
goal)

> useBaseVersion ignored when resolving artifacts from lolcal repostory (works 
> from remote)
> -
>
> Key: MDEP-691
> URL: https://issues.apache.org/jira/browse/MDEP-691
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: copy
>Reporter: Jakub Bochenski
>Priority: Major
>
> It seems it's only respected by the dependency:copy-dependencies goal



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MDEP-691) useBaseVersion ignored for dependency:copy goal

2020-05-07 Thread Jakub Bochenski (Jira)


[ 
https://issues.apache.org/jira/browse/MDEP-691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101774#comment-17101774
 ] 

Jakub Bochenski commented on MDEP-691:
--

I want the timestamped version because I need the timestamp. If you really need 
to know that the purpose is to deploy the file as an AWS lambda function and 
unique filenames help us keep track of the version. 

Now after some further testing I realized the problem seems to occur when 
resolving the artifact from local repository. It works as expected when using 
remote. 

> useBaseVersion ignored for dependency:copy goal
> ---
>
> Key: MDEP-691
> URL: https://issues.apache.org/jira/browse/MDEP-691
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: copy
>Reporter: Jakub Bochenski
>Priority: Major
>
> It seems it's only respected by the dependency:copy-dependencies goal



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MDEP-691) useBaseVersion ignored for dependency:copy goal

2020-04-24 Thread Jakub Bochenski (Jira)


[ 
https://issues.apache.org/jira/browse/MDEP-691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091475#comment-17091475
 ] 

Jakub Bochenski commented on MDEP-691:
--

The dependency:copy goal doesn't work for project dependencies in the first 
place, that would be dependency:copy-dependencies

> useBaseVersion ignored for dependency:copy goal
> ---
>
> Key: MDEP-691
> URL: https://issues.apache.org/jira/browse/MDEP-691
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: copy
>Reporter: Jakub Bochenski
>Priority: Major
>
> It seems it's only respected by the dependency:copy-dependencies goal



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MDEP-691) useBaseVersion ignored for dependency:copy goal

2020-04-24 Thread Jakub Bochenski (Jira)


[ 
https://issues.apache.org/jira/browse/MDEP-691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091473#comment-17091473
 ] 

Jakub Bochenski commented on MDEP-691:
--

I'm just trying to grab a single file and get it's timestamped version in the 
filename. 

> useBaseVersion ignored for dependency:copy goal
> ---
>
> Key: MDEP-691
> URL: https://issues.apache.org/jira/browse/MDEP-691
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: copy
>Reporter: Jakub Bochenski
>Priority: Major
>
> It seems it's only respected by the dependency:copy-dependencies goal



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MDEP-691) useBaseVersion ignored for dependency:copy goal

2020-04-24 Thread Jakub Bochenski (Jira)


[ 
https://issues.apache.org/jira/browse/MDEP-691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091465#comment-17091465
 ] 

Jakub Bochenski commented on MDEP-691:
--

I just run {code}mvnw   dependency:copy -Dartifact=${artifact} 
-Dmdep.useBaseVersion=true|false{code}

Regardless of the setting I get a file with 1-SNAPSHOT version, instead of a 
timestamped snapshot version. 

> useBaseVersion ignored for dependency:copy goal
> ---
>
> Key: MDEP-691
> URL: https://issues.apache.org/jira/browse/MDEP-691
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: copy
>Reporter: Jakub Bochenski
>Priority: Major
>
> It seems it's only respected by the dependency:copy-dependencies goal



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (MDEP-691) useBaseVersion ignored for dependency:copy goal

2020-04-24 Thread Jakub Bochenski (Jira)


[ 
https://issues.apache.org/jira/browse/MDEP-691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091465#comment-17091465
 ] 

Jakub Bochenski edited comment on MDEP-691 at 4/24/20, 10:55 AM:
-

I just run {code}mvn   dependency:copy -Dartifact=${artifact} 
-Dmdep.useBaseVersion=true|false{code}

Regardless of the setting I get a file with 1-SNAPSHOT version, instead of a 
timestamped snapshot version. 


was (Author: jbochenski):
I just run {code}mvnw   dependency:copy -Dartifact=${artifact} 
-Dmdep.useBaseVersion=true|false{code}

Regardless of the setting I get a file with 1-SNAPSHOT version, instead of a 
timestamped snapshot version. 

> useBaseVersion ignored for dependency:copy goal
> ---
>
> Key: MDEP-691
> URL: https://issues.apache.org/jira/browse/MDEP-691
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: copy
>Reporter: Jakub Bochenski
>Priority: Major
>
> It seems it's only respected by the dependency:copy-dependencies goal



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (MDEP-691) useBaseVersion ignored for dependency:copy goal

2020-04-20 Thread Jakub Bochenski (Jira)
Jakub Bochenski created MDEP-691:


 Summary: useBaseVersion ignored for dependency:copy goal
 Key: MDEP-691
 URL: https://issues.apache.org/jira/browse/MDEP-691
 Project: Maven Dependency Plugin
  Issue Type: Bug
  Components: copy
Reporter: Jakub Bochenski


It seems it's only respected by the dependency:copy-dependencies goal



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MCOMPILER-403) Spring Lombok -Werror [ERROR] An unknown compilation problem occurred

2019-11-15 Thread Jakub Bochenski (Jira)


[ 
https://issues.apache.org/jira/browse/MCOMPILER-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975072#comment-16975072
 ] 

Jakub Bochenski commented on MCOMPILER-403:
---

Use true to see warnings, the you will see it's 
this issue 
https://github.com/spring-projects/spring-boot/issues/6421#issuecomment-233591004

> Spring Lombok -Werror [ERROR] An unknown compilation problem occurred
> -
>
> Key: MCOMPILER-403
> URL: https://issues.apache.org/jira/browse/MCOMPILER-403
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.8.1
> Environment: Windows 10 Apache Maven 3.6.1, Java 1.8.0_231 or 11.0.4
>Reporter: Igor Rybak
>Priority: Major
> Attachments: spring-lombok-werror-bug-demo.zip
>
>
> Compilation fails with -Werror and Lombok in Spring Boot project with the 
> message "An unknown compilation problem occurred"
> Steps to reproduce:
> 1. Open the sample project spring-lombok-werror-bug-demo.zip
> 2. run {{mvn clean package}} in the root of the project (Apache Maven 3.6.1, 
> Java 1.8.0_231 or 11.0.4)
> Here is the same issue on Lombok GitHub repository:
> [https://github.com/rzwitserloot/lombok/issues/2285]
> {code:java}
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 5.698 s
> [INFO] Finished at: 2019-11-07T14:48:32+02:00
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile 
> (default-compile) on project spring-lombok-demo: Compilation failure -> [Help 
> 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile 
> (default-compile) on project spring-lombok-demo: Compilation failure
>  at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:215)
>  at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:156)
>  at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:148)
>  at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:117)
>  at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:81)
>  at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
>  (SingleThreadedBuilder.java:56)
>  at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (LifecycleStarter.java:128)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
>  at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
>  at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
>  at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
>  at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>  at sun.reflect.NativeMethodAccessorImpl.invoke 
> (NativeMethodAccessorImpl.java:62)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke 
> (DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke (Method.java:498)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
> (Launcher.java:282)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
> (Launcher.java:225)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
> (Launcher.java:406)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
> Caused by: org.apache.maven.plugin.compiler.CompilationFailureException: 
> Compilation failure
>  at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute 
> (AbstractCompilerMojo.java:1224)
>  at org.apache.maven.plugin.compiler.CompilerMojo.execute 
> (CompilerMojo.java:187)
>  at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
> (DefaultBuildPluginManager.java:137)
>  at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:210)
>  at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:156)
>  at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:148)
>  at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:117)
>  at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:81)
>  at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
>  (SingleThreadedBuilder.java:56)
>  at 

[jira] [Commented] (MWAR-353) Manifest still not written to exploded location

2019-11-13 Thread Jakub Bochenski (Jira)


[ 
https://issues.apache.org/jira/browse/MWAR-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16973474#comment-16973474
 ] 

Jakub Bochenski commented on MWAR-353:
--

[~rfscholte] I'm not sure if you are responding to my previous comment or not.  
I was just asking for a workaround that works past `3.1.0`

I was referring to the comment from MWAR-379 by [~khmarbaise]: "Removing the 
whole goal cause this can be handled simply with MavenArchiver configuration. "
I would very much like to see an example MavenArchiver configuration that does 
that

> Manifest still not written to exploded location
> ---
>
> Key: MWAR-353
> URL: https://issues.apache.org/jira/browse/MWAR-353
> Project: Maven WAR Plugin
>  Issue Type: Bug
>  Components: manifest
>Affects Versions: 2.6
>Reporter: Jakub Bochenski
>Priority: Major
> Fix For: 2.6
>
>
> If I have no manifest files I don't get anything in the exploded location.
> If I put a {{MANIFEST.MF}} under webapp folder's {{META-INF/MANIFEST.MF}} I 
> just get the static file.
> If I set {{archive/manifestFile}} to point at some file I just get the static 
> file.
> Workaround: change
> {code:xml}
>  
>   exploded 
> 
> {code}
> to
> {code:xml}
>  
>   manifest 
>   exploded 
> 
> {code}
>  
> and add the generated files to SCM ignore.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MDEP-204) go-offline fails to resolve artifact available in maven reactor

2018-11-23 Thread Jakub Bochenski (JIRA)


[ 
https://issues.apache.org/jira/browse/MDEP-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16697414#comment-16697414
 ] 

Jakub Bochenski commented on MDEP-204:
--

You might be interested in https://github.com/qaware/go-offline-maven-plugin

> go-offline fails to resolve artifact available in maven reactor
> ---
>
> Key: MDEP-204
> URL: https://issues.apache.org/jira/browse/MDEP-204
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: go-offline
>Affects Versions: 2.0, 2.1
> Environment: maven 2.1.0
>Reporter: Stevo Slavic
>Priority: Major
> Attachments: mvn-dependency-go-offline-failing-example.zip
>
>
> Attached is example project, for which IMO dependency:go-offline should be 
> able to resolve all dependencies as they are only intermodule dependencies 
> within same multimodule project which haven't been installed yet but are 
> available in maven reactor so can be considered as resolvable in offline mode 
> - instead dependency:go-offline fails to resolve these dependencies.



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


[jira] [Commented] (SCM-798) scm:branch ignores the tagBase parameter, there is no branchBase parameter

2018-03-23 Thread Jakub Bochenski (JIRA)

[ 
https://issues.apache.org/jira/browse/SCM-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16411519#comment-16411519
 ] 

Jakub Bochenski commented on SCM-798:
-

[~michael-o] I'm no longer using svn in my projects.
There are 2 problems here:
 - tagBase param is available for the branch mojo but it's completely useless
 - support for custom svn layout is incomplete -- there is tagBase for 
non-standard tag location, but there is no support for non-standard branches 
location

> scm:branch ignores the tagBase parameter, there is no branchBase parameter
> --
>
> Key: SCM-798
> URL: https://issues.apache.org/jira/browse/SCM-798
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-plugin, maven-scm-provider-svn
>Affects Versions: 1.9.4
>Reporter: Jakub Bochenski
>Priority: Blocker
>
> {code}[DEBUG] Configuring mojo 
> 'org.apache.maven.plugins:maven-scm-plugin:1.9.4:branch' with basic 
> configurator -->
> [DEBUG]   (f) basedir = /home/acme/gotham/common_ui
> [DEBUG]   (f) branch = 2.2/2.2.0
> [DEBUG]   (f) connectionType = connection
> [DEBUG]   (s) connectionUrl = 
> scm:svn:svn+ssh://s...@svn.acme.com/repos/trunk/common_ui
> [DEBUG]   (f) developerConnectionUrl = 
> scm:svn:svn+ssh://s...@svn.acme.com/repos/trunk/common_ui
> [DEBUG]   (f) pushChanges = true
> [DEBUG]   (f) remoteBranching = false
> [DEBUG]   (f) settings = org.apache.maven.execution.SettingsAdapter@7b300cde
> [DEBUG]   (f) tagBase = svn+ssh://s...@svn.acme.com/repos/branches/common_ui
> [DEBUG] -- end configuration --
> [INFO] Final Branch Name: '2.2/2.2.0'
> [INFO] Executing: /bin/sh -c cd /home/acme/gotham/common_ui && svn 
> --non-interactive copy --file /tmp/maven-scm-1267210601.commit . 
> svn+ssh://s...@svn.acme.com/repos/branches/2.2/2.2.0
> {code}
> I can see this code handling {{tagBase}}, but there is none for {{branchBase}}
> {code}
> if ( !StringUtils.isEmpty( tagBase ) && 
> repository.getProvider().equals( "svn" ) )
> {
> SvnScmProviderRepository svnRepo = (SvnScmProviderRepository) 
> repository.getProviderRepository();
> svnRepo.setTagBase( tagBase );
> }{code}
> Adding a parallel handling for {{branchBase}} param should be trivial. 
> Correcting the documentation is another thing -- the {{tagBase}} parameter is 
> present on the base Mojo class even though it's ignored in some goals.



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


[jira] [Commented] (MWAR-379) manifest goal violates general Maven principle and creates file into src/main/..

2018-02-08 Thread Jakub Bochenski (JIRA)

[ 
https://issues.apache.org/jira/browse/MWAR-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16356964#comment-16356964
 ] 

Jakub Bochenski commented on MWAR-379:
--

This broke the workaround for MWAR-353. Maybe that bug could get some attention 
then?

> manifest goal violates general Maven principle and creates file into 
> src/main/..
> 
>
> Key: MWAR-379
> URL: https://issues.apache.org/jira/browse/MWAR-379
> Project: Maven WAR Plugin
>  Issue Type: Bug
>  Components: manifest
>Affects Versions: 2.6
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Major
> Fix For: 3.0.0
>
>
> Currently the {{manifest}} goal of the war plugin will generate a file 
> {{MANIFEST.MF}} into {{src/main/webapp}} folder and violates Maven principle 
> (cause those folders are under version control). Either the generation should 
> be done into a folder like {{target/WhatEver...}} or the whole goal should be 
> removed.



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


[jira] [Commented] (MWAR-353) Manifest still not written to exploded location

2018-02-08 Thread Jakub Bochenski (JIRA)

[ 
https://issues.apache.org/jira/browse/MWAR-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16356958#comment-16356958
 ] 

Jakub Bochenski commented on MWAR-353:
--

{quote}Workaround doesn't work with 3.1.0 as manifest goal was removed{quote}

[~khmarbaise] any chance you could post the "MavenArchiver configuration" that 
can be used to replace the lost functionality?

> Manifest still not written to exploded location
> ---
>
> Key: MWAR-353
> URL: https://issues.apache.org/jira/browse/MWAR-353
> Project: Maven WAR Plugin
>  Issue Type: Bug
>  Components: manifest
>Affects Versions: 2.6
>Reporter: Jakub Bochenski
>Priority: Major
> Fix For: 2.6
>
>
> If I have no manifest files I don't get anything in the exploded location.
> If I put a {{MANIFEST.MF}} under webapp folder's {{META-INF/MANIFEST.MF}} I 
> just get the static file.
> If I set {{archive/manifestFile}} to point at some file I just get the static 
> file.
> Workaround: change
> {code:xml}
>  
>   exploded 
> 
> {code}
> to
> {code:xml}
>  
>   manifest 
>   exploded 
> 
> {code}
>  
> and add the generated files to SCM ignore.



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


[jira] [Commented] (MDEPLOY-229) Error injecting: org.apache.maven.artifact.deployer.DefaultArtifactDeployer in Maven 3.3.9

2018-02-02 Thread Jakub Bochenski (JIRA)

[ 
https://issues.apache.org/jira/browse/MDEPLOY-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16350190#comment-16350190
 ] 

Jakub Bochenski commented on MDEPLOY-229:
-

This is actually 
https://github.com/HubSpot/dependency-management-maven-plugin/issues/13 but I 
can't close the issue for some reason

> Error injecting: org.apache.maven.artifact.deployer.DefaultArtifactDeployer 
> in Maven 3.3.9
> --
>
> Key: MDEPLOY-229
> URL: https://issues.apache.org/jira/browse/MDEPLOY-229
> Project: Maven Deploy Plugin
>  Issue Type: Bug
>  Components: deploy:deploy
>Affects Versions: 2.8.2
> Environment: Maven 3.3.9
>Reporter: Jakub Bochenski
>Priority: Critical
>
> The stacktrace is huge but I think the gist is:
> {code:java}
> java.lang.IllegalArgumentException: Can not set 
> org.eclipse.aether.spi.log.Logger field 
> org.apache.maven.repository.internal.DefaultVersionRangeResolver.logger to 
> org.eclipse.aether.internal.impl.slf4j.Slf4jLoggerFactory{code}
> Tried the same with Maven 3.5.0 and it works fine.
> Full stack trace: 
> https://gist.github.com/jakub-bochenski/08b7e9dce1823ef55c2335eb7e79fb14



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


[jira] [Created] (MDEPLOY-229) Error injecting: org.apache.maven.artifact.deployer.DefaultArtifactDeployer in Maven 3.3.9

2018-01-31 Thread Jakub Bochenski (JIRA)
Jakub Bochenski created MDEPLOY-229:
---

 Summary: Error injecting: 
org.apache.maven.artifact.deployer.DefaultArtifactDeployer in Maven 3.3.9
 Key: MDEPLOY-229
 URL: https://issues.apache.org/jira/browse/MDEPLOY-229
 Project: Maven Deploy Plugin
  Issue Type: Bug
  Components: deploy:deploy
Affects Versions: 2.8.2
 Environment: Maven 3.3.9
Reporter: Jakub Bochenski


The stacktrace is huge but I think the gist is:
{code:java}
java.lang.IllegalArgumentException: Can not set 
org.eclipse.aether.spi.log.Logger field 
org.apache.maven.repository.internal.DefaultVersionRangeResolver.logger to 
org.eclipse.aether.internal.impl.slf4j.Slf4jLoggerFactory{code}

Tried the same with Maven 3.5.0 and it works fine.

Full stack trace: 
https://gist.github.com/jakub-bochenski/08b7e9dce1823ef55c2335eb7e79fb14



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


[jira] [Commented] (MDEPLOY-193) deployAtEnd does not deploy artifacts for multi-module project with build extensions

2017-10-17 Thread Jakub Bochenski (JIRA)

[ 
https://issues.apache.org/jira/browse/MDEPLOY-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208090#comment-16208090
 ] 

Jakub Bochenski commented on MDEPLOY-193:
-

[~j.joslet] great job,  I wish you could upvote comments on JIRA (sorry for 
spam)

> deployAtEnd does not deploy artifacts for multi-module project with build 
> extensions
> 
>
> Key: MDEPLOY-193
> URL: https://issues.apache.org/jira/browse/MDEPLOY-193
> Project: Maven Deploy Plugin
>  Issue Type: Bug
>  Components: deploy:deploy
>Affects Versions: 2.8.2
> Environment: windows 7 / sles 11
> maven 3.0.5
> java 7u45
>Reporter: Jörg Sesterhenn
> Attachments: deployAtEndFailure.zip
>
>
> The deploy plugin shows the same behaviour as described in MINSTALL-102. 
> We noticed that multimodule projects do not deploy any artifacts if there are 
> modules with packagings that add build extensions (e.g. atlassian-plugin, aar 
> = axis archives).
> This issue is here for better visibility as discussed in MINSTALL-102. 
> Please find attached testcase there.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Comment Edited] (WAGON-468) settings.xml server httpConfiguration ignored

2016-12-01 Thread Jakub Bochenski (JIRA)

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

Jakub Bochenski edited comment on WAGON-468 at 12/1/16 12:40 PM:
-

[~dantran] it's failing with {code}jbochenski@Latitude-E5470:~/acme-pipeline$ 
mvn  
-Dwagon.url=https://jenkins.acme-internal.com/plugin/repository/project/acme-Installer-DSL/Build/1828/repository
 org.codehaus.mojo:wagon-maven-plugin:1.1-SNAPSHOT:list -Dwagon.serverId=jenkins
[INFO] Scanning for projects... 


  
[INFO]  


  
[INFO]  


  
[INFO] Building Maven Stub Project (No POM) 1   


  
[INFO]  


  
[INFO]  


  
[INFO] --- wagon-maven-plugin:1.1-SNAPSHOT:list (default-cli) @ standalone-pom 
--- 

   
[INFO]  


  
[INFO] BUILD FAILURE


  
[INFO]  


  
[INFO] Total time: 0.613 s  


  
[INFO] Finished at: 2016-12-01T13:36:11+01:00   


  
[INFO] Final Memory: 12M/236M   


  
[INFO]  


  
[ERROR] Failed to execute goal 
org.codehaus.mojo:wagon-maven-plugin:1.1-SNAPSHOT:list (default-cli) on project 
standalone-pom: Unable to create a Wagon instance for 
https://jenkins.acme-internal.com/plugin/repository/project/acme-Installer-DSL/Build/1828/repository:
 While configuring wagon for 'jenkins': Unable to apply wagon configuration. 
Component does not implement interface 
org.codehaus.plexus.component.MapOrientedComponent -> [Help 1]  {code}


was (Author: jbochenski):
[~dantran] it's failing with {code}$ mvn  
-Dwagon.url=https://jenkins.acme-internal.com/plugin/repository/project/acme-Installer-DSL/Build/1828/repository
 

[jira] [Comment Edited] (WAGON-468) settings.xml server httpConfiguration ignored

2016-12-01 Thread Jakub Bochenski (JIRA)

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

Jakub Bochenski edited comment on WAGON-468 at 12/1/16 12:38 PM:
-

[~dantran] it's failing with {code}$ mvn  
-Dwagon.url=https://jenkins.acme-internal.com/plugin/repository/project/acme-Installer-DSL/Build/1828/repository
 org.codehaus.mojo:wagon-maven-plugin:1.1-SNAPSHOT:list -Dwagon.serverId=jenkins
[INFO] Scanning for projects... 


  
[INFO]  


  
[INFO]  


  
[INFO] Building Maven Stub Project (No POM) 1   


  
[INFO]  


  
[INFO]  


  
[INFO] --- wagon-maven-plugin:1.1-SNAPSHOT:list (default-cli) @ standalone-pom 
--- 

   
[INFO]  


  
[INFO] BUILD FAILURE


  
[INFO]  


  
[INFO] Total time: 0.613 s  


  
[INFO] Finished at: 2016-12-01T13:36:11+01:00   


  
[INFO] Final Memory: 12M/236M   


  
[INFO]  


  
[ERROR] Failed to execute goal 
org.codehaus.mojo:wagon-maven-plugin:1.1-SNAPSHOT:list (default-cli) on project 
standalone-pom: Unable to create a Wagon instance for 
https://jenkins.acme-internal.com/plugin/repository/project/acme-Installer-DSL/Build/1828/repository:
 While configuring wagon for 'jenkins': Unable to apply wagon configuration. 
Component does not implement interface 
org.codehaus.plexus.component.MapOrientedComponent{code}


was (Author: jbochenski):
[~dantran] it's failing with {code}$ mvn  
-Dwagon.url=https://jenkins.acme-internal.com/plugin/repository/project/acme-Installer-DSL/Build/1828/repository
 org.codehaus.mojo:wagon-maven-plugin:1.1-SNAPSHOT:list 

[jira] [Commented] (WAGON-468) settings.xml server httpConfiguration ignored

2016-12-01 Thread Jakub Bochenski (JIRA)

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

Jakub Bochenski commented on WAGON-468:
---

[~dantran] it's failing with {code}$ mvn  
-Dwagon.url=https://jenkins.acme-internal.com/plugin/repository/project/acme-Installer-DSL/Build/1828/repository
 org.codehaus.mojo:wagon-maven-plugin:1.1-SNAPSHOT:list -Dwagon.serverId=jenkins
[INFO] Scanning for projects... 


  
[INFO]  


  
[INFO]  


  
[INFO] Building Maven Stub Project (No POM) 1   


  
[INFO]  


  
[INFO]  


  
[INFO] --- wagon-maven-plugin:1.1-SNAPSHOT:list (default-cli) @ standalone-pom 
--- 

   
[INFO]  


  
[INFO] BUILD FAILURE


  
[INFO]  


  
[INFO] Total time: 0.613 s  


  
[INFO] Finished at: 2016-12-01T13:36:11+01:00   


  
[INFO] Final Memory: 12M/236M   


  
[INFO]  


  
[ERROR] Failed to execute goal 
org.codehaus.mojo:wagon-maven-plugin:1.1-SNAPSHOT:list (default-cli) on project 
standalone-pom: Unable to create a Wagon instance for 
https://jenkins.acme-internal.com/plugin/repository/project/acme-Installer-DSL/Build/1828/repository:
 While configuring wagon for 'jenkins': Unable to apply wagon configuration. 
Component does not implement interface 
org.codehaus.plexus.component.MapOrientedComponent{code}

> settings.xml server httpConfiguration ignored
> -
>
> Key: WAGON-468
> URL: https://issues.apache.org/jira/browse/WAGON-468
> Project: Maven Wagon
>  Issue Type: Bug
>Affects Versions: 1.0
>  

[jira] [Updated] (WAGON-468) settings.xml server httpConfiguration ignored

2016-11-28 Thread Jakub Bochenski (JIRA)

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

Jakub Bochenski updated WAGON-468:
--
Description: 
Since Jenkins requires preemptive authentication I've configured {{httpClient}} 
provder in {{settings.xml}} to provide it.
This works fine with "usual" maven artifact resolution, as well as with 
{{dependency:get}} etc.


{code}http://maven.apache.org/POM/4.0.0; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.1.0 
http://maven.apache.org/xsd/settings-1.1.0.xsd;>
  http://maven.apache.org/SETTINGS/1.1.0;>/home/jbochenski/.m2/repository
  http://maven.apache.org/SETTINGS/1.1.0;>

  jbochenski
  ***
  
httpclient

  
true
  

  
  jenkins

   
  http://maven.apache.org/SETTINGS/1.1.0;>
org.apache.maven.plugins
org.codehaus.mojo
  

{code}

However {{wagon:list}} fails with  {{Failed to execute goal 
org.codehaus.mojo:wagon-maven-plugin:1.0:list (default-cli) on project 
standalone-pom: Error handling resource: Access denied to: }}

{code}ClassRealm[plugin>org.codehaus.mojo:wagon-maven-plugin:1.0, parent: 
sun.misc.Launcher$AppClassLoader@55f96302]
[DEBUG] Configuring mojo 'org.codehaus.mojo:wagon-maven-plugin:1.0:list' with 
basic configurator -->
[DEBUG]   (f) caseSensitive = true
[DEBUG]   (f) includes = *
[DEBUG]   (f) project = MavenProject: org.apache.maven:standalone-pom:1 @ 
[DEBUG]   (f) serverId = jenkins
[DEBUG]   (f) settings = org.apache.maven.execution.SettingsAdapter@5215cd9a
[DEBUG]   (f) skip = false
{code}


  was:
Since Jenkins requires preemptive authentication I've configured{{httpClient}} 
provder in {{settings.xml}} to provide it.
This works fine with "usual" maven artifact resolution, as well as with 
{{dependency:get}} etc.


{code}http://maven.apache.org/POM/4.0.0; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.1.0 
http://maven.apache.org/xsd/settings-1.1.0.xsd;>
  http://maven.apache.org/SETTINGS/1.1.0;>/home/jbochenski/.m2/repository
  http://maven.apache.org/SETTINGS/1.1.0;>

  jbochenski
  ***
  
httpclient

  
true
  

  
  jenkins

   
  http://maven.apache.org/SETTINGS/1.1.0;>
org.apache.maven.plugins
org.codehaus.mojo
  

{code}

However {{wagon:list}} fails with  {{Failed to execute goal 
org.codehaus.mojo:wagon-maven-plugin:1.0:list (default-cli) on project 
standalone-pom: Error handling resource: Access denied to: }}

{code}ClassRealm[plugin>org.codehaus.mojo:wagon-maven-plugin:1.0, parent: 
sun.misc.Launcher$AppClassLoader@55f96302]
[DEBUG] Configuring mojo 'org.codehaus.mojo:wagon-maven-plugin:1.0:list' with 
basic configurator -->
[DEBUG]   (f) caseSensitive = true
[DEBUG]   (f) includes = *
[DEBUG]   (f) project = MavenProject: org.apache.maven:standalone-pom:1 @ 
[DEBUG]   (f) serverId = jenkins
[DEBUG]   (f) settings = org.apache.maven.execution.SettingsAdapter@5215cd9a
[DEBUG]   (f) skip = false
{code}



> settings.xml server httpConfiguration ignored
> -
>
> Key: WAGON-468
> URL: https://issues.apache.org/jira/browse/WAGON-468
> Project: Maven Wagon
>  Issue Type: Bug
>Affects Versions: 1.0
>Reporter: Jakub Bochenski
>Assignee: Dan Tran
>Priority: Blocker
>
> Since Jenkins requires preemptive authentication I've configured 
> {{httpClient}} provder in {{settings.xml}} to provide it.
> This works fine with "usual" maven artifact resolution, as well as with 
> {{dependency:get}} etc.
> {code}http://maven.apache.org/POM/4.0.0; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.1.0 
> http://maven.apache.org/xsd/settings-1.1.0.xsd;>
>xmlns="http://maven.apache.org/SETTINGS/1.1.0;>/home/jbochenski/.m2/repository
>   http://maven.apache.org/SETTINGS/1.1.0;>
> 
>   jbochenski
>   ***
>   
> httpclient
> 
>   
> true
>   
> 
>   
>   jenkins
> 
>
>   http://maven.apache.org/SETTINGS/1.1.0;>
> org.apache.maven.plugins
> org.codehaus.mojo
>   
> 
> {code}
> However {{wagon:list}} fails with  {{Failed to execute goal 
> org.codehaus.mojo:wagon-maven-plugin:1.0:list (default-cli) on project 
> standalone-pom: Error handling resource: Access denied to: }}
> {code}ClassRealm[plugin>org.codehaus.mojo:wagon-maven-plugin:1.0, parent: 
> sun.misc.Launcher$AppClassLoader@55f96302]
> [DEBUG] Configuring mojo 'org.codehaus.mojo:wagon-maven-plugin:1.0:list' with 
> basic configurator -->
> [DEBUG]   (f) caseSensitive = true
> [DEBUG]   (f) includes = *
> [DEBUG]   (f) project = 

[jira] [Created] (WAGON-468) settings.xml server httpConfiguration ignored

2016-11-24 Thread Jakub Bochenski (JIRA)
Jakub Bochenski created WAGON-468:
-

 Summary: settings.xml server httpConfiguration ignored
 Key: WAGON-468
 URL: https://issues.apache.org/jira/browse/WAGON-468
 Project: Maven Wagon
  Issue Type: Bug
Affects Versions: 1.0
Reporter: Jakub Bochenski
Priority: Blocker


Since Jenkins requires preemptive authentication I've configured{{httpClient}} 
provder in {{settings.xml}} to provide it.
This works fine with "usual" maven artifact resolution, as well as with 
{{dependency:get}} etc.


{code}http://maven.apache.org/POM/4.0.0; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.1.0 
http://maven.apache.org/xsd/settings-1.1.0.xsd;>
  http://maven.apache.org/SETTINGS/1.1.0;>/home/jbochenski/.m2/repository
  http://maven.apache.org/SETTINGS/1.1.0;>

  jbochenski
  ***
  
httpclient

  
true
  

  
  jenkins

   
  http://maven.apache.org/SETTINGS/1.1.0;>
org.apache.maven.plugins
org.codehaus.mojo
  

{code}

However {{wagon:list}} fails with  {{Failed to execute goal 
org.codehaus.mojo:wagon-maven-plugin:1.0:list (default-cli) on project 
standalone-pom: Error handling resource: Access denied to: }}

{code}ClassRealm[plugin>org.codehaus.mojo:wagon-maven-plugin:1.0, parent: 
sun.misc.Launcher$AppClassLoader@55f96302]
[DEBUG] Configuring mojo 'org.codehaus.mojo:wagon-maven-plugin:1.0:list' with 
basic configurator -->
[DEBUG]   (f) caseSensitive = true
[DEBUG]   (f) includes = *
[DEBUG]   (f) project = MavenProject: org.apache.maven:standalone-pom:1 @ 
[DEBUG]   (f) serverId = jenkins
[DEBUG]   (f) settings = org.apache.maven.execution.SettingsAdapter@5215cd9a
[DEBUG]   (f) skip = false
{code}




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


[jira] [Commented] (MPH-99) Evaluate has no output in quiet mode

2016-10-17 Thread Jakub Bochenski (JIRA)

[ 
https://issues.apache.org/jira/browse/MPH-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15582327#comment-15582327
 ] 

Jakub Bochenski commented on MPH-99:


+1 to what [~jglick] wrote.. what's the use of quiet mode then if you can't 
restrict the output to only interesting things?

> Evaluate has no output in quiet mode
> 
>
> Key: MPH-99
> URL: https://issues.apache.org/jira/browse/MPH-99
> Project: Maven Help Plugin
>  Issue Type: Bug
>  Components: evaluate
>Affects Versions: 2.2
>Reporter: Alexandre Garnier
>Assignee: Guillaume Boué
> Fix For: 2.2.1
>
> Attachments: output_on_quiet.patch
>
>
> When using {{help:evaluate}} in normal mode, the evaluation result is lost in 
> a lot of Maven {{[INFO\]}} :
> {code:language=bash}
> $ mvn help:evaluate -Dexpression=project.version
> [INFO] Scanning for projects...
> [INFO]
> [INFO] 
> 
> [INFO] Building myProject 1.0.0
> [INFO] 
> 
> [INFO]
> [INFO] --- maven-help-plugin:2.2:evaluate (default-cli) @ myProject ---
> [INFO] No artifact parameter specified, using 'com.test:myProject:pom:1.0.0' 
> as project.
> [INFO]
> 1.0.0
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 1.216s
> [INFO] Finished at: Fri Feb 07 10:32:22 CET 2014
> [INFO] Final Memory: 21M/224M
> [INFO] 
> 
> $ 
> {code}
> I was hoping that launching Maven in quiet mode would avoid all the logs and 
> only display the evaluation result, but there is just no output at all.
> {code:language=bash}
> $ mvn --quiet help:evaluate -Dexpression=project.version
> $ 
> {code}
> In attachment, a patch to use sysout instead of logging for evaluation output.



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


[jira] [Created] (MPH-114) Goal fails with “Unable to get the POM for the artifact”

2015-12-28 Thread Jakub Bochenski (JIRA)
Jakub Bochenski created MPH-114:
---

 Summary: Goal fails with “Unable to get the POM for the artifact”
 Key: MPH-114
 URL: https://issues.apache.org/jira/browse/MPH-114
 Project: Maven Help Plugin
  Issue Type: Bug
  Components: evaluate
Affects Versions: 2.2
Reporter: Jakub Bochenski


See linked SO question



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


[jira] [Created] (MNGSITE-271) CLONE - Better documentation related to repository order

2015-12-23 Thread Jakub Bochenski (JIRA)
Jakub Bochenski created MNGSITE-271:
---

 Summary: CLONE - Better documentation related to repository order
 Key: MNGSITE-271
 URL: https://issues.apache.org/jira/browse/MNGSITE-271
 Project: Maven Project Web Site
  Issue Type: Improvement
Reporter: Jakub Bochenski


I was not able to find clear documentation describing the order of repositories 
used during a build.  For example, the documentation should answer the 
following questions.
1. Which repositories are used first, the ones defined in settings.xml or in 
the pom.xml or super pom?
2. The order of repositories defined in the settings.xml profiles seems to be 
the reverse of what one would expect when viewed in the effective-pom, why is 
this?
3. If a repository ID in settings.xml matches one defined in pom.xml which one 
takes priority?

Some additional information is available in the JBoss build forum.
http://community.jboss.org/thread/160185



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


[jira] [Commented] (WAGON-405) Preemptive authentication still not working with Maven 3.0.4+

2015-12-23 Thread Jakub Bochenski (JIRA)

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

Jakub Bochenski commented on WAGON-405:
---

I just wasted whole day trying to figure out why the example in documentation 
doesn't work :(
Can someone with write access finally update the documentation?

> Preemptive authentication still not working with Maven 3.0.4+
> -
>
> Key: WAGON-405
> URL: https://issues.apache.org/jira/browse/WAGON-405
> Project: Maven Wagon
>  Issue Type: Bug
>Reporter: Konrad Windszus
> Attachments: WAGON-405-MVN3.1.1.log
>
>
> Although by default the preemptive authentication should work now with Maven 
> 3.0.4, a wireshare dump exposes, that each request for downloading a new 
> dependency does not initially come with the authentication header. Only after 
>  Nexus replied with a 401 the right credentials are set in the authentication 
> header. According to [1], since Maven 3.0.4 the default HTTP wagon uses 
> preemptive authentication which cannot be disabled [2]. Even with Maven 3.1.1 
> it does not work.
> [1] - http://maven.apache.org/guides/mini/guide-http-settings.html#Maven_3.0.4
> [2] - 
> http://maven.40175.n5.nabble.com/Maven-3-0-4-preemptive-auth-problem-tt5470892.html#none



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


[jira] [Commented] (MNGSITE-271) CLONE - Better documentation related to repository order

2015-12-23 Thread Jakub Bochenski (JIRA)

[ 
https://issues.apache.org/jira/browse/MNGSITE-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15070041#comment-15070041
 ] 

Jakub Bochenski commented on MNGSITE-271:
-

The original issue was autoclosed and I can't reopen it
Still there is no documentation for this: 
https://www.google.pl/search?q=site:maven.apache.org+repository+order

> CLONE - Better documentation related to repository order
> 
>
> Key: MNGSITE-271
> URL: https://issues.apache.org/jira/browse/MNGSITE-271
> Project: Maven Project Web Site
>  Issue Type: Improvement
>Reporter: Jakub Bochenski
>
> I was not able to find clear documentation describing the order of 
> repositories used during a build.  For example, the documentation should 
> answer the following questions.
> 1. Which repositories are used first, the ones defined in settings.xml or in 
> the pom.xml or super pom?
> 2. The order of repositories defined in the settings.xml profiles seems to be 
> the reverse of what one would expect when viewed in the effective-pom, why is 
> this?
> 3. If a repository ID in settings.xml matches one defined in pom.xml which 
> one takes priority?
> Some additional information is available in the JBoss build forum.
> http://community.jboss.org/thread/160185



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


[jira] [Commented] (SCM-813) SVN fails when trying to create a branch with nested directories

2015-12-22 Thread Jakub Bochenski (JIRA)

[ 
https://issues.apache.org/jira/browse/SCM-813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15068094#comment-15068094
 ] 

Jakub Bochenski commented on SCM-813:
-

Thanks -- is this going to be included in next snapshot build so I can test it?

Any word when 1.9.5 release is planned? 

> SVN fails when trying to create a branch with nested directories
> 
>
> Key: SCM-813
> URL: https://issues.apache.org/jira/browse/SCM-813
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-svn
>Affects Versions: 1.9.4
>Reporter: Jakub Bochenski
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 1.9.5
>
>
> It's impossible to have a branch like {{Major/Major.Minor/}} instead of just 
> {{Major.Minor/}}, because the svn plugin will fail on missing parent e.g.  
> {code}svn: E160013: Commit failed (details follow):
> svn: E160013: File not found: transaction '159463-3n0p', path 
> '/branches/foo/1/1.1'{code}
> It should use the --parent switch



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


[jira] [Created] (SCM-813) SVN fails when trying to create a branch with nested folders

2015-12-21 Thread Jakub Bochenski (JIRA)
Jakub Bochenski created SCM-813:
---

 Summary: SVN fails when trying to create a branch with nested 
folders
 Key: SCM-813
 URL: https://issues.apache.org/jira/browse/SCM-813
 Project: Maven SCM
  Issue Type: Bug
  Components: maven-scm-provider-svn
Affects Versions: 1.9.4
Reporter: Jakub Bochenski
Priority: Critical


It's impossible to have a branch like {{Major/Major.Minor/}} instead of just 
{{Major.Minor/}}, because the svn plugin will fail on missing parent e.g.  
{code}svn: E160013: Commit failed (details follow):
svn: E160013: File not found: transaction '159463-3n0p', path 
'/branches/foo/1/1.1'{code}

It should use the --parent switch



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


[jira] [Commented] (SCM-813) SVN fails when trying to create a branch with nested folders

2015-12-21 Thread Jakub Bochenski (JIRA)

[ 
https://issues.apache.org/jira/browse/SCM-813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15066951#comment-15066951
 ] 

Jakub Bochenski commented on SCM-813:
-

I'd be more than willing to provide a patch if it will be integrated. 
https://issues.apache.org/jira/browse/SCM-434 that'd allow me to work around my 
issue has been open with a patch for 6 years now..

> SVN fails when trying to create a branch with nested folders
> 
>
> Key: SCM-813
> URL: https://issues.apache.org/jira/browse/SCM-813
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-svn
>Affects Versions: 1.9.4
>Reporter: Jakub Bochenski
>Priority: Critical
>
> It's impossible to have a branch like {{Major/Major.Minor/}} instead of just 
> {{Major.Minor/}}, because the svn plugin will fail on missing parent e.g.  
> {code}svn: E160013: Commit failed (details follow):
> svn: E160013: File not found: transaction '159463-3n0p', path 
> '/branches/foo/1/1.1'{code}
> It should use the --parent switch



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


[jira] [Comment Edited] (SCM-813) SVN fails when trying to create a branch with nested folders

2015-12-21 Thread Jakub Bochenski (JIRA)

[ 
https://issues.apache.org/jira/browse/SCM-813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15067292#comment-15067292
 ] 

Jakub Bochenski edited comment on SCM-813 at 12/22/15 12:02 AM:


> See here
Maybe a stupid question, but is TagCommand also executed in branch goal?

Edit: this one has no {{--parents}} 
https://maven.apache.org/scm/maven-scm-providers/maven-scm-providers-svn/maven-scm-provider-svnexe/xref/org/apache/maven/scm/provider/svn/svnexe/command/branch/SvnBranchCommand.html


was (Author: jbochenski):
> See here
Maybe a stupid question, but is TagCommand also executed in branch goal?

> SVN fails when trying to create a branch with nested folders
> 
>
> Key: SCM-813
> URL: https://issues.apache.org/jira/browse/SCM-813
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-svn
>Affects Versions: 1.9.4
>Reporter: Jakub Bochenski
>Priority: Critical
>
> It's impossible to have a branch like {{Major/Major.Minor/}} instead of just 
> {{Major.Minor/}}, because the svn plugin will fail on missing parent e.g.  
> {code}svn: E160013: Commit failed (details follow):
> svn: E160013: File not found: transaction '159463-3n0p', path 
> '/branches/foo/1/1.1'{code}
> It should use the --parent switch



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


[jira] [Commented] (SCM-813) SVN fails when trying to create a branch with nested folders

2015-12-21 Thread Jakub Bochenski (JIRA)

[ 
https://issues.apache.org/jira/browse/SCM-813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15067292#comment-15067292
 ] 

Jakub Bochenski commented on SCM-813:
-

> See here
Maybe a stupid question, but is TagCommand also executed in branch goal?

> SVN fails when trying to create a branch with nested folders
> 
>
> Key: SCM-813
> URL: https://issues.apache.org/jira/browse/SCM-813
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-svn
>Affects Versions: 1.9.4
>Reporter: Jakub Bochenski
>Priority: Critical
>
> It's impossible to have a branch like {{Major/Major.Minor/}} instead of just 
> {{Major.Minor/}}, because the svn plugin will fail on missing parent e.g.  
> {code}svn: E160013: Commit failed (details follow):
> svn: E160013: File not found: transaction '159463-3n0p', path 
> '/branches/foo/1/1.1'{code}
> It should use the --parent switch



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


[jira] [Commented] (SCM-813) SVN fails when trying to create a branch with nested folders

2015-12-21 Thread Jakub Bochenski (JIRA)

[ 
https://issues.apache.org/jira/browse/SCM-813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15067287#comment-15067287
 ] 

Jakub Bochenski commented on SCM-813:
-

This is the logged command: {code}Executing: /bin/sh -c cd 
/home/jenkins/.jenkins/workspace/Foo/bar && svn --non-interactive copy --file 
/tmp/maven-scm-949188058.commit . 
svn+ssh://s...@svn.acme.com/repos/branches/bar/2.4/2.4.0{code}

> SVN fails when trying to create a branch with nested folders
> 
>
> Key: SCM-813
> URL: https://issues.apache.org/jira/browse/SCM-813
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-svn
>Affects Versions: 1.9.4
>Reporter: Jakub Bochenski
>Priority: Critical
>
> It's impossible to have a branch like {{Major/Major.Minor/}} instead of just 
> {{Major.Minor/}}, because the svn plugin will fail on missing parent e.g.  
> {code}svn: E160013: Commit failed (details follow):
> svn: E160013: File not found: transaction '159463-3n0p', path 
> '/branches/foo/1/1.1'{code}
> It should use the --parent switch



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


[jira] [Created] (MCOMPILER-251) testCompile silently ignores compilation errors (sometimes)

2015-09-01 Thread Jakub Bochenski (JIRA)
Jakub Bochenski created MCOMPILER-251:
-

 Summary: testCompile silently ignores compilation errors 
(sometimes)
 Key: MCOMPILER-251
 URL: https://issues.apache.org/jira/browse/MCOMPILER-251
 Project: Maven Compiler Plugin
  Issue Type: Bug
Affects Versions: 3.3
Reporter: Jakub Bochenski


If I have a file {{UserTestFactory.java}} containing a class {{UnitTestUtil}}
I get an error as expected:{code}
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.3:testCompile 
(default-testCompile) on project common_platform: Compilation failure: 
Compilation failure:
[ERROR] 
/home/acme/trunk_avalon/module/common_platform/src_test/com/acme/test/util/UserTestFactory.java:[10,8]
 class UnitTestUtil is public, should be declared in a file named 
UnitTestUtil.java{code}

However if I add another file {{FooUnitTest.java}}, having an import statement 
{{import com.acme.test.util.UserTestFactory;}} then the error is silently 
ignored. No classes appear in the test output directory.
{code}[INFO] --- maven-compiler-plugin:3.3:testCompile (default-testCompile) @ 
common_platform ---
[INFO] Compiling 170 source files to 
/home/acme/trunk_avalon/module/common_platform/build/testClasses
[INFO] 
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ common_platform 
---
[INFO] 
[INFO] --- maven-jar-plugin:2.6:jar (default-jar) @ common_platform ---
[INFO] Building jar: 
/home/acme/trunk_avalon/module/common_platform/target/common_platform-0.0.1-SNAPSHOT.jar
[INFO] 
[INFO] --- maven-assembly-plugin:2.5.3:single (default) @ common_platform ---
[INFO] Reading assembly descriptor: assembly/placeholders.xml
[INFO] Reading assembly descriptor: assembly/log-config.xml
[INFO] Building zip: 
/home/acme/trunk_avalon/module/common_platform/target/common_platform-0.0.1-SNAPSHOT-placeholders.zip
[INFO] Building zip: 
/home/acme/trunk_avalon/module/common_platform/target/common_platform-0.0.1-SNAPSHOT-log-config.zip
[INFO] 
[INFO] --- maven-assembly-plugin:2.5.3:single (assembly-overlay) @ 
common_platform ---
[INFO] Reading assembly descriptor: assembly/overlay.xml
[INFO] Building war: 
/home/acme/trunk_avalon/module/common_platform/target/common_platform-0.0.1-SNAPSHOT.war
[INFO] 
[INFO] --- maven-jar-plugin:2.6:test-jar (default-test-jar) @ common_platform 
---
[INFO] Building jar: 
/home/acme/trunk_avalon/module/common_platform/target/common_platform-0.0.1-SNAPSHOT-tests.jar
[INFO] 
[INFO] --- sortpom-maven-plugin:2.4.0:verify (default) @ common_platform ---
[INFO] Verifying file /home/acme/trunk_avalon/module/common_platform/pom.xml
[INFO] 
[INFO] --- maven-install-plugin:2.5.2:install (default-install) @ 
common_platform ---
[INFO] Installing 
/home/acme/trunk_avalon/module/common_platform/target/common_platform-0.0.1-SNAPSHOT.jar
 to 
/home/acme/.m2/repository/com/acme/common_platform/0.0.1-SNAPSHOT/common_platform-0.0.1-SNAPSHOT.jar
[INFO] Installing /home/acme/trunk_avalon/module/common_platform/pom.xml to 
/home/acme/.m2/repository/com/acme/common_platform/0.0.1-SNAPSHOT/common_platform-0.0.1-SNAPSHOT.pom
[INFO] Installing 
/home/acme/trunk_avalon/module/common_platform/target/common_platform-0.0.1-SNAPSHOT-placeholders.zip
 to 
/home/acme/.m2/repository/com/acme/common_platform/0.0.1-SNAPSHOT/common_platform-0.0.1-SNAPSHOT-placeholders.zip
[INFO] Installing 
/home/acme/trunk_avalon/module/common_platform/target/common_platform-0.0.1-SNAPSHOT-log-config.zip
 to 
/home/acme/.m2/repository/com/acme/common_platform/0.0.1-SNAPSHOT/common_platform-0.0.1-SNAPSHOT-log-config.zip
[INFO] Installing 
/home/acme/trunk_avalon/module/common_platform/target/common_platform-0.0.1-SNAPSHOT.war
 to 
/home/acme/.m2/repository/com/acme/common_platform/0.0.1-SNAPSHOT/common_platform-0.0.1-SNAPSHOT.war
[INFO] Installing 
/home/acme/trunk_avalon/module/common_platform/target/common_platform-0.0.1-SNAPSHOT-tests.jar
 to 
/home/acme/.m2/repository/com/acme/common_platform/0.0.1-SNAPSHOT/common_platform-0.0.1-SNAPSHOT-tests.jar
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 24.666 s
[INFO] Finished at: 2015-09-01T14:41:01+01:00
[INFO] Final Memory: 54M/730M
[INFO] 
{code}

Plugin configuration:
{code}
[DEBUG] Configuring mojo 
org.apache.maven.plugins:maven-compiler-plugin:3.3:testCompile from plugin 
realm ClassRealm[plugin>org.apache.maven.plugins:maven-compiler-plugin:3.3, 
parent: sun.misc.Launcher$AppClassLoader@10b28f30]
[DEBUG] Configuring mojo 
'org.apache.maven.plugins:maven-compiler-plugin:3.3:testCompile' with basic 
configurator -->
[DEBUG]   (f) basedir = /home/acme/trunk_avalon/module/common_platform
[DEBUG]   (f) buildDirectory = 

[jira] [Updated] (MWAR-353) Manifest still not written to exploded location

2015-08-17 Thread Jakub Bochenski (JIRA)

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

Jakub Bochenski updated MWAR-353:
-
Description: 
If I have no manifest files I don't get anything in the exploded location.
If I put a {{MANIFEST.MF}} under webapp folder's {{META-INF/MANIFEST.MF}} I 
just get the static file.

Workaround: change
{code}
goals 

goalexploded/goal 
/goals{code}
to
{code}
goals 

goalmanifest/goal 

goalexploded/goal 
/goals{code}
 
and add the generated files to SCM ignore.

  was:
When I open up my generated WAR file, the Manifest file contains all the 
entries I specified. This is correct. However, when I look into the exploded 
location, it's just the file I had in my project to begin with.

The exploded Manifest should be updated with the final contents.


 Manifest still not written to exploded location
 ---

 Key: MWAR-353
 URL: https://issues.apache.org/jira/browse/MWAR-353
 Project: Maven WAR Plugin
  Issue Type: Bug
  Components: manifest
Affects Versions: 2.6
Reporter: Jakub Bochenski
Assignee: Karl Heinz Marbaise
 Fix For: 2.6


 If I have no manifest files I don't get anything in the exploded location.
 If I put a {{MANIFEST.MF}} under webapp folder's {{META-INF/MANIFEST.MF}} I 
 just get the static file.
 Workaround: change
 {code}
   goals 
   
 goalexploded/goal 
   /goals{code}
 to
 {code}
   goals 
   
 goalmanifest/goal 
   
 goalexploded/goal 
   /goals{code}
  
 and add the generated files to SCM ignore.



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


[jira] [Updated] (MWAR-353) Manifest still not written to exploded location

2015-08-17 Thread Jakub Bochenski (JIRA)

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

Jakub Bochenski updated MWAR-353:
-
Affects Version/s: (was: 2.1-alpha-1)
   2.6

 Manifest still not written to exploded location
 ---

 Key: MWAR-353
 URL: https://issues.apache.org/jira/browse/MWAR-353
 Project: Maven WAR Plugin
  Issue Type: Bug
  Components: manifest
Affects Versions: 2.6
Reporter: Jakub Bochenski
Assignee: Karl Heinz Marbaise
 Fix For: 2.6


 When I open up my generated WAR file, the Manifest file contains all the 
 entries I specified. This is correct. However, when I look into the exploded 
 location, it's just the file I had in my project to begin with.
 The exploded Manifest should be updated with the final contents.



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


[jira] [Created] (MWAR-353) Manifest still not written to exploded location

2015-08-17 Thread Jakub Bochenski (JIRA)
Jakub Bochenski created MWAR-353:


 Summary: Manifest still not written to exploded location
 Key: MWAR-353
 URL: https://issues.apache.org/jira/browse/MWAR-353
 Project: Maven WAR Plugin
  Issue Type: Bug
  Components: manifest
Affects Versions: 2.1-alpha-1
Reporter: Jakub Bochenski
Assignee: Karl Heinz Marbaise
 Fix For: 2.6


When I open up my generated WAR file, the Manifest file contains all the 
entries I specified. This is correct. However, when I look into the exploded 
location, it's just the file I had in my project to begin with.

The exploded Manifest should be updated with the final contents.



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


[jira] [Updated] (MWAR-353) Manifest still not written to exploded location

2015-08-17 Thread Jakub Bochenski (JIRA)

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

Jakub Bochenski updated MWAR-353:
-
Description: 
If I have no manifest files I don't get anything in the exploded location.
If I put a {{MANIFEST.MF}} under webapp folder's {{META-INF/MANIFEST.MF}} I 
just get the static file.
If I set {{archive/manifestFile}} to point at some file I just get the static 
file.

Workaround: change
{code}
goals 

goalexploded/goal 
/goals{code}
to
{code}
goals 

goalmanifest/goal 

goalexploded/goal 
/goals{code}
 
and add the generated files to SCM ignore.

  was:
If I have no manifest files I don't get anything in the exploded location.
If I put a {{MANIFEST.MF}} under webapp folder's {{META-INF/MANIFEST.MF}} I 
just get the static file.

Workaround: change
{code}
goals 

goalexploded/goal 
/goals{code}
to
{code}
goals 

goalmanifest/goal 

goalexploded/goal 
/goals{code}
 
and add the generated files to SCM ignore.


 Manifest still not written to exploded location
 ---

 Key: MWAR-353
 URL: https://issues.apache.org/jira/browse/MWAR-353
 Project: Maven WAR Plugin
  Issue Type: Bug
  Components: manifest
Affects Versions: 2.6
Reporter: Jakub Bochenski
Assignee: Karl Heinz Marbaise
 Fix For: 2.6


 If I have no manifest files I don't get anything in the exploded location.
 If I put a {{MANIFEST.MF}} under webapp folder's {{META-INF/MANIFEST.MF}} I 
 just get the static file.
 If I set {{archive/manifestFile}} to point at some file I just get the static 
 file.
 Workaround: change
 {code}
   goals 
   
 goalexploded/goal 
   /goals{code}
 to
 {code}
   goals 
   
 goalmanifest/goal 
   
 goalexploded/goal 
   /goals{code}
  
 and add the generated files to SCM ignore.



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


[jira] [Updated] (SCM-798) scm:branch ignores the tagBase parameter, there is not branchBase parameter

2015-06-09 Thread Jakub Bochenski (JIRA)

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

Jakub Bochenski updated SCM-798:

Description: 
{code}[DEBUG] Configuring mojo 
'org.apache.maven.plugins:maven-scm-plugin:1.9.4:branch' with basic 
configurator --
[DEBUG]   (f) basedir = /home/acme/gotham/common_ui
[DEBUG]   (f) branch = 2.2/2.2.0
[DEBUG]   (f) connectionType = connection
[DEBUG]   (s) connectionUrl = 
scm:svn:svn+ssh://s...@svn.acme.com/repos/trunk/common_ui
[DEBUG]   (f) developerConnectionUrl = 
scm:svn:svn+ssh://s...@svn.acme.com/repos/trunk/common_ui
[DEBUG]   (f) pushChanges = true
[DEBUG]   (f) remoteBranching = false
[DEBUG]   (f) settings = org.apache.maven.execution.SettingsAdapter@7b300cde
[DEBUG] -- end configuration --
[INFO] Final Branch Name: '2.2/2.2.0'
[INFO] Executing: /bin/sh -c cd /home/acme/gotham/common_ui  svn 
--non-interactive copy --file /tmp/maven-scm-1267210601.commit . 
svn+ssh://s...@svn.acme.com/repos/branches/2.2/2.2.0
{code}

I can see this code handling {{tagBase}}, but there is none for {{branchBase}}
{code}
if ( !StringUtils.isEmpty( tagBase )  
repository.getProvider().equals( svn ) )
{
SvnScmProviderRepository svnRepo = (SvnScmProviderRepository) 
repository.getProviderRepository();
svnRepo.setTagBase( tagBase );
}{code}
Adding a parallel handling for {{branchBase}} param should be trivial. 

Correcting the documentation is another thing -- the {{tagBase}} parameter is 
present on the base Mojo class even though it's ignored in some goals.

  was:
{code}[DEBUG] Configuring mojo 
'org.apache.maven.plugins:maven-scm-plugin:1.9.4:branch' with basic 
configurator --
[DEBUG]   (f) basedir = /home/acme/gotham/common_ui
[DEBUG]   (f) branch = 2.2/2.2.0
[DEBUG]   (f) connectionType = connection
[DEBUG]   (s) connectionUrl = 
scm:svn:svn+ssh://s...@svn.acme.com/repos/trunk/common_ui
[DEBUG]   (f) developerConnectionUrl = 
scm:svn:svn+ssh://s...@svn.acme.com/repos/trunk/common_ui
[DEBUG]   (f) pushChanges = true
[DEBUG]   (f) remoteBranching = false
[DEBUG]   (f) settings = org.apache.maven.execution.SettingsAdapter@7b300cde
[DEBUG] -- end configuration --
[INFO] Final Branch Name: '2.2/2.2.0'
[INFO] Executing: /bin/sh -c cd /home/acme/gotham/common_ui  svn 
--non-interactive copy --file /tmp/maven-scm-1267210601.commit . 
svn+ssh://s...@svn.acme.com/repos/branches/2.2/2.2.0
{code}

I can see this code handling {{tagBase}}, but there is none for {{branchBase}}
{code}
if ( !StringUtils.isEmpty( tagBase )  
repository.getProvider().equals( svn ) )
{
SvnScmProviderRepository svnRepo = (SvnScmProviderRepository) 
repository.getProviderRepository();
svnRepo.setTagBase( tagBase );
}{code}
Adding a parallel handling for {branchBase}} param should be trivial. 

Correcting the documentation is another thing -- the {{tagBase}} parameter is 
present on the base Mojo class even though it's ignored in some goals.


 scm:branch ignores the tagBase parameter, there is not branchBase parameter
 ---

 Key: SCM-798
 URL: https://issues.apache.org/jira/browse/SCM-798
 Project: Maven SCM
  Issue Type: Bug
  Components: maven-plugin, maven-scm-provider-svn
Affects Versions: 1.9.4
Reporter: Jakub Bochenski
Priority: Blocker

 {code}[DEBUG] Configuring mojo 
 'org.apache.maven.plugins:maven-scm-plugin:1.9.4:branch' with basic 
 configurator --
 [DEBUG]   (f) basedir = /home/acme/gotham/common_ui
 [DEBUG]   (f) branch = 2.2/2.2.0
 [DEBUG]   (f) connectionType = connection
 [DEBUG]   (s) connectionUrl = 
 scm:svn:svn+ssh://s...@svn.acme.com/repos/trunk/common_ui
 [DEBUG]   (f) developerConnectionUrl = 
 scm:svn:svn+ssh://s...@svn.acme.com/repos/trunk/common_ui
 [DEBUG]   (f) pushChanges = true
 [DEBUG]   (f) remoteBranching = false
 [DEBUG]   (f) settings = org.apache.maven.execution.SettingsAdapter@7b300cde
 [DEBUG] -- end configuration --
 [INFO] Final Branch Name: '2.2/2.2.0'
 [INFO] Executing: /bin/sh -c cd /home/acme/gotham/common_ui  svn 
 --non-interactive copy --file /tmp/maven-scm-1267210601.commit . 
 svn+ssh://s...@svn.acme.com/repos/branches/2.2/2.2.0
 {code}
 I can see this code handling {{tagBase}}, but there is none for {{branchBase}}
 {code}
 if ( !StringUtils.isEmpty( tagBase )  
 repository.getProvider().equals( svn ) )
 {
 SvnScmProviderRepository svnRepo = (SvnScmProviderRepository) 
 repository.getProviderRepository();
 svnRepo.setTagBase( tagBase );
 }{code}
 Adding a parallel handling for {{branchBase}} param should be trivial. 
 Correcting the documentation is another thing -- the {{tagBase}} parameter is 
 present on the base Mojo class even 

[jira] [Created] (SCM-798) scm:branch ignores the tagBase parameter, there is not branchBase parameter

2015-06-09 Thread Jakub Bochenski (JIRA)
Jakub Bochenski created SCM-798:
---

 Summary: scm:branch ignores the tagBase parameter, there is not 
branchBase parameter
 Key: SCM-798
 URL: https://issues.apache.org/jira/browse/SCM-798
 Project: Maven SCM
  Issue Type: Bug
  Components: maven-plugin, maven-scm-provider-svn
Affects Versions: 1.9.4
Reporter: Jakub Bochenski
Priority: Blocker


{code}[DEBUG] Configuring mojo 
'org.apache.maven.plugins:maven-scm-plugin:1.9.4:branch' with basic 
configurator --
[DEBUG]   (f) basedir = /home/acme/gotham/common_ui
[DEBUG]   (f) branch = 2.2/2.2.0
[DEBUG]   (f) connectionType = connection
[DEBUG]   (s) connectionUrl = 
scm:svn:svn+ssh://s...@svn.acme.com/repos/trunk/common_ui
[DEBUG]   (f) developerConnectionUrl = 
scm:svn:svn+ssh://s...@svn.acme.com/repos/trunk/common_ui
[DEBUG]   (f) pushChanges = true
[DEBUG]   (f) remoteBranching = false
[DEBUG]   (f) settings = org.apache.maven.execution.SettingsAdapter@7b300cde
[DEBUG] -- end configuration --
[INFO] Final Branch Name: '2.2/2.2.0'
[INFO] Executing: /bin/sh -c cd /home/acme/gotham/common_ui  svn 
--non-interactive copy --file /tmp/maven-scm-1267210601.commit . 
svn+ssh://s...@svn.acme.com/repos/branches/2.2/2.2.0
{code}

I can see this code handling {{tagBase}}, but there is none for {{branchBase}}
{code}
if ( !StringUtils.isEmpty( tagBase )  
repository.getProvider().equals( svn ) )
{
SvnScmProviderRepository svnRepo = (SvnScmProviderRepository) 
repository.getProviderRepository();
svnRepo.setTagBase( tagBase );
}{code}
Adding a parallel handling for {branchBase}} param should be trivial. 

Correcting the documentation is another thing -- the {{tagBase}} parameter is 
present on the base Mojo class even though it's ignored in some goals.



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


[jira] [Updated] (SCM-798) scm:branch ignores the tagBase parameter, there is not branchBase parameter

2015-06-09 Thread Jakub Bochenski (JIRA)

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

Jakub Bochenski updated SCM-798:

Description: 
{code}[DEBUG] Configuring mojo 
'org.apache.maven.plugins:maven-scm-plugin:1.9.4:branch' with basic 
configurator --
[DEBUG]   (f) basedir = /home/acme/gotham/common_ui
[DEBUG]   (f) branch = 2.2/2.2.0
[DEBUG]   (f) connectionType = connection
[DEBUG]   (s) connectionUrl = 
scm:svn:svn+ssh://s...@svn.acme.com/repos/trunk/common_ui
[DEBUG]   (f) developerConnectionUrl = 
scm:svn:svn+ssh://s...@svn.acme.com/repos/trunk/common_ui
[DEBUG]   (f) pushChanges = true
[DEBUG]   (f) remoteBranching = false
[DEBUG]   (f) settings = org.apache.maven.execution.SettingsAdapter@7b300cde
[DEBUG]   (f) tagBase = svn+ssh://s...@svn.acme.com/repos/branches/common_ui
[DEBUG] -- end configuration --
[INFO] Final Branch Name: '2.2/2.2.0'
[INFO] Executing: /bin/sh -c cd /home/acme/gotham/common_ui  svn 
--non-interactive copy --file /tmp/maven-scm-1267210601.commit . 
svn+ssh://s...@svn.acme.com/repos/branches/2.2/2.2.0
{code}

I can see this code handling {{tagBase}}, but there is none for {{branchBase}}
{code}
if ( !StringUtils.isEmpty( tagBase )  
repository.getProvider().equals( svn ) )
{
SvnScmProviderRepository svnRepo = (SvnScmProviderRepository) 
repository.getProviderRepository();
svnRepo.setTagBase( tagBase );
}{code}
Adding a parallel handling for {{branchBase}} param should be trivial. 

Correcting the documentation is another thing -- the {{tagBase}} parameter is 
present on the base Mojo class even though it's ignored in some goals.

  was:
{code}[DEBUG] Configuring mojo 
'org.apache.maven.plugins:maven-scm-plugin:1.9.4:branch' with basic 
configurator --
[DEBUG]   (f) basedir = /home/acme/gotham/common_ui
[DEBUG]   (f) branch = 2.2/2.2.0
[DEBUG]   (f) connectionType = connection
[DEBUG]   (s) connectionUrl = 
scm:svn:svn+ssh://s...@svn.acme.com/repos/trunk/common_ui
[DEBUG]   (f) developerConnectionUrl = 
scm:svn:svn+ssh://s...@svn.acme.com/repos/trunk/common_ui
[DEBUG]   (f) pushChanges = true
[DEBUG]   (f) remoteBranching = false
[DEBUG]   (f) settings = org.apache.maven.execution.SettingsAdapter@7b300cde
[DEBUG] -- end configuration --
[INFO] Final Branch Name: '2.2/2.2.0'
[INFO] Executing: /bin/sh -c cd /home/acme/gotham/common_ui  svn 
--non-interactive copy --file /tmp/maven-scm-1267210601.commit . 
svn+ssh://s...@svn.acme.com/repos/branches/2.2/2.2.0
{code}

I can see this code handling {{tagBase}}, but there is none for {{branchBase}}
{code}
if ( !StringUtils.isEmpty( tagBase )  
repository.getProvider().equals( svn ) )
{
SvnScmProviderRepository svnRepo = (SvnScmProviderRepository) 
repository.getProviderRepository();
svnRepo.setTagBase( tagBase );
}{code}
Adding a parallel handling for {{branchBase}} param should be trivial. 

Correcting the documentation is another thing -- the {{tagBase}} parameter is 
present on the base Mojo class even though it's ignored in some goals.


 scm:branch ignores the tagBase parameter, there is not branchBase parameter
 ---

 Key: SCM-798
 URL: https://issues.apache.org/jira/browse/SCM-798
 Project: Maven SCM
  Issue Type: Bug
  Components: maven-plugin, maven-scm-provider-svn
Affects Versions: 1.9.4
Reporter: Jakub Bochenski
Priority: Blocker

 {code}[DEBUG] Configuring mojo 
 'org.apache.maven.plugins:maven-scm-plugin:1.9.4:branch' with basic 
 configurator --
 [DEBUG]   (f) basedir = /home/acme/gotham/common_ui
 [DEBUG]   (f) branch = 2.2/2.2.0
 [DEBUG]   (f) connectionType = connection
 [DEBUG]   (s) connectionUrl = 
 scm:svn:svn+ssh://s...@svn.acme.com/repos/trunk/common_ui
 [DEBUG]   (f) developerConnectionUrl = 
 scm:svn:svn+ssh://s...@svn.acme.com/repos/trunk/common_ui
 [DEBUG]   (f) pushChanges = true
 [DEBUG]   (f) remoteBranching = false
 [DEBUG]   (f) settings = org.apache.maven.execution.SettingsAdapter@7b300cde
 [DEBUG]   (f) tagBase = svn+ssh://s...@svn.acme.com/repos/branches/common_ui
 [DEBUG] -- end configuration --
 [INFO] Final Branch Name: '2.2/2.2.0'
 [INFO] Executing: /bin/sh -c cd /home/acme/gotham/common_ui  svn 
 --non-interactive copy --file /tmp/maven-scm-1267210601.commit . 
 svn+ssh://s...@svn.acme.com/repos/branches/2.2/2.2.0
 {code}
 I can see this code handling {{tagBase}}, but there is none for {{branchBase}}
 {code}
 if ( !StringUtils.isEmpty( tagBase )  
 repository.getProvider().equals( svn ) )
 {
 SvnScmProviderRepository svnRepo = (SvnScmProviderRepository) 
 repository.getProviderRepository();
 svnRepo.setTagBase( tagBase );
 }{code}
 Adding a parallel handling for 

[jira] [Created] (MENFORCER-229) Ban Distribution Management documentation example doesn't work

2015-05-06 Thread Jakub Bochenski (JIRA)
Jakub Bochenski created MENFORCER-229:
-

 Summary: Ban Distribution Management documentation example doesn't 
work
 Key: MENFORCER-229
 URL: https://issues.apache.org/jira/browse/MENFORCER-229
 Project: Maven Enforcer Plugin
  Issue Type: Bug
  Components: Documentation, Standard Rules
Affects Versions: 1.4
Reporter: Jakub Bochenski


See 
https://github.com/jakub-bochenski/maven-enforcer-aggregator-failure/tree/master



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