[jira] [Comment Edited] (MANT-66) Ambiguous date in generated header comment
[
https://issues.apache.org/jira/browse/MANT-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14516515#comment-14516515
]
Michael Osipov edited comment on MANT-66 at 4/28/15 6:35 AM:
-
[~s...@apache.org], how about an output like the help plugin but with version
number:
{noformat}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLS...
{noformat}
was (Author: michael-o):
[~sebb], how about an output like the help plugin but with version number:
{noformat}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLS...
{noformat}
> Ambiguous date in generated header comment
> --
>
> Key: MANT-66
> URL: https://issues.apache.org/jira/browse/MANT-66
> Project: Maven Ant Plugin
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Sebb
>Priority: Trivial
>
> The date in the header comment is ambigious. For example:
>
> Is that Oct 4th or April 10th 2011?
> Or even April 11th, 2010?
> Dates should always use the format /mm/dd (or -mm-dd etc.).
> It might be worth updating the comment to include the plugin version number
> as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MANT-66) Ambiguous date in generated header comment
[
https://issues.apache.org/jira/browse/MANT-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14516515#comment-14516515
]
Michael Osipov commented on MANT-66:
[~sebb], how about an output like the help plugin but with version number:
{noformat}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLS...
{noformat}
> Ambiguous date in generated header comment
> --
>
> Key: MANT-66
> URL: https://issues.apache.org/jira/browse/MANT-66
> Project: Maven Ant Plugin
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Sebb
>Priority: Trivial
>
> The date in the header comment is ambigious. For example:
>
> Is that Oct 4th or April 10th 2011?
> Or even April 11th, 2010?
> Dates should always use the format /mm/dd (or -mm-dd etc.).
> It might be worth updating the comment to include the plugin version number
> as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ARCHETYPE-481) Add excludePatterns property to allow excluding certain files/folders when creating archetype from project.
Petar Tahchiev created ARCHETYPE-481:
Summary: Add excludePatterns property to allow excluding certain
files/folders when creating archetype from project.
Key: ARCHETYPE-481
URL: https://issues.apache.org/jira/browse/ARCHETYPE-481
Project: Maven Archetype
Issue Type: New Feature
Reporter: Petar Tahchiev
I think it would be nice to have this property in the `archetype.properties`
file:
{code}
excludePatterns=.project,.classpath,.idea/**
{code}
to allow excluding certain files/folders when creating archetype from already
existing project.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARCHETYPE-480) Allow generated pom.name, pom.description and pom.url to include custom properties when using create-archetype-from-project
[
https://issues.apache.org/jira/browse/ARCHETYPE-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14515980#comment-14515980
]
ASF GitHub Bot commented on ARCHETYPE-480:
--
GitHub user paranoiabla opened a pull request:
https://github.com/apache/maven-archetype/pull/5
Allow generated pom.name, pom.description and pom.url to include custom ...
...properties when using create-archetype-from-project. This is a
pull-request for https://issues.apache.org/jira/browse/ARCHETYPE-480
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/paranoiabla/maven-archetype ARCHETYPE-480
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/maven-archetype/pull/5.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #5
commit 3db45b04878de50b57c37cad40793bb5f35757d4
Author: Petar Tahchiev
Date: 2015-04-28T00:02:09Z
Allow generated pom.name, pom.description and pom.url to include custom
properties when using create-archetype-from-project
> Allow generated pom.name, pom.description and pom.url to include custom
> properties when using create-archetype-from-project
> ---
>
> Key: ARCHETYPE-480
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-480
> Project: Maven Archetype
> Issue Type: Improvement
>Reporter: Petar Tahchiev
>
> It would be nice to allow the pom's name, description and url to include
> custom properties when I create an archetype from project. For instance I may
> want to declare a property in `archetype.properties`:
> {code}
> projectname=MySampleProjectname
> {code}
> and then in my `pom.xml`:
> {code}
> MySampleProjectname
> MySampleProjectname parent application
> {code}
> So when I invoke `mvn archetype:create-from-project` the result would be:
> {code}
> ${projectname}
> ${projectname} parent application
> {code}
> which will then be replaced with whatever is specified in the command line
> during project creation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ARCHETYPE-480) Allow generated pom.name, pom.description and pom.url to include custom properties when using create-archetype-from-project
Petar Tahchiev created ARCHETYPE-480:
Summary: Allow generated pom.name, pom.description and pom.url to
include custom properties when using create-archetype-from-project
Key: ARCHETYPE-480
URL: https://issues.apache.org/jira/browse/ARCHETYPE-480
Project: Maven Archetype
Issue Type: Improvement
Reporter: Petar Tahchiev
It would be nice to allow the pom's name, description and url to include custom
properties when I create an archetype from project. For instance I may want to
declare a property in `archetype.properties`:
{code}
projectname=MySampleProjectname
{code}
and then in my `pom.xml`:
{code}
MySampleProjectname
MySampleProjectname parent application
{code}
So when I invoke `mvn archetype:create-from-project` the result would be:
{code}
${projectname}
${projectname} parent application
{code}
which will then be replaced with whatever is specified in the command line
during project creation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MJAVADOC-428) problem with generation link to DefaultHandler
Roman Ivanov created MJAVADOC-428:
-
Summary: problem with generation link to DefaultHandler
Key: MJAVADOC-428
URL: https://issues.apache.org/jira/browse/MJAVADOC-428
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.10.3
Reporter: Roman Ivanov
problem is described at https://jira.codehaus.org/browse/MJAVADOC-425
update for new doxia works well the only issue left is :
{quote}
One more case:
http://docs.oracle.com/javase/7/docs/api/org/xml/sax
/helpers.DefaultHandler.html?is-external=true: 404 Not Found
This link is broken because DefaultHandler is preceded by dot instead of '/'.
{quote}
Looks like it is not related to doxia version problem, but still a problem.
You can find that error there - http://checkstyle.sourceforge.net/linkcheck.html
to reproduce that problem please comment out line
https://github.com/checkstyle/checkstyle/blob/master/pom.xml#L1100
and run "mvn clean site"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5805) Custom packaging types: configuring DefaultLifecycleMapping mojo executions
[
https://issues.apache.org/jira/browse/MNG-5805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14515112#comment-14515112
]
ASF GitHub Bot commented on MNG-5805:
-
Github user atanasenko closed the pull request at:
https://github.com/apache/maven/pull/43
> Custom packaging types: configuring DefaultLifecycleMapping mojo executions
> ---
>
> Key: MNG-5805
> URL: https://issues.apache.org/jira/browse/MNG-5805
> Project: Maven
> Issue Type: Improvement
> Components: Plugins and Lifecycle
>Reporter: Anton Tanasenko
>Assignee: Jason van Zyl
>Priority: Minor
> Fix For: 3.3.4
>
>
> Currently, DefaultLifecycleMapping does not support mapping phases to goals
> with a custom configuration (see
> maven-core/src/main/resources/META-INF/plexus/default-bindings.xml). It is
> impossible to bind, say, an assembly plugin to 'package' phase within a
> custom packaging type, since assembly plugin requires a meaningful
> configuration to be set.
> At my job, we have a number of poms, each serving a purpose of defining a
> lifecycle for a particular type of project (there's one for jar, a couple for
> wars and several more for other types of deployable artifacts).
> Now that I somewhat understand maven's lifecycle, It seems natural to convert
> such poms to custom packaging types, leaving only a single parent with global
> config and pluginManagement. But it is currently impossible, since we are
> using mostly standard plugins (only occasional dedicated ones) to configure
> projects' lifecycles.
> I did some digging around and put together a relatively straightforward
> change to maven-core:
> https://github.com/apache/maven/compare/master...atanasenko:mng-5805-lifecycle-mojo-config?w=1
> It both introduces support for specifying configuration and dependencies for
> mojo executions:
> {code:xml}
>
>
>
> org.apache.maven.plugins:maven-install-plugin:2.4:install
> ...
> ...
>
>
> ...
>
>
>
> {code}
> as well as retains support for existing mapping syntax:
> {code:xml}
> org.apache.maven.plugins:maven-install-plugin:2.4:install,
> ...
> {code}
> I will put together some its (as well as make sure that existing are running
> ok) and create a pull request for both. Also, there are a couple of changes
> that break API in org/apache/maven/lifecycle/Lifecycle.java and
> org/apache/maven/lifecycle/mapping/Lifecycle.java. How critical is it to
> mantain compatibility in those two?
> ITS:
> https://github.com/apache/maven-integration-testing/compare/master...atanasenko:mng-5805-lifecycle-mojo-config?w=1
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5805) Custom packaging types: configuring DefaultLifecycleMapping mojo executions
[
https://issues.apache.org/jira/browse/MNG-5805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14515110#comment-14515110
]
ASF GitHub Bot commented on MNG-5805:
-
Github user atanasenko closed the pull request at:
https://github.com/apache/maven-integration-testing/pull/12
> Custom packaging types: configuring DefaultLifecycleMapping mojo executions
> ---
>
> Key: MNG-5805
> URL: https://issues.apache.org/jira/browse/MNG-5805
> Project: Maven
> Issue Type: Improvement
> Components: Plugins and Lifecycle
>Reporter: Anton Tanasenko
>Assignee: Jason van Zyl
>Priority: Minor
> Fix For: 3.3.4
>
>
> Currently, DefaultLifecycleMapping does not support mapping phases to goals
> with a custom configuration (see
> maven-core/src/main/resources/META-INF/plexus/default-bindings.xml). It is
> impossible to bind, say, an assembly plugin to 'package' phase within a
> custom packaging type, since assembly plugin requires a meaningful
> configuration to be set.
> At my job, we have a number of poms, each serving a purpose of defining a
> lifecycle for a particular type of project (there's one for jar, a couple for
> wars and several more for other types of deployable artifacts).
> Now that I somewhat understand maven's lifecycle, It seems natural to convert
> such poms to custom packaging types, leaving only a single parent with global
> config and pluginManagement. But it is currently impossible, since we are
> using mostly standard plugins (only occasional dedicated ones) to configure
> projects' lifecycles.
> I did some digging around and put together a relatively straightforward
> change to maven-core:
> https://github.com/apache/maven/compare/master...atanasenko:mng-5805-lifecycle-mojo-config?w=1
> It both introduces support for specifying configuration and dependencies for
> mojo executions:
> {code:xml}
>
>
>
> org.apache.maven.plugins:maven-install-plugin:2.4:install
> ...
> ...
>
>
> ...
>
>
>
> {code}
> as well as retains support for existing mapping syntax:
> {code:xml}
> org.apache.maven.plugins:maven-install-plugin:2.4:install,
> ...
> {code}
> I will put together some its (as well as make sure that existing are running
> ok) and create a pull request for both. Also, there are a couple of changes
> that break API in org/apache/maven/lifecycle/Lifecycle.java and
> org/apache/maven/lifecycle/mapping/Lifecycle.java. How critical is it to
> mantain compatibility in those two?
> ITS:
> https://github.com/apache/maven-integration-testing/compare/master...atanasenko:mng-5805-lifecycle-mojo-config?w=1
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5805) Custom packaging types: configuring DefaultLifecycleMapping mojo executions
[
https://issues.apache.org/jira/browse/MNG-5805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14515111#comment-14515111
]
ASF GitHub Bot commented on MNG-5805:
-
Github user atanasenko closed the pull request at:
https://github.com/apache/maven-integration-testing/pull/11
> Custom packaging types: configuring DefaultLifecycleMapping mojo executions
> ---
>
> Key: MNG-5805
> URL: https://issues.apache.org/jira/browse/MNG-5805
> Project: Maven
> Issue Type: Improvement
> Components: Plugins and Lifecycle
>Reporter: Anton Tanasenko
>Assignee: Jason van Zyl
>Priority: Minor
> Fix For: 3.3.4
>
>
> Currently, DefaultLifecycleMapping does not support mapping phases to goals
> with a custom configuration (see
> maven-core/src/main/resources/META-INF/plexus/default-bindings.xml). It is
> impossible to bind, say, an assembly plugin to 'package' phase within a
> custom packaging type, since assembly plugin requires a meaningful
> configuration to be set.
> At my job, we have a number of poms, each serving a purpose of defining a
> lifecycle for a particular type of project (there's one for jar, a couple for
> wars and several more for other types of deployable artifacts).
> Now that I somewhat understand maven's lifecycle, It seems natural to convert
> such poms to custom packaging types, leaving only a single parent with global
> config and pluginManagement. But it is currently impossible, since we are
> using mostly standard plugins (only occasional dedicated ones) to configure
> projects' lifecycles.
> I did some digging around and put together a relatively straightforward
> change to maven-core:
> https://github.com/apache/maven/compare/master...atanasenko:mng-5805-lifecycle-mojo-config?w=1
> It both introduces support for specifying configuration and dependencies for
> mojo executions:
> {code:xml}
>
>
>
> org.apache.maven.plugins:maven-install-plugin:2.4:install
> ...
> ...
>
>
> ...
>
>
>
> {code}
> as well as retains support for existing mapping syntax:
> {code:xml}
> org.apache.maven.plugins:maven-install-plugin:2.4:install,
> ...
> {code}
> I will put together some its (as well as make sure that existing are running
> ok) and create a pull request for both. Also, there are a couple of changes
> that break API in org/apache/maven/lifecycle/Lifecycle.java and
> org/apache/maven/lifecycle/mapping/Lifecycle.java. How critical is it to
> mantain compatibility in those two?
> ITS:
> https://github.com/apache/maven-integration-testing/compare/master...atanasenko:mng-5805-lifecycle-mojo-config?w=1
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5805) Custom packaging types: configuring DefaultLifecycleMapping mojo executions
[
https://issues.apache.org/jira/browse/MNG-5805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14515081#comment-14515081
]
ASF GitHub Bot commented on MNG-5805:
-
GitHub user atanasenko opened a pull request:
https://github.com/apache/maven-integration-testing/pull/12
MNG-5805: Custom packaging types: configuring DefaultLifecycleMapping
mojo executions
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/atanasenko/maven-integration-testing master
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/maven-integration-testing/pull/12.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #12
commit c36b987ab208a4154b0c03ffdc8d33d3d12caad2
Author: Anton Tanasenko
Date: 2015-04-27T21:58:32Z
MNG-5805: Custom packaging types: configuring DefaultLifecycleMapping
mojo executions
> Custom packaging types: configuring DefaultLifecycleMapping mojo executions
> ---
>
> Key: MNG-5805
> URL: https://issues.apache.org/jira/browse/MNG-5805
> Project: Maven
> Issue Type: Improvement
> Components: Plugins and Lifecycle
>Reporter: Anton Tanasenko
>Assignee: Jason van Zyl
>Priority: Minor
> Fix For: 3.3.4
>
>
> Currently, DefaultLifecycleMapping does not support mapping phases to goals
> with a custom configuration (see
> maven-core/src/main/resources/META-INF/plexus/default-bindings.xml). It is
> impossible to bind, say, an assembly plugin to 'package' phase within a
> custom packaging type, since assembly plugin requires a meaningful
> configuration to be set.
> At my job, we have a number of poms, each serving a purpose of defining a
> lifecycle for a particular type of project (there's one for jar, a couple for
> wars and several more for other types of deployable artifacts).
> Now that I somewhat understand maven's lifecycle, It seems natural to convert
> such poms to custom packaging types, leaving only a single parent with global
> config and pluginManagement. But it is currently impossible, since we are
> using mostly standard plugins (only occasional dedicated ones) to configure
> projects' lifecycles.
> I did some digging around and put together a relatively straightforward
> change to maven-core:
> https://github.com/apache/maven/compare/master...atanasenko:mng-5805-lifecycle-mojo-config?w=1
> It both introduces support for specifying configuration and dependencies for
> mojo executions:
> {code:xml}
>
>
>
> org.apache.maven.plugins:maven-install-plugin:2.4:install
> ...
> ...
>
>
> ...
>
>
>
> {code}
> as well as retains support for existing mapping syntax:
> {code:xml}
> org.apache.maven.plugins:maven-install-plugin:2.4:install,
> ...
> {code}
> I will put together some its (as well as make sure that existing are running
> ok) and create a pull request for both. Also, there are a couple of changes
> that break API in org/apache/maven/lifecycle/Lifecycle.java and
> org/apache/maven/lifecycle/mapping/Lifecycle.java. How critical is it to
> mantain compatibility in those two?
> ITS:
> https://github.com/apache/maven-integration-testing/compare/master...atanasenko:mng-5805-lifecycle-mojo-config?w=1
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MNG-5811) Display the time of execution for each participant of the build
Rocher Suchard created MNG-5811:
---
Summary: Display the time of execution for each participant of the
build
Key: MNG-5811
URL: https://issues.apache.org/jira/browse/MNG-5811
Project: Maven
Issue Type: Improvement
Components: General
Affects Versions: 3.3.1, 3.2.5
Reporter: Rocher Suchard
Priority: Minor
Hello,
When working with projet with a lots of plugins bundled in different phase, I'd
find rather interesting to have the execution time of such plugin, like you
have the execution time of each project in a multi module project.
The major use of such feature is to determine the plugins that takes too much
time in the build process and possibly to correct them.
For an example of what I want, compare the two output :
- default log (on any project, this is not relevant here) :
{code}
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Application ... SUCCESS [ 0.768 s]
[INFO] apps-common ... SUCCESS [ 3.649 s]
[INFO] apps-template-plugin .. SUCCESS [ 6.665 s]
[INFO] apps-general .. SUCCESS [ 12.627 s]
[INFO] apps-console .. SUCCESS [ 0.384 s]
[INFO] GUI Tools . SUCCESS [ 1.059 s]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 25.330 s
[INFO] Finished at: 2015-04-27T22:46:54+02:00
[INFO] Final Memory: 47M/613M
[INFO]
{code}
- "enhanced" logs :
{code}
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Application ...
SUCCESS [ 0.768 s]
[INFO] apps-common ...
SUCCESS [ 3.649 s]
[INFO] apps-template-plugin ..
SUCCESS [ 6.665 s]
[INFO] apps-general ..
SUCCESS [ 12.627 s]
[INFO] apps-console ..
SUCCESS [ 0.384 s]
[INFO] GUI Tools .
SUCCESS [ 1.059 s]
[INFO] - maven-clean-plugin:2.6.1:clean ...
SUCCESS [ 1.000 s]
[INFO] - maven-resources-plugin:2.6:resources (default-resources) ...
SUCCESS [ 1.000 s]
[INFO] - maven-compiler-plugin:2.0.2:compile (default-compile)...
SUCCESS [ 1.000 s]
[INFO] - maven-resources-plugin:2.6:testResources (default-testResources) ...
SUCCESS [ 1.000 s]
[INFO] - maven-compiler-plugin:2.0.2:testCompile (default-testCompile)...
SUCCESS [ 1.000 s]
[INFO] - maven-surefire-plugin:2.12.4:test (default-test) ...
SUCCESS [ 1.000 s]
[INFO] - maven-jar-plugin:2.4:jar (default-jar) ...
SUCCESS [ 1.000 s]
[INFO] - maven-install-plugin:2.4:install (default-install) ...
SUCCESS [ 1.000 s]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 25.330 s
[INFO] Finished at: 2015-04-27T22:46:54+02:00
[INFO] Final Memory: 47M/613M
[INFO]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5805) Custom packaging types: configuring DefaultLifecycleMapping mojo executions
[
https://issues.apache.org/jira/browse/MNG-5805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14514979#comment-14514979
]
ASF GitHub Bot commented on MNG-5805:
-
Github user atanasenko commented on the pull request:
https://github.com/apache/maven/pull/43#issuecomment-96817019
It looks like you applied only the pom file change of sisu version.
> Custom packaging types: configuring DefaultLifecycleMapping mojo executions
> ---
>
> Key: MNG-5805
> URL: https://issues.apache.org/jira/browse/MNG-5805
> Project: Maven
> Issue Type: Improvement
> Components: Plugins and Lifecycle
>Reporter: Anton Tanasenko
>Assignee: Jason van Zyl
>Priority: Minor
> Fix For: 3.3.4
>
>
> Currently, DefaultLifecycleMapping does not support mapping phases to goals
> with a custom configuration (see
> maven-core/src/main/resources/META-INF/plexus/default-bindings.xml). It is
> impossible to bind, say, an assembly plugin to 'package' phase within a
> custom packaging type, since assembly plugin requires a meaningful
> configuration to be set.
> At my job, we have a number of poms, each serving a purpose of defining a
> lifecycle for a particular type of project (there's one for jar, a couple for
> wars and several more for other types of deployable artifacts).
> Now that I somewhat understand maven's lifecycle, It seems natural to convert
> such poms to custom packaging types, leaving only a single parent with global
> config and pluginManagement. But it is currently impossible, since we are
> using mostly standard plugins (only occasional dedicated ones) to configure
> projects' lifecycles.
> I did some digging around and put together a relatively straightforward
> change to maven-core:
> https://github.com/apache/maven/compare/master...atanasenko:mng-5805-lifecycle-mojo-config?w=1
> It both introduces support for specifying configuration and dependencies for
> mojo executions:
> {code:xml}
>
>
>
> org.apache.maven.plugins:maven-install-plugin:2.4:install
> ...
> ...
>
>
> ...
>
>
>
> {code}
> as well as retains support for existing mapping syntax:
> {code:xml}
> org.apache.maven.plugins:maven-install-plugin:2.4:install,
> ...
> {code}
> I will put together some its (as well as make sure that existing are running
> ok) and create a pull request for both. Also, there are a couple of changes
> that break API in org/apache/maven/lifecycle/Lifecycle.java and
> org/apache/maven/lifecycle/mapping/Lifecycle.java. How critical is it to
> mantain compatibility in those two?
> ITS:
> https://github.com/apache/maven-integration-testing/compare/master...atanasenko:mng-5805-lifecycle-mojo-config?w=1
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MCHECKSTYLE-291) Change format of violation message
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14514907#comment-14514907
]
Michal Kordas edited comment on MCHECKSTYLE-291 at 4/27/15 8:23 PM:
It works in IntelliJ when searching by {{CTRL}}+{{N}}, so the guys probably
took this convention from somewhere.
was (Author: mkordas):
It works in IntelliJ when searching by {{CTRL}}+{{{N}}, so the guys probably
took this convention from somewhere.
> Change format of violation message
> --
>
> Key: MCHECKSTYLE-291
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-291
> Project: Maven Checkstyle Plugin
> Issue Type: Improvement
>Affects Versions: 2.15
>Reporter: Michal Kordas
>Assignee: Michael Osipov
>
> For example on LineLength violation in console I get the following error:
> _\[ERROR] src\test\java\com\test\SampleTest.java *\[89]* (sizes) LineLength:
> Line is longer than 180 characters (found 202)._
> It would be better to have colon and line number instead of braces, so that I
> can directly paste the reference to IntelliJ and go to affected line:
> _\[ERROR] src\test\java\com\test\SampleTest.java *:89* (sizes) LineLength:
> Line is longer than 180 characters (found 202)._
> The same format has exception stacktrace in Java.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MCHECKSTYLE-291) Change format of violation message
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14514907#comment-14514907
]
Michal Kordas commented on MCHECKSTYLE-291:
---
It works in IntelliJ when searching by {{CTRL}}+{{{N}}, so the guys probably
took this convention from somewhere.
> Change format of violation message
> --
>
> Key: MCHECKSTYLE-291
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-291
> Project: Maven Checkstyle Plugin
> Issue Type: Improvement
>Affects Versions: 2.15
>Reporter: Michal Kordas
>Assignee: Michael Osipov
>
> For example on LineLength violation in console I get the following error:
> _\[ERROR] src\test\java\com\test\SampleTest.java *\[89]* (sizes) LineLength:
> Line is longer than 180 characters (found 202)._
> It would be better to have colon and line number instead of braces, so that I
> can directly paste the reference to IntelliJ and go to affected line:
> _\[ERROR] src\test\java\com\test\SampleTest.java *:89* (sizes) LineLength:
> Line is longer than 180 characters (found 202)._
> The same format has exception stacktrace in Java.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MCHECKSTYLE-291) Change format of violation message
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14514891#comment-14514891
]
Michael Osipov commented on MCHECKSTYLE-291:
I do not consider {{SomeFile:10:15}} as a common format. Is it?
> Change format of violation message
> --
>
> Key: MCHECKSTYLE-291
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-291
> Project: Maven Checkstyle Plugin
> Issue Type: Improvement
>Affects Versions: 2.15
>Reporter: Michal Kordas
>Assignee: Michael Osipov
>
> For example on LineLength violation in console I get the following error:
> _\[ERROR] src\test\java\com\test\SampleTest.java *\[89]* (sizes) LineLength:
> Line is longer than 180 characters (found 202)._
> It would be better to have colon and line number instead of braces, so that I
> can directly paste the reference to IntelliJ and go to affected line:
> _\[ERROR] src\test\java\com\test\SampleTest.java *:89* (sizes) LineLength:
> Line is longer than 180 characters (found 202)._
> The same format has exception stacktrace in Java.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MCHECKSTYLE-291) Change format of violation message
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14514888#comment-14514888 ] Michael Osipov commented on MCHECKSTYLE-291: No I am not but the log file isn't the best source for that. > Change format of violation message > -- > > Key: MCHECKSTYLE-291 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-291 > Project: Maven Checkstyle Plugin > Issue Type: Improvement >Affects Versions: 2.15 >Reporter: Michal Kordas >Assignee: Michael Osipov > > For example on LineLength violation in console I get the following error: > _\[ERROR] src\test\java\com\test\SampleTest.java *\[89]* (sizes) LineLength: > Line is longer than 180 characters (found 202)._ > It would be better to have colon and line number instead of braces, so that I > can directly paste the reference to IntelliJ and go to affected line: > _\[ERROR] src\test\java\com\test\SampleTest.java *:89* (sizes) LineLength: > Line is longer than 180 characters (found 202)._ > The same format has exception stacktrace in Java. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MCHECKSTYLE-291) Change format of violation message
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14514877#comment-14514877
]
Michal Kordas commented on MCHECKSTYLE-291:
---
[~michael-o], I expect {{SomeFile:10}} if only line available and
{{SomeFile:10:15}} when both line and column are present.
> Change format of violation message
> --
>
> Key: MCHECKSTYLE-291
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-291
> Project: Maven Checkstyle Plugin
> Issue Type: Improvement
>Affects Versions: 2.15
>Reporter: Michal Kordas
>Assignee: Michael Osipov
>
> For example on LineLength violation in console I get the following error:
> _\[ERROR] src\test\java\com\test\SampleTest.java *\[89]* (sizes) LineLength:
> Line is longer than 180 characters (found 202)._
> It would be better to have colon and line number instead of braces, so that I
> can directly paste the reference to IntelliJ and go to affected line:
> _\[ERROR] src\test\java\com\test\SampleTest.java *:89* (sizes) LineLength:
> Line is longer than 180 characters (found 202)._
> The same format has exception stacktrace in Java.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5805) Custom packaging types: configuring DefaultLifecycleMapping mojo executions
[
https://issues.apache.org/jira/browse/MNG-5805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14514781#comment-14514781
]
ASF GitHub Bot commented on MNG-5805:
-
Github user jvanzyl commented on the pull request:
https://github.com/apache/maven/pull/43#issuecomment-96789423
Applied on d8ae13fd7b6be8a238a2b74f2b494668cd967c30. If it looks good then
close out this issue along with the IT PR.
> Custom packaging types: configuring DefaultLifecycleMapping mojo executions
> ---
>
> Key: MNG-5805
> URL: https://issues.apache.org/jira/browse/MNG-5805
> Project: Maven
> Issue Type: Improvement
> Components: Plugins and Lifecycle
>Reporter: Anton Tanasenko
>Assignee: Jason van Zyl
>Priority: Minor
> Fix For: 3.3.4
>
>
> Currently, DefaultLifecycleMapping does not support mapping phases to goals
> with a custom configuration (see
> maven-core/src/main/resources/META-INF/plexus/default-bindings.xml). It is
> impossible to bind, say, an assembly plugin to 'package' phase within a
> custom packaging type, since assembly plugin requires a meaningful
> configuration to be set.
> At my job, we have a number of poms, each serving a purpose of defining a
> lifecycle for a particular type of project (there's one for jar, a couple for
> wars and several more for other types of deployable artifacts).
> Now that I somewhat understand maven's lifecycle, It seems natural to convert
> such poms to custom packaging types, leaving only a single parent with global
> config and pluginManagement. But it is currently impossible, since we are
> using mostly standard plugins (only occasional dedicated ones) to configure
> projects' lifecycles.
> I did some digging around and put together a relatively straightforward
> change to maven-core:
> https://github.com/apache/maven/compare/master...atanasenko:mng-5805-lifecycle-mojo-config?w=1
> It both introduces support for specifying configuration and dependencies for
> mojo executions:
> {code:xml}
>
>
>
> org.apache.maven.plugins:maven-install-plugin:2.4:install
> ...
> ...
>
>
> ...
>
>
>
> {code}
> as well as retains support for existing mapping syntax:
> {code:xml}
> org.apache.maven.plugins:maven-install-plugin:2.4:install,
> ...
> {code}
> I will put together some its (as well as make sure that existing are running
> ok) and create a pull request for both. Also, there are a couple of changes
> that break API in org/apache/maven/lifecycle/Lifecycle.java and
> org/apache/maven/lifecycle/mapping/Lifecycle.java. How critical is it to
> mantain compatibility in those two?
> ITS:
> https://github.com/apache/maven-integration-testing/compare/master...atanasenko:mng-5805-lifecycle-mojo-config?w=1
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5805) Custom packaging types: configuring DefaultLifecycleMapping mojo executions
[
https://issues.apache.org/jira/browse/MNG-5805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14514780#comment-14514780
]
Jason van Zyl commented on MNG-5805:
Applied on d8ae13fd7b6be8a238a2b74f2b494668cd967c30
> Custom packaging types: configuring DefaultLifecycleMapping mojo executions
> ---
>
> Key: MNG-5805
> URL: https://issues.apache.org/jira/browse/MNG-5805
> Project: Maven
> Issue Type: Improvement
> Components: Plugins and Lifecycle
>Reporter: Anton Tanasenko
>Assignee: Jason van Zyl
>Priority: Minor
> Fix For: 3.3.4
>
>
> Currently, DefaultLifecycleMapping does not support mapping phases to goals
> with a custom configuration (see
> maven-core/src/main/resources/META-INF/plexus/default-bindings.xml). It is
> impossible to bind, say, an assembly plugin to 'package' phase within a
> custom packaging type, since assembly plugin requires a meaningful
> configuration to be set.
> At my job, we have a number of poms, each serving a purpose of defining a
> lifecycle for a particular type of project (there's one for jar, a couple for
> wars and several more for other types of deployable artifacts).
> Now that I somewhat understand maven's lifecycle, It seems natural to convert
> such poms to custom packaging types, leaving only a single parent with global
> config and pluginManagement. But it is currently impossible, since we are
> using mostly standard plugins (only occasional dedicated ones) to configure
> projects' lifecycles.
> I did some digging around and put together a relatively straightforward
> change to maven-core:
> https://github.com/apache/maven/compare/master...atanasenko:mng-5805-lifecycle-mojo-config?w=1
> It both introduces support for specifying configuration and dependencies for
> mojo executions:
> {code:xml}
>
>
>
> org.apache.maven.plugins:maven-install-plugin:2.4:install
> ...
> ...
>
>
> ...
>
>
>
> {code}
> as well as retains support for existing mapping syntax:
> {code:xml}
> org.apache.maven.plugins:maven-install-plugin:2.4:install,
> ...
> {code}
> I will put together some its (as well as make sure that existing are running
> ok) and create a pull request for both. Also, there are a couple of changes
> that break API in org/apache/maven/lifecycle/Lifecycle.java and
> org/apache/maven/lifecycle/mapping/Lifecycle.java. How critical is it to
> mantain compatibility in those two?
> ITS:
> https://github.com/apache/maven-integration-testing/compare/master...atanasenko:mng-5805-lifecycle-mojo-config?w=1
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MNG-5805) Custom packaging types: configuring DefaultLifecycleMapping mojo executions
[
https://issues.apache.org/jira/browse/MNG-5805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-5805.
--
Resolution: Fixed
> Custom packaging types: configuring DefaultLifecycleMapping mojo executions
> ---
>
> Key: MNG-5805
> URL: https://issues.apache.org/jira/browse/MNG-5805
> Project: Maven
> Issue Type: Improvement
> Components: Plugins and Lifecycle
>Reporter: Anton Tanasenko
>Assignee: Jason van Zyl
>Priority: Minor
> Fix For: 3.3.4
>
>
> Currently, DefaultLifecycleMapping does not support mapping phases to goals
> with a custom configuration (see
> maven-core/src/main/resources/META-INF/plexus/default-bindings.xml). It is
> impossible to bind, say, an assembly plugin to 'package' phase within a
> custom packaging type, since assembly plugin requires a meaningful
> configuration to be set.
> At my job, we have a number of poms, each serving a purpose of defining a
> lifecycle for a particular type of project (there's one for jar, a couple for
> wars and several more for other types of deployable artifacts).
> Now that I somewhat understand maven's lifecycle, It seems natural to convert
> such poms to custom packaging types, leaving only a single parent with global
> config and pluginManagement. But it is currently impossible, since we are
> using mostly standard plugins (only occasional dedicated ones) to configure
> projects' lifecycles.
> I did some digging around and put together a relatively straightforward
> change to maven-core:
> https://github.com/apache/maven/compare/master...atanasenko:mng-5805-lifecycle-mojo-config?w=1
> It both introduces support for specifying configuration and dependencies for
> mojo executions:
> {code:xml}
>
>
>
> org.apache.maven.plugins:maven-install-plugin:2.4:install
> ...
> ...
>
>
> ...
>
>
>
> {code}
> as well as retains support for existing mapping syntax:
> {code:xml}
> org.apache.maven.plugins:maven-install-plugin:2.4:install,
> ...
> {code}
> I will put together some its (as well as make sure that existing are running
> ok) and create a pull request for both. Also, there are a couple of changes
> that break API in org/apache/maven/lifecycle/Lifecycle.java and
> org/apache/maven/lifecycle/mapping/Lifecycle.java. How critical is it to
> mantain compatibility in those two?
> ITS:
> https://github.com/apache/maven-integration-testing/compare/master...atanasenko:mng-5805-lifecycle-mojo-config?w=1
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MASSEMBLY-614) useTransitiveFiltering implemented contrarily
[
https://issues.apache.org/jira/browse/MASSEMBLY-614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14514750#comment-14514750
]
Rafael Chaves commented on MASSEMBLY-614:
-
Was bitten by this as well. Since it has been broken for so long, people may
have started to rely on the buggy behavior, maybe just change the documentation?
> useTransitiveFiltering implemented contrarily
> -
>
> Key: MASSEMBLY-614
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-614
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 2.3
>Reporter: Joerg Schaible
>
> useTransitiveFiltering is implemented wrongly, it filters when set to false
> and does not filter when set to true.
> One of the declared dependencies in the project is this:
> {code:xml}
>
> com.sun.xml.ws
> jaxws-rt
> 2.2.6
>
> {code}
> The assembly descriptor is:
> {code:xml}
>
> false
> false
> true
> false
>
> *:jaxws*
>
>
> {code}
> The result contains only the jar for jaxws-rt, but not its dependencies.
> Setting useTransitiveFiltering to true, then all dependencies are included.
> It works quite contrary to the documentation and the implicit property name.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MWAR-344) Webresources not properly configured when configuration is override in profile
[
https://issues.apache.org/jira/browse/MWAR-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MWAR-344.
---
Resolution: Invalid
Assignee: Robert Scholte
This is actually a Maven core issue. Maven can perfectly merge almost every
element of the pom.xml, except those within configuration, since these are
plugin specific and Maven can't predict the representation of such a tag. The
merging is done by simple xml rules, which work very well for primitives,
Strings, Lists and Maps, but in case of an Object (such as Resource) they act
more like an override (and in case of Lists, index-based overrides).
http://maven.apache.org/pom.html#Plugins gives examples of some magic
attributes (\@combine.children and \@combine.self), and I've been working on
support for \@combine.id (https://github.com/sonatype/plexus-utils/issues/16)
but that still needs to be added to the Maven distribution.
Some similar issues:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20text%20~%20%22configuration%20merge%22
> Webresources not properly configured when configuration is override in profile
> --
>
> Key: MWAR-344
> URL: https://issues.apache.org/jira/browse/MWAR-344
> Project: Maven WAR Plugin
> Issue Type: Bug
>Affects Versions: 2.5, 2.6
> Environment: Apache Maven 3.0.5
>Reporter: Felix Martin
>Assignee: Robert Scholte
>Priority: Critical
> Attachments: mwar-bug.zip
>
>
> If in a profile you configure a webresource already configured as default
> includes/excludes are mixed.
> If default plugin configuration in pom is:
> {code:xml}
>
>
>
> ${basedir}/src/main/webapp2
>
> **/*.txt
>
>
>
> ${basedir}/src/main/webapp3
>
> **/*.txt
>
>
>
>
> {code}
> The configuration in runtime with no profile is:
> {noformat}
> [DEBUG] (s) directory = W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp2
> [DEBUG] (s) includes = [**/*.txt]
> [DEBUG] (s) directory = W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp3
> [DEBUG] (s) excludes = [**/*.txt]
> [DEBUG] (s) webResources = [Resource {targetPath: null, filtering: false,
> FileSet {directory: W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp2,
> PatternSet [includes: {**/*.txt}, excludes: {}]}}, Resource {targetPath:
> null, filtering: false, FileSet {directory:
> W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp3, PatternSet [includes: {},
> excludes: {**/*.txt}]}}]
> {noformat}
> which works as expected.
> If we add a profile named 'test' with the following configuration:
> {code:xml}
>
>
>
> ${basedir}/src/main/webapp4
>
> **/*.txt
>
>
>
>
> {code}
> The configuration in runtime with the profile 'test' is:
> {noformat}
> [DEBUG] (s) directory = W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp4
> [DEBUG] (s) includes = [**/*.txt]
> [DEBUG] (s) webResources = [Resource {targetPath: null, filtering: false,
> FileSet {directory: W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp4,
> PatternSet [includes: {**/*.txt}, excludes: {}]}}]
> {noformat}
> which also works as expected.
> But if we add anothjer profile named 'bug' with the following configuration:
> {code:xml}
>
>
>
> ${basedir}/src/main/webapp2
>
> **/*.json
>
>
>
> ${basedir}/src/main/webapp4
>
> **/*.txt
>
>
>
>
> {code}
> The configuration in runtime with the profile 'bug' is:
> {noformat}
> [DEBUG] (s) directory = W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp2
> [DEBUG] (s) includes = [**/*.json]
> [DEBUG] (s) directory = W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp4
> [DEBUG] (s) includes = [**/*.txt]
> [DEBUG] (s) excludes = [**/*.txt]
> [DEBUG] (s) webResources = [Resource {targetPath: null, filtering: false,
> FileSet {directory: W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp2,
> PatternSet [includes: {**/*.json}, excludes: {}]}}, Resource {targetPath:
> null, filtering: false, FileSet {directory:
> W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp4, PatternSet [includes:
> {**/*.txt}, excludes: {**/*.txt}]}}]
> {noformat}
> As we can see configuration for directory 'webapp2' is ok, but the
> configuration for directory 'webapp4' is mixed with configuration for
> directory 'webapp3' in the default configuration.
> An example project is attached.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MWAR-344) Webresources not properly configured when configuration is override in profile
[
https://issues.apache.org/jira/browse/MWAR-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Martin updated MWAR-344:
--
Description:
If in a profile you configure a webresource already configured as default
includes/excludes are mixed.
If default plugin configuration in pom is:
{code:xml}
${basedir}/src/main/webapp2
**/*.txt
${basedir}/src/main/webapp3
**/*.txt
{code}
The configuration in runtime with no profile is:
{noformat}
[DEBUG] (s) directory = W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp2
[DEBUG] (s) includes = [**/*.txt]
[DEBUG] (s) directory = W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp3
[DEBUG] (s) excludes = [**/*.txt]
[DEBUG] (s) webResources = [Resource {targetPath: null, filtering: false,
FileSet {directory: W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp2,
PatternSet [includes: {**/*.txt}, excludes: {}]}}, Resource {targetPath: null,
filtering: false, FileSet {directory:
W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp3, PatternSet [includes: {},
excludes: {**/*.txt}]}}]
{noformat}
which works as expected.
If we add a profile named 'test' with the following configuration:
{code:xml}
${basedir}/src/main/webapp4
**/*.txt
{code}
The configuration in runtime with the profile 'test' is:
{noformat}
[DEBUG] (s) directory = W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp4
[DEBUG] (s) includes = [**/*.txt]
[DEBUG] (s) webResources = [Resource {targetPath: null, filtering: false,
FileSet {directory: W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp4,
PatternSet [includes: {**/*.txt}, excludes: {}]}}]
{noformat}
which also works as expected.
But if we add anothjer profile named 'bug' with the following configuration:
{code:xml}
${basedir}/src/main/webapp2
**/*.json
${basedir}/src/main/webapp4
**/*.txt
{code}
The configuration in runtime with the profile 'bug' is:
{noformat}
[DEBUG] (s) directory = W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp2
[DEBUG] (s) includes = [**/*.json]
[DEBUG] (s) directory = W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp4
[DEBUG] (s) includes = [**/*.txt]
[DEBUG] (s) excludes = [**/*.txt]
[DEBUG] (s) webResources = [Resource {targetPath: null, filtering: false,
FileSet {directory: W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp2,
PatternSet [includes: {**/*.json}, excludes: {}]}}, Resource {targetPath: null,
filtering: false, FileSet {directory:
W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp4, PatternSet [includes:
{**/*.txt}, excludes: {**/*.txt}]}}]
{noformat}
As we can see configuration for directory 'webapp2' is ok, but the
configuration for directory 'webapp4' is mixed with configuration for directory
'webapp3' in the default configuration.
An example project is attached.
was:
If in a profile you configure a webresource already configured as default
includes/excludes are mixed.
If default plugin configuration in pom is:
{code:xml}
${basedir}/src/main/webapp2
**/*.txt
${basedir}/src/main/webapp3
**/*.txt
{code}
The configuration in runtime with no profile is:
{noformat}
[DEBUG] (s) directory = W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp2
[DEBUG] (s) includes = [**/*.txt]
[DEBUG] (s) directory = W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp3
[DEBUG] (s) excludes = [**/*.txt]
[DEBUG] (s) webResources = [Resource {targetPath: null, filtering: false,
FileSet {directory: W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp2,
PatternSet [includes: {**/*.txt}, excludes: {}]}}, Resource {targetPath: null,
filtering: false, FileSet {directory:
W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp3, PatternSet [includes: {},
excludes: {**/*.txt}]}}]
{noformat}
which works as expected.
If we add a profile named 'test' with the following configuration:
{code:xml}
${basedir}/src/main/webapp4
**/*.txt
{code}
The configuration in runtime with the profile 'test' is:
{noformat}
[DEBUG] (s) directory = W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp4
[DEBUG] (s) includes = [**/*.txt]
[DEBUG] (s) webResources = [Resource {targetPath: null, filtering: false,
FileSet {directory: W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp4,
PatternSet [includes: {**/*.txt}, excludes: {}]}}]
{noformat}
which also works as expected.
But if we add anothjer profile named 'bug' with the following configuration:
{code:xml}
${basedir}/src/main/webapp2
**/*.json
${basedir}/src/main/webapp4
**/*.txt
{code}
The configuration in runtime with the profile 'bug' is:
{noformat}
[DEBUG] (s) directory = W:\
[jira] [Updated] (MWAR-344) Webresources not properly configured when configuration is override in profile
[
https://issues.apache.org/jira/browse/MWAR-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Martin updated MWAR-344:
--
Description:
If in a profile you configure a webresource already configured as default
includes/excludes are mixed.
If default plugin configuration in pom is:
{code:xml}
${basedir}/src/main/webapp2
**/*.txt
${basedir}/src/main/webapp3
**/*.txt
{code}
The configuration in runtime with no profile is:
{noformat}
[DEBUG] (s) directory = W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp2
[DEBUG] (s) includes = [**/*.txt]
[DEBUG] (s) directory = W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp3
[DEBUG] (s) excludes = [**/*.txt]
[DEBUG] (s) webResources = [Resource {targetPath: null, filtering: false,
FileSet {directory: W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp2,
PatternSet [includes: {**/*.txt}, excludes: {}]}}, Resource {targetPath: null,
filtering: false, FileSet {directory:
W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp3, PatternSet [includes: {},
excludes: {**/*.txt}]}}]
{noformat}
which works as expected.
If we add a profile named 'test' with the following configuration:
{code:xml}
${basedir}/src/main/webapp4
**/*.txt
{code}
The configuration in runtime with the profile 'test' is:
{noformat}
[DEBUG] (s) directory = W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp4
[DEBUG] (s) includes = [**/*.txt]
[DEBUG] (s) webResources = [Resource {targetPath: null, filtering: false,
FileSet {directory: W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp4,
PatternSet [includes: {**/*.txt}, excludes: {}]}}]
{noformat}
which also works as expected.
But if we add anothjer profile named 'bug' with the following configuration:
{code:xml}
${basedir}/src/main/webapp2
**/*.json
${basedir}/src/main/webapp4
**/*.txt
{code}
The configuration in runtime with the profile 'bug' is:
{noformat}
[DEBUG] (s) directory = W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp2
[DEBUG] (s) includes = [**/*.json]
[DEBUG] (s) directory = W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp4
[DEBUG] (s) includes = [**/*.txt]
[DEBUG] (s) excludes = [**/*.txt]
[DEBUG] (s) webResources = [Resource {targetPath: null, filtering: false,
FileSet {directory: W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp2,
PatternSet [includes: {**/*.json}, excludes: {}]}}, Resource {targetPath: null,
filtering: false, FileSet {directory:
W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp4, PatternSet [includes:
{**/*.txt}, excludes: {**/*.txt}]}}]
{noformat}
As we can see configuration for directory 'webapp2' is ok, but the
configuration for directory 'webapp4' is mixed with configuration for directory
'webapp3' in the default configuration.
An example project is attached.
was:If in a profile you configure a webresource already configured as default
includes/excludes are mixed
> Webresources not properly configured when configuration is override in profile
> --
>
> Key: MWAR-344
> URL: https://issues.apache.org/jira/browse/MWAR-344
> Project: Maven WAR Plugin
> Issue Type: Bug
>Affects Versions: 2.5, 2.6
> Environment: Apache Maven 3.0.5
>Reporter: Felix Martin
>Priority: Critical
> Attachments: mwar-bug.zip
>
>
> If in a profile you configure a webresource already configured as default
> includes/excludes are mixed.
> If default plugin configuration in pom is:
> {code:xml}
>
>
>
> ${basedir}/src/main/webapp2
>
> **/*.txt
>
>
>
> ${basedir}/src/main/webapp3
>
> **/*.txt
>
>
>
>
> {code}
> The configuration in runtime with no profile is:
> {noformat}
> [DEBUG] (s) directory = W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp2
> [DEBUG] (s) includes = [**/*.txt]
> [DEBUG] (s) directory = W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp3
> [DEBUG] (s) excludes = [**/*.txt]
> [DEBUG] (s) webResources = [Resource {targetPath: null, filtering: false,
> FileSet {directory: W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp2,
> PatternSet [includes: {**/*.txt}, excludes: {}]}}, Resource {targetPath:
> null, filtering: false, FileSet {directory:
> W:\DESARROLLO\Workspaces\mwar-bug/src/main/webapp3, PatternSet [includes: {},
> excludes: {**/*.txt}]}}]
> {noformat}
> which works as expected.
> If we add a profile named 'test' with the following configuration:
> {code:xml}
>
>
>
> ${basedir}/src/main/webapp4
>
> **/*.txt
>
>
>
>
> {code}
> The configuration in runtime with the profile 'test' is:
> {nofor
[jira] [Updated] (MWAR-344) Webresources not properly configured when configuration is override in profile
[ https://issues.apache.org/jira/browse/MWAR-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Martin updated MWAR-344: -- Attachment: mwar-bug.zip Example project > Webresources not properly configured when configuration is override in profile > -- > > Key: MWAR-344 > URL: https://issues.apache.org/jira/browse/MWAR-344 > Project: Maven WAR Plugin > Issue Type: Bug >Affects Versions: 2.5, 2.6 > Environment: Apache Maven 3.0.5 >Reporter: Felix Martin >Priority: Critical > Attachments: mwar-bug.zip > > > If in a profile you configure a webresource already configured as default > includes/excludes are mixed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MCHECKSTYLE-291) Change format of violation message
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14514389#comment-14514389 ] Zlika commented on MCHECKSTYLE-291: --- Are you sure this change will not break other tools that may rely on the current format to parse the Maven output? > Change format of violation message > -- > > Key: MCHECKSTYLE-291 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-291 > Project: Maven Checkstyle Plugin > Issue Type: Improvement >Affects Versions: 2.15 >Reporter: Michal Kordas >Assignee: Michael Osipov > > For example on LineLength violation in console I get the following error: > _\[ERROR] src\test\java\com\test\SampleTest.java *\[89]* (sizes) LineLength: > Line is longer than 180 characters (found 202)._ > It would be better to have colon and line number instead of braces, so that I > can directly paste the reference to IntelliJ and go to affected line: > _\[ERROR] src\test\java\com\test\SampleTest.java *:89* (sizes) LineLength: > Line is longer than 180 characters (found 202)._ > The same format has exception stacktrace in Java. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MWAR-344) Webresources not properly configured when configuration is override in profile
Felix Martin created MWAR-344: - Summary: Webresources not properly configured when configuration is override in profile Key: MWAR-344 URL: https://issues.apache.org/jira/browse/MWAR-344 Project: Maven WAR Plugin Issue Type: Bug Affects Versions: 2.6, 2.5 Environment: Apache Maven 3.0.5 Reporter: Felix Martin Priority: Critical If in a profile you configure a webresource already configured as default includes/excludes are mixed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MSKINS-110) Changed size of left navigation bar
[
https://issues.apache.org/jira/browse/MSKINS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14514206#comment-14514206
]
Michael Osipov commented on MSKINS-110:
---
This is a bad fix without a problem description and you modified the
{{bootstrap css}} directly. We have {{maven-*.css}} for that.
> Changed size of left navigation bar
> ---
>
> Key: MSKINS-110
> URL: https://issues.apache.org/jira/browse/MSKINS-110
> Project: Maven Skins
> Issue Type: Improvement
> Components: Fluido Skin
>Affects Versions: fluido-1.4
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: fluido-1.4
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MSKINS-109) Support HiDPI displays
[ https://issues.apache.org/jira/browse/MSKINS-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14514184#comment-14514184 ] Michael Osipov commented on MSKINS-109: --- Were you able to create any updated artwork? > Support HiDPI displays > -- > > Key: MSKINS-109 > URL: https://issues.apache.org/jira/browse/MSKINS-109 > Project: Maven Skins > Issue Type: Improvement > Components: Fluido Skin >Affects Versions: fluido-1.3.1 > Environment: HiDPI/Retina display >Reporter: Hendrik Schreiber > Labels: close-pending > > Graphics provided in the skin (github ribbon, "Built by Maven", link icons, > ...) are only provided in standard resolution. By now, this looks amateurish > on screens with HiDPI (i.e. Retina displays). > Please provide hi res images that are scaled with width/height parameters so > that they look good on hi res displays. > Thanks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MSKINS-109) Support HiDPI displays
[ https://issues.apache.org/jira/browse/MSKINS-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MSKINS-109: -- Labels: close-pending (was: ) > Support HiDPI displays > -- > > Key: MSKINS-109 > URL: https://issues.apache.org/jira/browse/MSKINS-109 > Project: Maven Skins > Issue Type: Improvement > Components: Fluido Skin >Affects Versions: fluido-1.3.1 > Environment: HiDPI/Retina display >Reporter: Hendrik Schreiber > Labels: close-pending > > Graphics provided in the skin (github ribbon, "Built by Maven", link icons, > ...) are only provided in standard resolution. By now, this looks amateurish > on screens with HiDPI (i.e. Retina displays). > Please provide hi res images that are scaled with width/height parameters so > that they look good on hi res displays. > Thanks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MCHECKSTYLE-291) Change format of violation message
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14514181#comment-14514181
]
Michael Osipov edited comment on MCHECKSTYLE-291 at 4/27/15 2:13 PM:
-
Michal, here is the [code
spot|https://maven.apache.org/plugins/maven-checkstyle-plugin/xref/org/apache/maven/plugin/checkstyle/CheckstyleViolationCheckMojo.html#L642]:
{code}
if ( logViolationsToConsole )
{
String line = xpp.getAttributeValue( "", "line" );
String column = xpp.getAttributeValue( "", "column" );
String message = xpp.getAttributeValue( "", "message" );
String rule = RuleUtil.getName( source );
String category = RuleUtil.getCategory( source );
log( severity, file + '[' + line + ( ( column == null ) ? "" : ( ':' +
column ) ) + "] ("
+ category + ") " + rule + ": " + message );
}
{code}
How do you intend the column value to be retained?
was (Author: michael-o):
Michal, here is the [code
spot|https://maven.apache.org/plugins/maven-checkstyle-plugin/xref/org/apache/maven/plugin/checkstyle/CheckstyleViolationCheckMojo.html#L644]:
{code}
if ( logViolationsToConsole )
{
String line = xpp.getAttributeValue( "", "line" );
String column = xpp.getAttributeValue( "", "column" );
String message = xpp.getAttributeValue( "", "message" );
String rule = RuleUtil.getName( source );
String category = RuleUtil.getCategory( source );
log( severity, file + '[' + line + ( ( column == null ) ? "" : ( ':' +
column ) ) + "] ("
+ category + ") " + rule + ": " + message );
}
{code}
How do you intend the column value to be retained?
> Change format of violation message
> --
>
> Key: MCHECKSTYLE-291
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-291
> Project: Maven Checkstyle Plugin
> Issue Type: Improvement
>Affects Versions: 2.15
>Reporter: Michal Kordas
>Assignee: Michael Osipov
>
> For example on LineLength violation in console I get the following error:
> _\[ERROR] src\test\java\com\test\SampleTest.java *\[89]* (sizes) LineLength:
> Line is longer than 180 characters (found 202)._
> It would be better to have colon and line number instead of braces, so that I
> can directly paste the reference to IntelliJ and go to affected line:
> _\[ERROR] src\test\java\com\test\SampleTest.java *:89* (sizes) LineLength:
> Line is longer than 180 characters (found 202)._
> The same format has exception stacktrace in Java.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MCHECKSTYLE-291) Change format of violation message
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14514181#comment-14514181
]
Michael Osipov commented on MCHECKSTYLE-291:
Michal, here is the [code
spot|https://maven.apache.org/plugins/maven-checkstyle-plugin/xref/org/apache/maven/plugin/checkstyle/CheckstyleViolationCheckMojo.html#L644]:
{code}
if ( logViolationsToConsole )
{
String line = xpp.getAttributeValue( "", "line" );
String column = xpp.getAttributeValue( "", "column" );
String message = xpp.getAttributeValue( "", "message" );
String rule = RuleUtil.getName( source );
String category = RuleUtil.getCategory( source );
log( severity, file + '[' + line + ( ( column == null ) ? "" : ( ':' +
column ) ) + "] ("
+ category + ") " + rule + ": " + message );
}
{code}
How do you intend the column value to be retained?
> Change format of violation message
> --
>
> Key: MCHECKSTYLE-291
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-291
> Project: Maven Checkstyle Plugin
> Issue Type: Improvement
>Affects Versions: 2.15
>Reporter: Michal Kordas
>Assignee: Michael Osipov
>
> For example on LineLength violation in console I get the following error:
> _\[ERROR] src\test\java\com\test\SampleTest.java *\[89]* (sizes) LineLength:
> Line is longer than 180 characters (found 202)._
> It would be better to have colon and line number instead of braces, so that I
> can directly paste the reference to IntelliJ and go to affected line:
> _\[ERROR] src\test\java\com\test\SampleTest.java *:89* (sizes) LineLength:
> Line is longer than 180 characters (found 202)._
> The same format has exception stacktrace in Java.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MNG-5804) mvn.bat does not work in root directory on Windows
[
https://issues.apache.org/jira/browse/MNG-5804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MNG-5804.
---
Resolution: Duplicate
Assignee: Robert Scholte
> mvn.bat does not work in root directory on Windows
> --
>
> Key: MNG-5804
> URL: https://issues.apache.org/jira/browse/MNG-5804
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.3.1
> Environment: Win7 x64 german
>Reporter: Bernd Eckenfels
>Assignee: Robert Scholte
>Priority: Minor
> Labels: windows,
>
> On Windows the new `mvn.cmd` script does not work if the current working
> directory is the root dir of a drive. In that case it will initialize
> `%MAVEN_PROJECTBASEDIR%` with a trailing `\` and that will break the java
> command line as it escapes the following quote of
> `"-Dmaven.multiModuleProjectDirectory=%MAVEN_PROJECTBASEDIR%"`.
> It works on 3.2.1 and fails with 3.3.1:
> {code}
> c:\> cd /d C:\
> c:\>c:\devenv\apache-maven-3.2.1\bin\mvn --version
> Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9;
> 2014-02-14T18:37:52+01:00)
> Maven home: c:\devenv\apache-maven-3.2.1\bin\..
> ...
> c:\>c:\devenv\apache-maven-3.3.1\bin\mvn --version
> Usage: java [-options] class [args...]
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MNG-5802) JDK7 compatibility
[ https://issues.apache.org/jira/browse/MNG-5802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MNG-5802. --- Resolution: Duplicate Assignee: Robert Scholte Based on the attachment the actual issue is MNG-5796 > JDK7 compatibility > -- > > Key: MNG-5802 > URL: https://issues.apache.org/jira/browse/MNG-5802 > Project: Maven > Issue Type: Bug >Affects Versions: 3.3.1 > Environment: OS:Windows 7 x64 Enterprise; > JDK:1.7.55; >Reporter: hongwei.zhang >Assignee: Robert Scholte >Priority: Blocker > Attachments: 2015-04-27_104133.png, 2015-04-27_104352.png > > > Add the bin directory to system PATH,maven only works in c:/users/***,other > disk not work. > But,I replace maven to 3.2.5,it works ok. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
