[jira] (SUREFIRE-800) redirectTestOutputToFile is not taken into account in all cases with JUnit47 provider
[
https://jira.codehaus.org/browse/SUREFIRE-800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287832#comment-287832
]
Kristian Rosenvold commented on SUREFIRE-800:
-
Always rewarding when someone takes an interest, so thank you too !
> redirectTestOutputToFile is not taken into account in all cases with JUnit47
> provider
> -
>
> Key: SUREFIRE-800
> URL: https://jira.codehaus.org/browse/SUREFIRE-800
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.10
> Environment: all
>Reporter: nkeywal
>Assignee: Kristian Rosenvold
> Fix For: 2.12
>
>
> With the following class:
> {noformat}
> public class Test0 {
> public Test0(){
> System.out.println("Constructor");
> }
> @Test
> public void testT0() throws Exception {
> System.out.println("testT0");
> }
> @Test
> public void testT1() throws Exception {
> System.out.println("testT1");
> }
> @BeforeClass
> public static void setUpBeforeClass() throws Exception {
> System.out.println("setUpBeforeClass");
> }
> @AfterClass
> public static void tearDownAfterClass() throws Exception {
> System.out.println("tearDownAfterClass");
> }
> @Before
> public void setUp() throws Exception {
> System.out.println("setUp");
> }
> @After
> public void tearDown() throws Exception {
> System.out.println("tearDown");
> }
> }
> {noformat}
> Some elements of the output are not redirected with JUNit47.
> {noformat}
> Concurrency config is parallel='none', perCoreThreadCount=true,
> threadCount=2, useUnlimitedThreads=false
> setUpBeforeClass
> Constructor
> Constructor
> tearDownAfterClass
> Running Test0
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec
> {noformat}
> While it's ok with with JUNit4:
> {noformat}
> ---
> T E S T S
> ---
> Running Test0
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.09 sec
> {noformat}
--
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] (SUREFIRE-770) persistence.xml in src/test/resources/META-INF is not taken into account
[ https://jira.codehaus.org/browse/SUREFIRE-770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287834#comment-287834 ] Kristian Rosenvold commented on SUREFIRE-770: - A common approach to solving this issue is to have the following dependency chain (A->B->C) (A depends on B depends on C). In module B & C you can have the test configuration in test scope only and not in main scope. In module A you have the configuration in main scope only. In that way module "A" will be the only one with the non-test configuration. > persistence.xml in src/test/resources/META-INF is not taken into account > > > Key: SUREFIRE-770 > URL: https://jira.codehaus.org/browse/SUREFIRE-770 > Project: Maven Surefire > Issue Type: Bug > Components: classloading >Affects Versions: 2.9 > Environment: Windows XP >Reporter: Wolfgang Grossinger > Labels: proposedWontFix > Fix For: Backlog > > > When i have a persistence.xml in /src/main/resources/META-INF and in > /src/test/resources/META-INF the xml for the test is never used. I found a > few issues how to fix this but nobody had an explanation why this behavior is > as it is. For me this behavior is really strange (and I couldn't believe that > this is not my fault and is really not working). It seem this has to do with > classloading - in my opinion, the test classes and the test resources should > have priority, otherwise the whole separation of main/test is useless. I > hope, that there is no real reason why this is so at the moment, because this > behavior is really strange and absolutely against what the normal user would > expect. -- 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] (MRELEASE-724) Release plugin doesn't honor profiles defined in user settings
[
https://jira.codehaus.org/browse/MRELEASE-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287838#comment-287838
]
Eric Chatellier commented on MRELEASE-724:
--
Same error here.
> Release plugin doesn't honor profiles defined in user settings
> --
>
> Key: MRELEASE-724
> URL: https://jira.codehaus.org/browse/MRELEASE-724
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.2.2
>Reporter: Arnaud Heritier
>Priority: Critical
> Attachments: MRELEASE-724.log
>
>
> We tried to upgrade the release plugin from 2.2.1 to 2.2.2 and it broke our
> release.
> We don't define repositories (especially private ones) in our pom but in our
> developers settings (activated from command line or more often in
> activeProfiles)
> Releasing this project fails with :
> {code}
> arnaud@mbp-arnaud:~/Code/eXo/cloud-management (git:develop %)$ mvn
> release:prepare -DdryRun=true
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Reactor Build Order:
> [INFO]
> ...
> [INFO] --- maven-release-plugin:2.2.2:prepare (default-cli) @
> cloud-management-parent ---
> [INFO] Resuming release from phase 'run-preparation-goals'
> [INFO] Executing preparation goals - since this is simulation mode it is
> running against the original project, not the rewritten ones
> [INFO] Executing goals 'clean verify'...
> [WARNING] Maven will be executed in interactive mode, but no input stream has
> been configured for this MavenInvoker instance.
> [INFO] [INFO] Scanning for projects...
> [INFO] [INFO]
>
> [INFO] [INFO] Reactor Build Order:
> ...
> [INFO] [INFO]
>
> [INFO] [INFO] Building eXo Cloud Management :: Parent 1.1-M4-SNAPSHOT
> [INFO] [INFO]
>
> ...
> [INFO] [INFO] --- maven-license-plugin:1.9.0:check (check-headers) @
> cloud-management-parent ---
> [INFO] [WARNING] The POM for
> org.exoplatform.cloud-management:cloud-build-tools:jar:0.1-M1 is missing, no
> dependency information available
> [INFO] [INFO]
>
> [INFO] [INFO] Reactor Summary:
> [INFO] [INFO]
> [INFO] [INFO] eXo Cloud Management :: Parent FAILURE
> [1.257s]
> ...
> [INFO] [INFO]
>
> [INFO] [INFO] BUILD FAILURE
> [INFO] [INFO]
>
> ...
> [INFO] [INFO]
>
> [INFO] [WARNING] The requested profile "exo-central" could not be activated
> because it does not exist.
> [INFO] [WARNING] The requested profile "local-properties" could not be
> activated because it does not exist.
> [INFO] [WARNING] The requested profile "exo-private" could not be activated
> because it does not exist.
> [INFO] [WARNING] The requested profile "exo-staging" could not be activated
> because it does not exist.
> [INFO] [ERROR] Failed to execute goal
> com.mycila.maven-license-plugin:maven-license-plugin:1.9.0:check
> (check-headers) on project cloud-management-parent: Execution check-headers
> of goal com.mycila.maven-license-plugin:maven-license-plugin:1.9.0:check
> failed: Plugin com.mycila.maven-license-plugin:maven-license-plugin:1.9.0 or
> one of its dependencies could not be resolved: Failure to find
> org.exoplatform.cloud-management:cloud-build-tools:jar:0.1-M1 in
> http://repository.exoplatform.org/public was cached in the local repository,
> resolution will not be reattempted until the update interval of exo-fr-mirror
> has elapsed or updates are forced -> [Help 1]
> [INFO] [ERROR]
> [INFO] [ERROR] To see the full stack trace of the errors, re-run Maven with
> the -e switch.
> [INFO] [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [INFO] [ERROR]
> [INFO] [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [INFO] [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] eXo Cloud Management :: Parent FAILURE [5.210s]
> ...
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
> -
[jira] (MRRESOURCES-55) Support groupId:artifactId:version:type and groupId:artifactId:version:type:classifier as resource bundle references
[ https://jira.codehaus.org/browse/MRRESOURCES-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287847#comment-287847 ] Robert Scholte commented on MRRESOURCES-55: --- I've just checked the downloader and it looks to me this project is as good as dead: Latest release was 2006. I don't think this shared component really adds something. So I'm considering to move that part of the code to this plugin. > Support groupId:artifactId:version:type and > groupId:artifactId:version:type:classifier as resource bundle references > > > Key: MRRESOURCES-55 > URL: https://jira.codehaus.org/browse/MRRESOURCES-55 > Project: Maven 2.x Remote Resources Plugin > Issue Type: New Feature >Affects Versions: 1.2 >Reporter: Andrew Phillips >Assignee: Robert Scholte > Attachments: MRRESOURCES-55-preserve-original-codepath-patch.txt, > MRRESOURCES-55-remote-resources-patch.txt > > > Currently, the RR plugin only support groupId:artifactId:version as an > identifier for a remote bundle. However, there are quite a few use cases > (e.g. platform-specific bundles) where it would be very useful to be able to > identify bundles additionally by classifier. The current workaround we use - > different versions - works, but isn't particularly elegant or semantically > accurate. > The proposal therefore is to also allow identifiers of the type > groupId:artifactId:version:type:classifier > As Brett pointed out in an IRC chat, this automatically adds the type to the > identifier as well. One could ignore it or enforce 'jar' (the current > default), but on the other hand there seems to be no reason *not* to allow > types such as 'zip', or even 'war' or 'ear'. Only 'pom' doesn't make much > sense. > Two potential implementations, with tests, are attached. -- 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] (MRRESOURCES-55) Support groupId:artifactId:version:type and groupId:artifactId:version:type:classifier as resource bundle references
[ https://jira.codehaus.org/browse/MRRESOURCES-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287848#comment-287848 ] Andrew Phillips commented on MRRESOURCES-55: Thanks for the update, Robert. Good luck ;-) > Support groupId:artifactId:version:type and > groupId:artifactId:version:type:classifier as resource bundle references > > > Key: MRRESOURCES-55 > URL: https://jira.codehaus.org/browse/MRRESOURCES-55 > Project: Maven 2.x Remote Resources Plugin > Issue Type: New Feature >Affects Versions: 1.2 >Reporter: Andrew Phillips >Assignee: Robert Scholte > Attachments: MRRESOURCES-55-preserve-original-codepath-patch.txt, > MRRESOURCES-55-remote-resources-patch.txt > > > Currently, the RR plugin only support groupId:artifactId:version as an > identifier for a remote bundle. However, there are quite a few use cases > (e.g. platform-specific bundles) where it would be very useful to be able to > identify bundles additionally by classifier. The current workaround we use - > different versions - works, but isn't particularly elegant or semantically > accurate. > The proposal therefore is to also allow identifiers of the type > groupId:artifactId:version:type:classifier > As Brett pointed out in an IRC chat, this automatically adds the type to the > identifier as well. One could ignore it or enforce 'jar' (the current > default), but on the other hand there seems to be no reason *not* to allow > types such as 'zip', or even 'war' or 'ear'. Only 'pom' doesn't make much > sense. > Two potential implementations, with tests, are attached. -- 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] (MRRESOURCES-55) Support groupId:artifactId:version:type and groupId:artifactId:version:type:classifier as resource bundle references
[ https://jira.codehaus.org/browse/MRRESOURCES-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRRESOURCES-55. - Resolution: Fixed Fix Version/s: 1.3 Fixed in [rev. 1229389|http://svn.apache.org/viewvc?rev=1229389&view=rev], SNAPSHOT deployed, please verify. > Support groupId:artifactId:version:type and > groupId:artifactId:version:type:classifier as resource bundle references > > > Key: MRRESOURCES-55 > URL: https://jira.codehaus.org/browse/MRRESOURCES-55 > Project: Maven 2.x Remote Resources Plugin > Issue Type: New Feature >Affects Versions: 1.2 >Reporter: Andrew Phillips >Assignee: Robert Scholte > Fix For: 1.3 > > Attachments: MRRESOURCES-55-preserve-original-codepath-patch.txt, > MRRESOURCES-55-remote-resources-patch.txt > > > Currently, the RR plugin only support groupId:artifactId:version as an > identifier for a remote bundle. However, there are quite a few use cases > (e.g. platform-specific bundles) where it would be very useful to be able to > identify bundles additionally by classifier. The current workaround we use - > different versions - works, but isn't particularly elegant or semantically > accurate. > The proposal therefore is to also allow identifiers of the type > groupId:artifactId:version:type:classifier > As Brett pointed out in an IRC chat, this automatically adds the type to the > identifier as well. One could ignore it or enforce 'jar' (the current > default), but on the other hand there seems to be no reason *not* to allow > types such as 'zip', or even 'war' or 'ear'. Only 'pom' doesn't make much > sense. > Two potential implementations, with tests, are attached. -- 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] (MRRESOURCES-56) The maven-remote-resources-plugin (1.2.1) fails to create a usable Resource Bundle if the outputDirectory configuration parameter is specified and does not explicitly contain $
[
https://jira.codehaus.org/browse/MRRESOURCES-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRRESOURCES-56:
--
Description:
Issue:
The maven-remote-resources-plugin (1.2.1) fails to create a usable Resource
Bundle if the outputDirectory configuration parameter is specified and does not
explicitly contain ${project.build.outputDirectory} - this makes
${project.build.outputDirectory} the only viable configuration.
The documentation for the remote-resources:bundle goal: (see:
http://maven.apache.org/plugins/maven-remote-resources-plugin/bundle-mojo.html#outputDirectory)
states:
outputDirectory:
The directory where you want the resource bundle manifest written to.
Type: java.io.File
Required: No
Expression: ${project.build.outputDirectory}
Reproduction the issue:
With this initial POM:
{code:xml}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
4.0.0
org.gteley
test
0.0.1-SNAPSHOT
maven-remote-resources-plugin
1.2.1
bundle
**/database*
{code}
With this project directory structure:
{noformat}
test/
|
+src/
|
+ main/
|
+ resources
|
`database.ddl
`database.sql
{noformat}
Execute this command: mvn clean package to obtain this good result:
{noformat}
test/
|
+src/
|
+target/
|
+test-0.0.1-SNAPSHOT.jar/
|
`database.ddl
`database.sql
|
+ META-INF\
|
` MANIFEST.MF
|
+ maven
|
` remote-resources.xml
|
+ org.gteley/
|
`pom.properties
`pom.xml
|
+ classes/
|
`database.ddl
`database.sql
|
+ META-INF\
|
+ maven
|
` remote-resources.xml
|
+ maven-archiver/
|
` pom.properties
|
+ maven-shared-archive-resources/
+ test-classes/
{noformat}
Everything is fine, the contents of the Resource Bundle
(test-0.0.1-SNAPSHOT.jar) are as required and expected for subsequent
consumption by the remote-resource:process goal..
Now, amend the POM to explicitly specify the default value for the
outputDirectory parameter:
(...)
**/database*
${project.build.outputDirectory}
(...)
Execute this command again: mvn clean package to obtain the same good result.
OK far, now amend the POM to explicitly specify an alternative value
(${project.build.directory}) for the outputDirectory parameter:
(...)
**/database*
${project.build.directory}
(...)
The result below now reveals the issue, the Resource Bundle
(test-0.0.1-SNAPSHOT.jar) is created, but without the necessary
META-INF/maven/remote-resources.xml file:
test/
|
|
+ META-INF\
|
` MANIFEST.MF
|
+ maven
|
` remote-resources.xml
|
+ org.gteley/
|
`pom.properties
`pom.xml
|
+src/
|
+target/
|
+test-0.0.1-SNAPSHOT.jar/
|
`database.ddl
`database.sql
|
+ classes/
|
`database.ddl
`database.sql
|
+ maven-archiver/
|
` pom.properties
|
+ maven-shared-archive-resources/
+ test-classes/
By specifying ${project.build.directory} the
META-INF/maven/remote-resources.xml file lies at the same directory level as
the src and target directories (as expected) - but the Resource Bundle
(test-0.0.1-SNAPSHOT.jar) does not now contain the
META-INF/maven/remote-resources.xml file rendering useless for subsequent
processing by the remote-resource:process goal:
Another way to also render the Bundled Resource useless for processing by the
remote-resource:process goal is to append a subdirectory to the valid
${project.build.outputDirectory} configuration.
Amend the POM again this time specify an additional subdirectory to the
${project.build.outputDirectory} configuration of the outputDirectory parameter
like this:
(...)
**/database*
${project.build.outputDirectory}/somedirectory
(...)
Execute this command: mvn clean package to obtain this bad result:
test/
|
+src/
|
+target/
|
+test-0.0.1-SNAPSHOT.jar/
|
`database.ddl
`database.sql
|
+ somedirectory
|
+ META-INF\
|
` MANIFEST.MF
[jira] (MRRESOURCES-56) The maven-remote-resources-plugin (1.2.1) fails to create a usable Resource Bundle if the outputDirectory configuration parameter is specified and does not explicitly contain $
[
https://jira.codehaus.org/browse/MRRESOURCES-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287860#comment-287860
]
Robert Scholte edited comment on MRRESOURCES-56 at 1/9/12 5:01 PM:
---
I've added some formatting, but there seems to be a bug:
Where you read {noformat}$\{project.build.outputDirectory}{noformat}
you should actually read ${project.build.outputDirectory}
was (Author: rfscholte):
I've added some formatting, but there seems to be a bug:
Where you read $\\{project.build.outputDirectory}
you should actually read ${project.build.outputDirectory}
> The maven-remote-resources-plugin (1.2.1) fails to create a usable Resource
> Bundle if the outputDirectory configuration parameter is specified and does
> not explicitly contain ${project.build.outputDirectory}
> ---
>
> Key: MRRESOURCES-56
> URL: https://jira.codehaus.org/browse/MRRESOURCES-56
> Project: Maven 2.x Remote Resources Plugin
> Issue Type: Bug
>Affects Versions: 1.2.1
> Environment: Window XP, Java 1.6
>Reporter: Gareth Tudor Eley
> Attachments: test.zip
>
>
> Issue:
> The maven-remote-resources-plugin (1.2.1) fails to create a usable Resource
> Bundle if the outputDirectory configuration parameter is specified and does
> not explicitly contain ${project.build.outputDirectory} - this makes
> ${project.build.outputDirectory} the only viable configuration.
> The documentation for the remote-resources:bundle goal: (see:
> http://maven.apache.org/plugins/maven-remote-resources-plugin/bundle-mojo.html#outputDirectory)
> states:
> outputDirectory:
> The directory where you want the resource bundle manifest written to.
> Type: java.io.File
> Required: No
> Expression: ${project.build.outputDirectory}
> Reproduction the issue:
> With this initial POM:
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> org.gteley
> test
> 0.0.1-SNAPSHOT
>
>
>
> maven-remote-resources-plugin
> 1.2.1
>
>
>
> bundle
>
>
>
>
>
> **/database*
>
>
>
>
>
>
> {code}
> With this project directory structure:
> {noformat}
> test/
> |
> +src/
> |
> + main/
> |
> + resources
> |
> `database.ddl
> `database.sql
> {noformat}
> Execute this command: mvn clean package to obtain this good result:
> {noformat}
> test/
> |
> +src/
> |
> +target/
> |
> +test-0.0.1-SNAPSHOT.jar/
> |
> `database.ddl
> `database.sql
> |
> + META-INF\
> |
> ` MANIFEST.MF
> |
> + maven
> |
> ` remote-resources.xml
> |
> + org.gteley/
> |
> `pom.properties
> `pom.xml
> |
> + classes/
> |
> `database.ddl
> `database.sql
> |
> + META-INF\
> |
> + maven
> |
> ` remote-resources.xml
> |
> + maven-archiver/
> |
> ` pom.properties
> |
> + maven-shared-archive-resources/
> + test-classes/
> {noformat}
> Everything is fine, the contents of the Resource Bundle
> (test-0.0.1-SNAPSHOT.jar) are as required and expected for subsequent
> consumption by the remote-resource:process goal..
> Now, amend the POM to explicitly specify the default value for the
> outputDirectory parameter:
> {code:xml}
> (...)
>
>
> **/database*
>
>
> $\{project.build.outputDirectory}
>
>
> (...)
> {code}
> Execute this command again: mvn clean package to obtain the same good result.
> OK far, now amend the POM to explicitly specify an alternative value
> (${project.build.directory}) for the outputDirectory parameter:
> {code:xml}
>
>
> **/database*
>
>
> $\{project.build.directory}
>
>
> {code}
> The result below now reveals the issue, the Resource Bundle
> (test-0.0.1-SNAPSHOT.jar) is created, but without the necessary
> META-INF/maven/remote-resources.xml file:
> {noformat}
> test/
> |
> |
> + META-INF\
> |
> ` MANIFEST.MF
> |
> + maven
> |
> ` remote-resources.xml
> |
> + org.gt
[jira] (MRRESOURCES-56) The maven-remote-resources-plugin (1.2.1) fails to create a usable Resource Bundle if the outputDirectory configuration parameter is specified and does not explicitly contain $
[
https://jira.codehaus.org/browse/MRRESOURCES-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRRESOURCES-56:
--
Description:
Issue:
The maven-remote-resources-plugin (1.2.1) fails to create a usable Resource
Bundle if the outputDirectory configuration parameter is specified and does not
explicitly contain ${project.build.outputDirectory} - this makes
${project.build.outputDirectory} the only viable configuration.
The documentation for the remote-resources:bundle goal: (see:
http://maven.apache.org/plugins/maven-remote-resources-plugin/bundle-mojo.html#outputDirectory)
states:
outputDirectory:
The directory where you want the resource bundle manifest written to.
Type: java.io.File
Required: No
Expression: ${project.build.outputDirectory}
Reproduction the issue:
With this initial POM:
{code:xml}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
4.0.0
org.gteley
test
0.0.1-SNAPSHOT
maven-remote-resources-plugin
1.2.1
bundle
**/database*
{code}
With this project directory structure:
{noformat}
test/
|
+src/
|
+ main/
|
+ resources
|
`database.ddl
`database.sql
{noformat}
Execute this command: mvn clean package to obtain this good result:
{noformat}
test/
|
+src/
|
+target/
|
+test-0.0.1-SNAPSHOT.jar/
|
`database.ddl
`database.sql
|
+ META-INF\
|
` MANIFEST.MF
|
+ maven
|
` remote-resources.xml
|
+ org.gteley/
|
`pom.properties
`pom.xml
|
+ classes/
|
`database.ddl
`database.sql
|
+ META-INF\
|
+ maven
|
` remote-resources.xml
|
+ maven-archiver/
|
` pom.properties
|
+ maven-shared-archive-resources/
+ test-classes/
{noformat}
Everything is fine, the contents of the Resource Bundle
(test-0.0.1-SNAPSHOT.jar) are as required and expected for subsequent
consumption by the remote-resource:process goal..
Now, amend the POM to explicitly specify the default value for the
outputDirectory parameter:
{code:xml}
(...)
**/database*
$\{project.build.outputDirectory}
(...)
{code}
Execute this command again: mvn clean package to obtain the same good result.
OK far, now amend the POM to explicitly specify an alternative value
(${project.build.directory}) for the outputDirectory parameter:
{code:xml}
**/database*
$\{project.build.directory}
{code}
The result below now reveals the issue, the Resource Bundle
(test-0.0.1-SNAPSHOT.jar) is created, but without the necessary
META-INF/maven/remote-resources.xml file:
{noformat}
test/
|
|
+ META-INF\
|
` MANIFEST.MF
|
+ maven
|
` remote-resources.xml
|
+ org.gteley/
|
`pom.properties
`pom.xml
|
+src/
|
+target/
|
+test-0.0.1-SNAPSHOT.jar/
|
`database.ddl
`database.sql
|
+ classes/
|
`database.ddl
`database.sql
|
+ maven-archiver/
|
` pom.properties
|
+ maven-shared-archive-resources/
+ test-classes/
{noformat}
By specifying ${project.build.directory} the
META-INF/maven/remote-resources.xml file lies at the same directory level as
the src and target directories (as expected) - but the Resource Bundle
(test-0.0.1-SNAPSHOT.jar) does not now contain the
META-INF/maven/remote-resources.xml file rendering useless for subsequent
processing by the remote-resource:process goal:
Another way to also render the Bundled Resource useless for processing by the
remote-resource:process goal is to append a subdirectory to the valid
${project.build.outputDirectory} configuration.
Amend the POM again this time specify an additional subdirectory to the
${project.build.outputDirectory} configuration of the outputDirectory parameter
like this:
{code:xml}
(...)
**/database*
$\{project.build.outputDirectory}/somedirectory
(...)
{code}
Execute this command: mvn clean package to obtain this bad result:
{noformat}
test/
|
+src/
|
+target/
|
+test-0.0.1-SNAPSHOT.jar/
|
`database.ddl
`database.sql
|
+ somedirectory
|
