[jira] (MINDEXER-69) Severe keyword serach performance regression

2012-11-20 Thread JIRA 

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

Tamás Cservenák updated MINDEXER-69:


Fix Version/s: 5.1.0
 Assignee: Tamás Cservenák

> Severe keyword serach performance regression 
> -
>
> Key: MINDEXER-69
> URL: https://jira.codehaus.org/browse/MINDEXER-69
> Project: Maven Indexer
>  Issue Type: Bug
>Affects Versions: 5.0.0
>Reporter: Igor Fedorenko
>Assignee: Tamás Cservenák
> Fix For: 5.1.0
>
> Attachments: 
> 0001-MINDEXER-69-reuse-rewritten-query-for-all-artifacts.patch
>
>
> I have a performance regression test evaluates performance of keyword search 
> from 15 indexes of various sizes. Everything else being equal, I see ~2.3 
> times performance drop going from maven indexer 4.1.2 to 5.0.0. I'll attach 
> proposed patch with analysis of the problem shortly.

--
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] (MINDEXER-69) Severe keyword serach performance regression

2012-11-20 Thread JIRA 

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

Tamás Cservenák closed MINDEXER-69.
---

Resolution: Fixed

Applied.
http://svn.apache.org/viewvc?view=revision&revision=1411588

> Severe keyword serach performance regression 
> -
>
> Key: MINDEXER-69
> URL: https://jira.codehaus.org/browse/MINDEXER-69
> Project: Maven Indexer
>  Issue Type: Bug
>Affects Versions: 5.0.0
>Reporter: Igor Fedorenko
>Assignee: Tamás Cservenák
> Fix For: 5.1.0
>
> Attachments: 
> 0001-MINDEXER-69-reuse-rewritten-query-for-all-artifacts.patch
>
>
> I have a performance regression test evaluates performance of keyword search 
> from 15 indexes of various sizes. Everything else being equal, I see ~2.3 
> times performance drop going from maven indexer 4.1.2 to 5.0.0. I'll attach 
> proposed patch with analysis of the problem shortly.

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

[jira] (MRELEASE-787) release:prepare-with-pom fails when suppressCommitBeforeTag is used (SVN)

2012-11-20 Thread Erik Schepers (JIRA) 

[ 
https://jira.codehaus.org/browse/MRELEASE-787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313959#comment-313959
 ] 

Erik Schepers commented on MRELEASE-787:


Retested with 2.4-SNAPSHOT (based on 
[r1411374|http://svn.apache.org/viewvc?rev=1411374&view=rev]).

The build still fails. Now there are 2 problems:

# The tag is created, but the {{release-pom.xml}} is not part of the tag
# Committing the next development version to trunk fails (see logging below)

{noformat}
[INFO] Modified POMs are not committed because suppressCommitBeforeTagOrBranch 
is set to false.
[INFO] Tagging release with the label democonsumer-parent-5.1.0...
[INFO] Executing: /bin/sh -c cd 
/work/tactbl2/di788/tmp/checkoutTESTREPO/TESTREPO/trunk/Demo/DemoConsumer && 
svn --non-interactive copy --file /tmp/maven-scm-247432815.commit . 
file:///work/tactbl2/di788/tmp/TESTREPO/tags/Demo/DemoConsumer/democonsumer-parent-5.1.0
[INFO] Working directory: 
/work/tactbl2/di788/tmp/checkoutTESTREPO/TESTREPO/trunk/Demo/DemoConsumer
[INFO] Transforming 'DemoConsumer (TP)'...
[INFO] Transforming 'Consumer (TS)'...
[INFO] Removing release POM for 'DemoConsumer (TP)'...
[INFO] Removing release POM for 'Consumer (TS)'...
[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd 
/work/tactbl2/di788/tmp/checkoutTESTREPO/TESTREPO/trunk/Demo/DemoConsumer && 
svn --non-interactive commit --file /tmp/maven-scm-2116850369.commit --targets 
/tmp/maven-scm-8006235259427407667-targets
[INFO] Working directory: 
/work/tactbl2/di788/tmp/checkoutTESTREPO/TESTREPO/trunk/Demo/DemoConsumer
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] DemoConsumer (TP) . FAILURE [9.037s]
[INFO] Consumer (TS) . SUCCESS [0.013s]
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 9.701s
[INFO] Finished at: Tue Nov 20 09:34:26 CET 2012
[INFO] Final Memory: 34M/583M
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-release-plugin:2.4-SNAPSHOT:prepare-with-pom 
(default-cli) on project democonsumer-parent: Unable to commit files
[ERROR] Provider message:
[ERROR] The svn command failed.
[ERROR] Command output:
[ERROR] svn: Commit failed (details follow):
[ERROR] svn: 
'/work/tactbl2/di788/tmp/checkoutTESTREPO/TESTREPO/trunk/Demo/DemoConsumer/release-pom.xml'
 is not under version control
[ERROR] -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal 
org.apache.maven.plugins:maven-release-plugin:2.4-SNAPSHOT:prepare-with-pom 
(default-cli) on project democonsumer-parent: Unable to commit files
Provider message:
The svn command failed.
Command output:
svn: Commit failed (details follow):
svn: 
'/work/tactbl2/di788/tmp/checkoutTESTREPO/TESTREPO/trunk/Demo/DemoConsumer/release-pom.xml'
 is not under version control

at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at 
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.MojoFailureE

[jira] (MINVOKER-115) install goal doesn't install required plugins (from the reactor build) to the local repo

2012-11-20 Thread Anders Hammar (JIRA) 

[ 
https://jira.codehaus.org/browse/MINVOKER-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313967#comment-313967
 ] 

Anders Hammar commented on MINVOKER-115:


Have you fixed the cause you found on trunk? I've written an IT but can't get 
it to fail with trunk. But it seems to fail with v1.7.

> install goal doesn't install required plugins (from the reactor build) to the 
> local repo
> 
>
> Key: MINVOKER-115
> URL: https://jira.codehaus.org/browse/MINVOKER-115
> Project: Maven 2.x Invoker Plugin
>  Issue Type: Bug
>Affects Versions: 1.5
> Environment: MacOS 10.6.6
> Mac Java 1.6
> Maven 3.0.2
>Reporter: Anders Hammar
>
> In a multimodule build where the m-invoker-p is used to perform integration 
> tests for an archetype. In the build, a maven plugin is first created. Then a 
> maven archetype.
> For the archetype project, integration test is performed where a project is 
> generated based on the archetype and then a build (mvn verify) is done.
> However, the build fails as it can't find the maven plugin built earlier in 
> the reactor build. The maven-invoker-plugin:install goal installs all 
> dependencies to the cloned local repo, but it doesn't install the plugin 
> built.

--
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] (MINVOKER-115) install goal doesn't install required plugins (from the reactor build) to the local repo

2012-11-20 Thread Anders Hammar (JIRA) 

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

Anders Hammar updated MINVOKER-115:
---

Attachment: MINVOKER-115-IT.patch

Attaching the IT.

> install goal doesn't install required plugins (from the reactor build) to the 
> local repo
> 
>
> Key: MINVOKER-115
> URL: https://jira.codehaus.org/browse/MINVOKER-115
> Project: Maven 2.x Invoker Plugin
>  Issue Type: Bug
>Affects Versions: 1.5
> Environment: MacOS 10.6.6
> Mac Java 1.6
> Maven 3.0.2
>Reporter: Anders Hammar
> Attachments: MINVOKER-115-IT.patch
>
>
> In a multimodule build where the m-invoker-p is used to perform integration 
> tests for an archetype. In the build, a maven plugin is first created. Then a 
> maven archetype.
> For the archetype project, integration test is performed where a project is 
> generated based on the archetype and then a build (mvn verify) is done.
> However, the build fails as it can't find the maven plugin built earlier in 
> the reactor build. The maven-invoker-plugin:install goal installs all 
> dependencies to the cloned local repo, but it doesn't install the plugin 
> built.

--
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-5346) update maven-plugin-plugin:descriptor default binding from generate-resources phase to process-classes

2012-11-20 Thread Karl Heinz Marbaise (JIRA) 

[ 
https://jira.codehaus.org/browse/MNG-5346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313976#comment-313976
 ] 

Karl Heinz Marbaise commented on MNG-5346:
--

The current solution to get it working without the above 
skipErrorNoDescriptorsFound configuration:

{code}

  
org.apache.maven.plugins
maven-plugin-plugin

  XXX


  
default-descriptor

  descriptor

process-classes
  
  
help-descriptor

  helpmojo

process-classes
  

  

{code}

> update maven-plugin-plugin:descriptor default binding from generate-resources 
> phase to process-classes
> --
>
> Key: MNG-5346
> URL: https://jira.codehaus.org/browse/MNG-5346
> Project: Maven 2 & 3
>  Issue Type: Wish
>Reporter: Herve Boutemy
>
> with Java annotations support added in Maven Plugin Tools 3.0, descriptor 
> cannot be generated before compilation
> actually, to use annotations, users need to add extra configuration to avoid 
> failure and to bind the goal to proper phase:
> {code:xml}
>   true
> 
> 
>   
> mojo-descriptor
> 
>   descriptor
> 
>   {code}
> changing the default lifecycle binding will enable removal of this extra 
> configuration
> notice that removing the configuration from pom will require to check newer 
> Maven version is used to build 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] (MNG-5346) update maven-plugin-plugin:descriptor default binding from generate-resources phase to process-classes

2012-11-20 Thread Karl Heinz Marbaise (JIRA) 

[ 
https://jira.codehaus.org/browse/MNG-5346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313976#comment-313976
 ] 

Karl Heinz Marbaise edited comment on MNG-5346 at 11/20/12 5:23 AM:


The current solution to get it working without the above 
skipErrorNoDescriptorsFound configuration:

{code}

  
org.apache.maven.plugins
maven-plugin-plugin

  configurator


  
default-descriptor

  descriptor

process-classes
  
  
help-descriptor

  helpmojo

process-classes
  

  

{code}

  was (Author: khmarbaise):
The current solution to get it working without the above 
skipErrorNoDescriptorsFound configuration:

{code}

  
org.apache.maven.plugins
maven-plugin-plugin

  XXX


  
default-descriptor

  descriptor

process-classes
  
  
help-descriptor

  helpmojo

process-classes
  

  

{code}
  
> update maven-plugin-plugin:descriptor default binding from generate-resources 
> phase to process-classes
> --
>
> Key: MNG-5346
> URL: https://jira.codehaus.org/browse/MNG-5346
> Project: Maven 2 & 3
>  Issue Type: Wish
>Reporter: Herve Boutemy
>
> with Java annotations support added in Maven Plugin Tools 3.0, descriptor 
> cannot be generated before compilation
> actually, to use annotations, users need to add extra configuration to avoid 
> failure and to bind the goal to proper phase:
> {code:xml}
>   true
> 
> 
>   
> mojo-descriptor
> 
>   descriptor
> 
>   {code}
> changing the default lifecycle binding will enable removal of this extra 
> configuration
> notice that removing the configuration from pom will require to check newer 
> Maven version is used to build 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] (MPECLIPSE-138) Generated .classpath files are not compatible with m2e

2012-11-20 Thread Radim Kolar (JIRA) 
Radim Kolar created MPECLIPSE-138:
-

 Summary: Generated .classpath files are not compatible with m2e
 Key: MPECLIPSE-138
 URL: https://jira.codehaus.org/browse/MPECLIPSE-138
 Project: Maven 1.x Eclipse Plugin
  Issue Type: Bug
Reporter: Radim Kolar
Priority: Critical


If you run Eclipse maven plugin m2e included in Eclipse Juno on project files 
generated by maven eclipse plugin, m2e will complain about Unsupported 
IClasspathEntry kind=4.

More information here:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=394042

--
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-5336) Descriptor Reference for settings.xml is incorrect

2012-11-20 Thread Dennis Lundberg (JIRA) 

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

Dennis Lundberg closed MNG-5336.


Resolution: Fixed

Modello was updated to version 1.6 in 
[r1411559|http://svn.apache.org/viewvc?view=revision&revision=1411559]. That 
solved it.

> Descriptor Reference for settings.xml is incorrect
> --
>
> Key: MNG-5336
> URL: https://jira.codehaus.org/browse/MNG-5336
> Project: Maven 2 & 3
>  Issue Type: Bug
>  Components: Settings
>Affects Versions: 3.0.4
>Reporter: Jan Hänsli
>Assignee: Dennis Lundberg
> Fix For: 3.1.0
>
>
> The example settings.xml found here 
> (http://maven.apache.org/ref/3.0.4/maven-settings/settings.html) is not valid!
> 65: 
> 66:   value
> 67: 
> bad line 67:  
> correct line 67:  
> Steps to reproduce:
> - Copy & Paste the document into your IDE or XML editor.
> - Start the xml validator and try to validate the document against 
> http://maven.apache.org/xsd/settings-1.1.0.xsd

--
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] (MENFORCER-144) generate every enforcer plugin site in /enforcer and redirect previous /plugins/maven-enforcer-plugin

2012-11-20 Thread Herve Boutemy (JIRA) 

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

Herve Boutemy closed MENFORCER-144.
---

Resolution: Fixed
  Assignee: Herve Boutemy

done in [r1359931|http://svn.apache.org/viewvc?view=revision&revision=1359931]

> generate every enforcer plugin site in /enforcer and redirect previous 
> /plugins/maven-enforcer-plugin
> -
>
> Key: MENFORCER-144
> URL: https://jira.codehaus.org/browse/MENFORCER-144
> Project: Maven 2.x Enforcer Plugin
>  Issue Type: Task
>  Components: Plugin
>Affects Versions: 1.1.1
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
> Fix For: 1.2
>
>
> like SUREFIRE-924, this will be necessary for 
> svnpubsub+maven-scm-publish-plugin migration

--
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] (MENFORCER-145) use maven-plugin-tools' java 5 annotations

2012-11-20 Thread Herve Boutemy (JIRA) 
Herve Boutemy created MENFORCER-145:
---

 Summary: use maven-plugin-tools' java 5 annotations
 Key: MENFORCER-145
 URL: https://jira.codehaus.org/browse/MENFORCER-145
 Project: Maven 2.x Enforcer Plugin
  Issue Type: Task
  Components: Plugin
Affects Versions: 1.1.1
Reporter: Herve Boutemy


MPLUGIN-203

--
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] (MENFORCER-145) use maven-plugin-tools' java 5 annotations

2012-11-20 Thread Herve Boutemy (JIRA) 

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

Herve Boutemy closed MENFORCER-145.
---

   Resolution: Fixed
Fix Version/s: 1.2
 Assignee: Herve Boutemy

done in [r1411846|http://svn.apache.org/viewvc?rev=1411846&view=rev]

> use maven-plugin-tools' java 5 annotations
> --
>
> Key: MENFORCER-145
> URL: https://jira.codehaus.org/browse/MENFORCER-145
> Project: Maven 2.x Enforcer Plugin
>  Issue Type: Task
>  Components: Plugin
>Affects Versions: 1.1.1
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
> Fix For: 1.2
>
>
> MPLUGIN-203

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

[jira] (MRELEASE-802) Windows 7 russian - plugin uses wrong encoding for path to .m2\repository during release:prepare

2012-11-20 Thread Victor Homyakov (JIRA) 
Victor Homyakov created MRELEASE-802:


 Summary: Windows 7 russian - plugin uses wrong encoding for path 
to .m2\repository during release:prepare
 Key: MRELEASE-802
 URL: https://jira.codehaus.org/browse/MRELEASE-802
 Project: Maven 2.x Release Plugin
  Issue Type: Bug
  Components: prepare
Affects Versions: 2.3.2
 Environment: OS Windows 7 russian
User account has national characters: USERPROFILE=C:\Users\Виктор
Maven .m2 folder has default location in %USERPROFILE%\.m2 i.e. 
C:\Users\Виктор\.m2

Reporter: Victor Homyakov
Priority: Critical


{{mvn clean install}} and {{mvn clean deploy}} commands are working without 
problems - needed plugins are downloaded and jars installed to my 
{{.m2\repository}}.

But when starting mvn release:prepare, it gives errors with output:

{code}
[INFO] [release:prepare {execution: default-cli}]
[INFO] Resuming release from phase 'run-preparation-goals'
[INFO] Executing goals 'clean verify'...
[INFO] Executing: cmd.exe /X /C "C:\Bin\maven\bin\..\bin\mvn -s 
C:\Users\51FB~1\AppData\Local\Temp\release-settings7085663422359991829.xml 
clean verify --no-plugin-updates -Psonatype-oss-release -P sonatype-oss-release"
[INFO] Scanning for projects...
Downloading: 
http://repo1.maven.org/maven2/org/sonatype/oss/oss-parent/7/oss-parent-7.pom
[WARNING] Unable to get resource 'org.sonatype.oss:oss-parent:pom:7' from 
repository central (http://repo1.maven.org/maven2): Specified destination 
directory cannot be created: 
C:\Users\??\.m2\repository\org\sonatype\oss\oss-parent\7
[INFO] 

[ERROR] FATAL ERROR
[INFO] 

[INFO] Error building POM (may not be this project's POM).
{code}

Note username replaced with question signs: {{C:\Users\??\.m2\repository\}}

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

[jira] (MRELEASE-802) Windows 7 russian - plugin uses wrong encoding for path to .m2\repository during release:prepare

2012-11-20 Thread Victor Homyakov (JIRA) 

[ 
https://jira.codehaus.org/browse/MRELEASE-802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=314035#comment-314035
 ] 

Victor Homyakov commented on MRELEASE-802:
--

JIRA itself has problems with national characters and backslashes... Another 
try:

USERNAME=Виктор
USERPROFILE=C:\Users\Виктор

Maven searches repository in C:\Users\\??\.m2\repository\ instead of 
C:\Users\Виктор\.m2\repository\

(When I place single backslash between "Users" and "?" - it isn't visible, when 
place two backslashes - they both are visible. WTF?)


> Windows 7 russian - plugin uses wrong encoding for path to .m2\repository 
> during release:prepare
> 
>
> Key: MRELEASE-802
> URL: https://jira.codehaus.org/browse/MRELEASE-802
> Project: Maven 2.x Release Plugin
>  Issue Type: Bug
>  Components: prepare
>Affects Versions: 2.3.2
> Environment: OS Windows 7 russian
> User account has national characters: USERPROFILE=C:\Users\Виктор
> Maven .m2 folder has default location in %USERPROFILE%\.m2 i.e. 
> C:\Users\Виктор\.m2
>Reporter: Victor Homyakov
>Priority: Critical
>
> {{mvn clean install}} and {{mvn clean deploy}} commands are working without 
> problems - needed plugins are downloaded and jars installed to my 
> {{.m2\repository}}.
> But when starting mvn release:prepare, it gives errors with output:
> {code}
> [INFO] [release:prepare {execution: default-cli}]
> [INFO] Resuming release from phase 'run-preparation-goals'
> [INFO] Executing goals 'clean verify'...
> [INFO] Executing: cmd.exe /X /C "C:\Bin\maven\bin\..\bin\mvn -s 
> C:\Users\51FB~1\AppData\Local\Temp\release-settings7085663422359991829.xml 
> clean verify --no-plugin-updates -Psonatype-oss-release -P 
> sonatype-oss-release"
> [INFO] Scanning for projects...
> Downloading: 
> http://repo1.maven.org/maven2/org/sonatype/oss/oss-parent/7/oss-parent-7.pom
> [WARNING] Unable to get resource 'org.sonatype.oss:oss-parent:pom:7' from 
> repository central (http://repo1.maven.org/maven2): Specified destination 
> directory cannot be created: 
> C:\Users\??\.m2\repository\org\sonatype\oss\oss-parent\7
> [INFO] 
> 
> [ERROR] FATAL ERROR
> [INFO] 
> 
> [INFO] Error building POM (may not be this project's POM).
> {code}
> Note username replaced with question signs: 
> {{C:\Users\??\.m2\repository\}}

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

[jira] (MRELEASE-802) Windows 7 russian - plugin uses wrong encoding for path to .m2\repository during release:prepare

2012-11-20 Thread Victor Homyakov (JIRA) 

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

Victor Homyakov updated MRELEASE-802:
-

Attachment: screenshot.png

The only reliable way to show non-ascii characters

> Windows 7 russian - plugin uses wrong encoding for path to .m2\repository 
> during release:prepare
> 
>
> Key: MRELEASE-802
> URL: https://jira.codehaus.org/browse/MRELEASE-802
> Project: Maven 2.x Release Plugin
>  Issue Type: Bug
>  Components: prepare
>Affects Versions: 2.3.2
> Environment: OS Windows 7 russian
> User account has national characters: USERPROFILE=C:\Users\Виктор
> Maven .m2 folder has default location in %USERPROFILE%\.m2 i.e. 
> C:\Users\Виктор\.m2
>Reporter: Victor Homyakov
>Priority: Critical
> Attachments: screenshot.png
>
>
> {{mvn clean install}} and {{mvn clean deploy}} commands are working without 
> problems - needed plugins are downloaded and jars installed to my 
> {{.m2\repository}}.
> But when starting mvn release:prepare, it gives errors with output:
> {code}
> [INFO] [release:prepare {execution: default-cli}]
> [INFO] Resuming release from phase 'run-preparation-goals'
> [INFO] Executing goals 'clean verify'...
> [INFO] Executing: cmd.exe /X /C "C:\Bin\maven\bin\..\bin\mvn -s 
> C:\Users\51FB~1\AppData\Local\Temp\release-settings7085663422359991829.xml 
> clean verify --no-plugin-updates -Psonatype-oss-release -P 
> sonatype-oss-release"
> [INFO] Scanning for projects...
> Downloading: 
> http://repo1.maven.org/maven2/org/sonatype/oss/oss-parent/7/oss-parent-7.pom
> [WARNING] Unable to get resource 'org.sonatype.oss:oss-parent:pom:7' from 
> repository central (http://repo1.maven.org/maven2): Specified destination 
> directory cannot be created: 
> C:\Users\??\.m2\repository\org\sonatype\oss\oss-parent\7
> [INFO] 
> 
> [ERROR] FATAL ERROR
> [INFO] 
> 
> [INFO] Error building POM (may not be this project's POM).
> {code}
> Note username replaced with question signs: 
> {{C:\Users\??\.m2\repository\}}

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

[jira] (MRELEASE-802) Windows 7 russian - plugin uses wrong encoding for path to .m2\repository during release:prepare

2012-11-20 Thread Victor Homyakov (JIRA) 

[ 
https://jira.codehaus.org/browse/MRELEASE-802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=314037#comment-314037
 ] 

Victor Homyakov edited comment on MRELEASE-802 at 11/20/12 3:14 PM:


The only reliable way to show non-ascii characters is screenshot

  was (Author: victor-homyakov):
The only reliable way to show non-ascii characters
  
> Windows 7 russian - plugin uses wrong encoding for path to .m2\repository 
> during release:prepare
> 
>
> Key: MRELEASE-802
> URL: https://jira.codehaus.org/browse/MRELEASE-802
> Project: Maven 2.x Release Plugin
>  Issue Type: Bug
>  Components: prepare
>Affects Versions: 2.3.2
> Environment: OS Windows 7 russian
> User account has national characters: USERPROFILE=C:\Users\Виктор
> Maven .m2 folder has default location in %USERPROFILE%\.m2 i.e. 
> C:\Users\Виктор\.m2
>Reporter: Victor Homyakov
>Priority: Critical
> Attachments: screenshot.png
>
>
> {{mvn clean install}} and {{mvn clean deploy}} commands are working without 
> problems - needed plugins are downloaded and jars installed to my 
> {{.m2\repository}}.
> But when starting mvn release:prepare, it gives errors with output:
> {code}
> [INFO] [release:prepare {execution: default-cli}]
> [INFO] Resuming release from phase 'run-preparation-goals'
> [INFO] Executing goals 'clean verify'...
> [INFO] Executing: cmd.exe /X /C "C:\Bin\maven\bin\..\bin\mvn -s 
> C:\Users\51FB~1\AppData\Local\Temp\release-settings7085663422359991829.xml 
> clean verify --no-plugin-updates -Psonatype-oss-release -P 
> sonatype-oss-release"
> [INFO] Scanning for projects...
> Downloading: 
> http://repo1.maven.org/maven2/org/sonatype/oss/oss-parent/7/oss-parent-7.pom
> [WARNING] Unable to get resource 'org.sonatype.oss:oss-parent:pom:7' from 
> repository central (http://repo1.maven.org/maven2): Specified destination 
> directory cannot be created: 
> C:\Users\??\.m2\repository\org\sonatype\oss\oss-parent\7
> [INFO] 
> 
> [ERROR] FATAL ERROR
> [INFO] 
> 
> [INFO] Error building POM (may not be this project's POM).
> {code}
> Note username replaced with question signs: 
> {{C:\Users\??\.m2\repository\}}

--
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] (MINVOKER-115) install goal doesn't install required plugins (from the reactor build) to the local repo

2012-11-20 Thread Anders Hammar (JIRA) 

[ 
https://jira.codehaus.org/browse/MINVOKER-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=314038#comment-314038
 ] 

Anders Hammar commented on MINVOKER-115:


This IT fails for me with trunk as well after cleaning up the local repo...

> install goal doesn't install required plugins (from the reactor build) to the 
> local repo
> 
>
> Key: MINVOKER-115
> URL: https://jira.codehaus.org/browse/MINVOKER-115
> Project: Maven 2.x Invoker Plugin
>  Issue Type: Bug
>Affects Versions: 1.5
> Environment: MacOS 10.6.6
> Mac Java 1.6
> Maven 3.0.2
>Reporter: Anders Hammar
> Attachments: MINVOKER-115-IT.patch
>
>
> In a multimodule build where the m-invoker-p is used to perform integration 
> tests for an archetype. In the build, a maven plugin is first created. Then a 
> maven archetype.
> For the archetype project, integration test is performed where a project is 
> generated based on the archetype and then a build (mvn verify) is done.
> However, the build fails as it can't find the maven plugin built earlier in 
> the reactor build. The maven-invoker-plugin:install goal installs all 
> dependencies to the cloned local repo, but it doesn't install the plugin 
> built.

--
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-187) incremental stuff detect changes even if nothing has changed means too much compilation

2012-11-20 Thread Olivier Lamy (JIRA) 
Olivier Lamy created MCOMPILER-187:
--

 Summary: incremental stuff detect changes even if nothing has 
changed means too much compilation
 Key: MCOMPILER-187
 URL: https://jira.codehaus.org/browse/MCOMPILER-187
 Project: Maven 2.x Compiler Plugin
  Issue Type: Bug
Affects Versions: 3.0
Reporter: Olivier Lamy
Priority: Critical




--
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-187) incremental stuff detect changes even if nothing has changed means too much compilation

2012-11-20 Thread Daniel Kulp (JIRA) 

[ 
https://jira.codehaus.org/browse/MCOMPILER-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=314039#comment-314039
 ] 

Daniel Kulp commented on MCOMPILER-187:
---


This occurs with CXF.  If I update cxf/trunk/pom.xml with 3.0 version of plugin 
and go into api and run "mvn -Pfastinstall" a couple times, I always see the:

{code}
Changes detected - recompiling the module!
Compiling 518 source files
{code}

messages.   I was hoping to be able to run with -X to display debug information 
to see what changes it was detecting to maybe help figure out why, but that 
didn't yield anything useful at all.  It would be good to get some debug 
information spit out for this.


> incremental stuff detect changes even if nothing has changed means too much 
> compilation
> ---
>
> Key: MCOMPILER-187
> URL: https://jira.codehaus.org/browse/MCOMPILER-187
> Project: Maven 2.x Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.0
>Reporter: Olivier Lamy
>Priority: Critical
>


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

[jira] (MRELEASE-787) release:prepare-with-pom fails when suppressCommitBeforeTag is used (SVN)

2012-11-20 Thread Robert Scholte (JIRA) 

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

Robert Scholte reopened MRELEASE-787:
-


> release:prepare-with-pom fails when suppressCommitBeforeTag is used (SVN)
> -
>
> Key: MRELEASE-787
> URL: https://jira.codehaus.org/browse/MRELEASE-787
> Project: Maven 2.x Release Plugin
>  Issue Type: Bug
>  Components: prepare-with-pom
>Affects Versions: 2.2, 2.3.2
> Environment: Subversion 1.6.12
>Reporter: Brian Albers
>Assignee: Robert Scholte
> Fix For: 2.4
>
> Attachments: MRELEASE-787.diff
>
>
> When running a prepare-with-pom goal, using the suppressCommitBeforeTag 
> option causes the removal of the release-pom.xml to fail.
> This is due to the fact that the SVN command to remove the release-pom won't 
> complete because the release-pom was never committed. The ultimate error is 
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare-with-pom
> (default-cli) on project com.example.project: Cannot remove release POMs from 
> SCM
> [ERROR] Provider message:
> [ERROR] The svn command failed.
> [ERROR] Command output:
> [ERROR] svn: Use --force to override this restriction
> [ERROR] svn: 'C:\code\release-pom.xml' has local modifications
> {code}
> When suppressCommitBeforeTag is not used, the SCM operations are:
> # Status
> # Add the release-pom.xml
> # (build)
> # Commit with release version
> # Copy (create the tag)
> # Remove the release-pom.xml
> # Commit with next development version
> When suppressCommitBeforeTag is used, step #4 is omitted, which causes step 
> #6 to fail with the supplied error. In both cases, the tag successfully has 
> the release-pom.xml included.
> Could the --force option be used to suppress the warning?

--
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] (MINVOKER-115) install goal doesn't install required plugins (from the reactor build) to the local repo

2012-11-20 Thread Robert Scholte (JIRA) 

[ 
https://jira.codehaus.org/browse/MINVOKER-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=314041#comment-314041
 ] 

Robert Scholte commented on MINVOKER-115:
-

Since the plugin was created in {{plugin}}-module and reused in an IT of the 
{{itests}}-module, it is out of reach; the {{maven-invoker-plugin}} can't 
discover that the plugin is used.
I'm thinking of 2 parameters: {{includeReactorProjects}} and 
{{excludeReactorProjects}}, where you can specify 
{{groupId:artifactId[:type:classifier]}} with '*'-support.
Sounds reasonable?


> install goal doesn't install required plugins (from the reactor build) to the 
> local repo
> 
>
> Key: MINVOKER-115
> URL: https://jira.codehaus.org/browse/MINVOKER-115
> Project: Maven 2.x Invoker Plugin
>  Issue Type: Bug
>Affects Versions: 1.5
> Environment: MacOS 10.6.6
> Mac Java 1.6
> Maven 3.0.2
>Reporter: Anders Hammar
> Attachments: MINVOKER-115-IT.patch
>
>
> In a multimodule build where the m-invoker-p is used to perform integration 
> tests for an archetype. In the build, a maven plugin is first created. Then a 
> maven archetype.
> For the archetype project, integration test is performed where a project is 
> generated based on the archetype and then a build (mvn verify) is done.
> However, the build fails as it can't find the maven plugin built earlier in 
> the reactor build. The maven-invoker-plugin:install goal installs all 
> dependencies to the cloned local repo, but it doesn't install the plugin 
> built.

--
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-289) Incorrect warning with javax.xml

2012-11-20 Thread Arnaud Heritier (JIRA) 

[ 
https://jira.codehaus.org/browse/MDEP-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=314043#comment-314043
 ] 

Arnaud Heritier commented on MDEP-289:
--

I agree with your anlyze and he fact that classes included in the JDK shouldn't 
be reported as missing deps (but I don't know how to fix that for now - without 
a dirty hack)

> Incorrect warning with javax.xml
> 
>
> Key: MDEP-289
> URL: https://jira.codehaus.org/browse/MDEP-289
> Project: Maven 2.x Dependency Plugin
>  Issue Type: Bug
>  Components: analyze
>Affects Versions: 2.1
> Environment: OS : Windows XP
> Maven 2.2.1
> Java 1.5
>Reporter: zaccret
> Attachments: sandbox.zip
>
>
> When you use some javax.xml classes in a project and that you have transitive 
> dependencies containing these classes, you will get a warning if you analyze 
> your dependencies (Used undeclared dependencies found), even if the classes 
> you use are contained in your JDK.
> I attach a project using javax.xml.parsers.DocumentBuilder which is included 
> in Java Class Library (rt.jar) but also in a transitive dependency (xml-apis).
> I think we should not get a warning because the Java Class Library should be 
> the first library found in the classpath, doesn't 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-388) NPE in analyze-report

2012-11-20 Thread Arnaud Heritier (JIRA) 

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

Arnaud Heritier closed MDEP-388.


   Resolution: Duplicate
Fix Version/s: 2.6

This is fixed in the incoming 2.6 release

> NPE in analyze-report
> -
>
> Key: MDEP-388
> URL: https://jira.codehaus.org/browse/MDEP-388
> Project: Maven 2.x Dependency Plugin
>  Issue Type: New Feature
>  Components: analyze
>Affects Versions: 2.5.1
>Reporter: Benson Margulies
> Fix For: 2.6
>
>
> Using Maven 3.0.4, and site plugin 3.2, and an execution of the 
> analyze-report goal, I get the following NPE. I'm going to go try to make 
> some sense and add notes here.
> {noformat}
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.maven.plugin.dependency.AnalyzeReportMojo.executeReport(AnalyzeReportMojo.java:100)
>   at 
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:135)
>   at 
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:228)
>   at 
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319)
>   at 
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135)
>   at 
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
>   at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
>   ... 20 more
> {noformat}

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

[jira] (MCOMPILER-187) incremental stuff detect changes even if nothing has changed means too much compilation

2012-11-20 Thread Olivier Lamy (JIRA) 

[ 
https://jira.codehaus.org/browse/MCOMPILER-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=314045#comment-314045
 ] 

Olivier Lamy commented on MCOMPILER-187:


more details.
If you have plugins generating files in ${project.build.outputDirectory} 
incremental stuff will detect a change and trigger a compilation.
See remote-resources-plugin which generate some files ( 
target/classes/META-INF/LICENSE or target/classes/META-INF/NOTICE) even if 
nothing has changed.

> incremental stuff detect changes even if nothing has changed means too much 
> compilation
> ---
>
> Key: MCOMPILER-187
> URL: https://jira.codehaus.org/browse/MCOMPILER-187
> Project: Maven 2.x Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.0
>Reporter: Olivier Lamy
>Priority: Critical
>


--
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-187) incremental stuff detect changes even if nothing has changed means too much compilation

2012-11-20 Thread Olivier Lamy (JIRA) 

[ 
https://jira.codehaus.org/browse/MCOMPILER-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=314046#comment-314046
 ] 

Olivier Lamy commented on MCOMPILER-187:


IMHO we must check only .class for timestamp changes.

> incremental stuff detect changes even if nothing has changed means too much 
> compilation
> ---
>
> Key: MCOMPILER-187
> URL: https://jira.codehaus.org/browse/MCOMPILER-187
> Project: Maven 2.x Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.0
>Reporter: Olivier Lamy
>Priority: Critical
>


--
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-187) incremental stuff detect changes even if nothing has changed means too much compilation

2012-11-20 Thread Daniel Kulp (JIRA) 

[ 
https://jira.codehaus.org/browse/MCOMPILER-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=314047#comment-314047
 ] 

Daniel Kulp commented on MCOMPILER-187:
---

Agree with the .class only checks.

> incremental stuff detect changes even if nothing has changed means too much 
> compilation
> ---
>
> Key: MCOMPILER-187
> URL: https://jira.codehaus.org/browse/MCOMPILER-187
> Project: Maven 2.x Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.0
>Reporter: Olivier Lamy
>Priority: Critical
>


--
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-187) incremental stuff detect changes even if nothing has changed means too much compilation

2012-11-20 Thread Olivier Lamy (JIRA) 

[ 
https://jira.codehaus.org/browse/MCOMPILER-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=314048#comment-314048
 ] 

Olivier Lamy commented on MCOMPILER-187:


first check only .class files.
Note file extensions to check are configurable (but default list contains only 
.class)

> incremental stuff detect changes even if nothing has changed means too much 
> compilation
> ---
>
> Key: MCOMPILER-187
> URL: https://jira.codehaus.org/browse/MCOMPILER-187
> Project: Maven 2.x Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.0
>Reporter: Olivier Lamy
>Priority: Critical
>


--
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-187) incremental stuff detect changes even if nothing has changed means too much compilation

2012-11-20 Thread Olivier Lamy (JIRA) 

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

Olivier Lamy closed MCOMPILER-187.
--

   Resolution: Fixed
Fix Version/s: 3.1
 Assignee: Olivier Lamy

fixed http://svn.apache.org/r1411914

> incremental stuff detect changes even if nothing has changed means too much 
> compilation
> ---
>
> Key: MCOMPILER-187
> URL: https://jira.codehaus.org/browse/MCOMPILER-187
> Project: Maven 2.x Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.0
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
>Priority: Critical
> Fix For: 3.1
>
>


--
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] (MECLIPSE-736) Generated .classpath files are not compatible with m2e

2012-11-20 Thread Brett Porter (JIRA) 

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

Brett Porter moved MPECLIPSE-138 to MECLIPSE-736:
-

Workflow: Maven New  (was: jira)
 Key: MECLIPSE-736  (was: MPECLIPSE-138)
 Project: Maven 2.x Eclipse Plugin  (was: Maven 1.x Eclipse Plugin)

> Generated .classpath files are not compatible with m2e
> --
>
> Key: MECLIPSE-736
> URL: https://jira.codehaus.org/browse/MECLIPSE-736
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: Bug
>Reporter: Radim Kolar
>Priority: Critical
>
> If you run Eclipse maven plugin m2e included in Eclipse Juno on project files 
> generated by maven eclipse plugin, m2e will complain about Unsupported 
> IClasspathEntry kind=4.
> More information here:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=394042

--
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] (MCHANGES-294) Support REST API for JIRA

2012-11-20 Thread Benson Margulies (JIRA) 

[ 
https://jira.codehaus.org/browse/MCHANGES-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=314058#comment-314058
 ] 

Benson Margulies commented on MCHANGES-294:
---

Rev 1411970 - initial refactoring.


> Support REST API for JIRA
> -
>
> Key: MCHANGES-294
> URL: https://jira.codehaus.org/browse/MCHANGES-294
> Project: Maven 2.x Changes Plugin
>  Issue Type: Bug
>  Components: jira
>Affects Versions: 2.8
>Reporter: Benson Margulies
>
> Ever since 4.2.1, JIRA has supported a REST API. the current trickery of 
> building a URL and expecting an RSS feed isn't supported, and they've since 
> broken it.
> http://docs.atlassian.com/jira/REST/5.1.1/#id343964 
> is the doc we could aim at.
> █▓▒░benson@tinfoilhat░▒▓██▓▒░ Mon Nov 19 07:12:07P 
> ~/x/oapgit/ curl https://issues.apache.org/jira/rest/api/latest/serverInfo
> {"baseUrl":"https://issues.apache.org/jira","version":"5.1.3","versionNumbers":[5,1,3],"buildNumber":782,"buildDate":"2012-08-14T00:00:00.000+","scmInfo":"4389c897ff46ac633147bfa0023fbc37f3cb8ca3","serverTitle":"ASF
>  JIRA"}%  
>
> █▓▒░benson@tinfoilhat░▒▓██▓▒░ Mon Nov 19 07:12:46P 

--
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] (MCHECKSTYLE-183) Checkstyle fails to compile assignment of anonymous class with generics

2012-11-20 Thread Ronald Chen (JIRA) 
Ronald Chen created MCHECKSTYLE-183:
---

 Summary: Checkstyle fails to compile assignment of anonymous class 
with generics
 Key: MCHECKSTYLE-183
 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-183
 Project: Maven 2.x Checkstyle Plugin
  Issue Type: Bug
Affects Versions: 2.9.1
 Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800)
Maven home: /home/rchen/dev/tools/apache-maven-3.0.4
Java version: 1.6.0_26, vendor: Sun Microsystems Inc.
Java home: /home/rchen/dev/tools/jdk1.6.0_26/jre
Default locale: en_CA, platform encoding: UTF-8
OS name: "linux", version: "2.6.36-020636-generic", arch: "amd64", family: 
"unix"

Reporter: Ronald Chen
 Attachments: checkstyles-override-with-generics-fixed.tar.gz

Attached is a repo case where checkstyles fails to compile valid code and hence 
fails.

To run attached code use: mvn checkstyle:check

The checkstyles parser doesn't like code like:
{code}
CheckstylesOverrideWithGenericsBug assigned = new 
CheckstylesOverrideWithGenericsBug() {
  @Overrdie
  public  void doStuff(SRC src) {
  }
};
{code}

The workaround is to remove the generics and use a more specific type.  In the 
attached file I've include two more other cases which don't reproduce the 
problem.

Another problem is checkstyles fails when it fails to parse code.  This is 
horrible.  Checkstyles should skip over files it cannot parse unless you can 
guarantee the checkstyles parser is as good as all other java compilers.

--
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-5356) Make encrypt/decrypt logic pluggable

2012-11-20 Thread Jason van Zyl (JIRA) 

[ 
https://jira.codehaus.org/browse/MNG-5356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=314060#comment-314060
 ] 

Jason van Zyl commented on MNG-5356:


If this is really just a resuable encrypt/decrypt component I would recommend 
separating it from the core.

> Make encrypt/decrypt logic pluggable
> 
>
> Key: MNG-5356
> URL: https://jira.codehaus.org/browse/MNG-5356
> Project: Maven 2 & 3
>  Issue Type: Improvement
> Environment: n/a
>Reporter: Anders Hammar
>Assignee: Anders Hammar
> Fix For: 3.1.0
>
>
> It would be good if Maven Core facilitated the encryption (and decryption) 
> logic to be replaceable. Today's solution is very much hard-coded to the 
> plexus logic.
> This would make it possible for enterprise environments to re-use existing 
> solutions, like for eg smart cards, for this. The default should be the 
> current implementation though.

--
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] (MCHECKSTYLE-183) Checkstyle fails to compile assignment of anonymous class with generics

2012-11-20 Thread Ronald Chen (JIRA) 

[ 
https://jira.codehaus.org/browse/MCHECKSTYLE-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=314059#comment-314059
 ] 

Ronald Chen commented on MCHECKSTYLE-183:
-

I have a typo in the description, it should be @Override instead of @Overrdie.  
It is correct in the attached file.

> Checkstyle fails to compile assignment of anonymous class with generics
> ---
>
> Key: MCHECKSTYLE-183
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-183
> Project: Maven 2.x Checkstyle Plugin
>  Issue Type: Bug
>Affects Versions: 2.9.1
> Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800)
> Maven home: /home/rchen/dev/tools/apache-maven-3.0.4
> Java version: 1.6.0_26, vendor: Sun Microsystems Inc.
> Java home: /home/rchen/dev/tools/jdk1.6.0_26/jre
> Default locale: en_CA, platform encoding: UTF-8
> OS name: "linux", version: "2.6.36-020636-generic", arch: "amd64", family: 
> "unix"
>Reporter: Ronald Chen
> Attachments: checkstyles-override-with-generics-fixed.tar.gz
>
>
> Attached is a repo case where checkstyles fails to compile valid code and 
> hence fails.
> To run attached code use: mvn checkstyle:check
> The checkstyles parser doesn't like code like:
> {code}
> CheckstylesOverrideWithGenericsBug assigned = new 
> CheckstylesOverrideWithGenericsBug() {
>   @Overrdie
>   public  void doStuff(SRC src) {
>   }
> };
> {code}
> The workaround is to remove the generics and use a more specific type.  In 
> the attached file I've include two more other cases which don't reproduce the 
> problem.
> Another problem is checkstyles fails when it fails to parse code.  This is 
> horrible.  Checkstyles should skip over files it cannot parse unless you can 
> guarantee the checkstyles parser is as good as all other java compilers.

--
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-5372) remove classes that were added during Maven 3 alpha and beta but were deprecated before 3.0 final release

2012-11-20 Thread Jason van Zyl (JIRA) 

[ 
https://jira.codehaus.org/browse/MNG-5372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=314061#comment-314061
 ] 

Jason van Zyl commented on MNG-5372:


I reverted this as it breaks Tycho users. They would be forced to change 
versions of Tycho if they upgraded to Maven 3.1.x.

> remove classes that were added during Maven 3 alpha and beta but were 
> deprecated before 3.0 final release
> -
>
> Key: MNG-5372
> URL: https://jira.codehaus.org/browse/MNG-5372
> Project: Maven 2 & 3
>  Issue Type: Task
>Affects Versions: 3.0.4
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
> Fix For: 3.1.0
>
>
> such code should be safe to remove, instead of staying as deprecated

--
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-5372) remove classes that were added during Maven 3 alpha and beta but were deprecated before 3.0 final release

2012-11-20 Thread Jason van Zyl (JIRA) 

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

Jason van Zyl closed MNG-5372.
--

Resolution: Won't Fix

> remove classes that were added during Maven 3 alpha and beta but were 
> deprecated before 3.0 final release
> -
>
> Key: MNG-5372
> URL: https://jira.codehaus.org/browse/MNG-5372
> Project: Maven 2 & 3
>  Issue Type: Task
>Affects Versions: 3.0.4
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
> Fix For: 3.1.0
>
>
> such code should be safe to remove, instead of staying as deprecated

--
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-5261) upgrade wagon version to 2.3 to fix issues with redirect

2012-11-20 Thread Jason van Zyl (JIRA) 

[ 
https://jira.codehaus.org/browse/MNG-5261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=314062#comment-314062
 ] 

Jason van Zyl commented on MNG-5261:


Maven core master has been updated to use Wagon 2.3 from the staging repository 
and all the ITs are passing. This looks like it's good to go.

> upgrade wagon version to 2.3 to fix issues with redirect
> 
>
> Key: MNG-5261
> URL: https://jira.codehaus.org/browse/MNG-5261
> Project: Maven 2 & 3
>  Issue Type: Bug
>  Components: Deployment
>Affects Versions: 3.0.4
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
> Fix For: 3.1.0
>
>
> related to WAGON-369

--
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-5261) upgrade wagon version to 2.3 to fix issues with redirect

2012-11-20 Thread Jason van Zyl (JIRA) 

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

Jason van Zyl updated MNG-5261:
---

Assignee: Jason van Zyl  (was: Olivier Lamy)

> upgrade wagon version to 2.3 to fix issues with redirect
> 
>
> Key: MNG-5261
> URL: https://jira.codehaus.org/browse/MNG-5261
> Project: Maven 2 & 3
>  Issue Type: Bug
>  Components: Deployment
>Affects Versions: 3.0.4
>Reporter: Olivier Lamy
>Assignee: Jason van Zyl
> Fix For: 3.1.0
>
>
> related to WAGON-369

--
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-5353) Ignore pre-releases in exclusive upper bound [lw,up)

2012-11-20 Thread Jason van Zyl (JIRA) 

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

Jason van Zyl updated MNG-5353:
---

Fix Version/s: (was: 3.1.0)
   3.1.1
  Summary: Ignore pre-releases in exclusive upper bound [lw,up)  (was: 
version ranges: Ignore qualifiers in exclusive upper bound [lw,up))

> Ignore pre-releases in exclusive upper bound [lw,up)
> 
>
> Key: MNG-5353
> URL: https://jira.codehaus.org/browse/MNG-5353
> Project: Maven 2 & 3
>  Issue Type: Wish
>  Components: Dependencies
>Affects Versions: 2.0.11, 2.2.1, 3.0.4
>Reporter: Jesse Long
>Assignee: Jason van Zyl
> Fix For: 3.1.1
>
>
> Please change the behaviour of exclusive upper bounds to the following:
> In a version range, like [1.7.0,1.8.0), 1.8.0-alpha1 should not be included 
> in the range. 1.8.0* should not be included in the range.
> This allows for us configure natural ranges for projects using semantic 
> versioning.
> Please see:
> http://markmail.org/message/4tubas4uok6ahbcp
> http://markmail.org/message/s2ry2uru4ibub43q

--
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-5353) Ignore pre-releases in exclusive upper bound [lw,up)

2012-11-20 Thread Jason van Zyl (JIRA) 

[ 
https://jira.codehaus.org/browse/MNG-5353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=314064#comment-314064
 ] 

Jason van Zyl commented on MNG-5353:


This feature appears to be the desire to have a filter which removes 
pre-releases from being selected.

> Ignore pre-releases in exclusive upper bound [lw,up)
> 
>
> Key: MNG-5353
> URL: https://jira.codehaus.org/browse/MNG-5353
> Project: Maven 2 & 3
>  Issue Type: Wish
>  Components: Dependencies
>Affects Versions: 2.0.11, 2.2.1, 3.0.4
>Reporter: Jesse Long
>Assignee: Jason van Zyl
> Fix For: 3.1.1
>
>
> Please change the behaviour of exclusive upper bounds to the following:
> In a version range, like [1.7.0,1.8.0), 1.8.0-alpha1 should not be included 
> in the range. 1.8.0* should not be included in the range.
> This allows for us configure natural ranges for projects using semantic 
> versioning.
> Please see:
> http://markmail.org/message/4tubas4uok6ahbcp
> http://markmail.org/message/s2ry2uru4ibub43q

--
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-5237) Cannot download maven dependencies through NTLM proxy

2012-11-20 Thread kino lucky (JIRA) 

[ 
https://jira.codehaus.org/browse/MNG-5237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=314068#comment-314068
 ] 

kino lucky commented on MNG-5237:
-

I have encountered the same issue. I use the cntlm proxy that should not need 
username and password, because the cntlm has already had the username and 
password.
But after i have set the username and password in the setting.xml of the maven 
too, it works well.

> Cannot download maven dependencies through NTLM proxy
> -
>
> Key: MNG-5237
> URL: https://jira.codehaus.org/browse/MNG-5237
> Project: Maven 2 & 3
>  Issue Type: Bug
>  Components: Dependencies
>Affects Versions: 3.0.4
> Environment: windows xp64 using cygwin
>Reporter: Niels Mordt-Ostergaard
>Assignee: Jason van Zyl
>
> Using proxy in settings.xml, I was able to download maven dependencies in 
> 3.0.3, but this seems to be broken with 3.0.4:
> Proxy definition in settings.xml (hidden ip adress below, but correct proxy 
> ip on my system):
> {code:xml}  
>
>   optional
>   true
>   http
>   
>   
>   xxx.xx.xx.xx
>   8080
>   localhost|127.0.0.1
> 
>   {code}
> Output from 3.0.3:
> {noformat}$ mvn -V clean
> Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
> Maven home: C:\Program Files\apache-maven-3.0.3
> Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
> Java home: C:\Program Files\Java\jdk1.6.0_24\jre
> Default locale: no_NO, platform encoding: Cp1252
> OS name: "windows xp", version: "5.2", arch: "amd64", family: "windows"
> [INFO] Scanning for projects...
> [INFO]
> [INFO] 
> 
> [INFO] Building 
> [INFO] 
> 
> Downloading: 
> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom
> Downloaded: 
> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom
>  (5 KB at 4.9 KB/sec)
> . and so on...
> Output from 3.0.4:
> $ mvn -V clean
> Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
> Maven home: C:\Program Files\apache-maven-3.0.4
> Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
> Java home: C:\Program Files\Java\jdk1.6.0_24\jre
> Default locale: no_NO, platform encoding: Cp1252
> OS name: "windows xp", version: "5.2", arch: "amd64", family: "windows"
> [INFO] Scanning for projects...
> [INFO]
> [INFO] 
> 
> [INFO] Building 
> [INFO] 
> 
> Downloading: 
> http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 0.390s
> [INFO] Finished at: Fri Feb 03 13:14:35 CET 2012
> [INFO] Final Memory: 5M/490M
> [INFO] 
> 
> [ERROR] Plugin org.apache.maven.plugins:maven-clean-plugin:2.4.1 or one of 
> its dependencies could not be resolved: Failed to read artifact descriptor 
> for org.apache.maven.plugins:maven-clean-plugin:jar:2.4.1: Could not transfer 
> artifact org.apache.maven.plugins:maven-clean-plugin:pom:2.4.1 from/to 
> central (http://repo.maven.apache.org/maven2): Access denied to: 
> http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom,
>  ReasonPhrase:Forbidden. -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException
> {noformat}

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

[jira] (MNG-5353) Ignore pre-releases in exclusive upper bound [lw,up)

2012-11-20 Thread Herve Boutemy (JIRA) 

[ 
https://jira.codehaus.org/browse/MNG-5353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=314069#comment-314069
 ] 

Herve Boutemy commented on MNG-5353:


IMHO, not really a filter, since a filter can let "holes" in a mathematical 
range, but here, there won't be holes: just the upper bound that is lower than 
previously

for the purpose of demonstration, I'll not [lw,up( the new notion, to look 
different from [lw,up)
givne the comparisaon algorithm, [lw,up( = [lw,up-alpha-alpha-alpha-alpha-...)
Since nobody creates the alpha of an alpha, [lw,up( is not that far from 
[lw,up-alpha-alpha)

IMHO, if you simply add "-a-a" to upper bound version and let actual range 
calculation algorithm, you have the solution for every real world situation: 
only people knowing the approximation will try with "up-a-a-1" or "up-a-rc-1" 
and show you the problem (or take "-a-a-a" to be even more tricky to get fooled)

> Ignore pre-releases in exclusive upper bound [lw,up)
> 
>
> Key: MNG-5353
> URL: https://jira.codehaus.org/browse/MNG-5353
> Project: Maven 2 & 3
>  Issue Type: Wish
>  Components: Dependencies
>Affects Versions: 2.0.11, 2.2.1, 3.0.4
>Reporter: Jesse Long
>Assignee: Jason van Zyl
> Fix For: 3.1.1
>
>
> Please change the behaviour of exclusive upper bounds to the following:
> In a version range, like [1.7.0,1.8.0), 1.8.0-alpha1 should not be included 
> in the range. 1.8.0* should not be included in the range.
> This allows for us configure natural ranges for projects using semantic 
> versioning.
> Please see:
> http://markmail.org/message/4tubas4uok6ahbcp
> http://markmail.org/message/s2ry2uru4ibub43q

--
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-5353) Ignore pre-releases in exclusive upper bound [lw,up)

2012-11-20 Thread Herve Boutemy (JIRA) 

[ 
https://jira.codehaus.org/browse/MNG-5353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=314069#comment-314069
 ] 

Herve Boutemy edited comment on MNG-5353 at 11/21/12 1:05 AM:
--

IMHO, not really a filter, since a filter can let "holes" in a mathematical 
range, but here, there won't be any holes: just the upper bound that is lower 
than previously

for the purpose of demonstration, I'll note [lw,up( the new notion, to look 
different from [lw,up)
given the comparisaon algorithm, [lw,up( = 
[lw,up-alpha-alpha-alpha-alpha-...infinite...)
Since nobody creates the alpha of an alpha, [lw,up( is not that far from 
[lw,up-alpha-alpha)

IMHO, if you simply add "-a-a" to upper bound version and let actual range 
calculation algorithm, you have the solution for every real world situation: 
only people knowing the approximation will try with "up-a-a-1" or "up-a-rc-1" 
and show you the problem (you can add "-a-a-a" to be even more tricky to get 
fooled)

  was (Author: hboutemy):
IMHO, not really a filter, since a filter can let "holes" in a mathematical 
range, but here, there won't be holes: just the upper bound that is lower than 
previously

for the purpose of demonstration, I'll not [lw,up( the new notion, to look 
different from [lw,up)
givne the comparisaon algorithm, [lw,up( = [lw,up-alpha-alpha-alpha-alpha-...)
Since nobody creates the alpha of an alpha, [lw,up( is not that far from 
[lw,up-alpha-alpha)

IMHO, if you simply add "-a-a" to upper bound version and let actual range 
calculation algorithm, you have the solution for every real world situation: 
only people knowing the approximation will try with "up-a-a-1" or "up-a-rc-1" 
and show you the problem (or take "-a-a-a" to be even more tricky to get fooled)
  
> Ignore pre-releases in exclusive upper bound [lw,up)
> 
>
> Key: MNG-5353
> URL: https://jira.codehaus.org/browse/MNG-5353
> Project: Maven 2 & 3
>  Issue Type: Wish
>  Components: Dependencies
>Affects Versions: 2.0.11, 2.2.1, 3.0.4
>Reporter: Jesse Long
>Assignee: Jason van Zyl
> Fix For: 3.1.1
>
>
> Please change the behaviour of exclusive upper bounds to the following:
> In a version range, like [1.7.0,1.8.0), 1.8.0-alpha1 should not be included 
> in the range. 1.8.0* should not be included in the range.
> This allows for us configure natural ranges for projects using semantic 
> versioning.
> Please see:
> http://markmail.org/message/4tubas4uok6ahbcp
> http://markmail.org/message/s2ry2uru4ibub43q

--
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-5383) Maven will not install snapshots locally if it downloads snapshots from server in same build

2012-11-20 Thread Mike Percy (JIRA) 
Mike Percy created MNG-5383:
---

 Summary: Maven will not install snapshots locally if it downloads 
snapshots from server in same build
 Key: MNG-5383
 URL: https://jira.codehaus.org/browse/MNG-5383
 Project: Maven 2 & 3
  Issue Type: Bug
Affects Versions: 3.0.3
 Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 09:31:09-0800)
Maven home: /usr/share/maven
Java version: 1.6.0_37, vendor: Apple Inc.
Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
Default locale: en_US, platform encoding: MacRoman
OS name: "mac os x", version: "10.7.5", arch: "x86_64", family: "mac"
Reporter: Mike Percy


Seeing this issue in Maven 3.0.3 with Apache Flume 1.4.0-SNAPSHOT.

We have a multi-module project and are pushing SNAPSHOT jars to our repo. We 
had to change some deps and the result is we ran into a situation where Maven 
would only install jars to the local repo (when running mvn install) if the 
SNAPSHOT jars did not need to be downloaded. It sounds strange but I tried 
several times with the same outcome. Details below:

>From https://issues.apache.org/jira/browse/FLUME-1732

To reproduce:

1. Delete all flume jars from your local repo: rm -rf 
~/.m2/repository/org/apache
2. Run install build:
{noformat}
mvn clean install
{noformat}
This build will fail with tests complaining about missing dependencies. Even 
though it says it is installing the locally built modules to the local 
repository, in reality the artifacts are not there. They are whatever was 
downloaded from upstream (several days old). So these lines of output are not 
accurate:

{noformat}
[INFO] --- maven-install-plugin:2.3.1:install (default-install) @ flume-ng-sdk 
---
[INFO] Installing 
/Users/mpercy/src/flume.alt/flume-ng-sdk/target/flume-ng-sdk-1.4.0-SNAPSHOT.jar 
to 
/Users/mpercy/.m2/repository/org/apache/flume/flume-ng-sdk/1.4.0-SNAPSHOT/flume-ng-sdk-1.4.0-SNAPSHOT.jar
[INFO] Installing /Users/mpercy/src/flume.alt/flume-ng-sdk/pom.xml to 
/Users/mpercy/.m2/repository/org/apache/flume/flume-ng-sdk/1.4.0-SNAPSHOT/flume-ng-sdk-1.4.0-SNAPSHOT.pom
{noformat}

because that .pom matches the old one that was downloaded from a few days ago 
(specifically, it does not contain the netty dependency which is in the local 
pom).

Even weirder, if you simply execute the same command again, as in the above 
step, it will go through fine.

3. Run install build:
{noformat}
mvn clean install
{noformat}

Build success!

As one might expect under normal circumstances, now the SNAPSHOT artifacts in 
the local repository are from the local build (the install message was not a 
lie).


--
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