[jira] (MPH-53) mvn help:describe returns the version that is specified in metadata instead of the one in the parent pom
[
https://jira.codehaus.org/browse/MPH-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MPH-53:
--
Component/s: describe
Description:
{{mvn help:describe}} returns a different version than {{mvn
help:effective-pom}} returns:
{noformat}
> mvn help:describe -Dplugin=surefire
...
[INFO] [help:describe]
[INFO] Plugin: 'org.apache.maven.plugins:maven-surefire-plugin:2.2'
---
Group Id: org.apache.maven.plugins
Artifact Id: maven-surefire-plugin
Version: 2.2
Goal Prefix: surefire
{noformat}
However, when I run {{mvn help:effective-pom}}
I get
{code:xml}
...
maven-surefire-plugin
2.4.3
true
**/*Test.java
html
...
{code}
My pom structure is quite simple: just a parent {{pom.xml}} with the
pluginmanagement section as above and a child pom using that. I have tested
with both maven 2.0.8 and 2.0.9.
See the discussion here:
http://www.nabble.com/Wrong-output-of-mvn-help%3Adescribe--td19168212.html
was:
mvn help:describe returns a different version than mvn help:effective-pom
returns:
> mvn help:describe -Dplugin=surefire
...
[INFO] [help:describe]
[INFO] Plugin: 'org.apache.maven.plugins:maven-surefire-plugin:2.2'
---
Group Id: org.apache.maven.plugins
Artifact Id: maven-surefire-plugin
Version: 2.2
Goal Prefix: surefire
However, when I run:
> mvn help:effective-pom
I get
...
maven-surefire-plugin
2.4.3
true
**/*Test.java
html
...
My pom structure is quite simple: just a parent pom.xml with the
pluginmanagement section as above and a child pom using that. I have tested
with both maven 2.0.8 and 2.0.9.
See the discussion here:
http://www.nabble.com/Wrong-output-of-mvn-help%3Adescribe--td19168212.html
> mvn help:describe returns the version that is specified in metadata instead
> of the one in the parent pom
> -
>
> Key: MPH-53
> URL: https://jira.codehaus.org/browse/MPH-53
> Project: Maven 2.x Help Plugin
> Issue Type: Bug
> Components: describe
>Affects Versions: 2.0.1
> Environment: windows xp
> tested with mvn 2.0.8 & 2.0.9
>Reporter: Rintcius Blok
> Fix For: Backlog
>
>
> {{mvn help:describe}} returns a different version than {{mvn
> help:effective-pom}} returns:
> {noformat}
> > mvn help:describe -Dplugin=surefire
> ...
> [INFO] [help:describe]
> [INFO] Plugin: 'org.apache.maven.plugins:maven-surefire-plugin:2.2'
> ---
> Group Id: org.apache.maven.plugins
> Artifact Id: maven-surefire-plugin
> Version: 2.2
> Goal Prefix: surefire
> {noformat}
> However, when I run {{mvn help:effective-pom}}
> I get
> {code:xml}
> ...
>
>
>
> maven-surefire-plugin
> 2.4.3
>
> true
>
> **/*Test.java
>
> html
>
>
>
>
> ...
> {code}
> My pom structure is quite simple: just a parent {{pom.xml}} with the
> pluginmanagement section as above and a child pom using that. I have tested
> with both maven 2.0.8 and 2.0.9.
> See the discussion here:
> http://www.nabble.com/Wrong-output-of-mvn-help%3Adescribe--td19168212.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-87) help:effective-pom uses platform encoding and garbles non-ascii characters, emits invalid XML
[
https://jira.codehaus.org/browse/MPH-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MPH-87:
--
Component/s: effective-pom
Description:
As stated in http://www.w3.org/TR/REC-xml/#sec-guessing-no-ext-info XML files
without a BOM and without a XML encoding declaration should read the XML as
UTF-8.
{{help:effective-pom}} does use the platform encoding for writing the
effective-pom without emitting an appropriate XML encoding declaration in the
resulting XML file.
I have created a small sample project (available at
https://github.com/mfriedenhagen/invalidpom, attached as ZIP) which will
reproduce the issue.
While the parent pom
(https://raw.github.com/mfriedenhagen/invalidpom/master/pom.xml) has a XML
encoding declaration,
https://raw.github.com/mfriedenhagen/invalidpom/master/child-invalid/pom.xml
has none.
Now running:
{code}
mvn -s settings.xml -gs settings.xml clean validate
{code}
will produce an invalid character for the developer name "Jörg" in
{{child-invalid}}.
Two workarounds are:
* to include a XML encoding declaration as done in {{child-valid}}.
* to use {{JAVA_TOOL_OPTIONS}} on Windows as stated in
http://stackoverflow.com/a/623036/49132
* to use {{MAVEN_OPTS=-Dfile.encoding=utf-8 mvn -s settings.xml -gs
settings.xml clean validate}}.
Nonetheless I consider this a Major bug, as it clearly violates the
recommendations of W3C.
was:
As stated in http://www.w3.org/TR/REC-xml/#sec-guessing-no-ext-info XML files
without a BOM and without a XML encoding declaration should read the XML as
UTF-8.
{{help:effective-pom}} does use the platform encoding for writing the
effective-pom without emitting an appropriate XML encoding declaration in the
resulting XML file.
I have created a small sample project (available at
https://github.com/mfriedenhagen/invalidpom, attached as ZIP) which will
reproduce the issue.
While the parent pom
(https://raw.github.com/mfriedenhagen/invalidpom/master/pom.xml) has a XML
encoding declaration,
https://raw.github.com/mfriedenhagen/invalidpom/master/child-invalid/pom.xml
has none.
Now running:
{code}
mvn -s settings.xml -gs settings.xml clean validate
{code}
will produce an invalid character for the developer name "Jörg" in
{{child-invalid}}.
Two workarounds are:
* to include a XML encoding declaration as done in {{child-valid}}.
* to use {{JAVA_TOOL_OPTIONS}} on Windows as stated in
http://stackoverflow.com/a/623036/49132
* to use {{MAVEN_OPTS=-Dfile.encoding=utf-8 mvn -s settings.xml -gs
settings.xml clean validate}}.
Nonetheless I consider this a Major bug, as it clearly violates the
recommendations of W3C.
> help:effective-pom uses platform encoding and garbles non-ascii characters,
> emits invalid XML
> -
>
> Key: MPH-87
> URL: https://jira.codehaus.org/browse/MPH-87
> Project: Maven 2.x Help Plugin
> Issue Type: Bug
> Components: effective-pom
>Affects Versions: 2.1.1
> Environment: Windows, MacOSX, Linux, Maven 3.0.4
>Reporter: Mirko Friedenhagen
> Attachments: mfriedenhagen-invalidpom-MPH-87-0-g42a5c31.zip
>
>
> As stated in http://www.w3.org/TR/REC-xml/#sec-guessing-no-ext-info XML files
> without a BOM and without a XML encoding declaration should read the XML as
> UTF-8.
> {{help:effective-pom}} does use the platform encoding for writing the
> effective-pom without emitting an appropriate XML encoding declaration in the
> resulting XML file.
> I have created a small sample project (available at
> https://github.com/mfriedenhagen/invalidpom, attached as ZIP) which will
> reproduce the issue.
> While the parent pom
> (https://raw.github.com/mfriedenhagen/invalidpom/master/pom.xml) has a XML
> encoding declaration,
> https://raw.github.com/mfriedenhagen/invalidpom/master/child-invalid/pom.xml
> has none.
> Now running:
> {code}
> mvn -s settings.xml -gs settings.xml clean validate
> {code}
> will produce an invalid character for the developer name "Jörg" in
> {{child-invalid}}.
> Two workarounds are:
> * to include a XML encoding declaration as done in {{child-valid}}.
> * to use {{JAVA_TOOL_OPTIONS}} on Windows as stated in
> http://stackoverflow.com/a/623036/49132
> * to use {{MAVEN_OPTS=-Dfile.encoding=utf-8 mvn -s settings.xml -gs
> settings.xml clean validate}}.
> Nonetheless I consider this a Major bug, as it clearly violates the
> recommendations of W3C.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-83) all-profiles should list profiles from settings.xml even if there is no project
[ https://jira.codehaus.org/browse/MPH-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MPH-83: -- Component/s: all-profiles > all-profiles should list profiles from settings.xml even if there is no > project > --- > > Key: MPH-83 > URL: https://jira.codehaus.org/browse/MPH-83 > Project: Maven 2.x Help Plugin > Issue Type: Bug > Components: all-profiles >Affects Versions: 2.1.1 >Reporter: Julien Nicoulaud > > Running the goal all-profiles somewhere outside of a project answers "No > profile detected !". I have active and inactive profiles in my settings.xml, > they should appear. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-86) Hide passwords for effective-pom
[
https://jira.codehaus.org/browse/MPH-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MPH-86:
--
Component/s: effective-pom
> Hide passwords for effective-pom
>
>
> Key: MPH-86
> URL: https://jira.codehaus.org/browse/MPH-86
> Project: Maven 2.x Help Plugin
> Issue Type: Bug
> Components: effective-pom
>Affects Versions: 2.1.1
> Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
> Maven home: C:\Program Files (x86)\RscApplications\Maven3\bin\..
> Java version: 1.6.0, vendor: IBM Corporation
> Java home: C:\programs\ejbdeploy_base_v7\java\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1 build 7601 service pack 1", arch: "x86",
> family: "windows"
>Reporter: Stefan Cordes
>
> Executing
> {{mvn help:effective-pom -Doutput=pom-effective.txt}}
> with
> {code:xml}
>
>
> default
>
> true
>
>
> MyUserId
> MyVerySecretPassword
>
>
>
>
> {code}
> in
> {{%userprofile%\.m2\settings.xml}}
> results in an pom-effective.txt
> which contains
> {code:xml}
>
> MyUserId
> MyVerySecretPassword
>
> {code}
> As (in our case) the pom-effective.txt should be checked in version control
> system for later debug support we strongly need to hide the password analog
> to
> "MPH-44 Hide passwords for effective-settings":
> {code:xml}
>
> MyUserId
> ***
>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-78) effective-pom creates invalid xml because it outputs the Resource.mergeId
[
https://jira.codehaus.org/browse/MPH-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MPH-78:
--
Component/s: effective-pom
> effective-pom creates invalid xml because it outputs the Resource.mergeId
> -
>
> Key: MPH-78
> URL: https://jira.codehaus.org/browse/MPH-78
> Project: Maven 2.x Help Plugin
> Issue Type: Bug
> Components: effective-pom
>Affects Versions: 2.1.1
>Reporter: Jacob Robertson
>Priority: Minor
>
> My organization would like to use the output from the effective-pom goal as
> part of the deployed meta data in an ear. This is useful for some of our
> scripting that needs properties and dependencyManagement versions resolved
> (i.e. from parent poms), and the pom that is currently put in the ear does
> not have that information. However, once we start generating the
> effective-pom.xml file, any tool that uses xml validation will notice that
> the mergeId tag is invalid. This is especially annoying in eclipse, as it
> marks the whole project as having an error due to the effective-pom.xml file
> being in the target directory under the eclipse project. We can of course
> turn the xml validation off for the eclipse project or folder, but this is
> one additional step to ask a multitude of developers to take in configuring
> their projects.
> I notice that the EffectivePomMojo class has a "cleanModel" method that
> appears to sort the properties. Just to play with this, I added a
> "cleanResources" method that calls Resource.setMergeId(null). This technique
> does in fact work as I hoped for outputting the xml without the mergeId, but
> it requires upgrading this plugin to use at least Maven 2.0.10.
> {code}
> private static void cleanModel( Model pom )
> {
> Properties properties = new SortedProperties();
> properties.putAll( pom.getProperties() );
> pom.setProperties( properties );
> cleanResources( pom.getBuild().getResources() );
> cleanResources( pom.getBuild().getTestResources() );
> }
> private static void cleanResources( List resources )
> {
> for ( Iterator i = resources.iterator(); i.hasNext(); )
> {
> Resource resource = (Resource) i.next();
> resource.setMergeId( null );
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-79) help:active-profiles does not list active inherited profiles
[ https://jira.codehaus.org/browse/MPH-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MPH-79. - Resolution: Fixed Fix Version/s: 2.2 Fixed in [r1442405|http://svn.apache.org/viewvc?rev=1442405&view=rev] for Maven3. With Maven3 this information is available, with Maven2 you have to try to calculate it, and with inheritence you're often wrong. > help:active-profiles does not list active inherited profiles > > > Key: MPH-79 > URL: https://jira.codehaus.org/browse/MPH-79 > Project: Maven 2.x Help Plugin > Issue Type: Bug > Components: active-profiles >Affects Versions: 2.2 > Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 20:16:01+0100) > Windows (XP,2003,2008), Java 1.6 >Reporter: Xavier D. >Assignee: Robert Scholte >Priority: Minor > Fix For: 2.2 > > > The code fix for http://jira.codehaus.org/browse/MPH-16 appears to have been > removed and the test now breaks. > Refer to http://jira.codehaus.org/browse/MPH-16 for the Testcase zip file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-79) help:active-profiles does not list active inherited profiles
[ https://jira.codehaus.org/browse/MPH-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte reassigned MPH-79: - Assignee: Robert Scholte > help:active-profiles does not list active inherited profiles > > > Key: MPH-79 > URL: https://jira.codehaus.org/browse/MPH-79 > Project: Maven 2.x Help Plugin > Issue Type: Bug > Components: active-profiles >Affects Versions: 2.2 > Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 20:16:01+0100) > Windows (XP,2003,2008), Java 1.6 >Reporter: Xavier D. >Assignee: Robert Scholte >Priority: Minor > > The code fix for http://jira.codehaus.org/browse/MPH-16 appears to have been > removed and the test now breaks. > Refer to http://jira.codehaus.org/browse/MPH-16 for the Testcase zip file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-79) help:active-profiles does not list active inherited profiles
[ https://jira.codehaus.org/browse/MPH-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MPH-79: -- Component/s: active-profiles > help:active-profiles does not list active inherited profiles > > > Key: MPH-79 > URL: https://jira.codehaus.org/browse/MPH-79 > Project: Maven 2.x Help Plugin > Issue Type: Bug > Components: active-profiles >Affects Versions: 2.2 > Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 20:16:01+0100) > Windows (XP,2003,2008), Java 1.6 >Reporter: Xavier D. >Priority: Minor > > The code fix for http://jira.codehaus.org/browse/MPH-16 appears to have been > removed and the test now breaks. > Refer to http://jira.codehaus.org/browse/MPH-16 for the Testcase zip file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-45) Active profiles repeated each time for all projects in reactor
[ https://jira.codehaus.org/browse/MPH-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MPH-45: -- Component/s: all-profiles > Active profiles repeated each time for all projects in reactor > -- > > Key: MPH-45 > URL: https://jira.codehaus.org/browse/MPH-45 > Project: Maven 2.x Help Plugin > Issue Type: Improvement > Components: all-profiles >Reporter: Sander Verhagen > Attachments: MPH-45.diff > > > Running the active-profiles goal in a multi-module project (with subsequently > more than one project in the reactor) will all the active profiles for all > the projects in the reactor, repeating this for every single project that is > built, resulting in exhaustive output. > Given that each showing of active profiles of a single project costs about > eight lines in output (including some whitelines; that's with only one > profile active), and us (over here) having 73 projects in the reactor, that's > (73-1)*(73-1)*8 output lines being wasted. That's a silly 41472 lines for a > simple "mvn install". Well, I suppose an even simpler "mvn clean" will do the > same ;-) > And now I'm not even getting started about the fact that these 73 projects > all share the same profile that they get from their top parent project. > Over here we have a custom maven-help-plugin version running that shows the > active profiles of every project in the reactor *only once*. I made the > assumption that profiles are not going to change during the coarse of a > single Maven execution. > Is this a patch that we would be generally interested in? > Or is this perhaps a bug in the behaviour of the plugin? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-31) medium mode should include plugin descriptions
[ https://jira.codehaus.org/browse/MPH-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MPH-31: -- Component/s: describe > medium mode should include plugin descriptions > -- > > Key: MPH-31 > URL: https://jira.codehaus.org/browse/MPH-31 > Project: Maven 2.x Help Plugin > Issue Type: Bug > Components: describe >Reporter: Dan Fabulich > Fix For: Backlog > > > Run "mvn help:describe -Dplugin=compiler -Dmojo=compile". You'll get this: > [INFO] Mojo: 'compiler:compile' > === > Goal: 'compile' > Description: > Compiles application sources > === > Try again with "mvn help:describe -Dplugin=compiler -Dmojo=compile -Dmedium". > You'll get the exact same information. Try again with "-Dfull". You'll get > a highly verbose description of every parameter, including their type, > required, readonly, and description. > -Dmedium should include an "in-between" amount of information. I might > suggest that it include all parameters by name and the description, but not > type/required/readonly. (Perhaps omit readonly parameters from -Dmedium > view?) We might also consider using only the first sentence of the > description, just like Javadoc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPMD-161) PMD/CPD violation exclusions by class/issue
[ https://jira.codehaus.org/browse/MPMD-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MPMD-161. - Resolution: Fixed fixed http://svn.apache.org/r1442345 > PMD/CPD violation exclusions by class/issue > --- > > Key: MPMD-161 > URL: https://jira.codehaus.org/browse/MPMD-161 > Project: Maven 2.x PMD Plugin > Issue Type: New Feature > Components: CPD, PMD >Reporter: Andrey Utis >Assignee: Olivier Lamy > Fix For: 3.0 > > Attachments: pmd2.7.1_exclusions2.patch, pmd_exclude_trunk.patch, > pmd_exclude_trunk_v2.patch > > > I work on a system that has a lot of legacy code with a lot of PMD/CPD > violations. Introducing PMD to the build is not an easy option, since the > build would always fail. So the next best thing is to exclude any existing > violations and only fail if a new violation is introduced. Unfortunately, if > I have thousands of violations, PMD doesn't provide a good way to do this. > I'd have to add comments or annotations to all these places to ignore the > violation. > We came up with an alternative solution to this. We modified the PMD plugin > to read a properties file that contains a mapping of class name to a list of > excluded violations. If a particular violation is in this file, it does not > cause the build to fail. Similar idea for CPD. > An svn patch is attached (apply to 2.7.1) > (Disclaimer: this is probably not the most elegant piece of code but it works > and it was quick. Feel free to re-factor and make it more in line with the > rest of the plugin code) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPMD-161) PMD/CPD violation exclusions by class/issue
[ https://jira.codehaus.org/browse/MPMD-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318676#comment-318676 ] Olivier Lamy edited comment on MPMD-161 at 2/4/13 2:53 PM: --- fixed http://svn.apache.org/r1442345 Thanks ! was (Author: olamy): fixed http://svn.apache.org/r1442345 > PMD/CPD violation exclusions by class/issue > --- > > Key: MPMD-161 > URL: https://jira.codehaus.org/browse/MPMD-161 > Project: Maven 2.x PMD Plugin > Issue Type: New Feature > Components: CPD, PMD >Reporter: Andrey Utis >Assignee: Olivier Lamy > Fix For: 3.0 > > Attachments: pmd2.7.1_exclusions2.patch, pmd_exclude_trunk.patch, > pmd_exclude_trunk_v2.patch > > > I work on a system that has a lot of legacy code with a lot of PMD/CPD > violations. Introducing PMD to the build is not an easy option, since the > build would always fail. So the next best thing is to exclude any existing > violations and only fail if a new violation is introduced. Unfortunately, if > I have thousands of violations, PMD doesn't provide a good way to do this. > I'd have to add comments or annotations to all these places to ignore the > violation. > We came up with an alternative solution to this. We modified the PMD plugin > to read a properties file that contains a mapping of class name to a list of > excluded violations. If a particular violation is in this file, it does not > cause the build to fail. Similar idea for CPD. > An svn patch is attached (apply to 2.7.1) > (Disclaimer: this is probably not the most elegant piece of code but it works > and it was quick. Feel free to re-factor and make it more in line with the > rest of the plugin code) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPMD-161) PMD/CPD violation exclusions by class/issue
[ https://jira.codehaus.org/browse/MPMD-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Utis updated MPMD-161: - Attachment: pmd_exclude_trunk_v2.patch I added annotations for the parameters passed from the pom. Is that what you meant? I also added unit tests in a similar style to what was already there. Let me know if this is what you need. Thanks. > PMD/CPD violation exclusions by class/issue > --- > > Key: MPMD-161 > URL: https://jira.codehaus.org/browse/MPMD-161 > Project: Maven 2.x PMD Plugin > Issue Type: New Feature > Components: CPD, PMD >Reporter: Andrey Utis >Assignee: Olivier Lamy > Fix For: 3.0 > > Attachments: pmd2.7.1_exclusions2.patch, pmd_exclude_trunk.patch, > pmd_exclude_trunk_v2.patch > > > I work on a system that has a lot of legacy code with a lot of PMD/CPD > violations. Introducing PMD to the build is not an easy option, since the > build would always fail. So the next best thing is to exclude any existing > violations and only fail if a new violation is introduced. Unfortunately, if > I have thousands of violations, PMD doesn't provide a good way to do this. > I'd have to add comments or annotations to all these places to ignore the > violation. > We came up with an alternative solution to this. We modified the PMD plugin > to read a properties file that contains a mapping of class name to a list of > excluded violations. If a particular violation is in this file, it does not > cause the build to fail. Similar idea for CPD. > An svn patch is attached (apply to 2.7.1) > (Disclaimer: this is probably not the most elegant piece of code but it works > and it was quick. Feel free to re-factor and make it more in line with the > rest of the plugin code) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5181) New resolution from local repository is very confusing
[ https://jira.codehaus.org/browse/MNG-5181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318665#comment-318665 ] Brian Fox commented on MNG-5181: i'm on the fence about if this is good or not, but I think the option if provided should be simple-local-repository without the manager part. People already get confused about what's a local repo vs what's a repository manager and the mixing of these concepts here will make that worse. > New resolution from local repository is very confusing > -- > > Key: MNG-5181 > URL: https://jira.codehaus.org/browse/MNG-5181 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Dependencies >Affects Versions: 3.0, 3.0.1, 3.0.2, 3.0.3 >Reporter: Arnaud Heritier >Assignee: Olivier Lamy > Fix For: 3.1.0 > > > I just discover the change introduced in Maven 3.x to try to improve the > resolution mechanism and to avoid to use a local artifact which may not be > available in its remote repository : > https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository > Even if the feature is interesting it has several problems : > # When an artifact isn't accessible from its remote repository it isn't used > by maven which replies a classical "dependency not found error". It is really > annoying for a user with some Maven 2 skills which will have a look at his > local repo, will find the artifact and won't understand why Maven doesn't use > it. At least the error reported by Maven should be clear that even if the > dependency is available locally, it isn't used because it's remote repository > isn't available. > # This behavior cannot be configured to be only a warning for example. It is > really annoying because it doesn't take care of some context and constraints > we may have in a development team. Let's imagine that the remote artifact is > really removed. Cool Maven broke the build to warn us. But it brakes the > build of all the team whereas perhaps only one of them may try to solve the > issue (and it can be a long resolution). Thus having the ability to configure > if this control is blocker or warning may allow the team to configure it as > blocker on the CI server and as warning on the development environment. > # This behavior may introduce some bad practices for example when we are > using a staging feature on a repository manager. In our case my teams have a > dedicated profile to activate a staging repository when we are validating a > release. I recommend to not have this profile always activated but to do it > only on-demand to avoid them to DL staging stuffs they don't need. With this > new feature they need for all builds they run to activate this staging > profile while binaries are stored in it. When you have to do it 20 times per > day minimum let's imagine what the developer does : It adds it as an > alwaysActive profile and then forget to remove it when the release is ended. > For all these reason I would like we improve this feature to make it more > usable and before all bet understandable for ours users. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-132) Provide general "maven.compiler.main.skip" attribute
[ https://jira.codehaus.org/browse/MCOMPILER-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318662#comment-318662 ] Matthew Adams commented on MCOMPILER-132: - @Olivier, I suppose I agree with you about #3. Better to be explicit there. > Provide general "maven.compiler.main.skip" attribute > > > Key: MCOMPILER-132 > URL: https://jira.codehaus.org/browse/MCOMPILER-132 > Project: Maven 2.x Compiler Plugin > Issue Type: New Feature >Reporter: Dieter König >Assignee: Olivier Lamy >Priority: Minor > Fix For: 3.1 > > > Please provide general "maven.compiler.main.skip" attribute which will allow > to skip all executions of compiler plugin. > Desired usecase: > Execution of profile's where compilation of sources is not needed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPMD-161) PMD/CPD violation exclusions by class/issue
[ https://jira.codehaus.org/browse/MPMD-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318660#comment-318660 ] Olivier Lamy commented on MPMD-161: --- not really :-) We now use mojo annotations. Furthermore a unit or it test will be welcome for such new feature. Thanks ! > PMD/CPD violation exclusions by class/issue > --- > > Key: MPMD-161 > URL: https://jira.codehaus.org/browse/MPMD-161 > Project: Maven 2.x PMD Plugin > Issue Type: New Feature > Components: CPD, PMD >Reporter: Andrey Utis >Assignee: Olivier Lamy > Fix For: 3.0 > > Attachments: pmd2.7.1_exclusions2.patch, pmd_exclude_trunk.patch > > > I work on a system that has a lot of legacy code with a lot of PMD/CPD > violations. Introducing PMD to the build is not an easy option, since the > build would always fail. So the next best thing is to exclude any existing > violations and only fail if a new violation is introduced. Unfortunately, if > I have thousands of violations, PMD doesn't provide a good way to do this. > I'd have to add comments or annotations to all these places to ignore the > violation. > We came up with an alternative solution to this. We modified the PMD plugin > to read a properties file that contains a mapping of class name to a list of > excluded violations. If a particular violation is in this file, it does not > cause the build to fail. Similar idea for CPD. > An svn patch is attached (apply to 2.7.1) > (Disclaimer: this is probably not the most elegant piece of code but it works > and it was quick. Feel free to re-factor and make it more in line with the > rest of the plugin code) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJARSIGNER-24) Use Password Encryption in pom.xml
[ https://jira.codehaus.org/browse/MJARSIGNER-24?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318657#comment-318657 ] Olivier Lamy commented on MJARSIGNER-24: @Jerome feel free to provide patches for all bugs !! I'm pretty sure you will find some to work one ;-) > Use Password Encryption in pom.xml > -- > > Key: MJARSIGNER-24 > URL: https://jira.codehaus.org/browse/MJARSIGNER-24 > Project: Maven 2.x Jar Signer Plugin > Issue Type: New Feature >Reporter: Zang MingJie > Attachments: jarsigner.patch, patch, securejarsigner.patch > > > See http://maven.apache.org/guides/mini/guide-encryption.html > Here is a patch for it -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-301) Allow build-classpath to output to property
[ https://jira.codehaus.org/browse/MDEP-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MDEP-301. - Resolution: Fixed Fix Version/s: 2.7 Assignee: Olivier Lamy applied http://svn.apache.org/r1442131 Thanks for the patch ! > Allow build-classpath to output to property > --- > > Key: MDEP-301 > URL: https://jira.codehaus.org/browse/MDEP-301 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: build-classpath >Affects Versions: 2.1 >Reporter: Bjorn Beskow >Assignee: Olivier Lamy > Fix For: 2.7 > > Attachments: build-path-to-property.patch, mdep-301.diff, > mdep-301.diff > > > I frequently have the need to set the bootClasspath for the compiler plugin, > and would like to do it from project dependencies. Hence I would like to be > able to get the output of build-classpath to a property instead of a file. > Attached is a patch which adds an "outputProperty" property, and assigns the > classpath value to it if specified. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPMD-161) PMD/CPD violation exclusions by class/issue
[ https://jira.codehaus.org/browse/MPMD-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318650#comment-318650 ] Andrey Utis commented on MPMD-161: -- I attached a patch for trunk, please let me know if this works for you. Thanks, Andrey > PMD/CPD violation exclusions by class/issue > --- > > Key: MPMD-161 > URL: https://jira.codehaus.org/browse/MPMD-161 > Project: Maven 2.x PMD Plugin > Issue Type: New Feature > Components: CPD, PMD >Reporter: Andrey Utis >Assignee: Olivier Lamy > Fix For: 3.0 > > Attachments: pmd2.7.1_exclusions2.patch, pmd_exclude_trunk.patch > > > I work on a system that has a lot of legacy code with a lot of PMD/CPD > violations. Introducing PMD to the build is not an easy option, since the > build would always fail. So the next best thing is to exclude any existing > violations and only fail if a new violation is introduced. Unfortunately, if > I have thousands of violations, PMD doesn't provide a good way to do this. > I'd have to add comments or annotations to all these places to ignore the > violation. > We came up with an alternative solution to this. We modified the PMD plugin > to read a properties file that contains a mapping of class name to a list of > excluded violations. If a particular violation is in this file, it does not > cause the build to fail. Similar idea for CPD. > An svn patch is attached (apply to 2.7.1) > (Disclaimer: this is probably not the most elegant piece of code but it works > and it was quick. Feel free to re-factor and make it more in line with the > rest of the plugin code) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPMD-161) PMD/CPD violation exclusions by class/issue
[ https://jira.codehaus.org/browse/MPMD-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Utis updated MPMD-161: - Attachment: pmd_exclude_trunk.patch Patch that can be applied to trunk > PMD/CPD violation exclusions by class/issue > --- > > Key: MPMD-161 > URL: https://jira.codehaus.org/browse/MPMD-161 > Project: Maven 2.x PMD Plugin > Issue Type: New Feature > Components: CPD, PMD >Reporter: Andrey Utis >Assignee: Olivier Lamy > Fix For: 3.0 > > Attachments: pmd2.7.1_exclusions2.patch, pmd_exclude_trunk.patch > > > I work on a system that has a lot of legacy code with a lot of PMD/CPD > violations. Introducing PMD to the build is not an easy option, since the > build would always fail. So the next best thing is to exclude any existing > violations and only fail if a new violation is introduced. Unfortunately, if > I have thousands of violations, PMD doesn't provide a good way to do this. > I'd have to add comments or annotations to all these places to ignore the > violation. > We came up with an alternative solution to this. We modified the PMD plugin > to read a properties file that contains a mapping of class name to a list of > excluded violations. If a particular violation is in this file, it does not > cause the build to fail. Similar idea for CPD. > An svn patch is attached (apply to 2.7.1) > (Disclaimer: this is probably not the most elegant piece of code but it works > and it was quick. Feel free to re-factor and make it more in line with the > rest of the plugin code) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (ARCHETYPE-429) JIRA report in site only shows fixes up to v2.1 of plugin
[ https://jira.codehaus.org/browse/ARCHETYPE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Hammar closed ARCHETYPE-429. --- Resolution: Fixed Fix Version/s: 2.3 JIRA report removed in [r1442099|http://svn.apache.org/r1442099] > JIRA report in site only shows fixes up to v2.1 of plugin > - > > Key: ARCHETYPE-429 > URL: https://jira.codehaus.org/browse/ARCHETYPE-429 > Project: Maven Archetype > Issue Type: Bug > Components: Documentation >Affects Versions: 2.2 > Environment: n/a >Reporter: Anders Hammar >Assignee: Anders Hammar >Priority: Minor > Fix For: 2.3 > > > The plugin's site has a JIRA report than only shows versions 2.1, 2.0, > 2.0-alpha-5. This should be updated according to Apache Maven project plugin > standards. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-682) Apostrophe's in Markdown are removed resulting in HTML full of spelling error
Alex Collins created MSITE-682: -- Summary: Apostrophe's in Markdown are removed resulting in HTML full of spelling error Key: MSITE-682 URL: https://jira.codehaus.org/browse/MSITE-682 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Affects Versions: 3.1 Reporter: Alex Collins Repro: 1. Create Maven 3 project. 2. Add site 3.1 to plugins, add doxia-markdown-module:1.3 to plugin deps. 3. Create src/site/markdown/test.md containing a sentence with an apostrophe. 4. mvn site 5. Examine target/site/test.md. Expected: sentence would be reproduced with apos. Actual: sentence is missing apos. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-682) Apostrophe's in Markdown are removed resulting in HTML full of spelling error
[ https://jira.codehaus.org/browse/MSITE-682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318647#comment-318647 ] Alex Collins commented on MSITE-682: Naturally I mean "spelling errors" not "spelling error". Which is a grammatical error. > Apostrophe's in Markdown are removed resulting in HTML full of spelling error > - > > Key: MSITE-682 > URL: https://jira.codehaus.org/browse/MSITE-682 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug >Affects Versions: 3.1 >Reporter: Alex Collins > > Repro: > 1. Create Maven 3 project. > 2. Add site 3.1 to plugins, add doxia-markdown-module:1.3 to plugin deps. > 3. Create src/site/markdown/test.md containing a sentence with an apostrophe. > 4. mvn site > 5. Examine target/site/test.md. > Expected: sentence would be reproduced with apos. > Actual: sentence is missing apos. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (ARCHETYPE-429) JIRA report in site only shows fixes up to v2.1 of plugin
[ https://jira.codehaus.org/browse/ARCHETYPE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318646#comment-318646 ] Anders Hammar commented on ARCHETYPE-429: - Checking several of the core plugins, I only found the JIRA report in the m-plugin-p's site. I think we should remove this report as it doesn't add much information. If someone is interested in what has been fixed that info can be accessed directly from JIRA instead. > JIRA report in site only shows fixes up to v2.1 of plugin > - > > Key: ARCHETYPE-429 > URL: https://jira.codehaus.org/browse/ARCHETYPE-429 > Project: Maven Archetype > Issue Type: Bug > Components: Documentation >Affects Versions: 2.2 > Environment: n/a >Reporter: Anders Hammar >Assignee: Anders Hammar >Priority: Minor > > The plugin's site has a JIRA report than only shows versions 2.1, 2.0, > 2.0-alpha-5. This should be updated according to Apache Maven project plugin > standards. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (ARCHETYPE-429) JIRA report in site only shows fixes up to v2.1 of plugin
Anders Hammar created ARCHETYPE-429: --- Summary: JIRA report in site only shows fixes up to v2.1 of plugin Key: ARCHETYPE-429 URL: https://jira.codehaus.org/browse/ARCHETYPE-429 Project: Maven Archetype Issue Type: Bug Components: Documentation Affects Versions: 2.2 Environment: n/a Reporter: Anders Hammar Priority: Minor The plugin's site has a JIRA report than only shows versions 2.1, 2.0, 2.0-alpha-5. This should be updated according to Apache Maven project plugin standards. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (ARCHETYPE-429) JIRA report in site only shows fixes up to v2.1 of plugin
[ https://jira.codehaus.org/browse/ARCHETYPE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Hammar reassigned ARCHETYPE-429: --- Assignee: Anders Hammar > JIRA report in site only shows fixes up to v2.1 of plugin > - > > Key: ARCHETYPE-429 > URL: https://jira.codehaus.org/browse/ARCHETYPE-429 > Project: Maven Archetype > Issue Type: Bug > Components: Documentation >Affects Versions: 2.2 > Environment: n/a >Reporter: Anders Hammar >Assignee: Anders Hammar >Priority: Minor > > The plugin's site has a JIRA report than only shows versions 2.1, 2.0, > 2.0-alpha-5. This should be updated according to Apache Maven project plugin > standards. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (ARCHETYPE-428) Improve Generate project in batch mode doc page
[ https://jira.codehaus.org/browse/ARCHETYPE-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Hammar closed ARCHETYPE-428. --- Resolution: Fixed Fix Version/s: 2.3 Fixed in [r1442075|http://svn.apache.org/r1442075] with output from plugin v2.2. > Improve Generate project in batch mode doc page > --- > > Key: ARCHETYPE-428 > URL: https://jira.codehaus.org/browse/ARCHETYPE-428 > Project: Maven Archetype > Issue Type: Improvement > Components: Documentation >Affects Versions: 2.2 > Environment: n/a >Reporter: Anders Hammar >Assignee: Anders Hammar >Priority: Minor > Fix For: 2.3 > > > The "Generate project in batch mode" doc page could be improved: > * Update according to output from latest plugin version > * Change "1.5" package name to something better > * Version of created project should be 1.0-SNAPSHOT to conform to Maven best > practices -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (ARCHETYPE-428) Improve Generate project in batch mode doc page
[ https://jira.codehaus.org/browse/ARCHETYPE-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Hammar reassigned ARCHETYPE-428: --- Assignee: Anders Hammar > Improve Generate project in batch mode doc page > --- > > Key: ARCHETYPE-428 > URL: https://jira.codehaus.org/browse/ARCHETYPE-428 > Project: Maven Archetype > Issue Type: Improvement > Components: Documentation >Affects Versions: 2.2 > Environment: n/a >Reporter: Anders Hammar >Assignee: Anders Hammar >Priority: Minor > > The "Generate project in batch mode" doc page could be improved: > * Update according to output from latest plugin version > * Change "1.5" package name to something better > * Version of created project should be 1.0-SNAPSHOT to conform to Maven best > practices -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (ARCHETYPE-428) Improve Generate project in batch mode doc page
Anders Hammar created ARCHETYPE-428: --- Summary: Improve Generate project in batch mode doc page Key: ARCHETYPE-428 URL: https://jira.codehaus.org/browse/ARCHETYPE-428 Project: Maven Archetype Issue Type: Improvement Components: Documentation Affects Versions: 2.2 Environment: n/a Reporter: Anders Hammar Priority: Minor The "Generate project in batch mode" doc page could be improved: * Update according to output from latest plugin version * Change "1.5" package name to something better * Version of created project should be 1.0-SNAPSHOT to conform to Maven best practices -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-952) Incompatibility with future release 4.12 of junit (Categories)
[ https://jira.codehaus.org/browse/SUREFIRE-952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Gross closed SUREFIRE-952. -- Resolution: Not A Bug > Incompatibility with future release 4.12 of junit (Categories) > -- > > Key: SUREFIRE-952 > URL: https://jira.codehaus.org/browse/SUREFIRE-952 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Affects Versions: 2.12.2, 2.12.4 >Reporter: Henning Gross >Priority: Blocker > Attachments: surefire-952.zip > > > Junit is introducing some interesting new features on Categories in 4.12. > @Category will become @Inherited and @ExcludeCategory/@IncludeCategory will > accept a class-array instead of just a single class. As we need these > urgently we are currently testing with the current snapshot of junit > (https://oss.sonatype.org/content/repositories/snapshots/junit/junit/4.12-SNAPSHOT/). > Unfortuneately the version seems to be incompatible. > All tests are executed always. Regardless of the settings in or > . Using 4.11 works fine. I do not know why this happens and > therefore cannot provide a patch but I would love to see it fixed. If someone > points me at the cause I will happily find a solution. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5430) use wagon 2.4
Olivier Lamy created MNG-5430: - Summary: use wagon 2.4 Key: MNG-5430 URL: https://jira.codehaus.org/browse/MNG-5430 Project: Maven 2 & 3 Issue Type: Bug Components: Dependencies Affects Versions: 3.0.4 Reporter: Olivier Lamy -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5430) use wagon 2.4
[ https://jira.codehaus.org/browse/MNG-5430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MNG-5430: -- Priority: Blocker (was: Major) > use wagon 2.4 > - > > Key: MNG-5430 > URL: https://jira.codehaus.org/browse/MNG-5430 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0.4 >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Blocker > Fix For: 3.0.5 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5430) use wagon 2.4
[ https://jira.codehaus.org/browse/MNG-5430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MNG-5430: -- Fix Version/s: 3.0.5 Assignee: Olivier Lamy > use wagon 2.4 > - > > Key: MNG-5430 > URL: https://jira.codehaus.org/browse/MNG-5430 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0.4 >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 3.0.5 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
