[jira] [Issue Comment Deleted] (SUREFIRE-1431) @{argLine} not replaced if undefined
[
https://issues.apache.org/jira/browse/SUREFIRE-1431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michal Domagala updated SUREFIRE-1431:
--
Comment: was deleted
(was: [~tibor17], could clarify your answer?
I understand that:
# I can setup argument line with *$*, but I have to know final settings before
I call Maven. It is problem because the settings is decided by jacoco plugin
during build
# To solve that issue *@* was introduced, but it fails without Jacoco plugin
As a solution I expect hint how to configure surefire to work without Jacoco
plugin but at the same time "consume" argLine produced by Jacoco (if jacoco
plugin is part of build)
)
> @{argLine} not replaced if undefined
>
>
> Key: SUREFIRE-1431
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1431
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.21.1
> Environment: Maven 3.5.0
>Reporter: Matthieu Fillon
>Assignee: Tibor Digana
> Attachments: maven.log
>
>
> I need to specify argLine for my tests. I also need it to work with Java
> agent Jacoco when a certain Maven profile is activated.
> So I added `@{argLine}` to my argLine property and it works fine when running
> with Jacoco agent activated.
> When running the tests without profile that activates Jacoco agent, the
> surefire plugin fails with following line (relevant maven logs attached) :
> {color:red}Error: Could not find or load main class @\{argLine} {color}
> I guess @{argLine} is only replaced if an argLine has been defined before by
> another plugin but if not it is not replaced at all.
> Should'nt it be replaced in any case and if none defined, just replace with
> empty value?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1431) @{argLine} not replaced if undefined
[
https://issues.apache.org/jira/browse/SUREFIRE-1431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202673#comment-16202673
]
Michal Domagala commented on SUREFIRE-1431:
---
[~tibor17], could clarify your answer?
I understand that:
# I can setup argument line with *$*, but I have to know final settings before
I call Maven. It is problem because the settings is decided by jacoco plugin
during build
# To solve that issue *@* was introduced, but it fails without Jacoco plugin
As a solution I expect hint how to configure surefire to work without Jacoco
plugin but at the same time "consume" argLine produced by Jacoco (if jacoco
plugin is part of build)
> @{argLine} not replaced if undefined
>
>
> Key: SUREFIRE-1431
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1431
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.21.1
> Environment: Maven 3.5.0
>Reporter: Matthieu Fillon
>Assignee: Tibor Digana
> Attachments: maven.log
>
>
> I need to specify argLine for my tests. I also need it to work with Java
> agent Jacoco when a certain Maven profile is activated.
> So I added `@{argLine}` to my argLine property and it works fine when running
> with Jacoco agent activated.
> When running the tests without profile that activates Jacoco agent, the
> surefire plugin fails with following line (relevant maven logs attached) :
> {color:red}Error: Could not find or load main class @\{argLine} {color}
> I guess @{argLine} is only replaced if an argLine has been defined before by
> another plugin but if not it is not replaced at all.
> Should'nt it be replaced in any case and if none defined, just replace with
> empty value?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-2802) Concurrent-safe access to local Maven repository
[ https://issues.apache.org/jira/browse/MNG-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199930#comment-16199930 ] Michal Domagala commented on MNG-2802: -- [~J-cztery] Local repository may be corrupted by Maven embedded with Eclipse etc. Takari extension is excellent but it is workaround only > Concurrent-safe access to local Maven repository > > > Key: MNG-2802 > URL: https://issues.apache.org/jira/browse/MNG-2802 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Stepan Roh >Assignee: John Casey > Fix For: Issues to be reviewed for 3.x > > > It seems that access to local Maven repository is not concurrent-safe that is > multiple Mavens running in parallel may damage contents of local Maven > repository. It would be a nice improvement, because sharing of local > repository will lower the need for contacting any other repository. I know > that Maven proxy can be used, but that adds another layer which may > unnecessarily stress the machine it runs on. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6204) Exception when parsing
[
https://issues.apache.org/jira/browse/MNG-6204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080028#comment-16080028
]
Michal Domagala commented on MNG-6204:
--
Fixed in plexus, see https://github.com/codehaus-plexus/plexus-utils/issues/22
> Exception when parsing
>
> Key: MNG-6204
> URL: https://issues.apache.org/jira/browse/MNG-6204
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap & Build
>Affects Versions: 3.3.9, 3.5.0-alpha-1, 3.5.0-beta-1
> Environment: Windows 7
>Reporter: Robert Kleinschmager
> Attachments: debug.log, pom.xml
>
>
> Parsing large pom.xml (>8kb), which contains * Steps
> ** use given !pom.xml!
> ** execute {{mvn validate}}
> * Expected
> ** pass
> * Actual
> ** {code}
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 10106
> at
> org.codehaus.plexus.util.xml.pull.MXParser.parsePI(MXParser.java:2502)
> {code}
> ** see !debug.log!
> * this is caused by [plexus-utils issue no
> 22|https://github.com/codehaus-plexus/plexus-utils/issues/22]
> ** PR must be merged
> [PR#23|https://github.com/codehaus-plexus/plexus-utils/pull/23]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1378) Nice to have systemPropertiesFile configurable by user property
[
https://issues.apache.org/jira/browse/SUREFIRE-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16032703#comment-16032703
]
Michal Domagala commented on SUREFIRE-1378:
---
SUREFIRE-1365 is similar but different. My issue refers to Java system
property, SUREFIRE-1365 to OS environment variable.
I'm new to Java interface in pom.xml. If you give me a link to piece of
documentation I will check if this will solve my problem.
(But my commit solves the problem here and now)
> Nice to have systemPropertiesFile configurable by user property
> ---
>
> Key: SUREFIRE-1378
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1378
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Reporter: Michal Domagala
>Priority: Minor
>
> I would like to have option to configure my tests with property files. But
> property file is not required, because in 95% my tests work fine with default
> configuration.
> I used the following workaround: I configured failsafe plugin in the
> following way
> {code:xml}
>
>
>
> (...)
> maven-failsafe-plugin
> (...)
> ${my.test.props.file}
> {code}
> In 95% I call *mvn verify*, systemPropertiesFile is not found and ignored
> -all pass
> In 5% I call *mvn verify -Dmy.test.props.file=x.props*
> The problem is in 95% I get warning about missing files. Also configuration
> is unnecessary complicated
> I would like drop whole connfiguration from pom.xml and use:
> In 95% *mvn verify*
> In 5% *mvn verify -Dfailsafe.systemPropertiesFile=x.props*
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (SUREFIRE-1378) Nice to have systemPropertiesFile configurable by user property
Michal Domagala created SUREFIRE-1378:
-
Summary: Nice to have systemPropertiesFile configurable by user
property
Key: SUREFIRE-1378
URL: https://issues.apache.org/jira/browse/SUREFIRE-1378
Project: Maven Surefire
Issue Type: Improvement
Components: Maven Failsafe Plugin, Maven Surefire Plugin
Reporter: Michal Domagala
Priority: Minor
I would like to have option to configure my tests with property files. But
property file is not required, because in 95% my tests work fine with default
configuration.
I used the following workaround: I configured failsafe plugin in the following
way
{code:xml}
(...)
maven-failsafe-plugin
(...)
${my.test.props.file}
{code}
In 95% I call *mvn verify*, systemPropertiesFile is not found and ignored -all
pass
In 5% I call *mvn verify -Dmy.test.props.file=x.props*
The problem is in 95% I get warning about missing files. Also configuration is
unnecessary complicated
I would like drop whole connfiguration from pom.xml and use:
In 95% *mvn verify*
In 5% *mvn verify -Dfailsafe.systemPropertiesFile=x.props*
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (MWAR-257) Remove deprecation of dependentWarExcludes, since there is no alternative on global level
[
https://issues.apache.org/jira/browse/MWAR-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15763729#comment-15763729
]
Michal Domagala edited comment on MWAR-257 at 12/20/16 9:38 AM:
Global level dependentWarExcludes/Includes are very useful and should be
restored.
Global exclusion of {{WEB-INB/lib/*.jar}} is simple solution to problem
[MWAR-33| https://issues.apache.org/jira/browse/MWAR-33] (jars with differents
versions can be in WEB-INF/lib with war as dependencies)
Unfortunately, commit https://fisheye6.atlassian.com/changelog/maven?cs=606628
for https://issues.apache.org/jira/browse/MWAR-118 marked
{{dependentWarExcludes}} deprecated. I read issue description and I don't know
why it is deprecated. I think it was mistake or under analyzed change.
Finally, in maven-war-plugin version 3.0.0 {{dependentWarExcludes}} is
removed. It has dramatic impact on my application, which heavy use WAR
customization implemented by war-extending-war.
My current setup for maven-war-plugin version 2.6 is global
{{dependentWarExcludes=WEB-INF/lib/*.jar}} and multiple WAR projects (for
particular clients) depending on parent WARs. Just dependency, nothing more.
If I switch to 3.0.0, I have to remove global {{dependentWarExcludes}} and for
each WAR project, beside dependency to parent WAR add section {{overlays}},
copy dependency data and add
{{WEB-INF/lib/*.jar}}
I expect answer like:
1. It is stupid to have global configuration in root, better copy the same
settings into multiple child projects. (I will know I have to stay with 2.6)
2. It is cool to have global configuration, keep calm and wait for newer maven
war plugin
was (Author: michaldo):
Global level dependentWarExcludes/Includes are very useful and should be
restored.
That will be a long story...
Global exclusion of {{WEB-INB/lib/*.jar}} is simple solution to solve problem
[MWAR-33| https://issues.apache.org/jira/browse/MWAR-33] (jars with differents
versions can be in WEB-INF/lib with war as dependencies)
Unfortunately, commit https://fisheye6.atlassian.com/changelog/maven?cs=606628
for https://issues.apache.org/jira/browse/MWAR-118 marked
{{dependentWarExcludes}} deprecated. I read issue description and I don't know
why it is deprecated. I expected it was mistake or under analyzed change.
> Remove deprecation of dependentWarExcludes, since there is no alternative on
> global level
> -
>
> Key: MWAR-257
> URL: https://issues.apache.org/jira/browse/MWAR-257
> Project: Maven WAR Plugin
> Issue Type: Bug
> Components: overlay
>Affects Versions: 2.1.1
>Reporter: dool
>Assignee: Michael Osipov
> Fix For: 3.1.0
>
>
> Hello,
> DependentWarExcludes is marked as deprecated. Documentation says to use
> / instead.
> But it seems to me that it is not possible to get the same behaviour with
> / as in this case we have to provide groupIds and
> artifactIds.
> Maybe this behaviour could be reproduced when setting both groupId and
> artifactId to * as below :
>
>
>
> *
> *
> **/*
>
>
>
>
> By the way, I found this, by looking for a way to disable overlay. The
> workaround I thought was configuring your plugin to exclude every files when
> overlaying.
> I think it would be nice to have a configuration parameter for that.
> Many thanks,
> Dool
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MWAR-257) Remove deprecation of dependentWarExcludes, since there is no alternative on global level
[
https://issues.apache.org/jira/browse/MWAR-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15763729#comment-15763729
]
Michal Domagala commented on MWAR-257:
--
Global level dependentWarExcludes/Includes are very useful and should be
restored.
That will be a long story...
Global exclusion of {{WEB-INB/lib/*.jar}} is simple solution to solve problem
[MWAR-33| https://issues.apache.org/jira/browse/MWAR-33] (jars with differents
versions can be in WEB-INF/lib with war as dependencies)
Unfortunately, commit https://fisheye6.atlassian.com/changelog/maven?cs=606628
for https://issues.apache.org/jira/browse/MWAR-118 marked
{{dependentWarExcludes}} deprecated. I read issue description and I don't know
why it is deprecated. I expected it was mistake or under analyzed change.
> Remove deprecation of dependentWarExcludes, since there is no alternative on
> global level
> -
>
> Key: MWAR-257
> URL: https://issues.apache.org/jira/browse/MWAR-257
> Project: Maven WAR Plugin
> Issue Type: Bug
> Components: overlay
>Affects Versions: 2.1.1
>Reporter: dool
>
> Hello,
> DependentWarExcludes is marked as deprecated. Documentation says to use
> / instead.
> But it seems to me that it is not possible to get the same behaviour with
> / as in this case we have to provide groupIds and
> artifactIds.
> Maybe this behaviour could be reproduced when setting both groupId and
> artifactId to * as below :
>
>
>
> *
> *
> **/*
>
>
>
>
> By the way, I found this, by looking for a way to disable overlay. The
> workaround I thought was configuring your plugin to exclude every files when
> overlaying.
> I think it would be nice to have a configuration parameter for that.
> Many thanks,
> Dool
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MWAR-360) Overlay: ignore WAR which is transitively dependent over JAR
[
https://issues.apache.org/jira/browse/MWAR-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15757820#comment-15757820
]
Michal Domagala commented on MWAR-360:
--
The current issue has not only performance impact, but it is also logical defect
Assume I have 3 WARs, war1, war2, war3. Each WAR applies
{{true}}.
war1 has a file {{x.html}}.
war2 depends on war1 and excludes file {{x.html}}
war3 depends on war2 and war2-classes
Expected: war3 does not contain {{x.html}}, actual: war3 contains {{x.html}}
> Overlay: ignore WAR which is transitively dependent over JAR
>
>
> Key: MWAR-360
> URL: https://issues.apache.org/jira/browse/MWAR-360
> Project: Maven WAR Plugin
> Issue Type: Improvement
>Reporter: Michal Domagala
>Priority: Minor
>
> Example:
> I have WAR project 'Base' with class A.
> I have WAR project 'Level1' which is depends on 'Base'. 'Level1' has class B
> extends A.
> Then 'Base' must have true
> Finally, I have WAR project 'Level2' with class C extends B. For the same
> reason 'Level1' must have true
> Expected: when Level2 WAR is build, only Level1 WAR is overlayed, because
> Level1 contains Base
> Actual: Level1 and Base are overlayed together. That wastes time.
> {noformat}
> [INFO] Copying webapp resources [mwar/Level2/src/main/webapp]
> [INFO] Processing overlay [ id mwar:Level1]
> [INFO] Processing overlay [ id Base:Base]
> [INFO] Webapp assembled in [26 msecs]
> {noformat}
> Reason: Level1 classes JAR has dependency to Base WAR, but that dependency is
> "fake"
> {noformat}
> [INFO] mwar:Level2:war:0.0.1-SNAPSHOT
> [INFO] +- mwar:Level1:war:0.0.1-SNAPSHOT:compile
> [INFO] \- mwar:Level1:jar:classes:0.0.1-SNAPSHOT:compile
> [INFO]+- Base:Base:war:0.0.1-SNAPSHOT:compile
> [INFO]\- Base:Base:jar:classes:0.0.1-SNAPSHOT:compile
> {noformat}
> Proposed solution: There should be option 'notOverlayTransitiveWar' which
> allow exclude WARs like 'Base' from overlaying, because the transitive WAR
> may be reached only over JAR and I think there is no reason any JAR really
> depends on WAR.
> Workaround is manually define ovelays in plugin configuration, but Maven
> spirit is Convention over Configuration
> h2. example
> # git clone https://github.com/michaldo/mwar360.git
> # cd mwar360
> # mvn package
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1288) systemProperties should not be deprecated
[
https://issues.apache.org/jira/browse/SUREFIRE-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15544673#comment-15544673
]
Michal Domagala commented on SUREFIRE-1288:
---
Let say my integration test use surefire and needs 10 system variables. My
parent pom keeps default configuration. Let say I have 2 different environments
which needs modify 5 out of 10 variables.
If my parent pom keeps default configuration in {{systemProperties}}, I can
define correct properties per environment in file and pass to execution as
{{systemPropertiesFile}}
But If I have default configuration in {{systemPropertyVariables}}, I cannot
override them with file. I have to pass each modified variable in command line
If I have third environment which needs to modify 3 out of 10 variables, I need
to prepare different execution command
Summary:
Using {{systemProperties}} I can share common execution command ({{mvn test
-Dmy.file=abc.properties}}) and modify configuration file per environment
Using {{systemPropertyVariables}} I need different execution command per
environment
> systemProperties should not be deprecated
> --
>
> Key: SUREFIRE-1288
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1288
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Michal Domagala
>
> Current property precedence is: (higher number=more important)
> 1. systemProperties
> 2. systemPropertiesFile
> 3. systemPropertyVariables
> systemPropertyVariables is not replacement for systemProperties because
> meaning is different.
> For me systemProperties are more useful, because I can define default values
> in pom.xml and optionally override them in runtime by configuration file.
> systemPropertyVariables are not useful because can be overriden only by
> command line arguments. Commandline is not friendly if several properties
> must be modified
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SUREFIRE-1288) systemProperties should not be deprecated
Michal Domagala created SUREFIRE-1288: - Summary: systemProperties should not be deprecated Key: SUREFIRE-1288 URL: https://issues.apache.org/jira/browse/SUREFIRE-1288 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Affects Versions: 2.19.1 Reporter: Michal Domagala Current property precedence is: (higher number=more important) 1. systemProperties 2. systemPropertiesFile 3. systemPropertyVariables systemPropertyVariables is not replacement for systemProperties because meaning is different. For me systemProperties are more useful, because I can define default values in pom.xml and optionally override them in runtime by configuration file. systemPropertyVariables are not useful because can be overriden only by command line arguments. Commandline is not friendly if several properties must be modified -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MWAR-371) Overlays break first-win rule for web resource with target path ending with '/'
[
https://issues.apache.org/jira/browse/MWAR-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michal Domagala updated MWAR-371:
-
Description:
I have WAR 'generic' containing 2 files: x/a1.txt and x/a2.txt
I have WAR 'custom' with two source files: src/main/custom/a1.txt and
src/main/custom/a2.txt and settings:
{code:xml}
maven-war-plugin
src/main/custom
a1.txt
x/
src/main/custom
a2.txt
x
{code}
Note that *targetPath* is different: *x/* vs *x*
When I build WAR 'custom'
Actual: a1.txt is generic, a2.txt is custom
Expected a1.txt and a2.txt are custom
was:
I have WAR 'generic' containing 2 files: x/a1.txt and x/a2.txt
I have WAR 'custom' with two source files: src/main/custom/a1.txt and
src/main/custom/a1.txt and settings:
{code:xml}
maven-war-plugin
src/main/custom
a1.txt
x/
src/main/custom
a2.txt
x
{code}
Note that *targetPath* is different: *x/* vs *x*
When I build WAR 'custom'
Actual: a1.txt is generic, a2.txt is custom
Expected a1.txt and a2.txt are custom
> Overlays break first-win rule for web resource with target path ending with
> '/'
> ---
>
> Key: MWAR-371
> URL: https://issues.apache.org/jira/browse/MWAR-371
> Project: Maven WAR Plugin
> Issue Type: Bug
> Components: overlay
>Affects Versions: 2.6
>Reporter: Michal Domagala
>Priority: Minor
>
> I have WAR 'generic' containing 2 files: x/a1.txt and x/a2.txt
> I have WAR 'custom' with two source files: src/main/custom/a1.txt and
> src/main/custom/a2.txt and settings:
> {code:xml}
> maven-war-plugin
>
>
>
> src/main/custom
> a1.txt
> x/
>
>
> src/main/custom
> a2.txt
> x
>
>
>
> {code}
> Note that *targetPath* is different: *x/* vs *x*
> When I build WAR 'custom'
> Actual: a1.txt is generic, a2.txt is custom
> Expected a1.txt and a2.txt are custom
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MWAR-371) Overlays break first-win rule for web resource with target path ending with '/'
[
https://issues.apache.org/jira/browse/MWAR-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15239088#comment-15239088
]
Michal Domagala commented on MWAR-371:
--
Example: https://github.com/michaldo/mwar371
Call mvn package and inspect WAR 'custom'
> Overlays break first-win rule for web resource with target path ending with
> '/'
> ---
>
> Key: MWAR-371
> URL: https://issues.apache.org/jira/browse/MWAR-371
> Project: Maven WAR Plugin
> Issue Type: Bug
> Components: overlay
>Affects Versions: 2.6
>Reporter: Michal Domagala
>Priority: Minor
>
> I have WAR 'generic' containing 2 files: x/a1.txt and x/a2.txt
> I have WAR 'custom' with two source files: src/main/custom/a1.txt and
> src/main/custom/a1.txt and settings:
> {code:xml}
> maven-war-plugin
>
>
>
> src/main/custom
> a1.txt
> x/
>
>
> src/main/custom
> a2.txt
> x
>
>
>
> {code}
> Note that *targetPath* is different: *x/* vs *x*
> When I build WAR 'custom'
> Actual: a1.txt is generic, a2.txt is custom
> Expected a1.txt and a2.txt are custom
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MWAR-371) Overlays break first-win rule for web resource with target path ending with '/'
[
https://issues.apache.org/jira/browse/MWAR-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michal Domagala updated MWAR-371:
-
Priority: Minor (was: Major)
> Overlays break first-win rule for web resource with target path ending with
> '/'
> ---
>
> Key: MWAR-371
> URL: https://issues.apache.org/jira/browse/MWAR-371
> Project: Maven WAR Plugin
> Issue Type: Bug
> Components: overlay
>Affects Versions: 2.6
>Reporter: Michal Domagala
>Priority: Minor
>
> I have WAR 'generic' containing 2 files: x/a1.txt and x/a2.txt
> I have WAR 'custom' with two source files: src/main/custom/a1.txt and
> src/main/custom/a1.txt and settings:
> {code:xml}
> maven-war-plugin
>
>
>
> src/main/custom
> a1.txt
> x/
>
>
> src/main/custom
> a2.txt
> x
>
>
>
> {code}
> Note that **targetPath** is different: **x/** vs **x**
> When I build WAR 'custom'
> Actual: a1.txt is generic, a2.txt is custom
> Expected a1.txt and a2.txt are custom
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MWAR-371) Overlays break first-win rule for web resource with target path ending with '/'
[
https://issues.apache.org/jira/browse/MWAR-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michal Domagala updated MWAR-371:
-
Description:
I have WAR 'generic' containing 2 files: x/a1.txt and x/a2.txt
I have WAR 'custom' with two source files: src/main/custom/a1.txt and
src/main/custom/a1.txt and settings:
{code:xml}
maven-war-plugin
src/main/custom
a1.txt
x/
src/main/custom
a2.txt
x
{code}
Note that *targetPath* is different: *x/* vs *x*
When I build WAR 'custom'
Actual: a1.txt is generic, a2.txt is custom
Expected a1.txt and a2.txt are custom
was:
I have WAR 'generic' containing 2 files: x/a1.txt and x/a2.txt
I have WAR 'custom' with two source files: src/main/custom/a1.txt and
src/main/custom/a1.txt and settings:
{code:xml}
maven-war-plugin
src/main/custom
a1.txt
x/
src/main/custom
a2.txt
x
{code}
Note that **targetPath** is different: **x/** vs **x**
When I build WAR 'custom'
Actual: a1.txt is generic, a2.txt is custom
Expected a1.txt and a2.txt are custom
> Overlays break first-win rule for web resource with target path ending with
> '/'
> ---
>
> Key: MWAR-371
> URL: https://issues.apache.org/jira/browse/MWAR-371
> Project: Maven WAR Plugin
> Issue Type: Bug
> Components: overlay
>Affects Versions: 2.6
>Reporter: Michal Domagala
>Priority: Minor
>
> I have WAR 'generic' containing 2 files: x/a1.txt and x/a2.txt
> I have WAR 'custom' with two source files: src/main/custom/a1.txt and
> src/main/custom/a1.txt and settings:
> {code:xml}
> maven-war-plugin
>
>
>
> src/main/custom
> a1.txt
> x/
>
>
> src/main/custom
> a2.txt
> x
>
>
>
> {code}
> Note that *targetPath* is different: *x/* vs *x*
> When I build WAR 'custom'
> Actual: a1.txt is generic, a2.txt is custom
> Expected a1.txt and a2.txt are custom
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MWAR-371) Overlays break first-win rule for web resource with target path ending with '/'
Michal Domagala created MWAR-371:
Summary: Overlays break first-win rule for web resource with
target path ending with '/'
Key: MWAR-371
URL: https://issues.apache.org/jira/browse/MWAR-371
Project: Maven WAR Plugin
Issue Type: Bug
Components: overlay
Affects Versions: 2.6
Reporter: Michal Domagala
I have WAR 'generic' containing 2 files: x/a1.txt and x/a2.txt
I have WAR 'custom' with two source files: src/main/custom/a1.txt and
src/main/custom/a1.txt and settings:
{code:xml}
maven-war-plugin
src/main/custom
a1.txt
x/
src/main/custom
a2.txt
x
{code}
Note that **targetPath** is different: **x/** vs **x**
When I build WAR 'custom'
Actual: a1.txt is generic, a2.txt is custom
Expected a1.txt and a2.txt are custom
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MWAR-360) Overlay: ignore WAR which is transitively dependent over JAR
[
https://issues.apache.org/jira/browse/MWAR-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15158592#comment-15158592
]
Michal Domagala commented on MWAR-360:
--
I take a look on code and it seems to me that in
org.apache.maven.plugin.war.overlay.OverlayManager.getOverlaysAsArtifacts()
(https://github.com/apache/maven-plugins/blob/trunk/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/overlay/OverlayManager.java#L244)
line
{{final Set artifacts = project.getArtifacts();}}
should be replaced (conditionally) by
{{final Set artifacts = project.getDependencyArtifacts();}}
I don't see any usecase why transitive dependent WARs should be taken as
overlay, because they are already included in direct dependent WARs
> Overlay: ignore WAR which is transitively dependent over JAR
>
>
> Key: MWAR-360
> URL: https://issues.apache.org/jira/browse/MWAR-360
> Project: Maven WAR Plugin
> Issue Type: Improvement
>Reporter: Michal Domagala
>Priority: Minor
>
> Example:
> I have WAR project 'Base' with class A.
> I have WAR project 'Level1' which is depends on 'Base'. 'Level1' has class B
> extends A.
> Then 'Base' must have true
> Finally, I have WAR project 'Level2' with class C extends B. For the same
> reason 'Level1' must have true
> Expected: when Level2 WAR is build, only Level1 WAR is overlayed, because
> Level1 contains Base
> Actual: Level1 and Base are overlayed together. That wastes time.
> {noformat}
> [INFO] Copying webapp resources [mwar/Level2/src/main/webapp]
> [INFO] Processing overlay [ id mwar:Level1]
> [INFO] Processing overlay [ id Base:Base]
> [INFO] Webapp assembled in [26 msecs]
> {noformat}
> Reason: Level1 classes JAR has dependency to Base WAR, but that dependency is
> "fake"
> {noformat}
> [INFO] mwar:Level2:war:0.0.1-SNAPSHOT
> [INFO] +- mwar:Level1:war:0.0.1-SNAPSHOT:compile
> [INFO] \- mwar:Level1:jar:classes:0.0.1-SNAPSHOT:compile
> [INFO]+- Base:Base:war:0.0.1-SNAPSHOT:compile
> [INFO]\- Base:Base:jar:classes:0.0.1-SNAPSHOT:compile
> {noformat}
> Proposed solution: There should be option 'notOverlayTransitiveWar' which
> allow exclude WARs like 'Base' from overlaying, because the transitive WAR
> may be reached only over JAR and I think there is no reason any JAR really
> depends on WAR.
> Workaround is manually define ovelays in plugin configuration, but Maven
> spirit is Convention over Configuration
> h2. example
> # git clone https://github.com/michaldo/mwar360.git
> # cd mwar360
> # mvn package
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MWAR-360) Overlay: ignore WAR which is transitively dependent over JAR
[
https://issues.apache.org/jira/browse/MWAR-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15148409#comment-15148409
]
Michal Domagala commented on MWAR-360:
--
Hi Karl, I provided a full example. I hope my problem will be clear now
> Overlay: ignore WAR which is transitively dependent over JAR
>
>
> Key: MWAR-360
> URL: https://issues.apache.org/jira/browse/MWAR-360
> Project: Maven WAR Plugin
> Issue Type: Improvement
>Reporter: Michal Domagala
>Priority: Minor
>
> Example:
> I have WAR project 'Base' with class A.
> I have WAR project 'Level1' which is depends on 'Base'. 'Level1' has class B
> extends A.
> Then 'Base' must have true
> Finally, I have WAR project 'Level2' with class C extends B. For the same
> reason 'Level1' must have true
> Expected: when Level2 WAR is build, only Level1 WAR is overlayed, because
> Level1 contains Base
> Actual: Level1 and Base are overlayed together. That wastes time.
> {noformat}
> [INFO] Copying webapp resources [mwar/Level2/src/main/webapp]
> [INFO] Processing overlay [ id mwar:Level1]
> [INFO] Processing overlay [ id Base:Base]
> [INFO] Webapp assembled in [26 msecs]
> {noformat}
> Reason: Level1 classes JAR has dependency to Base WAR, but that dependency is
> "fake"
> {noformat}
> [INFO] mwar:Level2:war:0.0.1-SNAPSHOT
> [INFO] +- mwar:Level1:war:0.0.1-SNAPSHOT:compile
> [INFO] \- mwar:Level1:jar:classes:0.0.1-SNAPSHOT:compile
> [INFO]+- Base:Base:war:0.0.1-SNAPSHOT:compile
> [INFO]\- Base:Base:jar:classes:0.0.1-SNAPSHOT:compile
> {noformat}
> Proposed solution: There should be option 'notOverlayTransitiveWar' which
> allow exclude WARs like 'Base' from overlaying, because the transitive WAR
> may be reached only over JAR and I think there is no reason any JAR really
> depends on WAR.
> Workaround is manually define ovelays in plugin configuration, but Maven
> spirit is Convention over Configuration
> h2. example
> # git clone https://github.com/michaldo/mwar360.git
> # cd mwar360
> # mvn package
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MWAR-360) Overlay: ignore WAR which is transitively dependent over JAR
[
https://issues.apache.org/jira/browse/MWAR-360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michal Domagala updated MWAR-360:
-
Description:
Example:
I have WAR project 'Base' with class A.
I have WAR project 'Level1' which is depends on 'Base'. 'Level1' has class B
extends A.
Then 'Base' must have true
Finally, I have WAR project 'Level2' with class C extends B. For the same
reason 'Level1' must have true
Expected: when Level2 WAR is build, only Level1 WAR is overlayed, because
Level1 contains Base
Actual: Level1 and Base are overlayed together. That wastes time.
{noformat}
[INFO] Copying webapp resources [mwar/Level2/src/main/webapp]
[INFO] Processing overlay [ id mwar:Level1]
[INFO] Processing overlay [ id Base:Base]
[INFO] Webapp assembled in [26 msecs]
{noformat}
Reason: Level1 classes JAR has dependency to Base WAR, but that dependency is
"fake"
{noformat}
[INFO] mwar:Level2:war:0.0.1-SNAPSHOT
[INFO] +- mwar:Level1:war:0.0.1-SNAPSHOT:compile
[INFO] \- mwar:Level1:jar:classes:0.0.1-SNAPSHOT:compile
[INFO]+- Base:Base:war:0.0.1-SNAPSHOT:compile
[INFO]\- Base:Base:jar:classes:0.0.1-SNAPSHOT:compile
{noformat}
Proposed solution: There should be option 'notOverlayTransitiveWar' which allow
exclude WARs like 'Base' from overlaying, because the transitive WAR may be
reached only over JAR and I think there is no reason any JAR really depends on
WAR.
Workaround is manually define ovelays in plugin configuration, but Maven spirit
is Convention over Configuration
h2. example
# git clone https://github.com/michaldo/mwar360.git
# cd mwar360
# mvn package
was:
Example:
I have WAR project 'Base' with class A.
I have WAR project 'Level1' which is depends on 'Base'. 'Level1' has class B
extends A.
Then 'Base' must have true
Finally, I have WAR project 'Level2' with class C extends B. For the same
reason 'Level1' must have true
Expected: when Level2 WAR is build, only Level1 WAR is overlayed, because
Level1 contains Base
Actual: Level1 and Base are overlayed together. That wastes time.
{noformat}
[INFO] Copying webapp resources [mwar/Level2/src/main/webapp]
[INFO] Processing overlay [ id mwar:Level1]
[INFO] Processing overlay [ id Base:Base]
[INFO] Webapp assembled in [26 msecs]
{noformat}
Reason: Level1 classes JAR has dependency to Base WAR, but that dependency is
"fake"
{noformat}
[INFO] mwar:Level2:war:0.0.1-SNAPSHOT
[INFO] +- mwar:Level1:war:0.0.1-SNAPSHOT:compile
[INFO] \- mwar:Level1:jar:classes:0.0.1-SNAPSHOT:compile
[INFO]+- Base:Base:war:0.0.1-SNAPSHOT:compile
[INFO]\- Base:Base:jar:classes:0.0.1-SNAPSHOT:compile
{noformat}
Proposed solution: There should be option 'notOverlayTransitiveWar' which allow
exclude WARs like 'Base' from overlaying, because the transitive WAR may be
reached only over JAR and I think there is no reason any JAR really depends on
WAR.
Workaround is manually define ovelays in plugin configuration, but Maven spirit
is Convention over Configuration
> Overlay: ignore WAR which is transitively dependent over JAR
>
>
> Key: MWAR-360
> URL: https://issues.apache.org/jira/browse/MWAR-360
> Project: Maven WAR Plugin
> Issue Type: Improvement
>Reporter: Michal Domagala
>Priority: Minor
>
> Example:
> I have WAR project 'Base' with class A.
> I have WAR project 'Level1' which is depends on 'Base'. 'Level1' has class B
> extends A.
> Then 'Base' must have true
> Finally, I have WAR project 'Level2' with class C extends B. For the same
> reason 'Level1' must have true
> Expected: when Level2 WAR is build, only Level1 WAR is overlayed, because
> Level1 contains Base
> Actual: Level1 and Base are overlayed together. That wastes time.
> {noformat}
> [INFO] Copying webapp resources [mwar/Level2/src/main/webapp]
> [INFO] Processing overlay [ id mwar:Level1]
> [INFO] Processing overlay [ id Base:Base]
> [INFO] Webapp assembled in [26 msecs]
> {noformat}
> Reason: Level1 classes JAR has dependency to Base WAR, but that dependency is
> "fake"
> {noformat}
> [INFO] mwar:Level2:war:0.0.1-SNAPSHOT
> [INFO] +- mwar:Level1:war:0.0.1-SNAPSHOT:compile
> [INFO] \- mwar:Level1:jar:classes:0.0.1-SNAPSHOT:compile
> [INFO]+- Base:Base:war:0.0.1-SNAPSHOT:compile
> [INFO]\- Base:Base:jar:classes:0.0.1-SNAPSHOT:compile
> {noformat}
> Proposed solution: There should be option 'notOverlayTransitiveWar' which
> allow exclude WARs like 'Base' from overlaying, because the transitive WAR
> may be reached only over JAR and I think there is no reason any JAR really
> depends on WAR.
> Workaround is manually define ovelays in plugin configuration, but Maven
> spirit is Convention over Configuration
> h2. example
> # git clone https://github.com/michaldo/mwar360.git
> # cd mwar360
> # mvn package
--
This message was sent by Atlassian JIRA
[jira] [Updated] (MWAR-360) Overlay: ignore WAR which is transitively dependent over JAR
[
https://issues.apache.org/jira/browse/MWAR-360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michal Domagala updated MWAR-360:
-
Description:
Example:
I have WAR project 'Base' with class A.
I have WAR project 'Level1' which is depends on 'Base'. 'Level1' has class B
extends A.
Then 'Base' must have true
Finally, I have WAR project 'Level2' with class C extends B. For the same
reason 'Level1' must have true
Expected: when Level2 WAR is build, only Level1 WAR is overlayed, because
Level1 contains Base
Actual: Level1 and Base are overlayed together. That wastes time.
{noformat}
[INFO] Copying webapp resources [mwar/Level2/src/main/webapp]
[INFO] Processing overlay [ id mwar:Level1]
[INFO] Processing overlay [ id Base:Base]
[INFO] Webapp assembled in [26 msecs]
{noformat}
Reason: Level1 classes JAR has dependency to Base WAR, but that dependency is
"fake"
{noformat}
[INFO] mwar:Level2:war:0.0.1-SNAPSHOT
[INFO] +- mwar:Level1:war:0.0.1-SNAPSHOT:compile
[INFO] \- mwar:Level1:jar:classes:0.0.1-SNAPSHOT:compile
[INFO]+- Base:Base:war:0.0.1-SNAPSHOT:compile
[INFO]\- Base:Base:jar:classes:0.0.1-SNAPSHOT:compile
{noformat}
Proposed solution: There should be option 'notOverlayTransitiveWar' which allow
exclude WARs like 'Base' from overlaying, because the transitive WAR may be
reached only over JAR and I think there is no reason any JAR really depends on
WAR.
Workaround is manually define ovelays in plugin configuration, but Maven spirit
is Convention over Configuration
was:
Example:
I have WAR project 'Base' with class A.
I have WAR project 'Level1' which is depends on 'Base'. 'Level1' has class B
extends A.
Then 'Base' must have true
Finally, I have WAR project 'Level2' with class C extends B. For the same
reason 'Level1' must have true
Expected: when Level2 WAR is build, only Level1 WAR is overlayed, because
Level1 contains Base
Actual: Level1 and Base are overlayed together. That wastes time.
[INFO] Copying webapp resources [mwar/Level2/src/main/webapp]
[INFO] Processing overlay [ id mwar:Level1]
[INFO] Processing overlay [ id Base:Base]
[INFO] Webapp assembled in [26 msecs]
Reason: Level1 classes JAR has dependency to Base WAR, but that dependency is
"fake"
[INFO] mwar:Level2:war:0.0.1-SNAPSHOT
[INFO] +- mwar:Level1:war:0.0.1-SNAPSHOT:compile
[INFO] \- mwar:Level1:jar:classes:0.0.1-SNAPSHOT:compile
[INFO]+- Base:Base:war:0.0.1-SNAPSHOT:compile
[INFO]\- Base:Base:jar:classes:0.0.1-SNAPSHOT:compile
Proposed solution: There should be option 'notOverlayTransitiveWar' which allow
exclude WARs like 'Base' from overlaying, because the transitive WAR may be
reached only over JAR and I think there is no reason any JAR really depends on
WAR.
Workaround is manually define ovelays in plugin configuration, but Maven spirit
is Convention over Configuration
> Overlay: ignore WAR which is transitively dependent over JAR
>
>
> Key: MWAR-360
> URL: https://issues.apache.org/jira/browse/MWAR-360
> Project: Maven WAR Plugin
> Issue Type: Improvement
>Reporter: Michal Domagala
>Priority: Minor
>
> Example:
> I have WAR project 'Base' with class A.
> I have WAR project 'Level1' which is depends on 'Base'. 'Level1' has class B
> extends A.
> Then 'Base' must have true
> Finally, I have WAR project 'Level2' with class C extends B. For the same
> reason 'Level1' must have true
> Expected: when Level2 WAR is build, only Level1 WAR is overlayed, because
> Level1 contains Base
> Actual: Level1 and Base are overlayed together. That wastes time.
> {noformat}
> [INFO] Copying webapp resources [mwar/Level2/src/main/webapp]
> [INFO] Processing overlay [ id mwar:Level1]
> [INFO] Processing overlay [ id Base:Base]
> [INFO] Webapp assembled in [26 msecs]
> {noformat}
> Reason: Level1 classes JAR has dependency to Base WAR, but that dependency is
> "fake"
> {noformat}
> [INFO] mwar:Level2:war:0.0.1-SNAPSHOT
> [INFO] +- mwar:Level1:war:0.0.1-SNAPSHOT:compile
> [INFO] \- mwar:Level1:jar:classes:0.0.1-SNAPSHOT:compile
> [INFO]+- Base:Base:war:0.0.1-SNAPSHOT:compile
> [INFO]\- Base:Base:jar:classes:0.0.1-SNAPSHOT:compile
> {noformat}
> Proposed solution: There should be option 'notOverlayTransitiveWar' which
> allow exclude WARs like 'Base' from overlaying, because the transitive WAR
> may be reached only over JAR and I think there is no reason any JAR really
> depends on WAR.
> Workaround is manually define ovelays in plugin configuration, but Maven
> spirit is Convention over Configuration
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MWAR-360) Overlay: ignore WAR which is transitively dependent over JAR
Michal Domagala created MWAR-360: Summary: Overlay: ignore WAR which is transitively dependent over JAR Key: MWAR-360 URL: https://issues.apache.org/jira/browse/MWAR-360 Project: Maven WAR Plugin Issue Type: Improvement Reporter: Michal Domagala Priority: Minor Example: I have WAR project 'Base' with class A. I have WAR project 'Level1' which is depends on 'Base'. 'Level1' has class B extends A. Then 'Base' must have true Finally, I have WAR project 'Level2' with class C extends B. For the same reason 'Level1' must have true Expected: when Level2 WAR is build, only Level1 WAR is overlayed, because Level1 contains Base Actual: Level1 and Base are overlayed together. That wastes time. [INFO] Copying webapp resources [mwar/Level2/src/main/webapp] [INFO] Processing overlay [ id mwar:Level1] [INFO] Processing overlay [ id Base:Base] [INFO] Webapp assembled in [26 msecs] Reason: Level1 classes JAR has dependency to Base WAR, but that dependency is "fake" [INFO] mwar:Level2:war:0.0.1-SNAPSHOT [INFO] +- mwar:Level1:war:0.0.1-SNAPSHOT:compile [INFO] \- mwar:Level1:jar:classes:0.0.1-SNAPSHOT:compile [INFO]+- Base:Base:war:0.0.1-SNAPSHOT:compile [INFO]\- Base:Base:jar:classes:0.0.1-SNAPSHOT:compile Proposed solution: There should be option 'notOverlayTransitiveWar' which allow exclude WARs like 'Base' from overlaying, because the transitive WAR may be reached only over JAR and I think there is no reason any JAR really depends on WAR. Workaround is manually define ovelays in plugin configuration, but Maven spirit is Convention over Configuration -- This message was sent by Atlassian JIRA (v6.3.4#6332)
