[jira] [Closed] (MRESOLVER-362) NoSuchFileException moving .tmp to .jar

[Stephane Nicoll (Jira)]

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

Stephane Nicoll closed MRESOLVER-362.
-
Resolution: Won't Fix

Thanks so much. This was indeed a problem on our end and there is more info in 
https://github.com/snicoll-scratches/MRESOLVER-362/pull/1

> NoSuchFileException moving .tmp to .jar
> ---
>
> Key: MRESOLVER-362
> URL: https://issues.apache.org/jira/browse/MRESOLVER-362
> Project: Maven Resolver
>  Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Stephane Nicoll
>Priority: Major
>
> It looks like MRESOLVER-290 broke our metadata verification tests. We have a 
> test that uses the resolver API to collect a bunch of dependencies, and 
> checking the state is correct. Since the upgrade to 1.9 we get this
> {noformat}
> Caused by: org.eclipse.aether.transfer.ArtifactTransferException: Could not 
> transfer artifact 
> org.springframework.boot:spring-boot-starter:jar:3.0.8-20230525.115211-13 
> from/to spring-snapshots (https://repo.spring.io/snapshot): 
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar.4959477968260906889.tmp
>  -> 
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar
>   at 
> org.eclipse.aether.connector.basic.ArtifactTransportListener.transferFailed(ArtifactTransportListener.java:44)
>   at 
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:417)
>   at 
> org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:260)
>   at 
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:536)
>   at 
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:448)
>   ... 45 more
> Caused by: java.nio.file.NoSuchFileException: 
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar.4959477968260906889.tmp
>  -> 
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar
>   at 
> java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
>   at 
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
>   at java.base/sun.nio.fs.UnixCopyFile.move(UnixCopyFile.java:416)
>   at 
> java.base/sun.nio.fs.UnixFileSystemProvider.move(UnixFileSystemProvider.java:266)
>   at java.base/java.nio.file.Files.move(Files.java:1432)
>   at org.eclipse.aether.util.FileUtils$2.move(FileUtils.java:108)
>   at 
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:500)
>   at 
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:414)
> {noformat}
> The test is here 
> https://github.com/spring-io/start.spring.io/tree/main/start-site-verification/src/test/java/io/spring/start/site



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MRESOLVER-362) NoSuchFileException moving .tmp to .jar

[Stephane Nicoll (Jira)]

[ 
https://issues.apache.org/jira/browse/MRESOLVER-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17726512#comment-17726512
 ] 

Stephane Nicoll commented on MRESOLVER-362:
---

I've created a sample that is based on our test. The only reference to Spring 
is a utility to delete temporary directories so it shouldn't matter:
https://github.com/snicoll-scratches/MRESOLVER-362

I can make it fail with the error above consistently. Switching to `1.8.2` and 
the error goes away:

{noformat}
./mvnw test -Dmaven-resolver.version=1.8.2
{noformat}

> NoSuchFileException moving .tmp to .jar
> ---
>
> Key: MRESOLVER-362
> URL: https://issues.apache.org/jira/browse/MRESOLVER-362
> Project: Maven Resolver
>  Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Stephane Nicoll
>Priority: Major
>
> It looks like MRESOLVER-290 broke our metadata verification tests. We have a 
> test that uses the resolver API to collect a bunch of dependencies, and 
> checking the state is correct. Since the upgrade to 1.9 we get this
> {noformat}
> Caused by: org.eclipse.aether.transfer.ArtifactTransferException: Could not 
> transfer artifact 
> org.springframework.boot:spring-boot-starter:jar:3.0.8-20230525.115211-13 
> from/to spring-snapshots (https://repo.spring.io/snapshot): 
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar.4959477968260906889.tmp
>  -> 
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar
>   at 
> org.eclipse.aether.connector.basic.ArtifactTransportListener.transferFailed(ArtifactTransportListener.java:44)
>   at 
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:417)
>   at 
> org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:260)
>   at 
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:536)
>   at 
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:448)
>   ... 45 more
> Caused by: java.nio.file.NoSuchFileException: 
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar.4959477968260906889.tmp
>  -> 
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar
>   at 
> java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
>   at 
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
>   at java.base/sun.nio.fs.UnixCopyFile.move(UnixCopyFile.java:416)
>   at 
> java.base/sun.nio.fs.UnixFileSystemProvider.move(UnixFileSystemProvider.java:266)
>   at java.base/java.nio.file.Files.move(Files.java:1432)
>   at org.eclipse.aether.util.FileUtils$2.move(FileUtils.java:108)
>   at 
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:500)
>   at 
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:414)
> {noformat}
> The test is here 
> https://github.com/spring-io/start.spring.io/tree/main/start-site-verification/src/test/java/io/spring/start/site



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MRESOLVER-362) NoSuchFileException moving .tmp to .jar

[Stephane Nicoll (Jira)]

[ 
https://issues.apache.org/jira/browse/MRESOLVER-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17726201#comment-17726201
 ] 

Stephane Nicoll commented on MRESOLVER-362:
---

If you want to give it a try with the latest state, make sure to revert 1ed8af5 
as I've downgraded to 1.8 in the meantime.

> NoSuchFileException moving .tmp to .jar
> ---
>
> Key: MRESOLVER-362
> URL: https://issues.apache.org/jira/browse/MRESOLVER-362
> Project: Maven Resolver
>  Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Stephane Nicoll
>Priority: Major
>
> It looks like MRESOLVER-290 broke our metadata verification tests. We have a 
> test that uses the resolver API to collect a bunch of dependencies, and 
> checking the state is correct. Since the upgrade to 1.9 we get this
> {noformat}
> Caused by: org.eclipse.aether.transfer.ArtifactTransferException: Could not 
> transfer artifact 
> org.springframework.boot:spring-boot-starter:jar:3.0.8-20230525.115211-13 
> from/to spring-snapshots (https://repo.spring.io/snapshot): 
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar.4959477968260906889.tmp
>  -> 
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar
>   at 
> org.eclipse.aether.connector.basic.ArtifactTransportListener.transferFailed(ArtifactTransportListener.java:44)
>   at 
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:417)
>   at 
> org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:260)
>   at 
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:536)
>   at 
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:448)
>   ... 45 more
> Caused by: java.nio.file.NoSuchFileException: 
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar.4959477968260906889.tmp
>  -> 
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar
>   at 
> java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
>   at 
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
>   at java.base/sun.nio.fs.UnixCopyFile.move(UnixCopyFile.java:416)
>   at 
> java.base/sun.nio.fs.UnixFileSystemProvider.move(UnixFileSystemProvider.java:266)
>   at java.base/java.nio.file.Files.move(Files.java:1432)
>   at org.eclipse.aether.util.FileUtils$2.move(FileUtils.java:108)
>   at 
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:500)
>   at 
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:414)
> {noformat}
> The test is here 
> https://github.com/spring-io/start.spring.io/tree/main/start-site-verification/src/test/java/io/spring/start/site



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MRESOLVER-362) NoSuchFileException moving .tmp to .jar

[Stephane Nicoll (Jira)]

[ 
https://issues.apache.org/jira/browse/MRESOLVER-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17726200#comment-17726200
 ] 

Stephane Nicoll commented on MRESOLVER-362:
---

Yes. I have a particular occurrence that fails every time, and on that same 
artifact above.

> NoSuchFileException moving .tmp to .jar
> ---
>
> Key: MRESOLVER-362
> URL: https://issues.apache.org/jira/browse/MRESOLVER-362
> Project: Maven Resolver
>  Issue Type: Bug
>Affects Versions: 1.9.10
>Reporter: Stephane Nicoll
>Priority: Major
>
> It looks like MRESOLVER-290 broke our metadata verification tests. We have a 
> test that uses the resolver API to collect a bunch of dependencies, and 
> checking the state is correct. Since the upgrade to 1.9 we get this
> {noformat}
> Caused by: org.eclipse.aether.transfer.ArtifactTransferException: Could not 
> transfer artifact 
> org.springframework.boot:spring-boot-starter:jar:3.0.8-20230525.115211-13 
> from/to spring-snapshots (https://repo.spring.io/snapshot): 
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar.4959477968260906889.tmp
>  -> 
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar
>   at 
> org.eclipse.aether.connector.basic.ArtifactTransportListener.transferFailed(ArtifactTransportListener.java:44)
>   at 
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:417)
>   at 
> org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:260)
>   at 
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:536)
>   at 
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:448)
>   ... 45 more
> Caused by: java.nio.file.NoSuchFileException: 
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar.4959477968260906889.tmp
>  -> 
> /var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar
>   at 
> java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
>   at 
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
>   at java.base/sun.nio.fs.UnixCopyFile.move(UnixCopyFile.java:416)
>   at 
> java.base/sun.nio.fs.UnixFileSystemProvider.move(UnixFileSystemProvider.java:266)
>   at java.base/java.nio.file.Files.move(Files.java:1432)
>   at org.eclipse.aether.util.FileUtils$2.move(FileUtils.java:108)
>   at 
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:500)
>   at 
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:414)
> {noformat}
> The test is here 
> https://github.com/spring-io/start.spring.io/tree/main/start-site-verification/src/test/java/io/spring/start/site



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (MRESOLVER-362) NoSuchFileException moving .tmp to .jar

[Stephane Nicoll (Jira)]

Stephane Nicoll created MRESOLVER-362:
-

 Summary: NoSuchFileException moving .tmp to .jar
 Key: MRESOLVER-362
 URL: https://issues.apache.org/jira/browse/MRESOLVER-362
 Project: Maven Resolver
  Issue Type: Bug
Affects Versions: 1.9.10
Reporter: Stephane Nicoll


It looks like MRESOLVER-290 broke our metadata verification tests. We have a 
test that uses the resolver API to collect a bunch of dependencies, and 
checking the state is correct. Since the upgrade to 1.9 we get this

{noformat}
Caused by: org.eclipse.aether.transfer.ArtifactTransferException: Could not 
transfer artifact 
org.springframework.boot:spring-boot-starter:jar:3.0.8-20230525.115211-13 
from/to spring-snapshots (https://repo.spring.io/snapshot): 
/var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar.4959477968260906889.tmp
 -> 
/var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar
at 
org.eclipse.aether.connector.basic.ArtifactTransportListener.transferFailed(ArtifactTransportListener.java:44)
at 
org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:417)
at 
org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:260)
at 
org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:536)
at 
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:448)
... 45 more
Caused by: java.nio.file.NoSuchFileException: 
/var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar.4959477968260906889.tmp
 -> 
/var/folders/46/2wr2nf9x0nzd1220xfnp1nzrgn/T/metadata-validation-m28912614894186841938/org/springframework/boot/spring-boot-starter/3.0.8-SNAPSHOT/spring-boot-starter-3.0.8-20230525.115211-13.jar
at 
java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
at 
java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
at java.base/sun.nio.fs.UnixCopyFile.move(UnixCopyFile.java:416)
at 
java.base/sun.nio.fs.UnixFileSystemProvider.move(UnixFileSystemProvider.java:266)
at java.base/java.nio.file.Files.move(Files.java:1432)
at org.eclipse.aether.util.FileUtils$2.move(FileUtils.java:108)
at 
org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:500)
at 
org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:414)
{noformat}

The test is here 
https://github.com/spring-io/start.spring.io/tree/main/start-site-verification/src/test/java/io/spring/start/site



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MNG-6397) Maven Transitive Dependency Resolution Does Not Respect Repository Definition in pom.xml

[Stephane Nicoll (Jira)]

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

Stephane Nicoll edited comment on MNG-6397 at 8/31/20, 8:18 AM:


> Spring Boot forces you to use @ instead:

It doesn't do that in any way. As Brian indicated, you don't have to use the 
parent if you don't want to (have you looked at the references he shared before 
replying)? Even if you do, you can easily override the resources filtering 
configuration to use whatever placeholders you fancy.


>  if you reference the Spring Boot parent POM (which is the highly recommended 
> way to do a Spring Boot project) 

Given the italics in "highly", I suspect you believe that's true. It isn't. 

I think Brian already showcased we're happy to improve things based on 
constructive feedback. [Spring Boot lets you chose your own 
parent|https://docs.spring.io/spring-boot/docs/current/maven-plugin/reference/html/#using-import].
 You can chose to import our BOM there or manage things yourself completely. Of 
course, doing so may mean more work for you. 


was (Author: snicoll):
> Spring Boot forces you to use @ instead:

It doesn't do that in any way. As Brian indicated, you don't have to use the 
parent if you don't want to (have you looked at the references he shared before 
replying)? Even if you do, you can easily override the resources filtering to 
use whatever placeholders you fancy.


>  if you reference the Spring Boot parent POM (which is the highly recommended 
> way to do a Spring Boot project) 

Given the italics in "highly", I suspect you believe that's true. It isn't. 

I think Brian already showcased we're happy to improve things based on 
constructive feedback. [Spring Boot lets you chose your own 
parent|https://docs.spring.io/spring-boot/docs/current/maven-plugin/reference/html/#using-import].
 You can chose to import our BOM there or manage things yourself completely. Of 
course, doing so may mean more work for you. 

> Maven Transitive Dependency Resolution Does Not Respect Repository Definition 
> in pom.xml
> 
>
> Key: MNG-6397
> URL: https://issues.apache.org/jira/browse/MNG-6397
> Project: Maven
>  Issue Type: New Feature
>  Components: Artifacts and Repositories, Dependencies, POM
>Affects Versions: 3.5.0, 3.5.2, 3.5.3, 3.6.0, 3.6.1, 3.6.3
> Environment: Apache Maven 3.5.0 
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T15:39:06-04:00)
> Maven home: /usr/local/share/maven
> Java version: 1.8.0_161, vendor: Oracle Corporation
> Java home: 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_161.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.10.5", arch: "x86_64", family: "mac"
>Reporter: Alan Czajkowski
>Priority: Critical
>  Labels: maven
>
> _*Note:* I am trying to do a build behind a firewall which means I cannot 
> access the Internet, I can only access my internal Maven repository inside my 
> network, so:_
> - _grabbing artifacts from https://artifacts.example.com/repository/maven/ 
> works fine_
> - _grabbing artifacts from anywhere else fails due to firewall restrictions_
> Let's begin:
> My {{pom.xml}} has the following:
> {code:xml}
> ...
> 
> ...
> 
> org.springframework.boot
> spring-boot-starter-web
> 2.0.0.RELEASE
> 
> ...
> 
> ...
> 
> ...
> 
> central
> Public
> https://artifacts.example.com/repository/maven/
> 
> true
> 
> 
> true
> 
> 
> ...
> 
> ...
> {code}
> The {{dependency:tree}} for the {{spring-boot-starter-web}} is as follows:
> {code:java}
> +- org.springframework.boot:spring-boot-starter-web:jar:2.0.0.RELEASE:compile
> |  +- 
> org.springframework.boot:spring-boot-starter-json:jar:2.0.0.RELEASE:compile
> |  |  +- 
> com.fasterxml.jackson.datatype:jackson-datatype-jdk8:jar:2.9.4:compile
> |  |  +- 
> com.fasterxml.jackson.datatype:jackson-datatype-jsr310:jar:2.9.4:compile
> |  |  \- 
> com.fasterxml.jackson.module:jackson-module-parameter-names:jar:2.9.4:compile
> |  +- 
> org.springframework.boot:spring-boot-starter-tomcat:jar:2.0.0.RELEASE:compile
> |  |  \- org.apache.tomcat.embed:tomcat-embed-websocket:jar:8.5.28:compile
> |  +- org.hibernate.validator:hibernate-validator:jar:6.0.7.Final:compile
> |  |  +- javax.validation:validation-api:jar:2.0.1.Final:compile
> |  |  +- org.jboss.logging:jboss-logging:jar:3.3.0.Final:compile
> |  |  \- com.fasterxml:classmate:jar:1.3.1:compile
> |  \- org.springframework:spring-web:jar:5.0.4.RELEASE:compile
> {code}
> How is it that the build fails as such:
> 

[jira] [Commented] (MNG-6397) Maven Transitive Dependency Resolution Does Not Respect Repository Definition in pom.xml

[Stephane Nicoll (Jira)]

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

Stephane Nicoll commented on MNG-6397:
--

> Spring Boot forces you to use @ instead:

It doesn't do that in any way. As Brian indicated, you don't have to use the 
parent if you don't want to (have you looked at the references he shared before 
replying)? Even if you do, you can easily override the resources filtering to 
use whatever placeholders you fancy.


>  if you reference the Spring Boot parent POM (which is the highly recommended 
> way to do a Spring Boot project) 

Given the italics in "highly", I suspect you believe that's true. It isn't. 

I think Brian already showcased we're happy to improve things based on 
constructive feedback. [Spring Boot lets you chose your own 
parent|https://docs.spring.io/spring-boot/docs/current/maven-plugin/reference/html/#using-import].
 You can chose to import our BOM there or manage things yourself completely. Of 
course, doing so may mean more work for you. 

> Maven Transitive Dependency Resolution Does Not Respect Repository Definition 
> in pom.xml
> 
>
> Key: MNG-6397
> URL: https://issues.apache.org/jira/browse/MNG-6397
> Project: Maven
>  Issue Type: New Feature
>  Components: Artifacts and Repositories, Dependencies, POM
>Affects Versions: 3.5.0, 3.5.2, 3.5.3, 3.6.0, 3.6.1, 3.6.3
> Environment: Apache Maven 3.5.0 
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T15:39:06-04:00)
> Maven home: /usr/local/share/maven
> Java version: 1.8.0_161, vendor: Oracle Corporation
> Java home: 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_161.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.10.5", arch: "x86_64", family: "mac"
>Reporter: Alan Czajkowski
>Priority: Critical
>  Labels: maven
>
> _*Note:* I am trying to do a build behind a firewall which means I cannot 
> access the Internet, I can only access my internal Maven repository inside my 
> network, so:_
> - _grabbing artifacts from https://artifacts.example.com/repository/maven/ 
> works fine_
> - _grabbing artifacts from anywhere else fails due to firewall restrictions_
> Let's begin:
> My {{pom.xml}} has the following:
> {code:xml}
> ...
> 
> ...
> 
> org.springframework.boot
> spring-boot-starter-web
> 2.0.0.RELEASE
> 
> ...
> 
> ...
> 
> ...
> 
> central
> Public
> https://artifacts.example.com/repository/maven/
> 
> true
> 
> 
> true
> 
> 
> ...
> 
> ...
> {code}
> The {{dependency:tree}} for the {{spring-boot-starter-web}} is as follows:
> {code:java}
> +- org.springframework.boot:spring-boot-starter-web:jar:2.0.0.RELEASE:compile
> |  +- 
> org.springframework.boot:spring-boot-starter-json:jar:2.0.0.RELEASE:compile
> |  |  +- 
> com.fasterxml.jackson.datatype:jackson-datatype-jdk8:jar:2.9.4:compile
> |  |  +- 
> com.fasterxml.jackson.datatype:jackson-datatype-jsr310:jar:2.9.4:compile
> |  |  \- 
> com.fasterxml.jackson.module:jackson-module-parameter-names:jar:2.9.4:compile
> |  +- 
> org.springframework.boot:spring-boot-starter-tomcat:jar:2.0.0.RELEASE:compile
> |  |  \- org.apache.tomcat.embed:tomcat-embed-websocket:jar:8.5.28:compile
> |  +- org.hibernate.validator:hibernate-validator:jar:6.0.7.Final:compile
> |  |  +- javax.validation:validation-api:jar:2.0.1.Final:compile
> |  |  +- org.jboss.logging:jboss-logging:jar:3.3.0.Final:compile
> |  |  \- com.fasterxml:classmate:jar:1.3.1:compile
> |  \- org.springframework:spring-web:jar:5.0.4.RELEASE:compile
> {code}
> How is it that the build fails as such:
> {code:java}
> ...
> Downloading: 
> https://repo.spring.io/milestone/org/jboss/shrinkwrap/shrinkwrap-bom/1.2.3/shrinkwrap-bom-1.2.3.pom
> Downloading: 
> https://repo.spring.io/snapshot/org/jboss/shrinkwrap/shrinkwrap-bom/1.2.3/shrinkwrap-bom-1.2.3.pom
> Downloading: 
> https://dl.bintray.com/rabbitmq/maven-milestones/org/jboss/shrinkwrap/shrinkwrap-bom/1.2.3/shrinkwrap-bom-1.2.3.pom
> Downloading: 
> https://repo.maven.apache.org/maven2/org/jboss/shrinkwrap/shrinkwrap-bom/1.2.3/shrinkwrap-bom-1.2.3.pom
> ...
> [ERROR] Failed to execute goal on project maven-multi-module-demo-backend: 
> Could not resolve dependencies for project 
> com.example.pipe:maven-multi-module-demo-backend:war:1.0.0-SNAPSHOT: Failed 
> to collect dependencies at 
> org.springframework.boot:spring-boot-starter-web:jar:2.0.0.RELEASE -> 
> org.hibernate.validator:hibernate-validator:jar:6.0.7.Final: Failed to read 
> artifact descriptor for 
> 

[jira] [Commented] (MJAR-264) finalName property can be set and is not immutable

[Stephane Nicoll (JIRA)]

[ 
https://issues.apache.org/jira/browse/MJAR-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16838387#comment-16838387
 ] 

Stephane Nicoll commented on MJAR-264:
--

This is not about the fact the field is not effectively read-only but rather 
that its default value is lazily resolved. Given that the field is supposed to 
be read-only, the default in the annotation basically means the value we should 
use. The problem with this arrangement (besides the field can actually be set) 
is that its value is resolved once the plugin executes. 

 

In other words, if you have an expression as in the attached project, 
\{{MavenProject#getBuild().getFinalName()}} does not return the same thing.

> finalName property can be set and is not immutable
> --
>
> Key: MJAR-264
> URL: https://issues.apache.org/jira/browse/MJAR-264
> Project: Maven JAR Plugin
>  Issue Type: Bug
>Affects Versions: 3.1.1
>Reporter: Stephane Nicoll
>Priority: Major
>
> From what I understood, the intention of making sure the {{finalName}} is 
> read-only was to prevent users to be able to mutate its value while the build 
> was running. Rather, they should use the standard {{build/finalName}} that is 
> immutable.
> Unfortunately, both these are happening at the moment. There is a bug so that 
> {{read-only}} is ignored and the field can be set anyway. And because the 
> field as a default to the standard property, its value is evaluated lazily 
> and can change based on the execution of another plugin.
> Here is a simple project that reproduces the problem with the latest version 
> of the plugin: [https://github.com/snicoll-scratches/test-jar-final-name]
> The Spring Boot Maven Plugin has the exact same setup (actually we did align 
> our plugin to what the jar plugin did for consistency). We broke users by 
> removing the field when we noticed one can still set it and we are looking 
> for advices as what to do. We want to make sure that the decision we take is 
> align with the direction of core plugins.
> Thanks!
>  
>  



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

[jira] [Created] (MJAR-264) finalName property can be set and is not immutable

[Stephane Nicoll (JIRA)]

Stephane Nicoll created MJAR-264:


 Summary: finalName property can be set and is not immutable
 Key: MJAR-264
 URL: https://issues.apache.org/jira/browse/MJAR-264
 Project: Maven JAR Plugin
  Issue Type: Bug
Affects Versions: 3.1.1
Reporter: Stephane Nicoll


>From what I understood, the intention of making sure the {{finalName}} is 
>read-only was to prevent users to be able to mutate its value while the build 
>was running. Rather, they should use the standard {{build/finalName}} that is 
>immutable.

Unfortunately, both these are happening at the moment. There is a bug so that 
{{read-only}} is ignored and the field can be set anyway. And because the field 
as a default to the standard property, its value is evaluated lazily and can 
change based on the execution of another plugin.

Here is a simple project that reproduces the problem with the latest version of 
the plugin: [https://github.com/snicoll-scratches/test-jar-final-name]

The Spring Boot Maven Plugin has the exact same setup (actually we did align 
our plugin to what the jar plugin did for consistency). We broke users by 
removing the field when we noticed one can still set it and we are looking for 
advices as what to do. We want to make sure that the decision we take is align 
with the direction of core plugins.

Thanks!

 

 



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

[jira] [Comment Edited] (SUREFIRE-1198) Failsafe does not allow to configure the jar file to use

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll edited comment on SUREFIRE-1198 at 11/3/18 3:47 PM:


I don't thinks that error is related to this issue. Spring Boot is using 
Failsafe 2.22.1 in {{spring-boot-starter-parent}} with this extra configuration

{noformat}

${project.build.outputDirectory}

{noformat}


was (Author: snicoll):
I don't thinks that error is related to this issue. Spring Boot is using 
Failsafe 2.22.1 in {{spring-boot-starter-parent}} with this extra configuration

{{noformat}}

${project.build.outputDirectory}

{{noformat}}

> Failsafe does not allow to configure the jar file to use
> 
>
> Key: SUREFIRE-1198
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1198
> Project: Maven Surefire
>  Issue Type: Bug
>Reporter: Stephane Nicoll
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.20
>
>
> See [this Spring Boot 
> issue|https://github.com/spring-projects/spring-boot/issues/4510#issuecomment-159448634]
> It seems that SUREFIRE-855 does not allow {{target/classes}} to be used 
> anymore. Is there a reason why this behaviour was completely removed in 
> favour of only the jar file?
> It would be nice if we had an option to chose between the two (defaulting to 
> the jar)



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

[jira] [Commented] (SUREFIRE-1198) Failsafe does not allow to configure the jar file to use

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll commented on SUREFIRE-1198:
---

I don't thinks that error is related to this issue. Spring Boot is using 
Failsafe 2.22.1 in {{spring-boot-starter-parent}} with this extra configuration

{{noformat}}

${project.build.outputDirectory}

{{noformat}}

> Failsafe does not allow to configure the jar file to use
> 
>
> Key: SUREFIRE-1198
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1198
> Project: Maven Surefire
>  Issue Type: Bug
>Reporter: Stephane Nicoll
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.20
>
>
> See [this Spring Boot 
> issue|https://github.com/spring-projects/spring-boot/issues/4510#issuecomment-159448634]
> It seems that SUREFIRE-855 does not allow {{target/classes}} to be used 
> anymore. Is there a reason why this behaviour was completely removed in 
> favour of only the jar file?
> It would be nice if we had an option to chose between the two (defaulting to 
> the jar)



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

[jira] [Commented] (MNGSITE-310) general recommendation for the element order in the POM

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll commented on MNGSITE-310:
-

Alright, thanks for the suggestion!

> general recommendation for the element order in the POM
> ---
>
> Key: MNGSITE-310
> URL: https://issues.apache.org/jira/browse/MNGSITE-310
> Project: Maven Project Web Site
>  Issue Type: Improvement
>Reporter: Franz van Betteraey
>Priority: Minor
>  Labels: convention, pom
>
> A 
> [convention|https://maven.apache.org/developers/conventions/code.html#POM_Code_Convention]
>  for the element order in POM files is recommended for Maven developer and 
> contributor but not for the general usage of Maven. I think it would be 
> useful to recommend the element order also for general usage. A common order 
> would
> * give an answer to the question of the order for all who ask themselves this 
> question
> * help to easily cope with the content of pom files (even in unknown projects)
> A good place for the recommendation would be the [Maven 
> conventions|https://maven.apache.org/maven-conventions.html] or [POM 
> reference |https://maven.apache.org/pom.html] document.
> The background for this request is a discussion on twitter:
> https://twitter.com/FrVaBe/status/870263530473369601
> https://twitter.com/snicoll/status/874231018957545472
> A possible argument against such a convention would probably be, that 
> projects that used another element order would be suddenly considered as 
> "wrong" ordered.
> But I think that everyone that wondered about how to order the elements has 
> probably found the developer conventions and used theses as an appropriate 
> convention. There are even tools to check this convention 
> ([SonarQube|https://jira.sonarsource.com/browse/RSPEC-3423]) and to support 
> this convention ([Tidy Maven 
> plugin|http://www.mojohaus.org/tidy-maven-plugin/]). The Convention is thus 
> already established.
>   



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

[jira] [Closed] (MNGSITE-310) general recommendation for the element order in the POM

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll closed MNGSITE-310.
---
Resolution: Won't Fix

> general recommendation for the element order in the POM
> ---
>
> Key: MNGSITE-310
> URL: https://issues.apache.org/jira/browse/MNGSITE-310
> Project: Maven Project Web Site
>  Issue Type: Improvement
>Reporter: Franz van Betteraey
>Priority: Minor
>  Labels: convention, pom
>
> A 
> [convention|https://maven.apache.org/developers/conventions/code.html#POM_Code_Convention]
>  for the element order in POM files is recommended for Maven developer and 
> contributor but not for the general usage of Maven. I think it would be 
> useful to recommend the element order also for general usage. A common order 
> would
> * give an answer to the question of the order for all who ask themselves this 
> question
> * help to easily cope with the content of pom files (even in unknown projects)
> A good place for the recommendation would be the [Maven 
> conventions|https://maven.apache.org/maven-conventions.html] or [POM 
> reference |https://maven.apache.org/pom.html] document.
> The background for this request is a discussion on twitter:
> https://twitter.com/FrVaBe/status/870263530473369601
> https://twitter.com/snicoll/status/874231018957545472
> A possible argument against such a convention would probably be, that 
> projects that used another element order would be suddenly considered as 
> "wrong" ordered.
> But I think that everyone that wondered about how to order the elements has 
> probably found the developer conventions and used theses as an appropriate 
> convention. There are even tools to check this convention 
> ([SonarQube|https://jira.sonarsource.com/browse/RSPEC-3423]) and to support 
> this convention ([Tidy Maven 
> plugin|http://www.mojohaus.org/tidy-maven-plugin/]). The Convention is thus 
> already established.
>   



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

[jira] [Assigned] (MINVOKER-224) Unable to set cloneProjectsTo to null

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll reassigned MINVOKER-224:


 Assignee: Robert Scholte
Affects Version/s: 3.0.1
Fix Version/s: 3.0.2

> Unable to set cloneProjectsTo to null
> -
>
> Key: MINVOKER-224
> URL: https://issues.apache.org/jira/browse/MINVOKER-224
> Project: Maven Invoker Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.1
>Reporter: Phillip Webb
>Assignee: Robert Scholte
> Fix For: 3.0.2
>
>
> [MINVOKER-219|https://issues.apache.org/jira/browse/MINVOKER-219] changed the 
> default value of {{cloneProjectsTo}} to {{target/its}}. This change 
> unfortunately now makes it impossible to have a {{null}} value, meaning that 
> in-place invocation is no longer supported. From the Javadoc:
> {quote}Directory to which projects should be cloned prior to execution. If 
> set to null, each integration test will be run in the directory in which the 
> corresponding IT POM was found. In this case, you most likely want to 
> configure your SCM to ignore target and build.log in the test's base 
> directory.{quote}
> Is it possible to revert this change, or to provide a alternative property to 
> allow cloning to be skipped?



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

[jira] [Reopened] (SUREFIRE-1424) javax.transaction.TransactionManager not visible with Java9

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll reopened SUREFIRE-1424:
---

> javax.transaction.TransactionManager not visible with Java9
> ---
>
> Key: SUREFIRE-1424
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1424
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1
> Environment: Apache Maven 3.5.0 
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
> Maven home: /Users/snicoll/tools/maven
> Java version: 9, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home
> Default locale: en_BE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"
>Reporter: Stephane Nicoll
>Assignee: Tibor Digana
>
> I am trying to port Spring Boot to Java9 and I am hitting an issue that looks 
> like Maven specific. I've managed to trim down the problem to [a simple class 
> that doesn't involve Spring 
> Boot|https://github.com/snicoll-scratches/test-jta-java9]
> If I run this project on the command line, I get the following:
> {noformat}
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.043 s <<< 
> FAILURE! - in com.example.testjtajava9.TestJtaJava9ApplicationTests
> contextLoads(com.example.testjtajava9.TestJtaJava9ApplicationTests)  Time 
> elapsed: 0.006 s  <<< ERROR!
> java.lang.NoClassDefFoundError: javax/transaction/TransactionManager
>   at 
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> Caused by: java.lang.ClassNotFoundException: 
> javax.transaction.TransactionManager
>   at 
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> {noformat}
> If I run that test with IntelliJ IDEA, it passes. This sample project has 
> also a simple Gradle build that shows it works with Gradle as well.



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

[jira] [Updated] (SUREFIRE-1424) javax.transaction.TransactionManager not visible with Java9

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll updated SUREFIRE-1424:
--
Description: 
I am trying to port Spring Boot to Java9 and I am hitting an issue that looks 
like Maven specific. I've managed to trim down the problem to [a simple class 
that doesn't involve Spring 
Boot|https://github.com/snicoll-scratches/test-jta-java9]

If I run this project on the command line, I get the following:

{noformat}
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.043 s <<< 
FAILURE! - in com.example.testjtajava9.TestJtaJava9ApplicationTests
contextLoads(com.example.testjtajava9.TestJtaJava9ApplicationTests)  Time 
elapsed: 0.006 s  <<< ERROR!
java.lang.NoClassDefFoundError: javax/transaction/TransactionManager
at 
com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
Caused by: java.lang.ClassNotFoundException: 
javax.transaction.TransactionManager
at 
com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
{noformat}

If I run that test with IntelliJ IDEA, it passes. This sample project has also 
a simple Gradle build that shows it works with Gradle as well.



  was:
I am trying to port Spring Boot to Java9 and I am hitting an issue that looks 
like Maven specific. I've managed to trim down the problem to [a simple class 
that doesn't involve Spring 
Boot|https://github.com/snicoll-scratches/test-jta-java9]

If I run this project on the command line, I get the following:

{noformat}
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.043 s <<< 
FAILURE! - in com.example.testjtajava9.TestJtaJava9ApplicationTests
contextLoads(com.example.testjtajava9.TestJtaJava9ApplicationTests)  Time 
elapsed: 0.006 s  <<< ERROR!
java.lang.NoClassDefFoundError: javax/transaction/TransactionManager
at 
com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
Caused by: java.lang.ClassNotFoundException: 
javax.transaction.TransactionManager
at 
com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
{noformat}

If I run that test with IntelliJ IDEA, it passes.




> javax.transaction.TransactionManager not visible with Java9
> ---
>
> Key: SUREFIRE-1424
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1424
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1
> Environment: Apache Maven 3.5.0 
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
> Maven home: /Users/snicoll/tools/maven
> Java version: 9, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home
> Default locale: en_BE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"
>Reporter: Stephane Nicoll
>
> I am trying to port Spring Boot to Java9 and I am hitting an issue that looks 
> like Maven specific. I've managed to trim down the problem to [a simple class 
> that doesn't involve Spring 
> Boot|https://github.com/snicoll-scratches/test-jta-java9]
> If I run this project on the command line, I get the following:
> {noformat}
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.043 s <<< 
> FAILURE! - in com.example.testjtajava9.TestJtaJava9ApplicationTests
> contextLoads(com.example.testjtajava9.TestJtaJava9ApplicationTests)  Time 
> elapsed: 0.006 s  <<< ERROR!
> java.lang.NoClassDefFoundError: javax/transaction/TransactionManager
>   at 
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> Caused by: java.lang.ClassNotFoundException: 
> javax.transaction.TransactionManager
>   at 
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> {noformat}
> If I run that test with IntelliJ IDEA, it passes. This sample project has 
> also a simple Gradle build that shows it works with Gradle as well.



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

[jira] [Created] (SUREFIRE-1424) javax.transaction.TransactionManager not visible with Java9

[Stephane Nicoll (JIRA)]

Stephane Nicoll created SUREFIRE-1424:
-

 Summary: javax.transaction.TransactionManager not visible with 
Java9
 Key: SUREFIRE-1424
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1424
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin
Affects Versions: 2.20.1
 Environment: Apache Maven 3.5.0 
(ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
Maven home: /Users/snicoll/tools/maven
Java version: 9, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home
Default locale: en_BE, platform encoding: UTF-8
OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"
Reporter: Stephane Nicoll


I am trying to port Spring Boot to Java9 and I am hitting an issue that looks 
like Maven specific. I've managed to trim down the problem to [a simple class 
that doesn't involve Spring 
Boot|https://github.com/snicoll-scratches/test-jta-java9]

If I run this project on the command line, I get the following:

{{noformat}}
ests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.043 s <<< 
FAILURE! - in com.example.testjtajava9.TestJtaJava9ApplicationTests
contextLoads(com.example.testjtajava9.TestJtaJava9ApplicationTests)  Time 
elapsed: 0.006 s  <<< ERROR!
java.lang.NoClassDefFoundError: javax/transaction/TransactionManager
at 
com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
Caused by: java.lang.ClassNotFoundException: 
javax.transaction.TransactionManager
at 
com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
{{noformat}}

If I run that test with IntelliJ IDEA, it passes.





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

[jira] [Updated] (SUREFIRE-1424) javax.transaction.TransactionManager not visible with Java9

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll updated SUREFIRE-1424:
--
Description: 
I am trying to port Spring Boot to Java9 and I am hitting an issue that looks 
like Maven specific. I've managed to trim down the problem to [a simple class 
that doesn't involve Spring 
Boot|https://github.com/snicoll-scratches/test-jta-java9]

If I run this project on the command line, I get the following:

{noformat}
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.043 s <<< 
FAILURE! - in com.example.testjtajava9.TestJtaJava9ApplicationTests
contextLoads(com.example.testjtajava9.TestJtaJava9ApplicationTests)  Time 
elapsed: 0.006 s  <<< ERROR!
java.lang.NoClassDefFoundError: javax/transaction/TransactionManager
at 
com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
Caused by: java.lang.ClassNotFoundException: 
javax.transaction.TransactionManager
at 
com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
{noformat}

If I run that test with IntelliJ IDEA, it passes.



  was:
I am trying to port Spring Boot to Java9 and I am hitting an issue that looks 
like Maven specific. I've managed to trim down the problem to [a simple class 
that doesn't involve Spring 
Boot|https://github.com/snicoll-scratches/test-jta-java9]

If I run this project on the command line, I get the following:

{{noformat}}
ests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.043 s <<< 
FAILURE! - in com.example.testjtajava9.TestJtaJava9ApplicationTests
contextLoads(com.example.testjtajava9.TestJtaJava9ApplicationTests)  Time 
elapsed: 0.006 s  <<< ERROR!
java.lang.NoClassDefFoundError: javax/transaction/TransactionManager
at 
com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
Caused by: java.lang.ClassNotFoundException: 
javax.transaction.TransactionManager
at 
com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
{{noformat}}

If I run that test with IntelliJ IDEA, it passes.




> javax.transaction.TransactionManager not visible with Java9
> ---
>
> Key: SUREFIRE-1424
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1424
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1
> Environment: Apache Maven 3.5.0 
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
> Maven home: /Users/snicoll/tools/maven
> Java version: 9, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home
> Default locale: en_BE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"
>Reporter: Stephane Nicoll
>
> I am trying to port Spring Boot to Java9 and I am hitting an issue that looks 
> like Maven specific. I've managed to trim down the problem to [a simple class 
> that doesn't involve Spring 
> Boot|https://github.com/snicoll-scratches/test-jta-java9]
> If I run this project on the command line, I get the following:
> {noformat}
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.043 s <<< 
> FAILURE! - in com.example.testjtajava9.TestJtaJava9ApplicationTests
> contextLoads(com.example.testjtajava9.TestJtaJava9ApplicationTests)  Time 
> elapsed: 0.006 s  <<< ERROR!
> java.lang.NoClassDefFoundError: javax/transaction/TransactionManager
>   at 
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> Caused by: java.lang.ClassNotFoundException: 
> javax.transaction.TransactionManager
>   at 
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> {noformat}
> If I run that test with IntelliJ IDEA, it passes.



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

[jira] [Created] (MASSEMBLY-860) Upgrade to Java 7

[Stephane Nicoll (JIRA)]

Stephane Nicoll created MASSEMBLY-860:
-

 Summary: Upgrade to Java 7
 Key: MASSEMBLY-860
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-860
 Project: Maven Assembly Plugin
  Issue Type: Improvement
Affects Versions: 3.0.0
Reporter: Stephane Nicoll
 Fix For: 3.0.1


Plexus IO 3 and Plexus Archiver 3.5 requires Java 7 so we need to first upgrade 
the plugin to Java 7



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

[jira] [Created] (MASSEMBLY-859) Upgrade to Plexus IO 3.0.0

[Stephane Nicoll (JIRA)]

Stephane Nicoll created MASSEMBLY-859:
-

 Summary: Upgrade to Plexus IO 3.0.0
 Key: MASSEMBLY-859
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-859
 Project: Maven Assembly Plugin
  Issue Type: Dependency upgrade
Affects Versions: 3.0.0
Reporter: Stephane Nicoll
 Fix For: 3.0.1






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

[jira] [Commented] (MASSEMBLY-854) Upgrade to Plexus Archiver 3.5

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll commented on MASSEMBLY-854:
---

Attempting to do that with {{3.5-SNAPSHOT}} leads to 

{noformat}
[INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce-bytecode-version) @ 
maven-assembly-plugin ---
[INFO] Restricted to JDK 1.6 yet 
org.codehaus.plexus:plexus-io:jar:3.0.0:compile contains 
org/codehaus/plexus/components/io/resources/EncodingSupported.class targeted to 
JDK 1.7
[INFO] Restricted to JDK 1.6 yet 
org.apache.commons:commons-compress:jar:1.14:compile contains 
org/apache/commons/compress/changes/ChangeSetResults.class targeted to JDK 1.7
[INFO] Restricted to JDK 1.6 yet 
org.codehaus.plexus:plexus-archiver:jar:3.5-SNAPSHOT:compile contains 
org/codehaus/plexus/archiver/ArchiveFile.class targeted to JDK 1.7
[WARNING] Rule 0: org.apache.maven.plugins.enforcer.EnforceBytecodeVersion 
failed with message:
Found Banned Dependency: org.codehaus.plexus:plexus-io:jar:3.0.0
Found Banned Dependency: org.apache.commons:commons-compress:jar:1.14
Found Banned Dependency: org.codehaus.plexus:plexus-archiver:jar:3.5-SNAPSHOT
Use 'mvn dependency:tree' to locate the source of the banned dependencies.
{noformat}

> Upgrade to Plexus Archiver 3.5
> --
>
> Key: MASSEMBLY-854
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-854
> Project: Maven Assembly Plugin
>  Issue Type: Task
>Affects Versions: 3.0.0
>Reporter: Stephane Nicoll
> Fix For: 3.0.1
>
>
> There is a critical regression fixed (see 
> https://github.com/codehaus-plexus/plexus-archiver/issues/53)



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

[jira] [Commented] (MNGSITE-310) general recommendation for the element order in the POM

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll commented on MNGSITE-310:
-

Claiming it is established based on what seems to be a misunderstanding is not 
really an argument. At the end of the day, this page is a Maven dev page and 
was never meant to be a public recommendation. If we didn't, I could only 
assume there is a good reason for that.

IMO (and at the current state of the project), providing an official 
recommendation for the entire POM file will be very hard to justify. I think 
some element can definitely be described (like having the parent relatively at 
the top) but such a well-defined order is a team/organization/project specific 
matter IMO

> general recommendation for the element order in the POM
> ---
>
> Key: MNGSITE-310
> URL: https://issues.apache.org/jira/browse/MNGSITE-310
> Project: Maven Project Web Site
>  Issue Type: Improvement
>Reporter: Franz van Betteraey
>Priority: Minor
>  Labels: convention, pom
>
> A 
> [convention|https://maven.apache.org/developers/conventions/code.html#POM_Code_Convention]
>  for the element order in POM files is recommended for Maven developer and 
> contributor but not for the general usage of Maven. I think it would be 
> useful to recommend the element order also for general usage. A common order 
> would
> * give an answer to the question of the order for all who ask themselves this 
> question
> * help to easily cope with the content of pom files (even in unknown projects)
> A good place for the recommendation would be the [Maven 
> conventions|https://maven.apache.org/maven-conventions.html] or [POM 
> reference |https://maven.apache.org/pom.html] document.
> The background for this request is a discussion on twitter:
> https://twitter.com/FrVaBe/status/870263530473369601
> https://twitter.com/snicoll/status/874231018957545472
> A possible argument against such a convention would probably be, that 
> projects that used another element order would be suddenly considered as 
> "wrong" ordered.
> But I think that everyone that wondered about how to order the elements has 
> probably found the developer conventions and used theses as an appropriate 
> convention. There are even tools to check this convention 
> ([SonarQube|https://jira.sonarsource.com/browse/RSPEC-3423]) and to support 
> this convention ([Tidy Maven 
> plugin|http://www.mojohaus.org/tidy-maven-plugin/]). The Convention is thus 
> already established.
>   



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

[jira] [Created] (MASSEMBLY-854) Upgrade to plexus archiver 3.5

[Stephane Nicoll (JIRA)]

Stephane Nicoll created MASSEMBLY-854:
-

 Summary: Upgrade to plexus archiver 3.5
 Key: MASSEMBLY-854
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-854
 Project: Maven Assembly Plugin
  Issue Type: Task
Affects Versions: 3.0.0
Reporter: Stephane Nicoll
 Fix For: 3.0.1


There is a critical regression fixed (see 
https://github.com/codehaus-plexus/plexus-archiver/issues/53)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (MCOMPILER-298) Support "-parameters" compiler option as a configuration key

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll edited comment on MCOMPILER-298 at 5/29/17 10:58 AM:
-

There is a change required in plexus compiler to make that happen, see PR
https://github.com/codehaus-plexus/plexus-compiler/pull/29

There is a PR available that needs a review: 
https://github.com/apache/maven-plugins/pull/114 (in particular I have no idea 
how to test the flag in an IT)


was (Author: snicoll):
There is a change required in plexus compiler to make that happen, see PR
https://github.com/codehaus-plexus/plexus-compiler/pull/29

There is a PR available that needs a review: 
https://github.com/apache/maven-plugins/pull/114

> Support "-parameters" compiler option as a configuration key
> 
>
> Key: MCOMPILER-298
> URL: https://issues.apache.org/jira/browse/MCOMPILER-298
> Project: Maven Compiler Plugin
>  Issue Type: Improvement
>Affects Versions: 3.6.1
>Reporter: brian clozel
>Priority: Minor
>  Labels: pull-request-available
>
> The {{-parameters}} flag is, as of JDK8, a standard compiler option for the 
> compiler. This option should be frequently used by developers and it would 
> make sense to have it as a first class option (like source, target and many 
> others) rather than using {{compilerArgs}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (MCOMPILER-298) Support "-parameters" compiler option as a configuration key

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll updated MCOMPILER-298:
--
Affects Version/s: 3.6.1
   Labels: pull-request-available  (was: )

> Support "-parameters" compiler option as a configuration key
> 
>
> Key: MCOMPILER-298
> URL: https://issues.apache.org/jira/browse/MCOMPILER-298
> Project: Maven Compiler Plugin
>  Issue Type: Improvement
>Affects Versions: 3.6.1
>Reporter: brian clozel
>Priority: Minor
>  Labels: pull-request-available
>
> The {{-parameters}} flag is, as of JDK8, a standard compiler option for the 
> compiler. This option should be frequently used by developers and it would 
> make sense to have it as a first class option (like source, target and many 
> others) rather than using {{compilerArgs}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (MCOMPILER-298) Support "-parameters" compiler option as a configuration key

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll edited comment on MCOMPILER-298 at 5/29/17 10:57 AM:
-

There is a change required in plexus compiler to make that happen, see PR
https://github.com/codehaus-plexus/plexus-compiler/pull/29

There is a PR available that needs a review: 
https://github.com/apache/maven-plugins/pull/114


was (Author: snicoll):
There is a change required in plexus compiler to make that happen, see PR
https://github.com/codehaus-plexus/plexus-compiler/pull/29

> Support "-parameters" compiler option as a configuration key
> 
>
> Key: MCOMPILER-298
> URL: https://issues.apache.org/jira/browse/MCOMPILER-298
> Project: Maven Compiler Plugin
>  Issue Type: Improvement
>Affects Versions: 3.6.1
>Reporter: brian clozel
>Priority: Minor
>  Labels: pull-request-available
>
> The {{-parameters}} flag is, as of JDK8, a standard compiler option for the 
> compiler. This option should be frequently used by developers and it would 
> make sense to have it as a first class option (like source, target and many 
> others) rather than using {{compilerArgs}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MCOMPILER-298) Support "-parameters" compiler option as a configuration key

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll commented on MCOMPILER-298:
---

There is a change required in plexus compiler to make that happen, see PR
https://github.com/codehaus-plexus/plexus-compiler/pull/29

> Support "-parameters" compiler option as a configuration key
> 
>
> Key: MCOMPILER-298
> URL: https://issues.apache.org/jira/browse/MCOMPILER-298
> Project: Maven Compiler Plugin
>  Issue Type: Improvement
>Reporter: brian clozel
>Priority: Minor
>
> The {{-parameters}} flag is, as of JDK8, a standard compiler option for the 
> compiler. This option should be frequently used by developers and it would 
> make sense to have it as a first class option (like source, target and many 
> others) rather than using {{compilerArgs}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll commented on MNG-5971:
--

That project is quite complicated, it would be nice if you could focus on the 
things you are complaining (like I did with a super simple project structure). 
The point in this issue is that anything that a child defines should override 
the parent. If you put the dependency directly in the child, it will override 
the version of the parent. If you import a BOM, it must do the same for 
consistency reason. Are we arguing that principle or are you referring to 
something else?

> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
>  Issue Type: Bug
>  Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.4.0
>
> Attachments: bom-cloud.zip
>
>
> When a project extends from a parent with a {{dependencyManagement}} section, 
> it is not always possible to properly override (and align) the version to use 
> for a group of dependencies.
> We typically use Bill Of Materials to gather a group of modules and make sure 
> their versions are consistent. 
> The following project demonstrates the issue: 
> https://github.com/snicoll-scratches/maven-dependency-management
> The first commit is a working use case where the parent uses a bom with 
> version A and we use the same bom with version B in the child. Version B is 
> used as expected.
> The second commit demonstrates the faulty scenario. Rather than using a bom 
> in the parent, we use a direct dependency (provided by that bom). We still 
> use the bom with a different version. In that case all the dependencies but 
> the one provided by the parent are overridden (leading to mixed versions for 
> the dependencies provided by the BOM).
> It looks like the distance is still used to compute the version while the 
> graph of dependencies should be flatten at each step for a proper override. 
> Thoughts? Thanks!



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

[jira] [Commented] (SUREFIRE-1198) Failsafe does not allow to configure the jar file to use

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll commented on SUREFIRE-1198:
---

I disagree. Builds have different requirements. This particular one makes it so 
that the jar that should be used for ITs is not the main artifact of the 
project. Since we're forced to use the jar, making it configurable doesn't 
sound insane to me.

> Failsafe does not allow to configure the jar file to use
> 
>
> Key: SUREFIRE-1198
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1198
> Project: Maven Surefire
>  Issue Type: Improvement
>Reporter: Stephane Nicoll
>
> See [this Spring Boot 
> issue|https://github.com/spring-projects/spring-boot/issues/4510#issuecomment-159448634]
> It seems that SUREFIRE-855 does not allow {{target/classes}} to be used 
> anymore. Is there a reason why this behaviour was completely removed in 
> favour of only the jar file?
> It would be nice if we had an option to chose between the two (defaulting to 
> the jar)



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

[jira] [Updated] (SUREFIRE-1198) Failsafe does not allow to configure the jar file to use

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll updated SUREFIRE-1198:
--
Issue Type: Improvement  (was: Bug)
   Summary: Failsafe does not allow to configure the jar file to use  (was: 
Failsafe does not allow to use target/classes anymore)

> Failsafe does not allow to configure the jar file to use
> 
>
> Key: SUREFIRE-1198
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1198
> Project: Maven Surefire
>  Issue Type: Improvement
>Reporter: Stephane Nicoll
>
> See [this Spring Boot 
> issue|https://github.com/spring-projects/spring-boot/issues/4510#issuecomment-159448634]
> It seems that SUREFIRE-855 does not allow {{target/classes}} to be used 
> anymore. Is there a reason why this behaviour was completely removed in 
> favour of only the jar file?
> It would be nice if we had an option to chose between the two (defaulting to 
> the jar)



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

[jira] [Comment Edited] (SUREFIRE-1198) Failsafe does not allow to use target/classes anymore

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll edited comment on SUREFIRE-1198 at 6/30/16 9:00 AM:


I can see that this issue got closed but I don't see a way to configure the jar 
file to use. 

In a Spring Boot project, we repackage the main jar with the fat jar and we 
rename the original jar. In 1.4, we've improved the jar layout and, long story 
short, failsafe doesn't work at all for us.

We have a couple of workaround but having the ability to configure the jar file 
of the project that is going to be used is fairly important for us. Users of 
the shade plugin should find this useful as well.

See [this issue|https://github.com/spring-projects/spring-boot/issues/6254]


was (Author: snicoll):
I can see that this issue got closed but I don't see a way to configure the jar 
file to use. 

In a Spring Boot project, we repackage the main jar with the fat jar and we 
rename the original jar. In 1.4, we've improved the jar layout and, long story 
short, failsafe doesn't work at all for us.

We have a couple of workaround but having the ability to configure the jar file 
of the project that is going to be used is fairly important for us. Users of 
the shade plugin should find this useful as well.

> Failsafe does not allow to use target/classes anymore
> -
>
> Key: SUREFIRE-1198
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1198
> Project: Maven Surefire
>  Issue Type: Bug
>Reporter: Stephane Nicoll
>
> See [this Spring Boot 
> issue|https://github.com/spring-projects/spring-boot/issues/4510#issuecomment-159448634]
> It seems that SUREFIRE-855 does not allow {{target/classes}} to be used 
> anymore. Is there a reason why this behaviour was completely removed in 
> favour of only the jar file?
> It would be nice if we had an option to chose between the two (defaulting to 
> the jar)



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

[jira] [Reopened] (SUREFIRE-1198) Failsafe does not allow to use target/classes anymore

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll reopened SUREFIRE-1198:
---

I can see that this issue got closed but I don't see a way to configure the jar 
file to use. 

In a Spring Boot project, we repackage the main jar with the fat jar and we 
rename the original jar. In 1.4, we've improved the jar layout and, long story 
short, failsafe doesn't work at all for us.

We have a couple of workaround but having the ability to configure the jar file 
of the project that is going to be used is fairly important for us. Users of 
the shade plugin should find this useful as well.

> Failsafe does not allow to use target/classes anymore
> -
>
> Key: SUREFIRE-1198
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1198
> Project: Maven Surefire
>  Issue Type: Bug
>Reporter: Stephane Nicoll
>
> See [this Spring Boot 
> issue|https://github.com/spring-projects/spring-boot/issues/4510#issuecomment-159448634]
> It seems that SUREFIRE-855 does not allow {{target/classes}} to be used 
> anymore. Is there a reason why this behaviour was completely removed in 
> favour of only the jar file?
> It would be nice if we had an option to chose between the two (defaulting to 
> the jar)



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

[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll commented on MNG-5971:
--

{noformat}
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for 
com.example:demo:jar:0.0.1-SNAPSHOT
[WARNING] Multiple conflicting imports of dependency 
'org.springframework.integration:spring-integration-http:jar' into model 
'[inherited]:spring-cloud-dependencies:pom:Brixton.M5' ('101 : 19, 
org.springframework.integration:spring-integration-bom:4.2.4.RELEASE 
/Users/snicoll/.m2/repository/org/springframework/integration/spring-integration-bom/4.2.4.RELEASE/spring-integration-bom-4.2.4.RELEASE.pom',
 '1803 : 16, org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE 
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom').
 To resolve this conflict, either declare the dependency directly in model 
'[inherited]:spring-cloud-dependencies:pom:Brixton.M5' to override what gets 
imported or rearrange the causing imports in the inheritance hierarchy to apply 
standard override logic. Without resolving this conflict, your build relies on 
indeterministic behaviour. @ 
org.springframework.cloud:spring-cloud-dependencies:Brixton.M5
[WARNING] Multiple conflicting imports of dependency 
'org.apache.httpcomponents:httpclient:jar' into model 
'[inherited]:spring-cloud-dependencies:pom:Brixton.M5' ('103 : 16, 
org.springframework.cloud:spring-cloud-consul-dependencies:1.0.0.M6 
/Users/snicoll/.m2/repository/org/springframework/cloud/spring-cloud-consul-dependencies/1.0.0.M6/spring-cloud-consul-dependencies-1.0.0.M6.pom',
 '1071 : 16, org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE 
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom',
 '1071 : 16, org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE 
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom',
 '1071 : 16, org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE 
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom',
 '1071 : 16, org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE 
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom',
 '1071 : 16, org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE 
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom').
 To resolve this conflict, either declare the dependency directly in model 
'[inherited]:spring-cloud-dependencies:pom:Brixton.M5' to override what gets 
imported or rearrange the causing imports in the inheritance hierarchy to apply 
standard override logic. Without resolving this conflict, your build relies on 
indeterministic behaviour. @ 
org.springframework.cloud:spring-cloud-dependencies:Brixton.M5
[WARNING] Multiple conflicting imports of dependency 
'org.apache.httpcomponents:httpcore:jar' into model 
'[inherited]:spring-cloud-dependencies:pom:Brixton.M5' ('108 : 16, 
org.springframework.cloud:spring-cloud-consul-dependencies:1.0.0.M6 
/Users/snicoll/.m2/repository/org/springframework/cloud/spring-cloud-consul-dependencies/1.0.0.M6/spring-cloud-consul-dependencies-1.0.0.M6.pom',
 '1082 : 16, org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE 
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom',
 '1082 : 16, org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE 
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom',
 '1082 : 16, org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE 
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom',
 '1082 : 16, org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE 
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom',
 '1082 : 16, org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE 
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom').
 To resolve this conflict, either declare the dependency directly in model 
'[inherited]:spring-cloud-dependencies:pom:Brixton.M5' to override what gets 
imported or rearrange the causing imports 

[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll commented on MNG-5971:
--

I will update and re-test but just to answer your question, yes we do rely on 
the order of declaration. That's the only way that I know of to manage a 
conflict. If several BOMs are working on a set of common dependencies you have 
to tell which one wins and ordering the boms (first win strategy) is something 
we do for _a very long time_

Practically speaking it also makes sense: you can't possibly ask 4 different 
projects to not have _any_ conflicting library at all.


> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
>  Issue Type: Bug
>  Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
>  Labels: close-pending
> Fix For: 3.4.0
>
> Attachments: bom-cloud.zip
>
>
> When a project extends from a parent with a {{dependencyManagement}} section, 
> it is not always possible to properly override (and align) the version to use 
> for a group of dependencies.
> We typically use Bill Of Materials to gather a group of modules and make sure 
> their versions are consistent. 
> The following project demonstrates the issue: 
> https://github.com/snicoll-scratches/maven-dependency-management
> The first commit is a working use case where the parent uses a bom with 
> version A and we use the same bom with version B in the child. Version B is 
> used as expected.
> The second commit demonstrates the faulty scenario. Rather than using a bom 
> in the parent, we use a direct dependency (provided by that bom). We still 
> use the bom with a different version. In that case all the dependencies but 
> the one provided by the parent are overridden (leading to mixed versions for 
> the dependencies provided by the BOM).
> It looks like the distance is still used to compute the version while the 
> graph of dependencies should be flatten at each step for a proper override. 
> Thoughts? Thanks!



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

[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll commented on MNG-5971:
--

{noformat}
Apache Maven 3.4.0-SNAPSHOT (24e792188260ffd41278555c9452c2a91e2acb3d; 
2016-02-22T03:48:56+01:00)
Maven home: /Users/snicoll/tools/maven
Java version: 1.8.0_60, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "Mac OS X", version: "10.11.3", arch: "x86_64", family: "Unix"
{noformat}

Is the following warnings a direct effect of this change? 

{noformat}
➜ mvn dependency:list
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for 
com.example:demo:jar:0.0.1-SNAPSHOT
[WARNING] 
'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
 must be unique: org.springframework.integration:spring-integration-http:jar -> 
duplicate declaration of version 4.2.4.RELEASE @ 
org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE, 
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom,
 line 1803, column 16
[WARNING] 
'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
 must be unique: org.apache.httpcomponents:httpclient:jar -> version 4.5 vs 
4.5.1 @ org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE, 
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom,
 line 1071, column 16
[WARNING] 
'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
 must be unique: org.apache.httpcomponents:httpclient:jar -> version 4.5 vs 
4.5.1 @ org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE, 
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom,
 line 1071, column 16
[WARNING] 
'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
 must be unique: org.apache.httpcomponents:httpclient:jar -> version 4.5 vs 
4.5.1 @ org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE, 
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom,
 line 1071, column 16
[WARNING] 
'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
 must be unique: org.apache.httpcomponents:httpclient:jar -> version 4.5 vs 
4.5.1 @ org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE, 
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom,
 line 1071, column 16
[WARNING] 
'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
 must be unique: org.apache.httpcomponents:httpclient:jar -> version 4.5 vs 
4.5.1 @ org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE, 
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom,
 line 1071, column 16
[WARNING] 
'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
 must be unique: org.apache.httpcomponents:httpcore:jar -> version 4.4.1 vs 
4.4.4 @ org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE, 
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom,
 line 1082, column 16
[WARNING] 
'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
 must be unique: org.apache.httpcomponents:httpcore:jar -> version 4.4.1 vs 
4.4.4 @ org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE, 
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom,
 line 1082, column 16
[WARNING] 
'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
 must be unique: org.apache.httpcomponents:httpcore:jar -> version 4.4.1 vs 
4.4.4 @ org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE, 
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom,
 line 1082, column 16
[WARNING] 
'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
 must be unique: org.apache.httpcomponents:httpcore:jar -> version 4.4.1 vs 
4.4.4 @ org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE, 
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom,
 line 1082, 

[jira] [Updated] (MNG-5971) Imported dependencies should be available to inheritance processing

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll updated MNG-5971:
-
Attachment: bom-cloud.zip

> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
>  Issue Type: Bug
>  Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
>  Labels: close-pending
> Fix For: 3.4.0
>
> Attachments: bom-cloud.zip
>
>
> When a project extends from a parent with a {{dependencyManagement}} section, 
> it is not always possible to properly override (and align) the version to use 
> for a group of dependencies.
> We typically use Bill Of Materials to gather a group of modules and make sure 
> their versions are consistent. 
> The following project demonstrates the issue: 
> https://github.com/snicoll-scratches/maven-dependency-management
> The first commit is a working use case where the parent uses a bom with 
> version A and we use the same bom with version B in the child. Version B is 
> used as expected.
> The second commit demonstrates the faulty scenario. Rather than using a bom 
> in the parent, we use a direct dependency (provided by that bom). We still 
> use the bom with a different version. In that case all the dependencies but 
> the one provided by the parent are overridden (leading to mixed versions for 
> the dependencies provided by the BOM).
> It looks like the distance is still used to compute the version while the 
> graph of dependencies should be flatten at each step for a proper override. 
> Thoughts? Thanks!



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

[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll commented on MNG-5971:
--

Christian, the sample project works now indeed, awesome! I've installed the 
snapshot to use it for the next couple days. I also want to re-test everything 
on the project that made me create this issue in the first place. I'll keep you 
posted. Thanks!

> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
>  Issue Type: Bug
>  Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
>  Labels: close-pending
> Fix For: 3.4.0
>
>
> When a project extends from a parent with a {{dependencyManagement}} section, 
> it is not always possible to properly override (and align) the version to use 
> for a group of dependencies.
> We typically use Bill Of Materials to gather a group of modules and make sure 
> their versions are consistent. 
> The following project demonstrates the issue: 
> https://github.com/snicoll-scratches/maven-dependency-management
> The first commit is a working use case where the parent uses a bom with 
> version A and we use the same bom with version B in the child. Version B is 
> used as expected.
> The second commit demonstrates the faulty scenario. Rather than using a bom 
> in the parent, we use a direct dependency (provided by that bom). We still 
> use the bom with a different version. In that case all the dependencies but 
> the one provided by the parent are overridden (leading to mixed versions for 
> the dependencies provided by the BOM).
> It looks like the distance is still used to compute the version while the 
> graph of dependencies should be flatten at each step for a proper override. 
> Thoughts? Thanks!



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

[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll commented on MNG-5971:
--

I appreciate the work Christian has done but I am -1 on the new scope as well 
and I really think the current one is broken. There is no way in my opinion 
that you should force a version in the parent. Any child pom can override 
whatever they want and it always worked that way in Maven-land. I really don't 
get why BOM should behave differently.

What I am after is consistency: if I can override the version of 
{{com.foo:bar}} in a child, I should be able to do exactly the same if said 
version is provided by a BOM. 



> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
>  Issue Type: Wish
>  Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
>
> When a project extends from a parent with a {{dependencyManagement}} section, 
> it is not always possible to properly override (and align) the version to use 
> for a group of dependencies.
> We typically use Bill Of Materials to gather a group of modules and make sure 
> their versions are consistent. 
> The following project demonstrates the issue: 
> https://github.com/snicoll-scratches/maven-dependency-management
> The first commit is a working use case where the parent uses a bom with 
> version A and we use the same bom with version B in the child. Version B is 
> used as expected.
> The second commit demonstrates the faulty scenario. Rather than using a bom 
> in the parent, we use a direct dependency (provided by that bom). We still 
> use the bom with a different version. In that case all the dependencies but 
> the one provided by the parent are overridden (leading to mixed versions for 
> the dependencies provided by the BOM).
> It looks like the distance is still used to compute the version while the 
> graph of dependencies should be flatten at each step for a proper override. 
> Thoughts? Thanks!



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

[jira] [Commented] (MNG-5971) Dependency management in a child project cannot override a version using a BOM

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll commented on MNG-5971:
--

Please stop looking at two poms in Spring Boot, the issue is more complicated 
than that and I've attached a sample project in my original description. Can we 
stop discussing technical and discuss feature please? :)

So yes, I would like that a BOM defined at a given level is included in the 
dependency management of said level, overriding what is provided by the parent 
if necessary. And that whole thing should become the dependency management of 
that level, that can be also overridden further down the road if necessary. 
Long story short: I want bom imports to behave _exactly as_ if I added each 
dependency contained in the bom directly in the project.

Your example is correct.

No back on the _feature_. BOM is an effective way of sharing dependencies: 
instead of having to copy 10 {{}} with their respective versions, I 
put them all in a bom and I import that bom with scope {{import}}. This is a 
very effective way of sharing a dependency management. All I am asking here is 
that it behaves  consistently in Maven. 

You already said that the current behaviour is on purpose (and other users 
don't want the bom to override dependencies) which means the bom would be some 
kind of "default if not exist" thing. I honestly don't understand the use case 
the way we (and others in the community) use the bom.

On my own personal opinion, the use case I am describing is _much more logical_ 
than the current behaviour: when you import a BOM in a project, it would be as 
if you had copy/pasted all the {{dependencyManagement}} section of that BOM  in 
the project. So I am seeing the BOM as a shortcut. Does that make sense?



> Dependency management in a child project cannot override a version using a BOM
> --
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
>  Issue Type: Wish
>  Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Priority: Trivial
>  Labels: close-pending
>
> When a project extends from a parent with a {{dependencyManagement}} section, 
> it is not always possible to properly override (and align) the version to use 
> for a group of dependencies.
> We typically use Bill Of Materials to gather a group of modules and make sure 
> their versions are consistent. 
> The following project demonstrates the issue: 
> https://github.com/snicoll-scratches/maven-dependency-management
> The first commit is a working use case where the parent uses a bom with 
> version A and we use the same bom with version B in the child. Version B is 
> used as expected.
> The second commit demonstrates the faulty scenario. Rather than using a bom 
> in the parent, we use a direct dependency (provided by that bom). We still 
> use the bom with a different version. In that case all the dependencies but 
> the one provided by the parent are overridden (leading to mixed versions for 
> the dependencies provided by the BOM).
> It looks like the distance is still used to compute the version while the 
> graph of dependencies should be flatten at each step for a proper override. 
> Thoughts? Thanks!



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

[jira] [Comment Edited] (MNG-5971) Dependency management in a child project cannot override a version using a BOM

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll edited comment on MNG-5971 at 2/17/16 4:43 PM:
---

Okay let me try to clarify. I don't think I am asking for anything funky. I 
want that anything that is defined closers "wins" _regardless of how it is 
added_. 

Think it this way (with a A -> B -> C hierarchy where C is the  child and A the 
grand-parent). A resolves its dependency management (including the ones from 
BOM). That gives a unified dependency management. Then B applies and does the 
same thing, adding or overriding some entries if necessary. Then C does. To me 
it's much more consistent to do things that way because you need that whatever 
you define at a given level will override the values from the parent if 
necessary.

{quote}
Imports never overwrite anything already present in the model.
{quote}

This very issue is about the fact that adding the dependency directly works, 
adding a bom that defines said dependency doesn't. IMO this is inconsistent 
considering how we're using BOM (= share a dependency management section).

Answering to your question. Of course I don't want that. I just want that 
whatever is defined in the user project overrides what the parent provides. So 
let's say that the parent provides {{com.foo:bar:1.0.0}}. If the user adds 
{{com.foo:bar:2.0.0}} then all is well. If the user adds a bom that contains a 
dependency management for {{com.foo.bar:2.0.0}} it doesn't. That's the problem 
I am trying to raise here.

In my mind there is no conflict: I am using the tools Maven provides to have a 
decent dependency management. The only mechanism I know to share dependency 
management is the BOM. Is there another one? (Changing the parent is not an 
option). I don't think so. If we can't use that mechanism to override versions 
(while we can by adding the dependency directly), it looks like something is 
missing in Maven.

I am ok with whatever alternatives Maven offers that would allow me to share 
the dependency management. I just don't think there is one.





was (Author: snicoll):
Okay let me try to clarify. I don't think I am asking for anything funky. I 
want that anything that is defined closers "wins" _regardless of how it is 
added_. 

Think it this way (with a A -> B -> C hierarchy where C is the  child and A the 
grand-parent). A resolves its dependency management (including the ones from 
BOM). That gives a unified dependency management. Then B applies and does the 
same thing, adding or overriding some entries if necessary. Then C does. To me 
it's much more consistent to do things that way because you need that whatever 
you define at a given level will override the values from the parent if 
necessary.

{quote}
Imports never overwrite anything already present in the model.
{quote}

This very issue is about the fact that adding the dependency directly works, 
adding a bom that defines said dependency doesn't. IMO this is inconsistent 
considering how we're using BOM (= share a dependency management section).

Answering to your question. Of course I don't want that. I just want that 
whatever is defined in the user project overrides what the parent provides. So 
let's say that the parent provides {{com.foo:bar:1.0.0}}. If the user adds 
{{com.foo:bar:2.0.0}} then all is well. If the user adds a bom that contains a 
dependency management for {{com.foo.bar:2.0.0}} it doesn't. That's the problem 
I am trying to raise here.

In my mind there is no conflict: I am using the tools Maven provides to have a 
decent dependency management. The only mechanism I know to share dependency 
management is the BOM. Is there another one? I don't think so. If we can't use 
that mechanism to override versions (while we can by adding the dependency 
directly), it looks like something is missing in Maven.

I am ok with whatever alternatives Maven offers that would allow me to share 
the dependency management. I just don't think there is one.




> Dependency management in a child project cannot override a version using a BOM
> --
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
>  Issue Type: Wish
>  Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Priority: Trivial
>  Labels: close-pending
>
> When a project extends from a parent with a {{dependencyManagement}} section, 
> it is not always possible to properly override (and align) the version to use 
> for a group of dependencies.
> We typically use Bill Of Materials to gather a group of modules and make sure 
> their versions are consistent. 
> The following project demonstrates the issue: 
> 

[jira] [Comment Edited] (MNG-5971) Dependency management in a child project cannot override a version using a BOM

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll edited comment on MNG-5971 at 2/17/16 4:44 PM:
---

Okay let me try to clarify. I don't think I am asking for anything funky. I 
want that anything that is defined closer "wins" _regardless of how it is 
added_. 

Think it this way (with a A -> B -> C hierarchy where C is the  child and A the 
grand-parent). A resolves its dependency management (including the ones from 
BOM). That gives a unified dependency management. Then B applies and does the 
same thing, adding or overriding some entries if necessary. Then C does. To me 
it's much more consistent to do things that way because you know that whatever 
you define at a given level will override the values from the parent if 
necessary.

{quote}
Imports never overwrite anything already present in the model.
{quote}

This very issue is about the fact that adding the dependency directly works, 
adding a bom that defines said dependency doesn't. IMO this is inconsistent 
considering how we're using BOM (= share a dependency management section).

Answering to your question. Of course I don't want that. I just want that 
whatever is defined in the user project overrides what the parent provides. So 
let's say that the parent provides {{com.foo:bar:1.0.0}}. If the user adds 
{{com.foo:bar:2.0.0}} then all is well. If the user adds a bom that contains a 
dependency management for {{com.foo.bar:2.0.0}} it doesn't. That's the problem 
I am trying to raise here.

In my mind there is no conflict: I am using the tools Maven provides to have a 
decent dependency management. The only mechanism I know to share dependency 
management is the BOM. Is there another one? (Changing the parent is not an 
option). I don't think so. If we can't use that mechanism to override versions 
(while we can by adding the dependency directly), it looks like something is 
missing in Maven.

I am ok with whatever alternatives Maven offers that would allow me to share 
the dependency management. I just don't think there is one.





was (Author: snicoll):
Okay let me try to clarify. I don't think I am asking for anything funky. I 
want that anything that is defined closer "wins" _regardless of how it is 
added_. 

Think it this way (with a A -> B -> C hierarchy where C is the  child and A the 
grand-parent). A resolves its dependency management (including the ones from 
BOM). That gives a unified dependency management. Then B applies and does the 
same thing, adding or overriding some entries if necessary. Then C does. To me 
it's much more consistent to do things that way because you need that whatever 
you define at a given level will override the values from the parent if 
necessary.

{quote}
Imports never overwrite anything already present in the model.
{quote}

This very issue is about the fact that adding the dependency directly works, 
adding a bom that defines said dependency doesn't. IMO this is inconsistent 
considering how we're using BOM (= share a dependency management section).

Answering to your question. Of course I don't want that. I just want that 
whatever is defined in the user project overrides what the parent provides. So 
let's say that the parent provides {{com.foo:bar:1.0.0}}. If the user adds 
{{com.foo:bar:2.0.0}} then all is well. If the user adds a bom that contains a 
dependency management for {{com.foo.bar:2.0.0}} it doesn't. That's the problem 
I am trying to raise here.

In my mind there is no conflict: I am using the tools Maven provides to have a 
decent dependency management. The only mechanism I know to share dependency 
management is the BOM. Is there another one? (Changing the parent is not an 
option). I don't think so. If we can't use that mechanism to override versions 
(while we can by adding the dependency directly), it looks like something is 
missing in Maven.

I am ok with whatever alternatives Maven offers that would allow me to share 
the dependency management. I just don't think there is one.




> Dependency management in a child project cannot override a version using a BOM
> --
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
>  Issue Type: Wish
>  Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Priority: Trivial
>  Labels: close-pending
>
> When a project extends from a parent with a {{dependencyManagement}} section, 
> it is not always possible to properly override (and align) the version to use 
> for a group of dependencies.
> We typically use Bill Of Materials to gather a group of modules and make sure 
> their versions are consistent. 
> The following project 

[jira] [Comment Edited] (MNG-5971) Dependency management in a child project cannot override a version using a BOM

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll edited comment on MNG-5971 at 2/17/16 4:43 PM:
---

Okay let me try to clarify. I don't think I am asking for anything funky. I 
want that anything that is defined closer "wins" _regardless of how it is 
added_. 

Think it this way (with a A -> B -> C hierarchy where C is the  child and A the 
grand-parent). A resolves its dependency management (including the ones from 
BOM). That gives a unified dependency management. Then B applies and does the 
same thing, adding or overriding some entries if necessary. Then C does. To me 
it's much more consistent to do things that way because you need that whatever 
you define at a given level will override the values from the parent if 
necessary.

{quote}
Imports never overwrite anything already present in the model.
{quote}

This very issue is about the fact that adding the dependency directly works, 
adding a bom that defines said dependency doesn't. IMO this is inconsistent 
considering how we're using BOM (= share a dependency management section).

Answering to your question. Of course I don't want that. I just want that 
whatever is defined in the user project overrides what the parent provides. So 
let's say that the parent provides {{com.foo:bar:1.0.0}}. If the user adds 
{{com.foo:bar:2.0.0}} then all is well. If the user adds a bom that contains a 
dependency management for {{com.foo.bar:2.0.0}} it doesn't. That's the problem 
I am trying to raise here.

In my mind there is no conflict: I am using the tools Maven provides to have a 
decent dependency management. The only mechanism I know to share dependency 
management is the BOM. Is there another one? (Changing the parent is not an 
option). I don't think so. If we can't use that mechanism to override versions 
(while we can by adding the dependency directly), it looks like something is 
missing in Maven.

I am ok with whatever alternatives Maven offers that would allow me to share 
the dependency management. I just don't think there is one.





was (Author: snicoll):
Okay let me try to clarify. I don't think I am asking for anything funky. I 
want that anything that is defined closers "wins" _regardless of how it is 
added_. 

Think it this way (with a A -> B -> C hierarchy where C is the  child and A the 
grand-parent). A resolves its dependency management (including the ones from 
BOM). That gives a unified dependency management. Then B applies and does the 
same thing, adding or overriding some entries if necessary. Then C does. To me 
it's much more consistent to do things that way because you need that whatever 
you define at a given level will override the values from the parent if 
necessary.

{quote}
Imports never overwrite anything already present in the model.
{quote}

This very issue is about the fact that adding the dependency directly works, 
adding a bom that defines said dependency doesn't. IMO this is inconsistent 
considering how we're using BOM (= share a dependency management section).

Answering to your question. Of course I don't want that. I just want that 
whatever is defined in the user project overrides what the parent provides. So 
let's say that the parent provides {{com.foo:bar:1.0.0}}. If the user adds 
{{com.foo:bar:2.0.0}} then all is well. If the user adds a bom that contains a 
dependency management for {{com.foo.bar:2.0.0}} it doesn't. That's the problem 
I am trying to raise here.

In my mind there is no conflict: I am using the tools Maven provides to have a 
decent dependency management. The only mechanism I know to share dependency 
management is the BOM. Is there another one? (Changing the parent is not an 
option). I don't think so. If we can't use that mechanism to override versions 
(while we can by adding the dependency directly), it looks like something is 
missing in Maven.

I am ok with whatever alternatives Maven offers that would allow me to share 
the dependency management. I just don't think there is one.




> Dependency management in a child project cannot override a version using a BOM
> --
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
>  Issue Type: Wish
>  Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Priority: Trivial
>  Labels: close-pending
>
> When a project extends from a parent with a {{dependencyManagement}} section, 
> it is not always possible to properly override (and align) the version to use 
> for a group of dependencies.
> We typically use Bill Of Materials to gather a group of modules and make sure 
> their versions are consistent. 
> The following project 

[jira] [Commented] (MNG-5971) Dependency management in a child project cannot override a version using a BOM

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll commented on MNG-5971:
--

Okay let me try to clarify. I don't think I am asking for anything funky. I 
want that anything that is defined closers "wins" _regardless of how it is 
added_. 

Think it this way (with a A -> B -> C hierarchy where C is the  child and A the 
grand-parent). A resolves its dependency management (including the ones from 
BOM). That gives a unified dependency management. Then B applies and does the 
same thing, adding or overriding some entries if necessary. Then C does. To me 
it's much more consistent to do things that way because you need that whatever 
you define at a given level will override the values from the parent if 
necessary.

{quote}
Imports never overwrite anything already present in the model.
{quote}

This very issue is about the fact that adding the dependency directly works, 
adding a bom that defines said dependency doesn't. IMO this is inconsistent 
considering how we're using BOM (= share a dependency management section).

Answering to your question. Of course I don't want that. I just want that 
whatever is defined in the user project overrides what the parent provides. So 
let's say that the parent provides {{com.foo:bar:1.0.0}}. If the user adds 
{{com.foo:bar:2.0.0}} then all is well. If the user adds a bom that contains a 
dependency management for {{com.foo.bar:2.0.0}} it doesn't. That's the problem 
I am trying to raise here.

In my mind there is no conflict: I am using the tools Maven provides to have a 
decent dependency management. The only mechanism I know to share dependency 
management is the BOM. Is there another one? I don't think so. If we can't use 
that mechanism to override versions (while we can by adding the dependency 
directly), it looks like something is missing in Maven.

I am ok with whatever alternatives Maven offers that would allow me to share 
the dependency management. I just don't think there is one.




> Dependency management in a child project cannot override a version using a BOM
> --
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
>  Issue Type: Wish
>  Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Priority: Trivial
>  Labels: close-pending
>
> When a project extends from a parent with a {{dependencyManagement}} section, 
> it is not always possible to properly override (and align) the version to use 
> for a group of dependencies.
> We typically use Bill Of Materials to gather a group of modules and make sure 
> their versions are consistent. 
> The following project demonstrates the issue: 
> https://github.com/snicoll-scratches/maven-dependency-management
> The first commit is a working use case where the parent uses a bom with 
> version A and we use the same bom with version B in the child. Version B is 
> used as expected.
> The second commit demonstrates the faulty scenario. Rather than using a bom 
> in the parent, we use a direct dependency (provided by that bom). We still 
> use the bom with a different version. In that case all the dependencies but 
> the one provided by the parent are overridden (leading to mixed versions for 
> the dependencies provided by the BOM).
> It looks like the distance is still used to compute the version while the 
> graph of dependencies should be flatten at each step for a proper override. 
> Thoughts? Thanks!



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

[jira] [Commented] (MNG-5971) Dependency management in a child project cannot override a version using a BOM

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll commented on MNG-5971:
--

"Override what is already there". This is quite a big issue in Spring Boot land 
today. We are promoting a "starter-parent" concept where a set of plugins are 
pre-configured with sensible defaults and "core" dependencies can be managed 
via properties (see the {{spring-boot-dependencies}} and 
{{spring-boot-starter-parent}}). 

This works fine until we started to integrate other components on top of Spring 
Boot that have their own boms and some specific requirements regarding 
dependencies. Spring Cloud Services is a typical case that is causing trouble: 
that project need to override the version of one dependency provided in the 
parent and there is no way in Maven to do that. What  we document is to add the 
bom and you should be good to go.

Failing is not an option and It looks like we have different concept of what a 
BOM is. In my opinion, a BOM is way to share the dependency management of a set 
of dependencies. As such, when a BOM is added in a project, it should behave 
exactly as if all the dependencies that it contains were added to the project. 
Since adding the dependency explicitly (rather than via the import of a bom) 
works, I guess this was intentional. I honestly don't get why it should behave 
differently.

Taking a bit of distance of the actual problem, I think our use case is 
actually quite nice: we want to provide _default_ dependencies management and a 
set of nice defaults for plugins that are typically used in a Spring Boot 
application. The only way I know to do that is via a parent pom. That's what we 
 did. Now we are stuck if the user wants to override the version of a 
dependency because the bom import does not work. I feel that use case is legit. 
What would you recommend then?

> Dependency management in a child project cannot override a version using a BOM
> --
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
>  Issue Type: Wish
>  Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Priority: Trivial
>  Labels: close-pending
>
> When a project extends from a parent with a {{dependencyManagement}} section, 
> it is not always possible to properly override (and align) the version to use 
> for a group of dependencies.
> We typically use Bill Of Materials to gather a group of modules and make sure 
> their versions are consistent. 
> The following project demonstrates the issue: 
> https://github.com/snicoll-scratches/maven-dependency-management
> The first commit is a working use case where the parent uses a bom with 
> version A and we use the same bom with version B in the child. Version B is 
> used as expected.
> The second commit demonstrates the faulty scenario. Rather than using a bom 
> in the parent, we use a direct dependency (provided by that bom). We still 
> use the bom with a different version. In that case all the dependencies but 
> the one provided by the parent are overridden (leading to mixed versions for 
> the dependencies provided by the BOM).
> It looks like the distance is still used to compute the version while the 
> graph of dependencies should be flatten at each step for a proper override. 
> Thoughts? Thanks!



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

[jira] [Created] (MNG-5971) Dependency management in a child project cannot override a version using a BOM

[Stephane Nicoll (JIRA)]

Stephane Nicoll created MNG-5971:


 Summary: Dependency management in a child project cannot override 
a version using a BOM
 Key: MNG-5971
 URL: https://issues.apache.org/jira/browse/MNG-5971
 Project: Maven
  Issue Type: Bug
  Components: Dependencies
Affects Versions: 3.3.3
Reporter: Stephane Nicoll


When a project extends from a parent with a {{dependencyManagement}} section, 
it is not always possible to properly override (and align) the version to use 
for a group of dependencies.

We typically use Bill Of Materials to gather a group of modules and make sure 
their versions are consistent. 

The following project demonstrates the issue: 
https://github.com/snicoll-scratches/maven-dependency-management

The first commit is a working use case where the parent uses a bom with version 
A and we use the same bom with version B in the child. Version B is used as 
expected.

The second commit demonstrates the faulty scenario. Rather than using a bom in 
the parent, we use a direct dependency (provided by that bom). We still use the 
bom with a different version. In that case all the dependencies but the one 
provided by the parent are overridden (leading to mixed versions for the 
dependencies provided by the BOM).

It looks like the distance is still used to compute the version while the graph 
of dependencies should be flatten at each step for a proper override. 

Thoughts? Thanks!



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

[jira] [Closed] (SUREFIRE-1198) Failsafe does not allow to use target/classes anymore

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll closed SUREFIRE-1198.
-
Resolution: Won't Fix

> Failsafe does not allow to use target/classes anymore
> -
>
> Key: SUREFIRE-1198
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1198
> Project: Maven Surefire
>  Issue Type: Bug
>Reporter: Stephane Nicoll
>
> See [this Spring Boot 
> issue|https://github.com/spring-projects/spring-boot/issues/4510#issuecomment-159448634]
> It seems that SUREFIRE-855 does not allow {{target/classes}} to be used 
> anymore. Is there a reason why this behaviour was completely removed in 
> favour of only the jar file?
> It would be nice if we had an option to chose between the two (defaulting to 
> the jar)



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

[jira] [Commented] (SUREFIRE-1198) Failsafe does not allow to use target/classes anymore

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll commented on SUREFIRE-1198:
---

What do you mean? I confirm that if surefire allows to configure the jar to use 
we are happy. 

> Failsafe does not allow to use target/classes anymore
> -
>
> Key: SUREFIRE-1198
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1198
> Project: Maven Surefire
>  Issue Type: Bug
>Reporter: Stephane Nicoll
>
> See [this Spring Boot 
> issue|https://github.com/spring-projects/spring-boot/issues/4510#issuecomment-159448634]
> It seems that SUREFIRE-855 does not allow {{target/classes}} to be used 
> anymore. Is there a reason why this behaviour was completely removed in 
> favour of only the jar file?
> It would be nice if we had an option to chose between the two (defaulting to 
> the jar)



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

[jira] [Created] (SUREFIRE-1198) Failsafe does not allow to use target/classes anymore

[Stephane Nicoll (JIRA)]

Stephane Nicoll created SUREFIRE-1198:
-

 Summary: Failsafe does not allow to use target/classes anymore
 Key: SUREFIRE-1198
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1198
 Project: Maven Surefire
  Issue Type: Bug
Reporter: Stephane Nicoll


See [this Spring Boot 
issue|https://github.com/spring-projects/spring-boot/issues/4510#issuecomment-159448634]

It seems that SUREFIRE-855 does not allow {{target/classes}} to be used 
anymore. Is there a reason why this behaviour was completely removed in favour 
of only the jar file?

It would be nice if we had an option to chose between the two (defaulting to 
the jar)




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

[jira] [Commented] (SUREFIRE-1198) Failsafe does not allow to use target/classes anymore

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll commented on SUREFIRE-1198:
---

Configuring the jar to use would work for us. I'll have a look.

> Failsafe does not allow to use target/classes anymore
> -
>
> Key: SUREFIRE-1198
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1198
> Project: Maven Surefire
>  Issue Type: Bug
>Reporter: Stephane Nicoll
>
> See [this Spring Boot 
> issue|https://github.com/spring-projects/spring-boot/issues/4510#issuecomment-159448634]
> It seems that SUREFIRE-855 does not allow {{target/classes}} to be used 
> anymore. Is there a reason why this behaviour was completely removed in 
> favour of only the jar file?
> It would be nice if we had an option to chose between the two (defaulting to 
> the jar)



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

[jira] (MEAR-147) wrong DOCTPYE in jboss-app.xml for 4.2

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll updated MEAR-147:
-

Fix Version/s: 2.8

 wrong DOCTPYE in jboss-app.xml for 4.2
 --

 Key: MEAR-147
 URL: https://jira.codehaus.org/browse/MEAR-147
 Project: Maven 2.x Ear Plugin
  Issue Type: Bug
Affects Versions: 2.7
Reporter: Andreas Wurzer
Assignee: Stephane Nicoll
 Fix For: 2.8

 Attachments: jboss42.patch, jboss42.patch


 MEAR-104 doesn't completly fix the issue with the generated jboss-app.xml 
 because the PUBLIC identifier in the DOCTYPE for JBoss 4.2 should be 
 -//JBoss//DTD J2EE Application 4.2//EN as seen in the jboss-app_4_2.dtd.
 At present it is -//JBoss//DTD J2EE Application 1.4//EN which leads to the 
 following problem - because it is validated against the wrong DTD for JBoss 
 4.0 (jboss-app_4.0.dtd).
 {{org.xml.sax.SAXParseException: The content of element type jboss-app must 
 match 
 (module-order?,security-domain?,unauthenticated-principal?,loader-repository?,jmx-name?,module*,security-role*)}}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MEAR-147) wrong DOCTPYE in jboss-app.xml for 4.2

[Stephane Nicoll (JIRA)]

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

Work on MEAR-147 started by Stephane Nicoll.

 wrong DOCTPYE in jboss-app.xml for 4.2
 --

 Key: MEAR-147
 URL: https://jira.codehaus.org/browse/MEAR-147
 Project: Maven 2.x Ear Plugin
  Issue Type: Bug
Affects Versions: 2.7
Reporter: Andreas Wurzer
Assignee: Stephane Nicoll
 Fix For: 2.8

 Attachments: jboss42.patch, jboss42.patch


 MEAR-104 doesn't completly fix the issue with the generated jboss-app.xml 
 because the PUBLIC identifier in the DOCTYPE for JBoss 4.2 should be 
 -//JBoss//DTD J2EE Application 4.2//EN as seen in the jboss-app_4_2.dtd.
 At present it is -//JBoss//DTD J2EE Application 1.4//EN which leads to the 
 following problem - because it is validated against the wrong DTD for JBoss 
 4.0 (jboss-app_4.0.dtd).
 {{org.xml.sax.SAXParseException: The content of element type jboss-app must 
 match 
 (module-order?,security-domain?,unauthenticated-principal?,loader-repository?,jmx-name?,module*,security-role*)}}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MEAR-147) wrong DOCTPYE in jboss-app.xml for 4.2

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll closed MEAR-147.


Resolution: Fixed

Fixed. Thanks for the patch!

 wrong DOCTPYE in jboss-app.xml for 4.2
 --

 Key: MEAR-147
 URL: https://jira.codehaus.org/browse/MEAR-147
 Project: Maven 2.x Ear Plugin
  Issue Type: Bug
Affects Versions: 2.7
Reporter: Andreas Wurzer
Assignee: Stephane Nicoll
 Fix For: 2.8

 Attachments: jboss42.patch, jboss42.patch


 MEAR-104 doesn't completly fix the issue with the generated jboss-app.xml 
 because the PUBLIC identifier in the DOCTYPE for JBoss 4.2 should be 
 -//JBoss//DTD J2EE Application 4.2//EN as seen in the jboss-app_4_2.dtd.
 At present it is -//JBoss//DTD J2EE Application 1.4//EN which leads to the 
 following problem - because it is validated against the wrong DTD for JBoss 
 4.0 (jboss-app_4.0.dtd).
 {{org.xml.sax.SAXParseException: The content of element type jboss-app must 
 match 
 (module-order?,security-domain?,unauthenticated-principal?,loader-repository?,jmx-name?,module*,security-role*)}}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MEAR-141) No way to configure generate env-entry elements in generated application.xml

[Stephane Nicoll (JIRA)]

[ 
https://jira.codehaus.org/browse/MEAR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=292636#comment-292636
 ] 

Stephane Nicoll commented on MEAR-141:
--

There was some confusion at the beginning but the issue is coming from Maven 2, 
not linux (probably some plexus dependency chain nightmare).



 No way to configure generate env-entry elements in generated application.xml
 

 Key: MEAR-141
 URL: https://jira.codehaus.org/browse/MEAR-141
 Project: Maven 2.x Ear Plugin
  Issue Type: Improvement
Affects Versions: 2.6
Reporter: Laird Nelson
Assignee: Stephane Nicoll
 Fix For: 2.8


 The maven-ear-plugin offers the {{security}} element for declaring 
 security-role-names in a generated application.xml.  It does not offer such a 
 facility for generating {{env-entry}} elements.  It should.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MEAR-141) No way to configure generate env-entry elements in generated application.xml

[Stephane Nicoll (JIRA)]

[ 
https://jira.codehaus.org/browse/MEAR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=292310#comment-292310
 ] 

Stephane Nicoll commented on MEAR-141:
--

It has nothing to do with linux. It's failing with maven 2.x

 No way to configure generate env-entry elements in generated application.xml
 

 Key: MEAR-141
 URL: https://jira.codehaus.org/browse/MEAR-141
 Project: Maven 2.x Ear Plugin
  Issue Type: Improvement
Affects Versions: 2.6
Reporter: Laird Nelson
Assignee: Stephane Nicoll
 Fix For: 2.8


 The maven-ear-plugin offers the {{security}} element for declaring 
 security-role-names in a generated application.xml.  It does not offer such a 
 facility for generating {{env-entry}} elements.  It should.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MEAR-141) No way to configure generate env-entry elements in generated application.xml

[Stephane Nicoll (JIRA)]

[ 
https://jira.codehaus.org/browse/MEAR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=292310#comment-292310
 ] 

Stephane Nicoll edited comment on MEAR-141 at 2/21/12 2:58 AM:
---

It has nothing to do with linux. It's failing with maven 2.x

Instead of reverting, can't you reopen this issue and ignore the test instead. 
It's working fine with Maven 3, we just need to figure out what is going wrong 
in plexus with 2.x

  was (Author: sni):
It has nothing to do with linux. It's failing with maven 2.x
  
 No way to configure generate env-entry elements in generated application.xml
 

 Key: MEAR-141
 URL: https://jira.codehaus.org/browse/MEAR-141
 Project: Maven 2.x Ear Plugin
  Issue Type: Improvement
Affects Versions: 2.6
Reporter: Laird Nelson
Assignee: Stephane Nicoll
 Fix For: 2.8


 The maven-ear-plugin offers the {{security}} element for declaring 
 security-role-names in a generated application.xml.  It does not offer such a 
 facility for generating {{env-entry}} elements.  It should.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MWAR-256) it's not possible to create classes attachment without classifier

[Stephane Nicoll (JIRA)]

[ 
https://jira.codehaus.org/browse/MWAR-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=290982#comment-290982
 ] 

Stephane Nicoll commented on MWAR-256:
--

well the idea is that this jar is meant to be deployed. you must have a 
classifer and if you don't like the default one, just change it.

Or what bothers you is the fact that the jar in WEB-INF/lib is named 
something-classes.jar ?

 it's not possible to create classes attachment without classifier
 -

 Key: MWAR-256
 URL: https://jira.codehaus.org/browse/MWAR-256
 Project: Maven 2.x WAR Plugin
  Issue Type: Bug
Affects Versions: 2.1.1
Reporter: Rafal Krzewski

 I would like to package classes in my war-packaged project into a jar, but I 
 don't want to use default 'classes' classifier assigned by the plugin. The 
 generated artifacts have distinct packaging types, so there is no conflict 
 and the classifier provides no useful additional information. Using the 
 following configuration:
 {quote}
 {{configuration}}
 {{classesClassifier/}}
 {{/configuration}}
 {quote}
 Results in classes classifier being used anyway. If I understand the 
 behavior correctly Plexus assigns the variable it's default value, when 
 presented an empty input. I don't think this can be fixed in way that is both 
 clean and backward compatible. Either the default value will change, which 
 would break existing builds that don't specify plugin version explicitly, or 
 some clunky additional parameter like 
 {{useClassesClassifierfalse/useClassesClassifier}}, or magic value like 
 {{classesClassifierNONE/classesClassifier}} need to be introduced.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MEAR-146) Expose parameter to not write library-directory element in application.xml

[Stephane Nicoll (JIRA)]

[ 
https://jira.codehaus.org/browse/MEAR-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=289722#comment-289722
 ] 

Stephane Nicoll commented on MEAR-146:
--

Well, I think you got it wrong or I am missing something. Your request *IS* 
about working around a bug!

The answer is backward compatibility. This option was present way before 
JavaEE5 came out (actually it was mostly used on old weblogic version and the 
magic APP-INF/lib thing). Changing the behavior of an existing option according 
the version of the spec you use is a bit tricky.

The other reason is that users (for mysterious reasons) keep on willing to put 
libs in the root. If you change the default, it's harder to justify the 
behavior breakage.

 Expose parameter to not write library-directory element in application.xml
 --

 Key: MEAR-146
 URL: https://jira.codehaus.org/browse/MEAR-146
 Project: Maven 2.x Ear Plugin
  Issue Type: Improvement
Affects Versions: 2.8
 Environment: Oracle WebLogic
Reporter: Alex Halovanic
Priority: Minor
 Attachments: ear-remove-librarydirectory-IT.patch, 
 ear-remove-librarydirectory.patch


 The current handling of defaultLibBundleDir leads to some issues on Oracle 
 Weblogic 10+.  The Ear plugin currently sets library-directory to the value 
 of defaultLibBundleDir in the application.xml for EARs v5+.  Some of Oracle's 
 classloading features break (specifically Generic File Loading) when this 
 element is set.  defaultLibBundleDir has to be set to APP-INF/lib since this 
 is the magic library folder for WebLogic.
 The patch adds a parameter to prevent setting library-directory for cases 
 like this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MEAR-146) Expose parameter to not write library-directory element in application.xml

[Stephane Nicoll (JIRA)]

[ 
https://jira.codehaus.org/browse/MEAR-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=289765#comment-289765
 ] 

Stephane Nicoll commented on MEAR-146:
--

k

 Expose parameter to not write library-directory element in application.xml
 --

 Key: MEAR-146
 URL: https://jira.codehaus.org/browse/MEAR-146
 Project: Maven 2.x Ear Plugin
  Issue Type: Improvement
Affects Versions: 2.8
 Environment: Oracle WebLogic
Reporter: Alex Halovanic
Priority: Minor
 Attachments: ear-remove-librarydirectory-IT.patch, 
 ear-remove-librarydirectory.patch


 The current handling of defaultLibBundleDir leads to some issues on Oracle 
 Weblogic 10+.  The Ear plugin currently sets library-directory to the value 
 of defaultLibBundleDir in the application.xml for EARs v5+.  Some of Oracle's 
 classloading features break (specifically Generic File Loading) when this 
 element is set.  defaultLibBundleDir has to be set to APP-INF/lib since this 
 is the magic library folder for WebLogic.
 The patch adds a parameter to prevent setting library-directory for cases 
 like this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MEAR-146) Expose parameter to not write library-directory element in application.xml

[Stephane Nicoll (JIRA)]

[ 
https://jira.codehaus.org/browse/MEAR-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=289642#comment-289642
 ] 

Stephane Nicoll commented on MEAR-146:
--

In that case, I prefer a weblogic configuration option, like we've done for 
JBoss. Your patch is a too wide option that sole purpose is to workaround a bug.

Something like

{code:xml}
configuration
  weblogic
write-library-directoryfalse/write-library-directory
  /weblogic
/configuration
{code}



 Expose parameter to not write library-directory element in application.xml
 --

 Key: MEAR-146
 URL: https://jira.codehaus.org/browse/MEAR-146
 Project: Maven 2.x Ear Plugin
  Issue Type: Improvement
Affects Versions: 2.8
 Environment: Oracle WebLogic
Reporter: Alex Halovanic
Priority: Minor
 Attachments: ear-remove-librarydirectory-IT.patch, 
 ear-remove-librarydirectory.patch


 The current handling of defaultLibBundleDir leads to some issues on Oracle 
 Weblogic 10+.  The Ear plugin currently sets library-directory to the value 
 of defaultLibBundleDir in the application.xml for EARs v5+.  Some of Oracle's 
 classloading features break (specifically Generic File Loading) when this 
 element is set.  defaultLibBundleDir has to be set to APP-INF/lib since this 
 is the magic library folder for WebLogic.
 The patch adds a parameter to prevent setting library-directory for cases 
 like this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MEAR-144) Allow multiple versions of web module inside a single EAR

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll closed MEAR-144.


Resolution: Won't Fix

That's not going to work. The Maven dependency identity mechanism is such that 
you can't have multiple versions of the same artifact.

 Allow multiple versions of web module inside a single EAR
 -

 Key: MEAR-144
 URL: https://jira.codehaus.org/browse/MEAR-144
 Project: Maven 2.x Ear Plugin
  Issue Type: Improvement
Affects Versions: 2.1, 2.2
 Environment: GNU/Linux x86_64 Ubuntu 
Reporter: wing-tung Leung
Priority: Minor

 Current Maven EAR plugin seems not to support explicit version for web 
 modules.
 This would be useful for generating EAR which contains multiple versions of a 
 web module (under different context roots), enabling online users to switch 
 back and forth between old and new releases from the web application.
 http://maven.apache.org/plugins/maven-ear-plugin/modules.html#awebModule

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MEAR-141) No way to programmatically generate env-entry elements in generated application.xml

[Stephane Nicoll (JIRA)]

[ 
https://jira.codehaus.org/browse/MEAR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=289591#comment-289591
 ] 

Stephane Nicoll commented on MEAR-141:
--

Jim Brownfield provided a patch for this one which I am currently reviewing and 
adapting.

 No way to programmatically generate env-entry elements in generated 
 application.xml
 ---

 Key: MEAR-141
 URL: https://jira.codehaus.org/browse/MEAR-141
 Project: Maven 2.x Ear Plugin
  Issue Type: Improvement
Affects Versions: 2.6
Reporter: Laird Nelson
Assignee: Stephane Nicoll
 Fix For: 2.8


 The maven-ear-plugin offers the {{security}} element for declaring 
 security-role-names in a generated application.xml.  It does not offer such a 
 facility for generating {{env-entry}} elements.  It should.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MEAR-141) No way to programmatically generate env-entry elements in generated application.xml

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll updated MEAR-141:
-

Fix Version/s: 2.8
 Assignee: Stephane Nicoll

 No way to programmatically generate env-entry elements in generated 
 application.xml
 ---

 Key: MEAR-141
 URL: https://jira.codehaus.org/browse/MEAR-141
 Project: Maven 2.x Ear Plugin
  Issue Type: Improvement
Affects Versions: 2.6
Reporter: Laird Nelson
Assignee: Stephane Nicoll
 Fix For: 2.8


 The maven-ear-plugin offers the {{security}} element for declaring 
 security-role-names in a generated application.xml.  It does not offer such a 
 facility for generating {{env-entry}} elements.  It should.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MEAR-141) No way to programmatically generate env-entry elements in generated application.xml

[Stephane Nicoll (JIRA)]

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

Work on MEAR-141 started by Stephane Nicoll.

 No way to programmatically generate env-entry elements in generated 
 application.xml
 ---

 Key: MEAR-141
 URL: https://jira.codehaus.org/browse/MEAR-141
 Project: Maven 2.x Ear Plugin
  Issue Type: Improvement
Affects Versions: 2.6
Reporter: Laird Nelson
Assignee: Stephane Nicoll
 Fix For: 2.8


 The maven-ear-plugin offers the {{security}} element for declaring 
 security-role-names in a generated application.xml.  It does not offer such a 
 facility for generating {{env-entry}} elements.  It should.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MEAR-141) No way to configure generate env-entry elements in generated application.xml

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll updated MEAR-141:
-

Summary: No way to configure generate env-entry elements in generated 
application.xml  (was: No way to programmatically generate env-entry elements 
in generated application.xml)

 No way to configure generate env-entry elements in generated application.xml
 

 Key: MEAR-141
 URL: https://jira.codehaus.org/browse/MEAR-141
 Project: Maven 2.x Ear Plugin
  Issue Type: Improvement
Affects Versions: 2.6
Reporter: Laird Nelson
Assignee: Stephane Nicoll
 Fix For: 2.8


 The maven-ear-plugin offers the {{security}} element for declaring 
 security-role-names in a generated application.xml.  It does not offer such a 
 facility for generating {{env-entry}} elements.  It should.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MEAR-141) No way to configure generate env-entry elements in generated application.xml

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll closed MEAR-141.


Resolution: Fixed

 No way to configure generate env-entry elements in generated application.xml
 

 Key: MEAR-141
 URL: https://jira.codehaus.org/browse/MEAR-141
 Project: Maven 2.x Ear Plugin
  Issue Type: Improvement
Affects Versions: 2.6
Reporter: Laird Nelson
Assignee: Stephane Nicoll
 Fix For: 2.8


 The maven-ear-plugin offers the {{security}} element for declaring 
 security-role-names in a generated application.xml.  It does not offer such a 
 facility for generating {{env-entry}} elements.  It should.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MEAR-146) Expose parameter to not write library-directory element in application.xml

[Stephane Nicoll (JIRA)]

[ 
https://jira.codehaus.org/browse/MEAR-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=289592#comment-289592
 ] 

Stephane Nicoll commented on MEAR-146:
--

I am confused. library-directory is only written if you set the 
defaultLibDirectory. If I understand you well, you're saying you must use it 
(to use the magic APP-INF/lib thing) but we should not write the value in that 
case?

I believe you're asking here to workaround a bug in Weblogic, right. Has this 
been reported by any chance?

 Expose parameter to not write library-directory element in application.xml
 --

 Key: MEAR-146
 URL: https://jira.codehaus.org/browse/MEAR-146
 Project: Maven 2.x Ear Plugin
  Issue Type: Improvement
Affects Versions: 2.8
 Environment: Oracle WebLogic
Reporter: Alex Halovanic
Priority: Minor
 Attachments: ear-remove-librarydirectory-IT.patch, 
 ear-remove-librarydirectory.patch


 The current handling of defaultLibBundleDir leads to some issues on Oracle 
 Weblogic 10+.  The Ear plugin currently sets library-directory to the value 
 of defaultLibBundleDir in the application.xml for EARs v5+.  Some of Oracle's 
 classloading features break (specifically Generic File Loading) when this 
 element is set.  defaultLibBundleDir has to be set to APP-INF/lib since this 
 is the magic library folder for WebLogic.
 The patch adds a parameter to prevent setting library-directory for cases 
 like this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MEAR-145) Add Maven version used to Created-By entry in manifest

[Stephane Nicoll (JIRA)]

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

Work on MEAR-145 started by Stephane Nicoll.

 Add Maven version used to Created-By entry in manifest
 --

 Key: MEAR-145
 URL: https://jira.codehaus.org/browse/MEAR-145
 Project: Maven 2.x Ear Plugin
  Issue Type: Improvement
Affects Versions: 2.7
 Environment: n/a
Reporter: Anders Hammar
Assignee: Stephane Nicoll
 Fix For: 2.8

 Attachments: MEAR-145.patch


 Upgrade the dependency to org.apache.maven:maven-archiver to newer version 
 (when released) to get the version of Maven Core used for building included 
 in the Created-By manifest entry. The call to MavenArchiver also needs to be 
 slightly updated to pass along the MavenSession.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MEAR-145) Add Maven version used to Created-By entry in manifest

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll updated MEAR-145:
-

Fix Version/s: 2.8
 Assignee: Stephane Nicoll

 Add Maven version used to Created-By entry in manifest
 --

 Key: MEAR-145
 URL: https://jira.codehaus.org/browse/MEAR-145
 Project: Maven 2.x Ear Plugin
  Issue Type: Improvement
Affects Versions: 2.7
 Environment: n/a
Reporter: Anders Hammar
Assignee: Stephane Nicoll
 Fix For: 2.8

 Attachments: MEAR-145.patch


 Upgrade the dependency to org.apache.maven:maven-archiver to newer version 
 (when released) to get the version of Maven Core used for building included 
 in the Created-By manifest entry. The call to MavenArchiver also needs to be 
 slightly updated to pass along the MavenSession.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MEAR-145) Add Maven version used to Created-By entry in manifest

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll closed MEAR-145.


Resolution: Fixed

Applied, thanks!

 Add Maven version used to Created-By entry in manifest
 --

 Key: MEAR-145
 URL: https://jira.codehaus.org/browse/MEAR-145
 Project: Maven 2.x Ear Plugin
  Issue Type: Improvement
Affects Versions: 2.7
 Environment: n/a
Reporter: Anders Hammar
Assignee: Stephane Nicoll
 Fix For: 2.8

 Attachments: MEAR-145.patch


 Upgrade the dependency to org.apache.maven:maven-archiver to newer version 
 (when released) to get the version of Maven Core used for building included 
 in the Created-By manifest entry. The call to MavenArchiver also needs to be 
 slightly updated to pass along the MavenSession.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MEAR-65) Support MAR archives

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll updated MEAR-65:


Fix Version/s: (was: 2.7)

Unless we get a better view of how this is bundled, I am going to remove it 
from the 2.7 roadmap.

 Support MAR archives
 

 Key: MEAR-65
 URL: https://jira.codehaus.org/browse/MEAR-65
 Project: Maven 2.x Ear Plugin
  Issue Type: Improvement
Affects Versions: 2.3
 Environment: N/A
Reporter: David J. M. Karlsen
Assignee: Stephane Nicoll
Priority: Trivial

 Add support for adding MARs to the archive (typemar/type), like the axis2 
 addressing module @:
 http://repo1.maven.org/maven2/org/apache/axis2/addressing/1.2/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MEAR-71) please support outputFilename here, same as in war plugin

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll updated MEAR-71:


Fix Version/s: (was: 2.7)
   2.8

 please support outputFilename here, same as in war plugin
 -

 Key: MEAR-71
 URL: https://jira.codehaus.org/browse/MEAR-71
 Project: Maven 2.x Ear Plugin
  Issue Type: New Feature
Reporter: Joakim Verona
Assignee: Stephane Nicoll
 Fix For: 2.8




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MWAR-269) war fails to build while using m2e in workspace resolution mode

[Stephane Nicoll (JIRA)]

[ 
https://jira.codehaus.org/browse/MWAR-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=285164#comment-285164
 ] 

Stephane Nicoll commented on MWAR-269:
--

It think the patch makes sense and is clean/short enough to be applied but 
before doing so I would like to reproduce your issue. Can you add a sample 
project or explain how I can reproduce the issue? Thanks.

 war fails to build while using m2e in workspace resolution mode
 ---

 Key: MWAR-269
 URL: https://jira.codehaus.org/browse/MWAR-269
 Project: Maven 2.x WAR Plugin
  Issue Type: Improvement
Affects Versions: 2.1.1
Reporter: Chris Gamache
 Attachments: maven-war-plugin.patch


 This is my first time for an issue/patch submission. Apologies if I'm doing 
 it wrong
 When building in Eclipse using m2e in workspace resolution mode, the 
 maven-war-plugin is not prepared for a dependency which isn't an assembly 
 but is instead a folder containing the compiled classes from within the local 
 workspace. I propose that if the incoming dependency happens to be a 
 directory that it get packaged up and copied to the destination instead of 
 blowing up with an exception.
 See attached patch for your review...

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MWAR-9) WAR plugin should support minimal WARs for inclusion within an EAR

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll updated MWAR-9:
---

Attachment: (was: maven-war-plugin-2.1.1-NM.patch)

 WAR plugin should support minimal WARs for inclusion within an EAR
 --

 Key: MWAR-9
 URL: https://jira.codehaus.org/browse/MWAR-9
 Project: Maven 2.x WAR Plugin
  Issue Type: Improvement
Reporter: Mike Perham
Assignee: Stephane Nicoll
 Fix For: 2.2

 Attachments: AbstractWarMojo.patch


 I noticed that when I build a WAR, I get a gigantic WEB-INF/lib with all my 
 deps.  This is fine for a default but maven should also support skeleton 
 WARs which will be packaged within an EAR.  We have EARs which package 3-4 
 WARs each and to have the deps duplicated within each WAR means we cannot 
 have shared data (since the classes are loaded within each WAR's classloader, 
 rather than by the parent EAR's classloader).  It also means 80MB EARs!  :-)
 It seems like two things need to happen:
 1) Add a skeleton flag which prevents copying any dependencies to 
 WEB-INF/lib.
 2) Instead generate a META-INF/MANIFEST.MF which has a Class-Path entry which 
 lists the relative locations of the dependencies within the parent EAR.
 Fabrice has basically the same idea written down here.  Starting with - for 
 a War... : 
 http://marc.theaimsgroup.com/?l=turbine-maven-userm=112737860024530w=2

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MEAR-141) No way to programmatically generate env-entry elements in generated application.xml

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll updated MEAR-141:
-

Issue Type: Improvement  (was: Bug)

yes it should.

 No way to programmatically generate env-entry elements in generated 
 application.xml
 ---

 Key: MEAR-141
 URL: https://jira.codehaus.org/browse/MEAR-141
 Project: Maven 2.x Ear Plugin
  Issue Type: Improvement
Affects Versions: 2.6
Reporter: Laird Nelson

 The maven-ear-plugin offers the {{security}} element for declaring 
 security-role-names in a generated application.xml.  It does not offer such a 
 facility for generating {{env-entry}} elements.  It should.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MEAR-140) HTML Anchors on page EAR Modules defect

[Stephane Nicoll (JIRA)]

[ 
https://jira.codehaus.org/browse/MEAR-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=272759#comment-272759
 ] 

Stephane Nicoll commented on MEAR-140:
--

Right, thanks for the report. It seems doxia added a 'a' in front of all links. 
I have no idea why and the doc does not seem to discuss this. Will have a look 
around to understand what is going on.

 HTML Anchors on page EAR Modules defect
 -

 Key: MEAR-140
 URL: https://jira.codehaus.org/browse/MEAR-140
 Project: Maven 2.x Ear Plugin
  Issue Type: Task
Affects Versions: 2.6
 Environment: Maven Site / Project Documentation
Reporter: Thomas
Priority: Trivial

 On the maven site page EAR Modules the Anchors are not working:
 http://maven.apache.org/plugins/maven-ear-plugin/modules.html
 They should link to the sections on the same page.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MIDEA-79) Sources for SNAPSHOT-dependencies are not downloaded correctly.

[Stephane Nicoll (JIRA)]

 [ 
https://jira.codehaus.org/browse/MIDEA-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephane Nicoll closed MIDEA-79.


Resolution: Won't Fix

With the current Maven support in IDEA itself, this is no longer necessary.

 Sources for SNAPSHOT-dependencies are not downloaded correctly.
 ---

 Key: MIDEA-79
 URL: https://jira.codehaus.org/browse/MIDEA-79
 Project: Maven 2.x IDEA Plugin
  Issue Type: Bug
Affects Versions: 2.0
Reporter: Jan Thomae
Assignee: Stephane Nicoll

 When downloading sources for SNAPSHOT dependencies,  the plugin uses the 
 wrong path. Instead of downloading 
 http://repository.insomnia-hq.de/de/insomniahq/icc/1.0-SNAPSHOT/icc-1.0-20061202.231038-59-sources.jar
 it tries to download
 http://repository.insomnia-hq.de/de/insomniahq/icc/icc-1.0-20061202.231038-59/icc-1.0-20061202.231038-59-sources.jar
 Also sometimes it tries to download
 http://repository.insomnia-hq.de/de/insomniahq/icc/1.0-SNAPSHOT/icc-1.0-SNAPSHOT-sources.jar
 instead of replacing the SNAPSHOT with the actual snapshot version.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MWAR-255) Negative time

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll updated MWAR-255:
-

Fix Version/s: 2.1.2

  Negative time
 

 Key: MWAR-255
 URL: https://jira.codehaus.org/browse/MWAR-255
 Project: Maven 2.x WAR Plugin
  Issue Type: Bug
Affects Versions: 2.1.1
 Environment: Linux x64, JDK 1.6.0_25, Maven 3.0.3
Reporter: Roman Ksoenko
 Fix For: 2.1.2


 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-war-plugin:2.1.1:war (default-war) on project 
 library: Execution default-war of goal 
 org.apache.maven.plugins:maven-war-plugin:2.1.1:war failed: Negative time - 
 [Help 1]
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
 goal org.apache.maven.plugins:maven-war-plugin:2.1.1:war (default-war) on 
 project library: Execution default-war of goal 
 org.apache.maven.plugins:maven-war-plugin:2.1.1:war failed: Negative time
   at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
   at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
   at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
   at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
   at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
   at 
 org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
   at 
 org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
   at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
   at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
   at 
 org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
   at 
 org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
 Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
 default-war of goal org.apache.maven.plugins:maven-war-plugin:2.1.1:war 
 failed: Negative time
   at 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
   at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
   ... 19 more
 Caused by: java.lang.IllegalArgumentException: Negative time
   at java.io.File.setLastModified(File.java:1258)
   at 
 org.apache.maven.plugin.war.packaging.AbstractWarPackagingTask.copyFile(AbstractWarPackagingTask.java:295)
   at 
 org.apache.maven.plugin.war.packaging.AbstractWarPackagingTask$1.registered(AbstractWarPackagingTask.java:150)
   at 
 org.apache.maven.plugin.war.util.WebappStructure.registerFile(WebappStructure.java:211)
   at 
 org.apache.maven.plugin.war.packaging.AbstractWarPackagingTask.copyFile(AbstractWarPackagingTask.java:145)
   at 
 org.apache.maven.plugin.war.packaging.AbstractWarPackagingTask.copyFiles(AbstractWarPackagingTask.java:103)
   at 
 org.apache.maven.plugin.war.packaging.AbstractWarPackagingTask.copyFiles(AbstractWarPackagingTask.java:125)
   at 
 org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.handeWebAppSourceDirectory(WarProjectPackagingTask.java:168)
   at 
 org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.performPackaging(WarProjectPackagingTask.java:93)
   at 
 org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:472)
   at 
 org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:404)
   at 
 org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:197)
   at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:159)
   at 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
   ... 20 more
 [ERROR] 
 [ERROR] 
 This occurs when I have in src/main/webapp/ files with date 1970-01-01 and 
 it's a rather hard to discover this.

--
This message is automatically generated by JIRA.
For more information on JIRA, 

[jira] Updated: (MWAR-248) Plugin warns about missing webxml attribute even if one exists

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll updated MWAR-248:
-

Fix Version/s: 2.1.2

 Plugin warns about missing webxml attribute even if one exists
 --

 Key: MWAR-248
 URL: https://jira.codehaus.org/browse/MWAR-248
 Project: Maven 2.x WAR Plugin
  Issue Type: Bug
Affects Versions: 2.1.1
Reporter: Gili
 Fix For: 2.1.2

 Attachments: debug.log


 I am attaching a debug log that clearly demonstrates how the WAR plugin warns 
 about a missing webxml attribute which exists. I am attempting to let the 
 plugin know that the web.xml file it is encountering is the same one 
 specified by the webxml attribute.
 My pom file contains:
   plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-war-plugin/artifactId
 version2.1.1/version
 configuration
   failOnMissingWebXmltrue/failOnMissingWebXml
   webXmlsrc/main/webapp/WEB-INF/web.xml/webXml
 /configuration
   /plugin

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MWAR-252) Missing documentation: Overlay filter

[Stephane Nicoll (JIRA)]

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

Stephane Nicoll updated MWAR-252:
-

Fix Version/s: (was: 2.2)
   2.1.2

 Missing documentation: Overlay filter
 -

 Key: MWAR-252
 URL: https://jira.codehaus.org/browse/MWAR-252
 Project: Maven 2.x WAR Plugin
  Issue Type: Improvement
  Components: overlay
Affects Versions: 2.1.1
Reporter: Martijn Baay
Assignee: Kristian Rosenvold
Priority: Minor
 Fix For: 2.1.2

 Attachments: filtering_doc.diff


 The option to enable filtering on an overlay is not documented on the Maven 
 War Plugin page.
 See: http://maven.apache.org/plugins/maven-war-plugin/overlays.html
 Section: Configuring Overlays
 When looking at the XRef the filtering option is there: 
 http://maven.apache.org/plugins/maven-war-plugin/xref/org/apache/maven/plugin/war/Overlay.html#62
 And obviously I applied that option to my project and it's working perfectly 
 :)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MWAR-253) Inherit dependencies from a WAR type dependency when it is overlayed.

[Stephane Nicoll (JIRA)]

[ 
http://jira.codehaus.org/browse/MWAR-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=269528#action_269528
 ] 

Stephane Nicoll commented on MWAR-253:
--

Yes I got that but a bug is something that is supposed to be provided by the 
plugin. What you are describing was never implemented. I am just trying to 
understand

 Inherit dependencies from a WAR type dependency when it is overlayed.
 -

 Key: MWAR-253
 URL: http://jira.codehaus.org/browse/MWAR-253
 Project: Maven 2.x WAR Plugin
  Issue Type: Bug
Affects Versions: 2.1.1
Reporter: Maarten Billemont

 When WAR artifact B depends on WAR artifact A, and also defines an overlay of 
 A, B should inherit all A's dependencies.
 This issue is related to MNG-1991, but can be resolved without much 
 discussion as it's unrelated to skinny WARs and such.
 Classes in B are guaranteed to have runtime access to all A's declared 
 dependencies when A is an overlay of B.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MWAR-253) Inherit dependencies from a WAR type dependency when it is overlayed.

[Stephane Nicoll (JIRA)]

[ 
http://jira.codehaus.org/browse/MWAR-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=269418#action_269418
 ] 

Stephane Nicoll commented on MWAR-253:
--

I am not sure I understand how it is a bug.

 Inherit dependencies from a WAR type dependency when it is overlayed.
 -

 Key: MWAR-253
 URL: http://jira.codehaus.org/browse/MWAR-253
 Project: Maven 2.x WAR Plugin
  Issue Type: Bug
Affects Versions: 2.1.1
Reporter: Maarten Billemont

 When WAR artifact B depends on WAR artifact A, and also defines an overlay of 
 A, B should inherit all A's dependencies.
 This issue is related to MNG-1991, but can be resolved without much 
 discussion as it's unrelated to skinny WARs and such.
 Classes in B are guaranteed to have runtime access to all A's declared 
 dependencies when A is an overlay of B.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MEAR-139) earSourceDirectory named in documentation as earSourcesDirectory

[Stephane Nicoll (JIRA)]

 [ 
http://jira.codehaus.org/browse/MEAR-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephane Nicoll updated MEAR-139:
-

Fix Version/s: 2.6

 earSourceDirectory named in documentation as earSourcesDirectory
 

 Key: MEAR-139
 URL: http://jira.codehaus.org/browse/MEAR-139
 Project: Maven 2.x Ear Plugin
  Issue Type: Bug
 Environment: http://maven.apache.org/plugins/maven-ear-plugin/
Reporter: Alexey Tomin
 Fix For: 2.6


 http://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html
   resourcesDirFile-   Deprecated. please use 
 earSourcesDirectory instead in table and below)
 http://maven.apache.org/plugins/maven-ear-plugin/examples/filtering-sources.html
   Filtering the content of the src/main/application directory or the one 
 defined by the earSourcesDirectory parameter is as easy as
 http://maven.apache.org/plugins/maven-ear-plugin/usage.html
   The default resource directory for an EAR is src/main/application as 
 defined by the earSourcesDirectory parameter

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MEAR-139) earSourceDirectory named in documentation as earSourcesDirectory

[Stephane Nicoll (JIRA)]

 [ 
http://jira.codehaus.org/browse/MEAR-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephane Nicoll closed MEAR-139.


Resolution: Fixed

Thank you for the report Alexey. It has been fixed and the site will be updated 
for the next release.

 earSourceDirectory named in documentation as earSourcesDirectory
 

 Key: MEAR-139
 URL: http://jira.codehaus.org/browse/MEAR-139
 Project: Maven 2.x Ear Plugin
  Issue Type: Bug
 Environment: http://maven.apache.org/plugins/maven-ear-plugin/
Reporter: Alexey Tomin
Assignee: Stephane Nicoll
 Fix For: 2.6


 http://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html
   resourcesDirFile-   Deprecated. please use 
 earSourcesDirectory instead in table and below)
 http://maven.apache.org/plugins/maven-ear-plugin/examples/filtering-sources.html
   Filtering the content of the src/main/application directory or the one 
 defined by the earSourcesDirectory parameter is as easy as
 http://maven.apache.org/plugins/maven-ear-plugin/usage.html
   The default resource directory for an EAR is src/main/application as 
 defined by the earSourcesDirectory parameter

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MEAR-138) Ear plugin doesn't attach jars with timestamp

[Stephane Nicoll (JIRA)]

[ 
http://jira.codehaus.org/browse/MEAR-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=265285#action_265285
 ] 

Stephane Nicoll commented on MEAR-138:
--

Yes the bundle filename indeed is rebuilt from the Artifact metadata. I would 
consider to use what Joerg suggests.

Would that be enough for you?

 Ear plugin doesn't attach jars with timestamp
 -

 Key: MEAR-138
 URL: http://jira.codehaus.org/browse/MEAR-138
 Project: Maven 2.x Ear Plugin
  Issue Type: Bug
Affects Versions: 2.5
 Environment: maven 3.0.3
Reporter: Michal Hlavac

 Since maven 3 ignore uniqueVersiontrue/uniqueVersion all snapshots are 
 built with timestamp. EJB plugin creates manifest with classpath that 
 contains jars with timestamps (e.g. artefact-1.0-20110429.071946-2.jar) but 
 ear plugin attach file artefact-1.0-SNAPSHOT.jar).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MEAR-137) Support for JEE Application Clients

[Stephane Nicoll (JIRA)]

 [ 
http://jira.codehaus.org/browse/MEAR-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephane Nicoll closed MEAR-137.


Resolution: Fixed

Added ITs and documentation. Also fixed a bug where the defaultBundleDir was 
affecting the location of the artifact.

 Support for JEE Application Clients
 ---

 Key: MEAR-137
 URL: http://jira.codehaus.org/browse/MEAR-137
 Project: Maven 2.x Ear Plugin
  Issue Type: New Feature
 Environment: any
Reporter: Pablo Rodriguez
Assignee: Stephane Nicoll
 Fix For: 2.6

 Attachments: maven-ear-plugin


 Currently the maven ear plugin only supports JEE application clients by 
 defining them as jarmodules with includeInApplicationXMLtrue/true. This 
 is a bit to hacky as Applicaiton client modules are first class EAR citizens 
 as ejb, war and rar modules.
 The patch provided here is half of my attempt to upgrade this application 
 client modules to be maven ear first citizens.
 I have created a maven-car-plugin defining a packaging type 'car' (in same 
 manner as war, ejb or rar).
 http://code.google.com/p/maven-car-plugin/
 The patch provided here, adds support to maven-ear-plugin to recognize the 
 'car' packaging type, include the artifact in the root of the ear and adds 
 the corresponding entry to application.xml
 Note that i would like this to be temporary and would prefer to see the car 
 packaging type, the maven-car-plugin be core maven plugins with gorupid 
 org.maven.plugins as there is no reason for application clients not having 
 same support as war, ejb or rar modules.
 I feel this extra module, packaging type and plugin are needed as confusion 
 has been arising around application clients
 http://jira.codehaus.org/browse/MEAR-46
 http://jira.codehaus.org/browse/MEAR-40
 Pablo

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MEAR-40) Autodetect Client Application modules and EJB3 modules.

[Stephane Nicoll (JIRA)]

 [ 
http://jira.codehaus.org/browse/MEAR-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephane Nicoll closed MEAR-40.
---

Resolution: Duplicate

Fixed with MEAR-137

 Autodetect Client Application modules and EJB3 modules.
 ---

 Key: MEAR-40
 URL: http://jira.codehaus.org/browse/MEAR-40
 Project: Maven 2.x Ear Plugin
  Issue Type: New Feature
Affects Versions: 2.2
Reporter: Markus KARG
Assignee: Stephane Nicoll
 Fix For: 2.6


 The J2EE 1.4 specification know the modules type EJB, WEB, RAR and 
 Client Application.
 The EAR plugin currently supports the autodetection of EJB, WEB and RAR.
 As a result, the EAR plugin automatically creates an application.xml file 
 containing module entries using the corresponding type, without the need to 
 add module entries to the pom.
 Unfortunately this is not working with Client Application modules and 
 EJB3 modules.
 To have a client module's corresponding java tag get added to the 
 application.xml file, the developer has to add it to the pom.xml manually, 
 what is not nice. Actually it would be easy for the EAR plugin to do that 
 automatically: It just needs to check whether each of the dependencies named 
 in the pom.xml file has a .jar extension AND contains a file called 
 /META-INF/client-application.xml (check J2EE 1.4 specification chapter 9 on 
 details). If such a file is found, the dependency is a Client Application 
 and in turn the EAR plugin has to add a java tag to the application.xml 
 file.
 Also, the support of EJB3 modules is not working, since they do not 
 necessarily have a /META-INF/ejb-jar.xml file contained, which would be 
 needed to discriminate utility JARs from EJB3 JARs (as the distinction of 
 utility JARs from Client Application JARs can be done as described above 
 using the existence of the /META-INF/client-application.xml file). 
 Nevertheless, there should be a means of automatic detection of EJB3 modules 
 for automatic generation of module entries in application.xml. A possible 
 way to solve that could be to analyze the content of each file with a .jar 
 extension: As soon as at least one class is contained that is annotated as 
 @Stateful, @Stateless, @Entity or @MessageDriven, or as soon as a file named 
 /META-INF/ejb-jar.xml is found in the jar, the definitively is an EJB 
 module and in turn the EAR module has to add a ejb tag to the 
 application.xml file. Actually this will slow down detection of module types, 
 but on the other hand the user decided to use the automation instead of 
 manually adding module entries, so he will accept the performance penalty.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MEAR-120) finalName does not work in multi module project

[Stephane Nicoll (JIRA)]

 [ 
http://jira.codehaus.org/browse/MEAR-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephane Nicoll closed MEAR-120.


Resolution: Cannot Reproduce

No response from user

 finalName does not work in multi module project
 -

 Key: MEAR-120
 URL: http://jira.codehaus.org/browse/MEAR-120
 Project: Maven 2.x Ear Plugin
  Issue Type: Bug
Affects Versions: 2.3.1
 Environment: OS name: linux version: 2.6.5-7.244-smp arch: i386 
 Family: unix
Reporter: Deepak Chavan

 I have given finalName for my projects but it is not working for some 
 modules. Following tag has been added in root pom.xml of my project:
 buildfinalNameso-${pom.artifactId}-${pom.version}/finalName
 .
 .
 ./build
 According to this it should append prefix so- for all modules but it is not 
 working as expected. 
 maven-ear-plugin version : 2.3.1
 maven : maven 2.0.8
 Thanks,
 Deepak

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MEAR-65) Support MAR archives

[Stephane Nicoll (JIRA)]

[ 
http://jira.codehaus.org/browse/MEAR-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=262374#action_262374
 ] 

Stephane Nicoll commented on MEAR-65:
-

How is this bundled? I guess that .mar is not detected as a standard jar file 
so you should place it somewhere special where Axis can discover it right?

Can you confirm this is still a valid use case? This seems to be quite old and 
I see more refs on 'aar' than 'mar' actually.

 Support MAR archives
 

 Key: MEAR-65
 URL: http://jira.codehaus.org/browse/MEAR-65
 Project: Maven 2.x Ear Plugin
  Issue Type: Improvement
Affects Versions: 2.3
 Environment: N/A
Reporter: David J. M. Karlsen
Assignee: Stephane Nicoll
Priority: Trivial
 Fix For: 2.6


 Add support for adding MARs to the archive (typemar/type), like the axis2 
 addressing module @:
 http://repo1.maven.org/maven2/org/apache/axis2/addressing/1.2/

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MEAR-48) Remove resourceDir deprecated feature

[Stephane Nicoll (JIRA)]

 [ 
http://jira.codehaus.org/browse/MEAR-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephane Nicoll updated MEAR-48:


Fix Version/s: (was: 2.6)
   2.7

 Remove resourceDir deprecated feature
 -

 Key: MEAR-48
 URL: http://jira.codehaus.org/browse/MEAR-48
 Project: Maven 2.x Ear Plugin
  Issue Type: Task
Affects Versions: 2.3
Reporter: Stephane Nicoll
Assignee: Stephane Nicoll
Priority: Minor
 Fix For: 2.7


 resourceDir is deprecated for a while now so it should be removed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MEAR-65) Support MAR archives

[Stephane Nicoll (JIRA)]

 [ 
http://jira.codehaus.org/browse/MEAR-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephane Nicoll updated MEAR-65:


Fix Version/s: (was: 2.6)
   2.7

 Support MAR archives
 

 Key: MEAR-65
 URL: http://jira.codehaus.org/browse/MEAR-65
 Project: Maven 2.x Ear Plugin
  Issue Type: Improvement
Affects Versions: 2.3
 Environment: N/A
Reporter: David J. M. Karlsen
Assignee: Stephane Nicoll
Priority: Trivial
 Fix For: 2.7


 Add support for adding MARs to the archive (typemar/type), like the axis2 
 addressing module @:
 http://repo1.maven.org/maven2/org/apache/axis2/addressing/1.2/

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MEAR-113) The default contextRoot should match the default bundleFileName

[Stephane Nicoll (JIRA)]

 [ 
http://jira.codehaus.org/browse/MEAR-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephane Nicoll updated MEAR-113:
-

Fix Version/s: (was: 2.6)
   2.7

 The default contextRoot should match the default bundleFileName
 ---

 Key: MEAR-113
 URL: http://jira.codehaus.org/browse/MEAR-113
 Project: Maven 2.x Ear Plugin
  Issue Type: Improvement
Affects Versions: 2.3.2
Reporter: Michael Semb Wever
 Fix For: 2.7

 Attachments: MEAR-113.patch, MEAR-113.patch


 In a webModule the contextRoot defaults to 
  / + a.getArtifactId()
 There is no way AFAIK to have a contextRoot that honours the webModule 
 artifact's finalName, necessary if it was dynamically set via profiles.
 (The only way i see here is to duplicate all the profile information and put 
 the maven-ear-plugin configuration into each profile, just to insert the 
 various contextRoot values).
 By making the contextRoot instead default to 
  / + getBundleFileName()
 this scenario is solved. 
 The webModule's contextRoot defaults to the build name of the artifact if it 
 were customised. If that artifact's finalName was not customised then it 
 defaults back to the artifactId therefore maintaining today's behavior and 
 not breaking any compatibility.
 Patch attached.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MEAR-71) please support outputFilename here, same as in war plugin

[Stephane Nicoll (JIRA)]

 [ 
http://jira.codehaus.org/browse/MEAR-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephane Nicoll updated MEAR-71:


Fix Version/s: (was: 2.6)
   2.7

 please support outputFilename here, same as in war plugin
 -

 Key: MEAR-71
 URL: http://jira.codehaus.org/browse/MEAR-71
 Project: Maven 2.x Ear Plugin
  Issue Type: New Feature
Reporter: Joakim Verona
Assignee: Stephane Nicoll
 Fix For: 2.7




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MEAR-87) Allow exclusion of artifacts when building the ear file.

[Stephane Nicoll (JIRA)]

 [ 
http://jira.codehaus.org/browse/MEAR-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephane Nicoll updated MEAR-87:


Fix Version/s: (was: 2.6)
   2.7

 Allow exclusion of artifacts when building the ear file.
 

 Key: MEAR-87
 URL: http://jira.codehaus.org/browse/MEAR-87
 Project: Maven 2.x Ear Plugin
  Issue Type: New Feature
Affects Versions: 2.3.1
Reporter: Dieter Houthooft
Priority: Minor
 Fix For: 2.7

 Attachments: maven-ear-plugin-excludes-fixed.patch, 
 maven-ear-plugin-excludes.patch


 What is included in the .ear file is determined by the module list and the 
 dependency list and its transitive dependencies. We are often confronted with 
 changing demands about what to include in our ear files. It is quite hard to 
 change our dependency management (scopes) every time without side-effects on 
 other distributable artifacts. So I created an exclude configuration option 
 which allows to exclude artifacts from the ear file based on regular 
 expressions (java.util.regex) matching artifactIds and groupIds.
 Use it like this:
 configuration
excludes
   exclude
  groupIdbe.nondistributable.*/groupId
   /exclude
/excludes
 /configuration

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Work started: (MEAR-137) Support for JEE Application Clients

[Stephane Nicoll (JIRA)]

 [ 
http://jira.codehaus.org/browse/MEAR-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on MEAR-137 started by Stephane Nicoll.

 Support for JEE Application Clients
 ---

 Key: MEAR-137
 URL: http://jira.codehaus.org/browse/MEAR-137
 Project: Maven 2.x Ear Plugin
  Issue Type: New Feature
 Environment: any
Reporter: Pablo Rodriguez
Assignee: Stephane Nicoll
 Fix For: 2.6

 Attachments: maven-ear-plugin


 Currently the maven ear plugin only supports JEE application clients by 
 defining them as jarmodules with includeInApplicationXMLtrue/true. This 
 is a bit to hacky as Applicaiton client modules are first class EAR citizens 
 as ejb, war and rar modules.
 The patch provided here is half of my attempt to upgrade this application 
 client modules to be maven ear first citizens.
 I have created a maven-car-plugin defining a packaging type 'car' (in same 
 manner as war, ejb or rar).
 http://code.google.com/p/maven-car-plugin/
 The patch provided here, adds support to maven-ear-plugin to recognize the 
 'car' packaging type, include the artifact in the root of the ear and adds 
 the corresponding entry to application.xml
 Note that i would like this to be temporary and would prefer to see the car 
 packaging type, the maven-car-plugin be core maven plugins with gorupid 
 org.maven.plugins as there is no reason for application clients not having 
 same support as war, ejb or rar modules.
 I feel this extra module, packaging type and plugin are needed as confusion 
 has been arising around application clients
 http://jira.codehaus.org/browse/MEAR-46
 http://jira.codehaus.org/browse/MEAR-40
 Pablo

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MEAR-137) Support for JEE Application Clients

[Stephane Nicoll (JIRA)]

[ 
http://jira.codehaus.org/browse/MEAR-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=261604#action_261604
 ] 

Stephane Nicoll commented on MEAR-137:
--

A candidate change has been added and a 2.6-SNAPSHOT has been deployed on the 
repository. Only make sense if you have the acr plugin as well (a release vote 
is ongoing)

 Support for JEE Application Clients
 ---

 Key: MEAR-137
 URL: http://jira.codehaus.org/browse/MEAR-137
 Project: Maven 2.x Ear Plugin
  Issue Type: New Feature
 Environment: any
Reporter: Pablo Rodriguez
Assignee: Stephane Nicoll
 Fix For: 2.6

 Attachments: maven-ear-plugin


 Currently the maven ear plugin only supports JEE application clients by 
 defining them as jarmodules with includeInApplicationXMLtrue/true. This 
 is a bit to hacky as Applicaiton client modules are first class EAR citizens 
 as ejb, war and rar modules.
 The patch provided here is half of my attempt to upgrade this application 
 client modules to be maven ear first citizens.
 I have created a maven-car-plugin defining a packaging type 'car' (in same 
 manner as war, ejb or rar).
 http://code.google.com/p/maven-car-plugin/
 The patch provided here, adds support to maven-ear-plugin to recognize the 
 'car' packaging type, include the artifact in the root of the ear and adds 
 the corresponding entry to application.xml
 Note that i would like this to be temporary and would prefer to see the car 
 packaging type, the maven-car-plugin be core maven plugins with gorupid 
 org.maven.plugins as there is no reason for application clients not having 
 same support as war, ejb or rar modules.
 I feel this extra module, packaging type and plugin are needed as confusion 
 has been arising around application clients
 http://jira.codehaus.org/browse/MEAR-46
 http://jira.codehaus.org/browse/MEAR-40
 Pablo

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MEAR-113) The default contextRoot should match the default bundleFileName

[Stephane Nicoll (JIRA)]

[ 
http://jira.codehaus.org/browse/MEAR-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=261606#action_261606
 ] 

Stephane Nicoll commented on MEAR-113:
--

I am still unsure how I could resolve this one without breaking existing use 
cases. Watchers, could you please provide relevant use cases? I don't think 
using final name is a good idea at all, actually. I would use a global property 
of the project and use that one in a webModule configuration. In that case, 
there's nothing needed here.

 The default contextRoot should match the default bundleFileName
 ---

 Key: MEAR-113
 URL: http://jira.codehaus.org/browse/MEAR-113
 Project: Maven 2.x Ear Plugin
  Issue Type: Improvement
Affects Versions: 2.3.2
Reporter: Michael Semb Wever
 Fix For: 2.6

 Attachments: MEAR-113.patch, MEAR-113.patch


 In a webModule the contextRoot defaults to 
  / + a.getArtifactId()
 There is no way AFAIK to have a contextRoot that honours the webModule 
 artifact's finalName, necessary if it was dynamically set via profiles.
 (The only way i see here is to duplicate all the profile information and put 
 the maven-ear-plugin configuration into each profile, just to insert the 
 various contextRoot values).
 By making the contextRoot instead default to 
  / + getBundleFileName()
 this scenario is solved. 
 The webModule's contextRoot defaults to the build name of the artifact if it 
 were customised. If that artifact's finalName was not customised then it 
 defaults back to the artifactId therefore maintaining today's behavior and 
 not breaking any compatibility.
 Patch attached.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MACR-2) Initial documentation

[Stephane Nicoll (JIRA)]

Initial documentation
-

 Key: MACR-2
 URL: http://jira.codehaus.org/browse/MACR-2
 Project: Maven ACR Plugin
  Issue Type: Improvement
Affects Versions: 1.0
Reporter: Stephane Nicoll


Create a simple documentation for the plugin.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Work started: (MACR-2) Initial documentation

[Stephane Nicoll (JIRA)]

 [ 
http://jira.codehaus.org/browse/MACR-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on MACR-2 started by Stephane Nicoll.

 Initial documentation
 -

 Key: MACR-2
 URL: http://jira.codehaus.org/browse/MACR-2
 Project: Maven ACR Plugin
  Issue Type: Improvement
Affects Versions: 1.0
Reporter: Stephane Nicoll
Assignee: Stephane Nicoll

 Create a simple documentation for the plugin.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (MACR-2) Initial documentation

[Stephane Nicoll (JIRA)]

 [ 
http://jira.codehaus.org/browse/MACR-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephane Nicoll resolved MACR-2.


   Resolution: Fixed
Fix Version/s: 1.0

 Initial documentation
 -

 Key: MACR-2
 URL: http://jira.codehaus.org/browse/MACR-2
 Project: Maven ACR Plugin
  Issue Type: Improvement
Affects Versions: 1.0
Reporter: Stephane Nicoll
Assignee: Stephane Nicoll
 Fix For: 1.0


 Create a simple documentation for the plugin.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Work started: (MACR-1) Initial version of the plugin

[Stephane Nicoll (JIRA)]

 [ 
http://jira.codehaus.org/browse/MACR-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on MACR-1 started by Stephane Nicoll.

 Initial version of the plugin
 -

 Key: MACR-1
 URL: http://jira.codehaus.org/browse/MACR-1
 Project: Maven ACR Plugin
  Issue Type: New Feature
Reporter: Stephane Nicoll
Assignee: Stephane Nicoll
 Fix For: 1.0


 Create initial version of the plugin aimed to support the JaveEE application 
 client packaging type. 
 The Maven type for this artifact is 'app-client'

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira